[OpenWrt-Devel] lantiq DSL drivers / firmware info

[Aleksander Wałęski]

On Mon, May 25, 2015 at 4:08 PM, Aleksander Wałęski <olewales at gmail.com> wrote:

>> Maybe you and Aleksander can try this patch again?
>
> Sure, I'll flash my device with this and let it run for some time to
> see if there are any problems.
>
Ok, I tested your latest patch and everything seems to work but I
suggest following build flag changes (which I tested in my build):

add --enable-debug-prints=err to ltq-vdsl-app and change
enable-debug-prints to err in ltq-vdsl-vr9. Default debug level in api
seems to be higher, thats why it caused so much spam in kernel log.
"err" seems to be fine. I didn't notice any messages in dmesg during
normal operation nor any other side effects to this. And it might
provide very useful info if something goes wrong. This is much more
important for vdsl_cpe_control app, and that is the reason why I
started to mess with compilation flags to begin with. with debug
prints disabled it strips all help text in the console which makes
playing with it somewhat frustrating. Here is an example of output of
the same command with debug-prints=off on ltq-vdsl-app:


DSL_CPE#>acos
nReturn=-1 (wrong number of parameters/help not available)


and with debug-prints=err


DSL_CPE#>acos
Long Form: AutobootConfigOptionSet
Short Form: acos

Input Parameter
- DSL_boolean_t bWaitBeforeConfigWrite
   false = 0
   true = 1
- DSL_boolean_t bWaitBeforeLinkActivation
   false = 0
   true = 1
- DSL_boolean_t bWaitBeforeRestart
   false = 0
   true = 1
- DSL_boolean_t bAutoContinueWaitBeforeConfigWrite (dsl_cpe_control)
   false = 0
   true = 1
- DSL_boolean_t bAutoContinueWaitBeforeLinkActivation (dsl_cpe_control)
   false = 0
   true = 1
- DSL_boolean_t bAutoContinueWaitBeforeRestart (dsl_cpe_control)
   false = 0
   true = 1

Output Parameter
- DSL_Error_t nReturn


Additionally, I added --disable-dsl-ceoc to ltq-vdsl-app since CEOC is
disabled in API by default anyway.


Again, can someone with ADSL line test what parameters
vdsl_cpe_control actually needs to operate with newest driver and
firmware version (from W9980)? I accidentally compiled driver with
high debbuging level at one point and got this in kernel log:

========== Port Mode Control (default) ===========
[  438.848000]
[  438.848000] Dual Port Lock      : UNLOCKED
xDSL Mode Lock      : UNLOCKED
[  438.848000]
[  438.848000] Preferred Port Mode : SINGLE
Preferred xDSL Mode : VDSL
[  438.848000]
[  438.848000] Current Port Mode   : NONE
Current xDSL Mode   : NONE
[  438.848000]
[  438.848000]
==================================================
[  438.848000]
========== Port Mode Control (current) ===========
[  438.848000]
[  438.848000] Dual Port Lock      : LOCKED
xDSL Mode Lock      : LOCKED
[  438.848000]
[  438.848000] Preferred Port Mode : SINGLE
Preferred xDSL Mode : VDSL
[  438.848000]
[  438.848000] Current Port Mode   : SINGLE
Current xDSL Mode   : VDSL
[  438.848000]
[  438.848000]
==================================================

This makes me wonder if maybe TP-LINK firmware is just prepared to
support VDSL by default, but needs a startup parameter to support
ADSL. I still don't think it needs "low level config" though. It makes
sense not to require end user to know annex/tone group connection
requires.
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel