OpenWrt Forum Archive

Topic: 2.6.19 is broken in wrtsl54gs, fix included

The content of this topic has been archived on 31 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

The WAN port (eth1) does not work on wrtsl54gs units using the 2.6.19 kernel. A previous forum post contains the symptoms... http://forum.openwrt.org/viewtopic.php?pid=45934

I dug into it today and confirmed that the 2.4 kernel variant of kamikaze does work on the unit. A little more digging at the b44 driver shows that it believes the eth0 phy address is 30 and the eth1 phy address is 5. The b44_phy_reset fails miserably on address 5. The 2.4 kernel uses address 30 for both eth0 and eth1. If, in the front of b44_phy_reset() you force bp->phy_addr to be 30 then both ethernet devices work.

I'm afraid I don't understand how this works, I was unable to find the datasheets for the underlying devices so all I can do is stab in the dark.

I have a suspicion that the reset is reseting the same phy twice and that the real eth1 phy might be somewhere else entirely but the default configuration happens to work. Or maybe not.

The mechanism for finding the phy address changed between the 2.4 and 2.6.19 kernels, probably leading to this problem.

The following patch works, but may be more invasive, for instance if anyone really does have a phy at 5 this will break them.

*** ./build_mipsel/linux-2.6-brcm47xx/linux-2.6.19.2/drivers/net/b44.c~ 2007-04-27 21:36:05.000000000 -0500
--- ./build_mipsel/linux-2.6-brcm47xx/linux-2.6.19.2/drivers/net/b44.c  2007-04-28 19:32:43.000000000 -0500
***************
*** 296,301 ****
--- 296,306 ----
        u32 val;
        int err;
 
+       /* hackish fix for wrtsl54gs, 5 fails, 30 works for eth1 */
+       if ( bp->phy_addr == 5) {
+           printk(KERN_INFO PFX "%s: Forcing PHY address to 30.\n", bp->dev->name);
+           bp->phy_addr = 30;
+       }
        if (bp->phy_addr == B44_PHY_ADDR_NO_PHY)
                return 0;
        err = b44_writephy(bp, MII_BMCR, BMCR_RESET);

Thanks for the fix Jim, it works great.

Just for the info still same problem with my wrtsl54gs on kamikaze-7.07 with linux-2.6.22

The same hack still works though (I am writing from behind my wrtsl54gs). Quite interesting actually the mix-up between the physical interfaces (even with the hack it resets eth0 twice, but happen to catch eth1 too on the second pass it seems).

Does any one have already compiled this kernel?

skorianez wrote:

Does any one have already compiled this kernel?

Yes, this works well on the kernel 2.6.22 (r8564).

I had installed last kamikaze release, this fix is included? How I can obtain the release of my kernel?

#uname -a 
Linux OpenWrt 2.6.22 #3 Thu Jul 26 18:00:50 CEST 2007 mips unknown

Because my WAN is not working.

(Last edited by skorianez on 13 Sep 2007, 16:46)

I'm using asus wl500w with today's kamikaze and having the same problem. A modified version of the above fix/hack solved it for me

I'm not hardcoding the incorrect phy_addr as it is different in my case.
    if ( bp->phy_addr != 30) {
      printk(KERN_INFO PFX "%s: Forcing PHY address to 30. Before it was %d\n", bp->dev->name, bp->phy_addr);
        bp->phy_addr = 30;

I'm using the network config from.
http://wiki.openwrt.org/OpenWrtDocs/Har … sus/WL500W

Anyone know how to get some sort of a fix for this upstream?

Hi, i have the same problem with kamikaze 7.09 kernel 2.6.22, my router wrtsl54gs doesnt receive its network configuration from the dhcp server. I know Jim a long time ago recommend to add this:

*** ./build_mipsel/linux-2.6-brcm47xx/linux-2.6.19.2/drivers/net/b44.c~ 2007-04-27 21:36:05.000000000 -0500
--- ./build_mipsel/linux-2.6-brcm47xx/linux-2.6.19.2/drivers/net/b44.c  2007-04-28 19:32:43.000000000 -0500
***************
*** 296,301 ****
--- 296,306 ----
        u32 val;
        int err;

+       /* hackish fix for wrtsl54gs, 5 fails, 30 works for eth1 */
+       if ( bp->phy_addr == 5) {
+           printk(KERN_INFO PFX "%s: Forcing PHY address to 30.\n", bp->dev->name);
+           bp->phy_addr = 30;
+       }
        if (bp->phy_addr == B44_PHY_ADDR_NO_PHY)
                return 0;
        err = b44_writephy(bp, MII_BMCR, BMCR_RESET);

Could anyone please explain where do i have to add that? or which is the procedure to fix this problem with my router? please i need your help.

I'm running into the same problem - and wondering why this is still not fixed in the official release after a year? I certainly would appreciate any assistance as I would rather not have to try and setup a cross-complier environment (let alone a VM ware instance for linux) and figure out how to compile this patch.

Thanks!

I'm having this same problem too.  I've got the wrtsl54gs with 2.6.22 - still no fix.  If someone can post a fix to the pre-compiled bin, by tomorrow morning,  I'll personally send them $50 via PayPal.  You have my word on it.  Any takers?  This would really help me out.

Thanks

E

earnoldy wrote:

I'm having this same problem too.  I've got the wrtsl54gs with 2.6.22 - still no fix.  If someone can post a fix to the pre-compiled bin, by tomorrow morning,  I'll personally send them $50 via PayPal.  You have my word on it.  Any takers?  This would really help me out.

Thanks

E

Hi,

Download this patch http://aorlinsk2.free.fr/openwrt/kamika … oken.patch
and save it in target/linux/brcm47xx-2.6/patches-2.6.22

Just recompile everything and you're done. This worked for me with r8564.

Hopefully it will work on latest trunk. Try to put it in trunk/target/linux/brcm47xx/patches-2.6.25


Anael

(Last edited by aorlinsk on 20 May 2008, 14:50)

With what I could find in the installation docs and the wiki, I tried my best to compile kamikaze in a VM running Fedora 8. The first time, the make script kept doing an infinite loop saying it could not find some file. After installing Fedora 9, I got it to compile, but when I tried to upgrade the firmware from the bin file that is in bin directory but, mtd says it has an invalid TRX header. I did make menuconfig to to set the device parameters so I don't know why it thinks it is invalid.

So I thought maybe these are not images in there, so I tried to find some information on the what the buildimage tool is and what buildroot-ng is. The instructions for getting the source from SVN does not really say; I'm guessing the whole make menuconfig, make thing is the buildroot-ng?

Also, it looked like some fix was applied for B44 in SVN, I can't find again how I got there to read that, but it was a recent change. It's not the code that is in this post, but it was something related to the PHY enumeration I think. I'm unsure if this is a similar fix for this problem or not.

I admit I am new here and to kamikaze, but not new to whiterussian. The information seems to be spread out all over the place which is a bit frustrating. And even if it was easy to find, I don't always know what I am looking for. If anyone would kindly point me in the right direction I would appreciate it. I'm trying to get the 2.6 kernel because I want to compile http://www.usb-server.com for it.

Thanks.

Hi,

Download this patch http://aorlinsk2.free.fr/openwrt/kamika … oken.patch
and save it in target/linux/brcm47xx-2.6/patches-2.6.22 <--PLEASE TELL ME WHERE IS THAT FOLDER? I MEAN I HAVE NEVER COMPILED THE KERNEL AND I DONT KNOW WHERE IS THAT FOLDER THAT YOU MENTION...where i can get the sources of kamikaze 7.09 for wrtsl54gs? i need that code to put the patch you say in this folder target/linux/brcm47xx-2.6/patches-2.6.22 or where is that folder??

Just recompile everything and you're done. This worked for me with r8564. <--WHAT is r8564?? if i have wrtsl54gs..that's r8564??

Hopefully it will work on latest trunk. Try to put it in trunk/target/linux/brcm47xx/patches-2.6.25 <--again...where is that folder?? im sorry to bother you too much. thanks a lot for the help that you could give me.



HI, I ALREADY did what say in this page: http://downloads.openwrt.org/kamikaze/docs/openwrt.html about how to compile kamikaze..i did it and download from https://svn.openwrt.org/openwrt/trunk kamikaze like the page says, and there wasnt errors...but when i go to the bin folder that was generated after i run make, there isnt any kamikaze with kernel 2.6....DID i make something wrong?? i go into the router and when i run uname -r, it returns: 2.4.35.4 ...and i was expecting that says something like 2.6.22...what i did wrong?? i followed the steps of that page...i just did make menuconfig i chose the packages i want and included in target/linux/brcm47xx/patches-2.6.25 the code from: http://aorlinsk2.free.fr/openwrt/kamika … oken.patch but tthe kamikaze that i got doesnt have kernel 2.6, what step i missed?? please help me, i need help.

(Last edited by gracey_26 on 22 May 2008, 09:46)

Gracey, I found it really hard to read your post and figure out what part you were saying and what part you were quoting. Like most forums, I think you can use quote tags here (http://forum.openwrt.org/help.php#bbcode) to make things easier to read. Anyhow, I am in the same boat as you, but thought I'd share my experience.

First, I decided to use the tarball for 7.09 (http://downloads.openwrt.org/kamikaze/7 … 09.tar.bz2) located on the downloads page. I extracted the source from that instead of SVN, because I have no idea how stable the SVN code is as it is the latest and greatest. I can't figure out with SVN how to find labels or snapshots of the trunk that was the 7.09 release, so I went with the tarball.

As far as the patch, I have not tried it yet because I can't get the firmware to load due to the invalid TRX header. However, I noticed that the kernel source and modules, etc. are not actually downloaded with SVN or in the tarball. The "buildroot-ng?" script downloads these during the build. So only after you make the first time, will the stuff in target appear. So build once, then copy the patch over, and build again.

Also, r8564 is a release from SVN. As I said, I can't figure out how SVN uses tags so I just went with the 7.09 tarball which is an earlier release but I assume.stable.

Lastly, make sure you run make menuconfig and set the options for the WRTSL54GS and choose the brcm47xx-2.6 for the 2.6 kernel otherwise it probably will only build the 2.4 kernel.

This is probably the blind leading the blind here as I followed the docs as you did but there seems to be a lot of information missing and its spread out everywhere. Unfortunately, it seems unless you are a long time member in this community, no one is eager to help you.

Hope what I have found out helps.

hi TenaciousWRT i will follow your advice with the quotes the next time smile. on the other hand..now i share with you my experience..just compile kamikaze with this patch http://aorlinsk2.free.fr/openwrt/kamika … oken.patch, i followed this steps:
1. $ svn co https://svn.openwrt.org/openwrt/trunk kamikaze
2. $svn co https://svn.openwrt.org/openwrt/packages packages
3. ln -s packages/*/* kamikaze/package/
4. put patch in /target/linux/brcm47xx/patches-2.6.25 and in /target/linux/brcm47xx/patches-2.6.23 (i dont know if the patch goes in both folders but i put it, and what i changed were this 2 first lines from that patch: --- linux-2.6.22.4/drivers/net/b44.c    2007-09-04 01:24:58.000000000 +0200
+++ linux-2.6.22.4.patch/drivers/net/b44.c    2007-09-04 01:35:12.000000000 +0200 and just replaced the 2.6.22.4 with 2.6.25 and 2.6.23     respectively)
5. the make menu config <--and i chose what i need and the kernel 2.6, the first i compiled i didnt choose the kernel 2.6.
6. make
and the with tftp i put the new firmware that generated after the compilation that i found in the bin folder for wrtsl54gs...but didnt work and i tried and tried with different combinations..didnt change the 2 first lines of the patch, change, without the patch..but anyway it never worked, so i stop trying and i hope that someone find the solution for this, but the patch doesnt work with linksys wrtsl54gs ..at least i had missed some step..if anyone have a solution for wan interfase can work with kamikaze kernel 2.6 and wrtsl54gs please let me know.

This still seems to be a problem under 2.6.25.9, any one know if the patch still works

[edit]

I have made some modifications to the patch (cosmetic) to work with 2.6.25

--- a/drivers/net/b44.c 2008-06-29 23:11:42.000000000 +1000
+++ b/drivers/net/b44.c 2008-06-29 23:11:12.000000000 +1000
@@ -324,6 +324,12 @@
        u32 val;
        int err;

+       /* hackish fix for wrtsl54gs, 5 fails, 30 works for eth1 */
+       if ( bp->phy_addr == 5) {
+               printk(KERN_INFO PFX "%s: Forcing PHY address to 30.\n", bp->dev->name);
+               bp->phy_addr = 30;
+       }
+       
        if (bp->phy_addr == B44_PHY_ADDR_NO_PHY)
                return 0;
        err = b44_writephy(bp, MII_BMCR, BMCR_RESET);

edit: on the asus 500w  its 4 not 5

(Last edited by alexsamad on 30 Jun 2008, 09:04)

Just an update, I followed alexsamad's patch on OpenWrt 2.6.25.12 from SVN and it worked great.  I actually changed the code in ~/build_dir/linux-brcm47xx/linux-2.6.25.12/drivers/net/b44.c  since I couldn't get the patch to work for me.

And a second question, is wireless working on the 2.6 kernel for the WRTSL54GS?  I see a wlan0 interface that can successfully scan.  I'll try experimenting and find out, but an answer from somebody "in the know" would be helpful as well.

I don't have a build environment I can use to compile the kernel. Is there anyway somebody can mail me or post the fixed kernel?
Thanks,
Scott

Thanks for the file... I'll attempt to install it at some point.

You are right about trusting binaries, especially kernels! I'm hoping that the patch makes it into the next release and I can use that. I'm going to work on getting set up with a dev environment (I'm most likely going to need to compile openswan and others). Question, I have a mac x86 laptop. How do I set up a mips dev environment on it? Will VMWare do mips?

Thanks,
Scott

anyone knows if this patch fixes ticket #1212

Fixed in rev > 12829

at least not fixed for my router and those wl-500g routers I think.
so ticket 1212 is still open.
any progress on this defect? or if I can help to test?

The discussion might have continued from here.