OpenWrt Forum Archive

Topic: WRT54G v2.2 / WRT54GS v1.1

The content of this topic has been archived between 6 Apr 2018 and 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

This thread is old; please stop linking to it.

OpenWrt's experimental release  now supports wrt54g v1.0 - v3.0 and wrt54gs v1.0-v2.0.

Yes. It's what I got. A WRT54GS v1.1. (It's not 54G nor 54GS) The label on the under side states that its a 54GS v1.1. And when I tried to tftp the openwrt-gs-code.bin firmware up to it, it says

Error code 4: Cann't downgrade to this old firmware version (2)

Can you help? Thank you.

TH

PS. I tried the whole thing with my old WRT54GS (without the v1.1) and everything is fine. Also the source is checked out fresh from cvs today.

We already know.

The WRT54GS was designed based on the WRT54G v2.0, now with WRT54G v2.2 we have a new WRT54GS v1.1. The key change appears to be a different ethernet switch, controlled by the ethernet (et) driver; with the change comes a new compatibility check, a new byte in the bin header created by addpattern.

I don't have a WRT54G v2.2 or WRT54GS v1.1 to test with, but if you understand the above you may be able to easily hack the existing openwrt sources; otherwise wait for us to finish with some updates to bring openwrt up to date with the recent firmware releases. (If anyone wants to donate hardware, email me and we'll set something up)

I just bought a new 54g 2.2 so I could use it to expiriment with OpenWRT.  I noted that on LinkSys's webpage they state that with the WRTG2.2 you cannot use earlier versions of the firmware.

So just before I downloaded my build of linksys's 3.1.3 source, I double checked the firmware that came with the 2.2 router.  and well the numbers are actually different.  It seems that the preloaded firmware on the 2.2 router shows version 3.3.1 , yet the current release of source and binary both show 3.1.3.   The 3.3.1 is showing a date in sept 04.

Umm..   Anybody else notice this?  Do I have to wait for linksys to release 3.3.1 ?  Is it a typo????

I've got a 2.2 version now too (had a whole lot of 2.0's previously) and my firmware revision reports Firmware Version: v3.03.1   

Can't flash with openwrt, so I'm assuming they might have changed something.

I recently received a V2.2 WRT54G and decided to dig around inside it a bit.

There are a number of differences between the V2.0 and V2.2 hardware. The following is a (non-exhaustive) list of differences I've been able to spot.

The v2.2 unit I have doesn't seem to use the ADMTek switch controller. It has a chip labeled BCM5325EKQM, manufactured by Broadcom instead of the ADMtek controller.

A single ram chip is now where the normal V2.0 units' dual ram chips used to sit, labeled "Hynix 432A", so I'm guessing it's a 32Mb chip. (V2.0 units had 2 ram chips afaik)

CPU is the usual BCM4712 (LKFB) but in an extremely TINY form factor. It's almost half the size of the V2.0 CPU. (The original V2 hardware I have uses the BCM4712KPB)

The flash chip looks pretty much like the same standard Intel Flash as the V2.0's have, though I can't be sure of the size.

The pin headers seem basically unchanged, except that they've moved around on the board and both headers are now next to each other.

There's two extra coils and two extra capacitors, presumably due to changes required to power the new BCM switch chip.

The WAN Ethernet, and Radio seem unchanged, except that the track layout is slightly different.

My digital camer is pretty poor, but I'll try to get some pictures up soon.

So, what do you think the verdict is? Should I try and tftp flash it? I'm pretty sure the switch will die, which is fine for my purposes as I only need a single workable ethernet.

Have they released the GPL code for 3.03.1 (which is what the firmware's web interface reports) yet?

I've consolidated a few threads on the topic; please see earlier responses.

Well what can I say.  I explicitely bought this yesterday for the sole reason of loading software to it for testing with my other 2.0 router.  Who'd a thunk in less than a month all the "advantage" of GPL would be put on hold as they go through a nother reconfig.

Interesting that the linksys support page points me to the 3.1.3 firmware for this router.  Guess I'll try that and see if it will accept it.

Maybe thats where its all going?

Shawn

Before I do try loading the 3.1.3 firmware, is there a way to extract the 3.3.1 firmware off?  I saw someone ask that question earlier with no answer.

I've retrieved a WRT54GV2_3.01.3_US_code.bin from their site and am comparing the headers with the 2.x headers.

MBM, how did you spot the header change? Binary compares? Or just hexediting? I'm digging through addpattern.c now, to see what the structure of the regular header is.

Have also just completed grabbing the GPL tarball for 3.01.3. Will let you know of my findings. Any suggestions for getting boot_wait set before I brick my router? ping.asp exploit seems to be fixed, unfortunately.

The newest source release from linksys is 3.37.2 (all releases are backwards compatible with older hardware).

The addpattern utility takes a trx file and produces a bin; the difference was spotted by running the same trx through different versions of addpattern and looking at the difference in a hex editor. (It can also be found by reading the checks in the firmware update code of the linksys webserver)

So, the 3.37.2 code should run on the WRT54G and WRT54GS?

Pardon my ignorance (i'm a reasonable kernel developer and have written device drivers, etc), but am new to OpenWRT.

Addpattern adds the W54G/W54S/U2ND header to the start of a .trx file correct? This is only required on the WRT's, and not the WAPs/other devices?

Interestingly, WRT54G_3_01_3_0922/release/tools/src/code_header.c seems to be the BCM defition of of addpattern's work.

And, I think, the crux of it is this final bit...

init_code_header(void)                                                                             
{                         
.
.
.

                                                                                              
        pattern->flags |= SUPPORT_4712_CHIP;                                                       
        pattern->flags |= SUPPORT_INTEL_FLASH;                                                     
        pattern->flags |= SUPPORT_5325E_SWITCH;   

So, it would appear that the additional byte in the header simply stores the hardware capabilities. The 5325E switch being the most important.

OK, using the mjn3's addpattern from openwrt snapshot, and the addpattern distributed with the Linksys GPL 3.03.1 release, I spot only a byte that's different. Not an additional byte?

the linksys addpattern produces:

00000000: 57 35 34 47  00 00 00 00  05 01 07 03  01 03 55 32  4E 44 00 00      W54G    ......U2ND
00000014: 07 00 00 00  00 00 00 00  00 00 00 00  48 44 52 30  00 D0 18 00      .           HDR0 Ð.

And mj3's original adpattern produces

00000000: 57 35 34 53  00 00 00 00  05 01 07 03  01 03 55 32  4E 44 00 00      W54S    ......U2ND
00000014: 00 00 00 00  00 00 00 00  00 00 00 00  48 44 52 30  00 D0 18 00                  HDR0 Ð.

Only difference being the byte at offset 0x14 (0x00 versus 0x07).

mbm, does this agree with what you've seen, or have you spotted an ADDITIONAL byte?

The byte at offset 0x03 is different; 0x53 vs 0x47.

Yeah, that's just the W54G/W54S difference. mjn3's addpattern only does the GS header, which is why the current openwrt buildprocess uses SED to hack it to produce both a openwrt-g-code.bin and openwrt-gs-code.bin

I've adpatterned an openwrt-linux.trx using the addpattern utility that comes with the 3.x build system and the router now accepts the flash via HTTP, or tftp.

Only problem is that it appears the switch is dead (which is to be expected) and the router is unhappy with the image. Sits and blinks power/dmz constantly. I recovered with the pin 15/16 shorting trick, and re-tftping with the original linksys firmware brings it back to life.

Sigh. My kingdom for a serial port.

Oh.. interesting. I have a WRT54GS v1.1. I can post pictures of the board if anyone wants to see. I have also plans for a serial port mod on my GS.

I downloaded 3.1.3 linksys firmware fine, as well as one i've made adjustments to.  Router works great.  Can't figure out any differences in the firmware either.

The only difference is that the byte at offset 0x14 in the header needs to be 0x07. I've managed to get openwrt booting with a Linksys kernel, and modules, but  an openwrt file system.

The only difference is that the byte at offset 0x14 in the header needs to be 0x07. I've managed to get openwrt booting with a Linksys kernel, and modules, but  an openwrt file system.

That's excellent, unfortunatly I just returned the unit yesterday due to it not working with OpenWRT.  Oh well, they placed the same unit back on the shelves, guess it's time to buy it back.

Before I do that though, I was wondering if there was anyway you could either post a bin that's corrected, or preferably write a how-to for the idiots, (like me) on how to change the header in the CVS snapshots, so that anyone could modify the needed byte to create a bin for the v2.2 WRT's?  Or maybe a perl script?

Also, when you say you got it "booting" does this mean it accepts the new firmware, (OpenWRT) and all functionality is the same even though the chipset is different for the internal switch and I belive also the radio has a different chipset; or does it mean that it's simply booting, but not all functionality is normal?

MUCH MUCH TIA,
Knight.

I've completed a proper openwrt build, with the new Ethernet/Switch driver, and new wifi driver and the most salient mtd changes applied to the stock openwrt (2.07) tree.

http://rodent.za.net/files/openwrt/

It boots, wifi works, switch works and so far things look ok.

I have succesfully flashed a V2.2 WRT54G with this.

However take note that this release is obviously untested, and that you could probably brick your router, so be sure to turn on the boot_wait nvram setting by following the instructions in the Userguide to enable boot_wait.

I cannot take responsibility for you bricking your router with this. I also haven't tried this build on the V2.0 hardware yet. The firmware revision reads v3.01.3 in the bin headers, that's simply because I used an older version of the addpattern header utility and is of no consequence.

Cliff notes:
-V2.2 openwrt based on openwrt buildtree of Jan 5.
-simple grab of Linksys drivers from the 3.37.2 tree
-switch, ether, flash code and some supporting code was changed
-untested, flash at your own risk.
-supposedly compatible with v2.0 hardware, but untested.

Before I do that though, I was wondering if there was anyway you could either post a bin that's corrected, or preferably write a how-to for the idiots, (like me) on how to change the header in the CVS snapshots, so that anyone could modify the needed byte to create a bin for the v2.2 WRT's?  Or maybe a perl script?

Unfortunately, there's some changes to the mtd (flash) that makes a stock openwrt snapshot refuse to boot cleanly, so just changing the bytes of a normal snapshot doesn't work.

Also, when you say you got it "booting" does this mean it accepts the new firmware, (OpenWRT) and all functionality is the same even though the chipset is different for the internal switch and I belive also the radio has a different chipset; or does it mean that it's simply booting, but not all functionality is normal?

The radio is the same, aside from the amplifier on it (according to the sveasoft forums) thus the new radios are rated to 34dBm (or some such). The new snapshot I've created works fine with the rest of my v2.0 WRT's and the switch appears to work fine.

I tried TheRoDent's firmware on my GS1.1 but failed. The tftp is successful, but after that the power led keeps flashing.

I tried TheRoDent's firmware on my GS1.1 but failed. The tftp is successful, but after that the power led keeps flashing.

Which hardware version are you using?  v2.0, or v2.2?, or any other?

Before I do that though, I was wondering if there was anyway you could either post a bin that's corrected, or preferably write a how-to for the idiots, (like me) on how to change the header in the CVS snapshots, so that anyone could modify the needed byte to create a bin for the v2.2 WRT's?  Or maybe a perl script?

Unfortunately, there's some changes to the mtd (flash) that makes a stock openwrt snapshot refuse to boot cleanly, so just changing the bytes of a normal snapshot doesn't work.

Also, when you say you got it "booting" does this mean it accepts the new firmware, (OpenWRT) and all functionality is the same even though the chipset is different for the internal switch and I belive also the radio has a different chipset; or does it mean that it's simply booting, but not all functionality is normal?

The radio is the same, aside from the amplifier on it (according to the sveasoft forums) thus the new radios are rated to 34dBm (or some such). The new snapshot I've created works fine with the rest of my v2.0 WRT's and the switch appears to work fine.

I'd be more than willing to give your snapshot a shot.  smile

I'll go back and purchase back my old unit, lol.

I tried TheRoDent's firmware on my GS1.1 but failed. The tftp is successful, but after that the power led keeps flashing.

Which hardware version are you using?  v2.0, or v2.2?, or any other?

I have successfully flashed my firmware with Rodents modified bin.  However, I am also experiencing the same problems as you had, ie, flashing power LED.  However approximately 30 seconds after the tftp was complete I telnetted to my WaRT, and it worked just fine for me.  The power LED is still flashing.  I waited for at least 15 minutes, then plugged the power plug and replugged it in, the LED is still flashing, but the WaRT still booted into OpenWaRT, and is working fine otherthan the original power LED flashing.  I can still get into Telnet on the WaRT.  I'll install SSH and I'll be on my way, unless the Power LED means something.  smile  For the moment I'll ignore it.  wink


I'll post back my results.

thyeh:  Can you telnet into the WaRT?...  Remember that you need to telnet into the IP that was originally set.  IE, to tftp it you need to tftp to 192.168.1.1, however for the rest of the time you need to telnet into the WaRT's address, mine is 192.168.1.250

Tested RoDents firmware on G2.2

Works perfect, or looks like... didn't have too much time to trash around...
But I lost my wireless signal... can it be because I tftped having an HyperWrt on it?
I'll try to restore the router to facory defaults shorting flash pins and re-flash it with RoDents
I'll let you know any news
yurgi