[OpenWrt-Devel] lantiq DSL drivers / firmware info
Sylwester Petela
sscapi at gmail.com
Mon May 25 02:52:44 EDT 2015
W dniu 2015-05-25 o 08:00, Aleksander Wałęski pisze:
> Good news! It works.
> Furthermore, I could only get it to work on my line with this new
> driver. I tried old driver with 6 different firmwares (VDSL fw
> versions: 3.2.8, 3.4.A, 4.6.D, 4.7.9, 6.8.4, 7.4.3). Older ones got me
> as far as "full_init [0x380]" but then process was interrupted and
> started all over again. I suspect that DSLAM I am connected to could
> not negotiate parameters it wanted from modem. Newer firmwares on the
> other hand just sit at "idle request [0xFF]". Probably they are not
> compatible with old driver version. This is quite interesting because
> they are reports from people running openwrt Lantiq devices on VDSL2
> lines from my ISP (Orange Polska).
>
> With the new driver and lastest firmware (from W9980) I got showtime
> right away, I didn't even have to touch any configuration. As I
> discovered, that's because this combination of driver/firmware
> (probably mostly firmware) seems to ignore all magic numbers passed by
> dsl_control. It behaves the same regardless of what I provide to
> vdsl_cpe_control as init bits (-i) or low level configuration file
> (-l). -M parameter also seems unnecessary. Firmware either has some
> hard coded values which match my connection, or more likely, it
> performs autodetection of line parameters. This makes sense because
> W9980 is sold worldwide and has to support all configurations
> imaginable. Unfortunately TP-LINK firmware seems to be mostly bunch of
> binaries talking to one another (in this case /lib/libcmm.so seems to
> call dsl_cpe_control) so passive analysis is not easy. Maybe someone
> could try to spy on firmware running on actual device.
>
> This of course should be confirmed by few people (preferably on vastly
> different connections) before sending patch upstream, but if it turns
> out to be true it will greatly simplify xDSL configuration on Lantiq
> devices. My dsl_control script currently looks like this (also on
> pastebin if line wraping messes with it: http://pastebin.com/G0jUQMxL)
>
> ---------------------------------------
>
> #!/bin/sh /etc/rc.common
> # Copyright (C) 2015 OpenWrt.org
>
> # needs to start before the atm layer which starts at 50
> START=48
>
> EXTRA_COMMANDS="status lucistat"
> EXTRA_HELP=" status Get DSL status information
> lucistat Get status information if lua friendly format"
>
> SERVICE_DAEMONIZE=1
> SERVICE_WRITE_PID=1
>
> [ -f /lib/functions/lantiq_dsl.sh ] && . /lib/functions/lantiq_dsl.sh
> XDSL_CTRL=vdsl_cpe_control
>
>
> start() {
>
> config_load network
> config_get firmware dsl firmware
> config_get xfer_mode dsl xfer_mode
>
> [ -z "${xfer_mode}" ] && xfer_mode=ptm
>
> case "${xfer_mode}" in
> atm)
> insmod ltq_atm_vr9
> ;;
> *)
> insmod ltq_ptm_vr9
> ;;
> esac
>
>
>
> [ -z "${firmware}" ] && firmware=/lib/firmware/vdsl.bin
> [ -f "${firmware}" ] || {
> echo failed to find $firmware
> return 1
> }
>
> service_start /sbin/vdsl_cpe_control \
> -i \
> -n /sbin/dsl_notify.sh \
> -f ${firmware} \
> -A /lib/firmware/vdsl.scr
> }
>
> stop() {
> DSL_NOTIFICATION_TYPE="DSL_INTERFACE_STATUS" \
> DSL_INTERFACE_STATUS="DOWN" \
> /sbin/dsl_notify.sh
>
> service_stop /sbin/vdsl_cpe_control
> }
>
> ---------------------------------------
>
> Got rid of most of the things. Whats left:
> 1. Module loading. Tried to just load both modules even if we don't
> use them but then kernel complains about IRQ conflict and crashes
> badly soon afterwards.
> 2. Firmware path. Hardcoding this would not be very elegant but we
> could remove it from network configuration file while reworking
> firmware installation script (it will be necessary eventually)
Getting rid of init script isn't good probably, as original driver in
UGW passes the same commands (mostly) to dsl_control.
Firmware dir is also in original UGW init script, moving it from config
to init doesn't make any difference.
> 3. dsl_notify stuff
> 4. -i command line switch. No "init bits" need to follow but it seems
> that it has to be there.
> 5. VDSL autoboot script (more on that below).
>
> TP-LINK includes vdsl.scr, which according to comment, enables ReTx in
> both directions. I have not noticed any change in my setup after
> enabling this but it think we should include this to maintain
> potentially the same performance.
General init is made by script (Low-level config, etc.) Rest is
calculated from API or by firmware (mostly firmware bits) (see My
earlier problem with ReTx on ADSL) You can see it in this log
http://pastebin.com/ne1aELff
>
>
>
> On the side note. Lantiq modem achieves a bit lower sync rates than
> router provided by my ISP (about 22Mbit / 3.5Mbit vs 25Mbit/4Mbit) but
> I am willing to make this sacrifice for having full control over
> hardware and configuration. I am seriously concerned about performance
> though. I managed to get 130Mbit/s from iperf over wired connection. I
> have yet to check NAT/routing performance but routing between subnets
> on gigabit ethernet I was hoping to do seems to be out of question.
Its switch related, vlan performance is quite low on vrx devices, as for
sync speed, depends what chip sits on DSLAM.
> On Sun, May 24, 2015 at 6:04 PM, Martin Blumenstingl
> <martin.blumenstingl at googlemail.com> wrote:
>>> Waiting impatiently for this new patch. For now I can say that I have
>>> problems with old driver combined with newest TP-LINK dsl firmware on
>>> VDSL line. Once I establish known working configuration I'll build fw
>>> with latest driver and test again.
>> New patch is ready: [0]
>>
>> Let me know if VDSL works with this driver for you.
>> Then we can think of how to get the new version into OpenWrt.
>>
>>
>> [0] https://gist.github.com/xdarklight/2986587133d97892a4b3/download
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
What You have missed is that driver needs to be universal, vrx supports
ADSL as well, annex a/b lines, it can be tuned to have better
performance but not without getting rid of its "universality".
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list