it seems that there is still a problem with the switch. so I'm a litte bit confused about the things he said: "its working with that build. so i will not care about it forever".
did that mean we have to stuck with 18007 or a broken switch?
maybe someone have a clue - how we can bring to switch to work?
it seems that there is still a problem with the switch. so I'm a litte bit confused about the things he said: "its working with that build. so i will not care about it forever".
did that mean we have to stuck with 18007 or a broken switch?
Someone should do a log of the boot up sequence, preferably with via a serial terminal connection, for the latest build and for the latest working build.
The comment that he doesn't care about it since it works for him tells me that you will need to find the problem yourself and then convince him that he is wrong.
You will need strong evidence..
There are a bunch of 600b and 300b users reporting this problem so I don't doubt that the problem is real. _________________ Kernel panic: Aiee, killing interrupt handler!
it seems that there is still a problem with the switch. so I'm a litte bit confused about the things he said: "its working with that build. so i will not care about it forever".
did that mean we have to stuck with 18007 or a broken switch?
hopefully not
I reopened the ticket..
Reopening the ticket without supplying any additional information for Brainslayer to go on is not very constructive.
It is a developers nightmare when it "works for me" but not for others and then not getting any hints of where the problem could be. _________________ Kernel panic: Aiee, killing interrupt handler!
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Wed Mar 14, 2012 20:45 Post subject:
okay. different approach. could someone setup such a device as wifi client and provide me remote login with ssh. so i can review it from the console. a computer should be connected on the lan port (or another ethernet device). so i can check the switch functions. just contact me with email with the connection details and i will do my best to get this resolved _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
There is the same switch issue on DIR-300/600 Bx and DIR-615 Dx.
With a DIR-615 D1 I noticed that WAN port is fully operative when LAN switch doesn't work. So you can reassign the WAN port to LAN port and you can do a downgrade to a working LAN switch firmware version.
I don't know if it helps.
@ Pondera
the DIR-300b / DIR-600b have an EASY Recovery Function build into the Ralink Chip itself.
1. power off Device, connect network to LAN-1
2. press & hold Reset Button while plug in the power
3. hold the Reset still for some seconds and then relase it
4. the power LED is blinking orange and you can connect to 192.168.0.1 to upgrade the firmware
cheers _________________ Reality has always been too small for human imagination...
Probably problem in initialization switch for Ralink.
Set build 18007 or more low where works
http://192.168.1.1/Diagnostics.asp
1. To adjust wi-fi and LAN
2. WEB
Command Shell -> Commands
switch reg r 90 > /tmp/var/tmp/switch_LAN
3. Save StartUP -> reboot
4. To be connected to the device
5. cat /tmp/var/tmp/switch_LAN
Update through WEB - build 18687
1. To be connected to the device wi-fi(telnet)
2. cat /tmp/var/tmp/switch_LAN
Should be 00007f7f or 10007f7f
Or as to check up through mii_mrg value of adjustments of ports LAN:
mii_mgr -g -p [REG] -r 0
I think we're on something here. There is a difference. Can I do something to "make it work" by hand? May be write r90 with 7f7f? or is this just too simple to work?
Update: looking at the data sheet of RT3050 it shows that all the 5 phy ports are disabled. Enabling the phy ports should be done at the initialization of the processor so I don't think it would be enough to write the register with the correct value.
BrainSlayer please can you check the initialization of the RT3052 for the ESR-9752SC kernel and possibily also the ones mentioned above? I think this may be the issue.
Update2: I've compared the raeth initialization code in the revision 18740 sources in rt305x_esw_init() and the content of the registers after the boot and I've found they are quite different:
*(unsigned long *)(0xb0110008) = 0xC8A07850;
*(unsigned long *)(0xb01100E4) = 0x00000000;
*(unsigned long *)(0xb0110014) = 0x00405555;
*(unsigned long *)(0xb0110050) = 0x00002001;
*(unsigned long *)(0xb0110090) = 0x00007f7f;
*(unsigned long *)(0xb0110098) = 0x00007f3f; //disable VLAN
*(unsigned long *)(0xb01100CC) = 0x0002500c;
*(unsigned long *)(0xb011009C) = 0x0008a301; //hashing algorithm=XOR48, aging interval=300sec
*(unsigned long *)(0xb011008C) = 0x02404040;
and the running router:
root@Senao:~# switch reg r 8
switch reg read offset=8, value=ffc86e5a
root@Senao:~# switch reg r e4
switch reg read offset=e4, value=3f
root@Senao:~# switch reg r 14
switch reg read offset=14, value=405555
root@Senao:~# switch reg r 50
switch reg read offset=50, value=2001
root@Senao:~# switch reg r 90
switch reg read offset=90, value=3f807f7f
root@Senao:~# switch reg r 98
switch reg read offset=98, value=7f3f
root@Senao:~# switch reg r cc
switch reg read offset=cc, value=a30c
root@Senao:~# switch reg r 9c
switch reg read offset=9c, value=8a101
root@Senao:~# switch reg r 8c
switch reg read offset=8c, value=27f7f7f
Same (old) issue on senao 9752.
Build 16214 that works shows:
root@Senao:~# switch reg r 90
switch reg read offset=90, value=7f7f
Build 18740 that does NOT work shows:
root@Senao:~# switch reg r 90
switch reg read offset=90, value=3f807f7f
Command Shell -> Commands
switch reg w 90 00007f7f
or
switch reg w 90 10007f7f
Also will work.
Initialization switch depends from uboot devices in which there are given commands to bring in the register the given values.
On native uboot Ralink all should be normal.
Same (old) issue on senao 9752.
Build 16214 that works shows:
root@Senao:~# switch reg r 90
switch reg read offset=90, value=7f7f
Build 18740 that does NOT work shows:
root@Senao:~# switch reg r 90
switch reg read offset=90, value=3f807f7f
Command Shell -> Commands
switch reg w 90 00007f7f
or
switch reg w 90 10007f7f
Also will work.
Initialization switch depends from uboot devices in which there are given commands to bring in the register the given values.
On native uboot Ralink all should be normal.
No it doesn't work. I tried, TBH without much hope, your suggestion but whatever screwed the register 90 also screwed something else and as I was supposing, just writing the right value to the register doesn't work.
Uboot is just the boot block/code. It's the kernel that initializes the chip to start ethernet operations properly. Unfortunately I've been far from kernel development for too long and now it's too hard with the few spare time that I have to dig deeper into this issue: it took more than one hour to find the raether.c and the 305x initialization. Looking at the kernel sources the initialization seems to be OK, or at least, by diffing with working 16214, it has not been changed for very long time, but for some reason during, or after, the kernel boot something changes the registers after their initialization.
BrainSlayer, we need your help ... please.
If needed I'm available for whatever investigation I can do in my system.
In the beginning we have uboot and only then a kernel dd-wrt.
Quote:
uboot
*(unsigned long *)(0xb0110050) = 0x00002001;
*(unsigned long *)(0xb0110090) = 0x00007f7f;
*(unsigned long *)(0xb0110098) = 0x00007f3f; //disable VLAN
*(unsigned long *)(0xb01100CC) = 0x0002500c;
*(unsigned long *)(0xb011009C) = 0x0008a301; //hashing algorithm=XOR48, aging interval=300sec
*(unsigned long *)(0xb011008C) = 0x02404040;
But it is the data from native SDK Ralink, and that there actually in uboot the given device the manufacturer of the device knows only.
After working off uboot then control it will be transferred in a kernel dd-wrt. And here we matter:
Quote:
root@Senao:~# switch reg r 90
switch reg read offset=90, value=3f807f7f
Has checked up operation here such script on the worker ralink 305x:
Code:
#!/bin/sh
switch reg r 90 > sw_1
sleep 2
switch reg w 90 3f807f7f
sleep 2
switch reg r 90 > sw_2
sleep 10
switch reg w 90 00007f7f
sleep 2
switch reg r 90 > sw_3
After 3f807f7f die away LAN ports (disable), but after 00007f7f start to work (enable).
Just values 3f8 speak: