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:
Exactly as you said it should work. But, at least in my case, when I try to set reg r 90 to 7f7f actually enabling the interfaces, nothing happens.
I have also tried to re-set all the registers to the ralink SDK values but still the ethernet interfaces are not working. This probably means that even if the hardware is properly configured, after kernel boot with hardware not properly configured the kernel does not handle the ethernet anymore even if I re-configure the registers to the proper values.
I have just reloaded the old 16214 that works and checked all the registers and they ALL are compliant with the ralink SDK, and in fact the switch is working. This means in the 18740 there is something that make the switch non operative.
Using "strings" I've checked if the sysinit code in services.so contains the correct switch reg w for esr9752 and in fact it contains:
switch reg w 14 405555
switch reg w 50 2001
switch reg w 98 7f3f
switch reg w e4 3f
switch reg w 40 1002
switch reg w 44 1001
switch reg w 48 1001
switch reg w 70 ffff417e
switch reg w 50 7001
switch reg w 98 7f2f
switch reg w e4 2f
switch reg w 40 1007
and considering the compiler optimizations on repeated strings, all the switch writes are present as per HAVE_ESR9752 define. There's no reason to think that the writes are not performed at sys initialization.
In fact I have checked the content of those registers and actually they correctly contain the values written by sysinit.
Hmmm and there is a bug in the /proc filesystem: the entry rt3052 is repeated two times. If some code is meant to reach config files into the /proc/rt3052/ it will never be able to reach them. Note that for the DIR600 in sysinit-rt2880.c there's a bunch of writes in there. Lines like this:
Don't know if there is some initialization also for the other rt3052 architectures, but sure with that double entry on esr9752 nothing can reach the mii/ctrl. In fact if I cd into that directory it is void.
Anyway: the fact that /proc/rt3052/ has been registered two times is a sure bug.
Using "strings" I've checked if the sysinit code in services.so contains the correct switch reg w for esr9752 and in fact it contains:
switch reg w 14 405555
switch reg w 50 2001
switch reg w 98 7f3f
switch reg w e4 3f
switch reg w 40 1002
switch reg w 44 1001
switch reg w 48 1001
switch reg w 70 ffff417e
switch reg w 50 7001
switch reg w 98 7f2f
switch reg w e4 2f
switch reg w 40 1007
and considering the compiler optimizations on repeated strings, all the switch writes are present as per HAVE_ESR9752 define. There's no reason to think that the writes are not performed at sys initialization.
In fact I have checked the content of those registers and actually they correctly contain the values written by sysinit.
Hmmm and there is a bug in the /proc filesystem: the entry rt3052 is repeated two times. If some code is meant to reach config files into the /proc/rt3052/ it will never be able to reach them. Note that for the DIR600 in sysinit-rt2880.c there's a bunch of writes in there. Lines like this:
Don't know if there is some initialization also for the other rt3052 architectures, but sure with that double entry on esr9752 nothing can reach the mii/ctrl. In fact if I cd into that directory it is void.
Anyway: the fact that /proc/rt3052/ has been registered two times is a sure bug.
Don't pay to this attention, all works and with:
Code:
root@My-Fan:~# cd /proc/
root@My-Fan:/proc# ls -l
...
-r--r--r-- 1 root root 0 Mar 18 07:37 partitions
dr-xr-xr-x 2 root root 0 Mar 18 07:37 rt3052
dr-xr-xr-x 2 root root 0 Mar 18 07:37 rt3052
dr-xr-xr-x 4 root root 0 Mar 18 07:37 scsi
...
root@My-Fan:/proc# cd rt3052
root@My-Fan:/proc/rt3052# ls
root@My-Fan:/proc/rt3052# cd ..
root@My-Fan:/proc# cat cpuinfo
system type : Ralink RT3052 id:1 rev:3
processor : 0
cpu model : MIPS 24Kc V4.12
BogoMIPS : 255.59
CPUClock : 384
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, 0x0ff8, 0x0ff8, 0x0ff8]
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
root@My-Fan:/proc#
Yes but the /proc filesystem looks like if rt3052_access_init() has been called two times and this should be fixed, if not because it's a bug, just for the cosmetics of the code.
Btw the access is called only in ra2882eth_init() but this is the hardware initialization. The problem there is that the driver printk() only 1 initialization string at boot time so the raeth function is called 1 time only. Who's responsible for the second call to rt3052_access_init()?
To you it was not thought and not to guess.
It is checked up. There is a router on a chip rt3052 and the loader uboot, in which disable all ports switch (a command f807f7f). Further we take dd-wrt SVN version 18740 in advance in Startup a command on reading and we look. Value of the given register instead of normal value 00007f7f we have f807f7f with ports disable here to you and the answer.
The command in stratup-00007f7f helps only
Last edited by vasek00 on Sun Mar 18, 2012 14:12; edited 1 time in total
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Sun Mar 18, 2012 14:08 Post subject:
its not access_init. the wireless driver itself caused the collision. i fixed that now _________________ "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
To you it was not thought and not to guess.
It is checked up. There is a router on a chip rt3052 and the loader uboot, in which disable all ports switch (a command f807f7f). Further we take dd-wrt SVN version 18740 in advance in Startup a command on reading and we look. Value of the given register instead of normal value 00007f7f we have f807f7f with ports disable here to you and the answer.
The command in stratup-00007f7f helps only
I may not be a guru of dd-wrt, but I'm quite confident with linux sources and startup processes. When I guess something I usually guess right and if I say something means I thought long enough.
Reading the sources sometimes is not enough, don't you know?
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Sun Mar 18, 2012 14:41 Post subject:
Ric03 wrote:
BrainSlayer wrote:
here the test build
BS, if you make a build for the esr-9752 I'll test it right away
the esr9752 does not use the /proc/rt3052 dir. so it can't be affected _________________ "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
