v6 with Linux without Hardware Mods (the original work)

» Welcome » WL-530G » WRT54G5 CFE

This is the original WRT54G-GS v5-v6 flashing page, not a republished work. This is where the reverse engineering and software development came from. If you find these works useful, consider donating to the project.
(this is a static image of what *used to be* a functional wiki. Some links may be broken. The wiki software is incompatible with our new server and maybe insecure, so was abandoned.

Also, try our Process Lasso system responsiveness and process priority optimization tool for Windows!

WARNING: Flashing your router with a third-party firmware VOIDs the warranty. You can not rely on a reversion firmware being available. I never have posted the reversion firmwrare for the GS. Do not return routers after you've flashed them, this just encourages the vendors to make sure third party firmwares can not be used.

WARNING: You may brick your router if something goes wrong. You assume full liability for whatever happens and hold nobody responsible for damages, tangible or intangible, resulting from the use or mis-use of information or software found here. You (the user) assumes all liability.

WARNING: At the moment for WRT54GS units this is a one way operation. However, WRT54G units can be reverted no problem. Also, if you know what you're doing you can manually revert your WRT54GS (or other model) using a customized version of OpenWrt. I've not finished the automated WRT54GS reversion firmware because there was long ago a minor problem with OpenWrt that caused it to crash when restoring the original boot loader. I later determined the problem and fixed it, but never updated the reversion firmware. I don't profit or benefit from this work, and have put so much time into it.. that I just haven't had a chance to do this last step for the WRT54GS. I sure got everything ready though, someone can easily create a reversion firmware. As a last resort, you CAN revert your GS unit using the 'G' reversion firmware, but it will then be a WRT54G instead of WRT54GS, and accept Linksys WRT54G firmware images.

Flashing third-party linux firmwares on the WRT54G/GS v5, v6 without hardware modifications

Does this page help you? Considerable effort went into the reverse engineering of the firmware format, easy creation of necessary utilities to manipulate these files, and distribution of the vxworks killer. PLEASE help me by donating to the cause. Thanks for your consideration.

The firmware options

Step-by-step: Flashing DD-WRT on to your router

Trouble-shooting flash of linux

How to revert back to the original Vxworks based Linksys firmware

Automatic reversion (MAC address and serial # not restored)

Manual reversion (MAC address and serial # restored)

Trouble-shooting reversion to VxWorks

Changing your MAC addresss

Notes when running DD-WRT

txpwr - wireless signal strength

Post-Install Notes

WRT54GS: How to enable 16MB of RAM

Recovery

Utilities and source code developed for this project

Technical Details

Firmware Image Format

Firmware image checksum algorithm

VxWorks BOOTP block format

BOOTP checksum algorithm

Default NVRAM changes

Project overview and history

This is a project started by Jeremy Collake (aka db90h) to flash a Vxworks based WRT54G/GS v5-v6 with third party linux firmware without the use of JTAG or serial cables. After considerable research and time, this has been accomplished!

I spent about a week documenting the firmware image format and deriving the checksum algorithm. While doing this, I noticed in the disassembly of the decompressed VxWorks boot loader that a capability existed to update the BSP itself (the same area of flash the CFE occupies). This was a dream come true!

So, I wrote a utility to create, view, extract, and fix firmware images for these units. This utility is fairly polished, runs under linux and Windows, and includes full C++ source code. At this point it was simply a matter of embedding appopriate CFEs into a firmware image and letting the VxWorks boot loader flash over itself.

After figuring out how, more time and work were needed to polish the method and make it fool-proof. I then worked on creating a capability to revert back to VxWorks.

ith DD-WRT micro, these routers are turned into truely useful and well-performing devices. This is especially true of GS units, which have 16MB of RAM so should run at least as well as the WRT54GL under any circumstances.

The risks (PLEASE READ)

If something goes wrong during the flash, like a power outage in the couple of seconds it takes to flash the CFE, your unit will be bricked, recoverable only by JTAG. This risk is small, but real.
If you don't follow instructions here, or don't read warnings, you are in for a world of bricked routers.

Compatibility

Device	Notes
WRT54G v1-v4	unnecessary
WRT54GL v1, v1.1	unnecessary
WRT54G v5	fully supported
WRT54G v5.1	fully supported
WRT54G v6	fully supported
WRT54G-D2	fully supported
WRT54G v7	not supported - Atheros *1
WRT54GS v1-v4	unnecessary
WRT54GS v5	fully supported
WRT54GS v5.1	fully supported
WRT54GS v5.2	fully supported
WRT54GS v6	fully supported

*1 WRT54Gv7 uses a different chipset (reported to be Atheros). I don't have one of these and have not done any work on it.
*2 Technically speaking, you can use the WRT54G reversion firmware on a WRT54GS. However, your unit will then believe its a WRT54G and accept WRT54G firmwares.

How to flash linux on to your router

The firmware options

At present there aren't many firmware options for these micro devices, but this is changing.

DD-WRT micro

DD-WRT is currently the only viable option for most users of micro devices.

OpenWrt micro - X-Wrt

Work is on-going to create a good micro build of OpenWrt which utilizes the new webif^2 http management console (a new generation of the original OpenWrt webif with vastly extended capabilities). This will be available soon. To encourage its development, [

donate].

Step-by-step: Flashing DD-WRT on to your router

This procedure is simple, but in an attempt to make it fool-proof I've split the steps up into very simple ones. Don't let the number of steps intimidate you. In the end, it's as simple as flashing vxworks_killer.bin, the TFTP'ing DD-WRT. Please make sure you read carefully every line in this procedure, and understand each one.

An alternate tutorial with screenshots is [

here]. It may be very helpful to anyone who has trouble with these instructions.

This update should take less than 5 minutes.

For the WRT54G v5, v5.1, and v6 ONLY

Download [vxworks_prep_v03.zip] and extract.
Download [vxworks_killer_g_v06.zip] and extract, OR create a custom firmware image with your MAC address embedded in it. See the 'Changing your MAC address' section below for more information.
Download [DD-WRT micro generic]. You may want to check [ DD-WRT] to make sure there isn't a newer version than v23 SP2 beta 08/03/06. Do not use the one labelled 'WRT54G' or 'WRT54GS', use the 'generic' version.
If you don't know how to use (or don't have) a console mode TFTP tool (i.e. tftp.exe), download the [Linksys TFTP transfer tool].
You will want to assign your network adaptor a manual IP address, since you may loose your automatically configured one and have trouble TFTP'ing the firmware. To do this see the troubleshooting section or google it. It's done at the properties dialog of your network connection, in the 'Internet Protocol (TCP/IP)' properties.
Go to your router's web based interface and enter the 'Administration' tab. Then select 'Firmware Upgrade' and choose the vxworks_prep_v03.bin file. Hit apply. After a minute, your browser window will go blank. At this point, power cycle your router.
Again point your web browser to http://192.168.1.1. You'll see a different sort of firmware upgrade screen. This is the Management Mode. Select and apply the vxworks_killer_g_v06.bin firmware upgrade. WAIT for your browser window to turn to report 'Success'. Have troubles? Try a different web browser, the http daemon in management mode is very finicky.
Now unplug the power cord of your router, then plug it back in. The power LED should now be blinking.
Now you need to do a binary mode TFTP transfer of DD-WRT micro generic to your router. To do this you can use the Windows TFTP console mode utility, the Linksys TFTP Windows GUI utility, or some other TFTP client. You may have to disable your firewall if by some chance it is blocking outgoing connections on port 69. Many TFTP clients don't default to binary mode, so be sure to specify it (i.e. the -i switch with the Windows console mode TFTP utility).

For Windows TFTP console mode utility (example, adjust accordingly):

tftp -i 192.168.1.1 put dd-wrt.v23_micro_generic.bin

For the GUI utility

simply enter your router's IP (192.168.1.1), select dd-wrt.v23_micro_generic.bin, leave the password field blank, and initiate the transfer.

Do NOT reboot your router after TFTP'ing, this will happen automatically. It takes a couple minutes after the TFTP transfer finishes for the firmware to actually be flashed.

Skip to 'finalizing' below, or 'troubleshooting' if you've run into problems.

For the WRT54GS v5, v5.1 and v6 ONLY

SERIOUS WARNING -- NO REVERSION TO VXWORKS ON THESE UNITS: At the moment for WRT54GS units this is a one way operation. No reversion back to VxWorks is available. I never got around to creating the GS reversion firmware. It could EASILY be created by someone using the tools I've written and the documentation here. A person once sent me a GS router hoping I might, but I didn't get to it and now no longer have that router. If someone would like to send me another GS unit, I will maybe get around to creating the reversion firmware. Also, if you'd like to donate other routers, feel free. Note that I make absolutely no guarantees that I'll complete anything though.

Download [vxworks_prep_gs_v03.zip] and extract.
Download and extract [vxworks_killer_gs_v08.zip], OR create a custom firmware image with your MAC address embedded in it. See the 'Changing your MAC address' section below for more information.
Download [DD-WRT micro generic]. You may want to check [DD-WRT] to make sure there isn't a newer version than v23 SP1. Do not use the one labelled 'WRT54G' or 'WRT54GS', use the 'generic' version.
If you don't know how to use (or don't have) a console mode TFTP tool (i.e. tftp.exe), download the [Linksys TFTP transfer tool].
You will want to assign your network adaptor a manual IP address, since you may loose your automatically configured one and have trouble TFTP'ing the firmware. To do this see the troubleshooting section or google it. It's done at the properties dialog of your network connection, in the 'Internet Protocol (TCP/IP)' properties.
Go to your router's web based interface and enter the 'Administration' tab. Then select 'Firmware Upgrade' and choose the vxworks_prep_gs_v03.bin file. Hit apply. After a minute, your browser window will go blank. At this point, power cycle your router.
Again point your web browser to http://192.168.1.1. You'll see a different sort of firmware upgrade screen. This is the Management Mode. Select and apply the vxworks_killer_gs_v08.bin firmware upgrade. WAIT for your browser window to turn to report 'Success'. Have troubles? Try a different web browser, the http daemon in management mode is very finicky.
Now unplug the power cord of your router, then plug it back in. The power LED should now be blinking.
Now you need to do a binary mode TFTP transfer of DD-WRT micro generic to your router. To do this you can use the Windows TFTP console mode utility, the Linksys TFTP Windows GUI utility, or some other TFTP client. You may have to disable your firewall if by some chance it is blocking outgoing connections on port 69. Many TFTP clients don't default to binary mode, so be sure to specify it (i.e. the -i switch with the Windows console mode TFTP utility).

For Windows TFTP console mode utility (example, adjust accordingly):

tftp -i 192.168.1.1 put dd-wrt.v23_micro_generic.bin

For the GUI utility

simply enter your router's IP (192.168.1.1), select dd-wrt.v23_micro_generic.bin, leave the password field blank, and initiate the transfer.

Do NOT reboot your router after TFTP'ing, this will happen automatically. It takes a couple minutes after the TFTP transfer finishes for the firmware to actually be flashed.

Finalizing

After your router reboots itself following the TFTP transfer, you should have access to the DD-WRT's HTTP interface at 192.168.1.1.

Congratulations, you're now running DD-WRT micro! This was a one tim operation, future firmware updates do not require this process.

If you have problems, please visit an appropriate user forum to get aid from your fellow users. There are many common problems, and common solutions. I suggest the forums at [

dd-wrt.com].

Remember, the default username and password for a new DD-WRT flash is:

username: root
password: admin

Trouble-shooting flash of linux

Q: My TFTP transfer seems to be succeeding, but the router isn't booting. The power LED just keeps winking at me. Is this a sign of physical attraction?

Make sure you waited for the router to flash the firmware and reboot itself. This takes a minute. There should be no need to power cycle it.
Make sure you flashed the micro generic build of DD-WRT.

Q: I can't seem to contact the router after I apply vxworks_killer, so can't TFTP the DD-WRT firmware. What's up?

You've probably lost your automatically assigned IP address. You need to manually set your network connection's IP address. Go to the properties of your network connection, select 'Internet Protocol (TCP/IP)', hit 'Properties', then enter this:

IP = 192.168.1.99
Subnet mask = 255.255.255.0
Gateway = 192.168.1.1
(optional) set first DNS server to 192.168.1.1

Since the MAC address of the router has changed, you may need to flush your ARP table (command: arp -d *)
Some users have reported the need to set the network adaptor to 10Base-T half-duplex. In Windows XP, this can be found by clicking the 'configure' button beside the name of your network adaptor in the network connection properties. I suggest trying this if you still can not contact the router. Don't forget to change it back.

Q: Is my router bricked?

Probably not. If ALL the ethernet port LEDs on the front of the router are constantly lit AND your power LED is flashing, then yes. Otherwise, NO IT IS NOT BRICKED. It can be recovered. However, it it may not be recoverable if you do anything crazy like start shorting pins. Be patient, ask for help in the forums.

Q: I've installed DD-WRT micro, but my router is unstable. Eh?

Try a different build of DD-WRT. The v23 SP2 betas are superior micro builds to the final v23 SP1.

Q: I made a mistake or need help... I mean, with this procedure, not life in general. Where can I get it?

Visit the forums at http://www.dd-wrt.com or the forums at http://www.linksysinfo.org .

How to revert back to the original Vxworks based Linksys firmware

Reverting back to VxWorks is now a simple process. I've created a firmware image that does nothing but revert your router back to a VxWorks. This firmware is based on OpenWrt.

Automatic reversion (MAC address and serial # not restored)

For the WRT54G v5, v5.1, and v6 ONLY

Download [http://dl2.bitsum.com/files/vxworks_revert_v02.zip] and extract.
Download the latest Linksys firmware for your router from http://www.linksys.com.
In the DD-WRT Administration/Firmware? Upgrade tab, select and apply the openwrt-wrt54g_v4-squashfs.bin firmware you extracted in step 1.
DO NOT TOUCH YOUR ROUTER. DO NOT POWER DOWN YOUR ROUTER. IF YOU DO, YOU MAY/WILL BRICK YOUR ROUTER.
After a few minutes (have patience) your router will reboot itself and the VxWorks boot loader's Management Mode will be engaged. You can visit it at http://192.168.1.1. If the browser doesn't respond, WAIT LONGER. Do not power off your router.
In the Management Mode, select and apply the Linksys firmware you downloaded in step 2. DO NOT apply vxworks killer instead, even if you want to go back to linux again right away. You must first apply a Linksys firmware to re-initialize the flash before you can go back to linux.
Power cycle the router after you see 'Success'.

Skip to finalizing below..

For the WRT54GS v5, v5.1 and v6 ONLY

No automated reversion available for this firmare, use manual reversion below.

Finalizing

If you had troubles, see the [WRT54G5_CFE#trouble_rev trouble shooting] section below. Othewrise, you are now back to Linksys firmware.

Manual reversion (MAC address and serial # restored)

WARNING: This procedure has not yet been as well tested as the flash to linux. Please use caution. I advise waiting to here reports of success from others. I've only tested on a WRT54Gv5.

For the WRT54G v5, v5.1, and v6 ONLY

Download [http://dl2.bitsum.com/files/vxworks_reversion_with_mac_restore_v05.zip] and extract.
Download the latest Linksys firmware for your router from http://www.linksys.com.
In the DD-WRT Administration/Firmware? Upgrade tab, select and apply the openwrt_wrt54g_squashfs.bin firmware you extracted in step 1. It's advised to use the 'restore defaults' option on DD-WRT, or reset the nvram immdiately after flashing. If you are TFTP'ing instead of using the web UI, use the TRX image included.
Wait for the unit to reboot. After 5 minutes if nothing happens, power cycle the router.
Connect to the router's shell through telnet (i.e. telnet 192.168.1.1). It won't ask you for a login, and do not set one.
Issue the following commands with your desired MAC addresses and serial number instead. The command syntax is of the embed.sh step is:

Where MAC_ADDRESS1 is the first MAC address and MAC address 2 is the second MAC address. The first MAC address is normally the one on the box and the second is exactly one number greater than the first. The third MAC address is the WLAN.
Where SERIAL_NUM is the serial number you'd like to embed.

Be sure to run the embed.sh script before flash.sh (even if you don't want to embed a new MAC and serial). If you don't, it will brick your box because part2.bin won't be found. I will add a protection against this in the next version.

cd /etc/bsptools
./embed.sh 00-11-22-33-44-55 00-11-22-33-44-56 00-11-22-33-44-57 CGFN12345678
./flash.sh

If there are no errors your router should reboot itself and you should be able to access the VxWorks management mode via your browser. At this time, flash an original Linksys firmware (do this first even if you plan to immediately do the vxworks_killer procedure again).

For the WRT54GS v5, v5.1 and v6 ONLY

WARNING: At the moment for WRT54GS units this is a one way operation because nobody has yet taken the time to write an automated reversion firmware. The process is the same as for the WRT54G, you flash a customized OpenWrt that you use to restore the original boot loader and BSP. Note that you can actually revert a WRT54GS to a WRT54G using the automated WRT54G reversion firmware. However, it will then only have 8MB of RAM accessible and appear to be a WRT54G model.

Trouble-shooting reversion to VxWorks

Q: I got the management mode back (meaning VxWorks bootloader is restored), but it won't accept the Linksys firmware. What do I do?

Some have reported this issue. I think it is due to the HTTP server crashing repeatedly, as its very unstable. Here are my recommendations (not step-by-step):

Keep trying to upload/flash the linksys firmware without rebooting your router until it finally accepts it. If you catch the HTTP server at the right time, it may work. Others have reported this works.
You might want to try uploading/flashing vxworks_prep_v03.bin, then reboot your router after it succceeds. The linksys firmware might now be accepted.

Q: What the hell is a power cycle? Is this anything like a motorcycle?

Unplug the power cord of your router. Then plug it back in.

Q: My router isn't responding at http://192.168.1.1 after I flashed vxrevert. Does my router hate me?

Wait. Wait. Wait. Do not power off your router.

Q: My router isn't responding at http://192.168.1.1 after 10 minutes. Is it okay to hit it with a hammer?

Wait another 5 minutes then power cycle your router. Now, are ALL your Ethernet port lights lit? If so, you may have a bricked router. If not, your router can be recovered. You may need to TFTP the DD-WRT micro firmware to the router again, but you will have to time the TFTP transfer so that it starts in a 3 second window when your router first turns on.

Changing your MAC addresss

Your factory default MAC address will change after applying the switch to linux procedure, and when reverting back to VxWorks. You can change it after you've installed your desired firmware, however it will reset back to the default if you restory the factory defaults.

Changing it via NVRAM

This method does not persist if unit is reset to factory defaults. However, since you won't be resetting to factory defaults often, this is perfectly acceptable. You can even add this to a startup script and then a reset to NVRAM won't matter.

Example code to change MAC address in linux based firmwares:

nvram set et0macaddr=00:90:4d:83:00:01
nvram set il0macaddr=00:90:4d:83:00:02
nvram commit

When flashing to linux

The Windows x32 utility below will allow you to set the default MAC address when switching to Linux. I whiped this utility out pretty quick, so don't expect anything fancy.

[VxWorks Killer Image Tool GUI v0.90 beta] Embeds a MAC address into a CFE and builds a VxWorks compatible image for the WRT54G/GS v5-v6.

You can also use my console mode utility, which is more powerful in that it allows any nvram variables to be changed/added:

[IMGTOOL_NVRAM v0.02 alpha] Utility to set/change default NVRAM variables inside a CFE image. Includes C++ source and Win32 binary.

When reverting to VxWorks

The 'manual' reversion firmware now supports this.

Notes when running DD-WRT

txpwr - wireless signal strength

The VxWorks firmware defaults to a higher tx power than does DD-WRT. To adjust DD-WRT so that its tx power is equivelent to what it was when using the Linksys VxWorks based firmware set the tx power to 84mw.

Post-Install Notes

WRT54GS: How to enable 16MB of RAM

DO NOT DO THIS IF YOU HAVE A WRT54G, YOU WILL BRICK YOUR ROUTER. THIS IS FOR THE GS ONLY. If you try to do this on other models you will brick your router

This applies only to WRT54GS v5-v6 users who utilized the vxworks_killer v0.7 or below. Only GS units have 16MB of RAM.

Telnet into your router and issue the following commands:

nvram set sdram_init=0x0A
nvram set nvram_ncdl=0
nvram commit
reboot

Simple as that! Now you should have 16MB of RAM accessible to DD-WRT.

For the curious, here are some notes about the RAM in this unit:

RAM : mira p2v28s40btp [5409fa03-6] spec: http://www.deutron.com.tw/data_sheets/sdram/p2v28s_0btp11_07024.pdf

The RAM supports up to 166mhz operation, though it's only running at 100mhz by default on these units.

Recovery

JTAG

Building an

unbuffered JTAG cable will allow recovery from any problem. The procedure is the same for other WRT54G models.

Pin shorting

You changed some random nvram variable or uploaded an incompatible firmware and now your router won't boot.

I can't recommend strong enough not to do this. The flash pins are delicate and easily damaged. Building an unbuffered JTAG cable is very easy, don't be scared. If you are scared, or just don't want to build one, contact Alden @ [

mailto:abessey@runbox.com] to purchase a very nice cable, with headers, at a reasonable price.

So you really want to short pins? At least do it right. Apparently grounding pin 16 (to the antenna shell) works. Thanks Mungewell for this tip.

Utilities and source code developed for this project

VX_WRT_IMGTOOL: Firmware image builder, extractor, viewer, and fixer

This utility, authored during this project, provides the ability to create, extract, view, and fix firmwares in the WRT54G/GS 5-6 firmware image format.

The full C++ source is included. Currently it can be built under Windows and Linux. A Windows x32 binary and Ubuntu 6.06 linux binary are included, along with the C++ source code. The code is endian neutral and has some built in sanity checking to make sure it was built correctly.

[Download WRT_VX_IMGTOOL v0.94 beta] - Windows x32 binary and C++ source (linux g++ ready).

 WRT54G/GS v5-v6 firmware image builder, extractor, fixer, and viewer
 v0.91 beta - Jun 27 2006 by Jeremy Collake (jeremy at bitsum.com)
 For info see: http://bitsum.com/openwiking/owbase/ow.asp?WRT54G5FE
 ------------------------------------------------------------------------------

 Usage:

 wrt_vx_imgtool
  [-x|v|f|b] [-d device] [-c abc] [-m abc] -o outfile infile1 infile2 ...

 Operations:

 [-b] Build the firmware (default
 [-x] Extract the firmware
       The image filename should be provided as the first, and only, 'infile'
       parameter. The -o switch can specify an output directory, if the CWD
       isn't desired. All files, primary and trailing, are extacted to
       the output folder, named in accordance with their type.
 [-v] Dump/analyze the firmware
       Similar to extraction, but no files are writen to disk
 [-f] Just fix the checksum of given input firmware

 Options:

 [-d] Set target device. Causes the code pattern and vendor name to be set to
      proper values. By default the device is the WRT54G. Valid devices:
       WRT54Gv5
       WRT54Gv6
       WRT54GSv5
 [-c] Over-rides the code pattern. Not recommended.
 [-m] Over-rides the vendor name. Not recommended.

 Notes:

 The deafult action is to build a new firmware, saved in outfile,
 and containing files supplied as input. The files should be named
 in accordance with their file type/flash area.

 The following files are normally included in the firmware images:
   vxWorks.bin
   igwhtm.dat
   langpak_en
   __trailing__ (some web UI fs appended to firmware)

 These files will be created if extraction is chosen, or should be
 supplied when building a firmware image.

IMGTOOL_NVRAM: CFE image default nvram adjuster

This utility can changed the default nvram variables in CFE images. It has not yet been ported to linux, but probably builds there with minor modifications.

The current verison of this tool does not set the correct nvram checksum or make any other NVRAM header modifications since these semm to be unused in the default nvram data block, and intead are only used in the actual nvram storage area. The checksum and other fields appear to be corrected when the default nvram is copied to the real nvram.

[IMGTOOL_NVRAM v0.1 alpha] Utility to set/change default NVRAM variables inside a CFE image. Includes C++ source and Win32 binary.

BSPTOOL: Tool to manipulate VxWorks BSP BOOTP images

This utility can changed the parameters located in a VxWorks BSP BOOTP physical image (file).

[BSPTOOL v0.4 alpha] Utility to manipulate BOOTP parameters. Full c++ source included. Compatible with MSVC++ and gnu/linux g++.

Usage:

bsptool v0.1 - (c)2006 Jeremy Collake - http://bitsum.com

 Usage:
    bsptool [/v] imagefile [/mac1 x] [/serial x] [/country x] [/vendor
            [/device x] [/codep x]

    /v                     view only
    /mac1 xx-xx-xx-xx-xx   first MAC address
    /mac2 xx-xx-xx-xx-xx   second MAC address
    /mac3 xx-xx-xx-xx-xx   third MAC address
    /serial xxxxxxxxxxxx   twelve digit serial number
    /device                optional device id (WRT54G or WRT54GS)
    /country               optional country (i.e. US)
    /vendor                optional vendor (i.e. LINKSYS)
    /codep                 optional code pattern (WG54))
    /bootstr               optional boot string
    imagefile              any image with BOOTP at end

 Notes:

    Any and all bootp parameters can be omitted.
    Only one image file is supported per execution.
    When /v (view only) is supplied, no changes will be made.

Sample run:

$ bsptool /mac1 00:11:22:33:44:55 /mac2 00-11-22-33-44-56   /mac3 00-11-22-33-44-57 /serial cdfb12345678

bsptool v0.2 - (c)2006 Jeremy Collake - http://bitsum.com
 MAC1 supplied: 00:11:22:33:44:55
 MAC2 supplied: 00:11:22:33:44:56
 MAC3 supplied: 00:11:22:33:44:57
 Serial supplied: cdfb12345678

Viewing BOOTP block ...
BOOTP block
 codep        : 0x57475635
 checksum     : 0x55d8 (calculated: 0x55cf)
 bootcode ver : 0x1000102
 model        : WRT54G
 vendor       : LINKSYS
 country      : US
 serial #     : CDFB0F2A0131
 hardware ver : 1.0
 pciid        : 0xffff
 mac1         : 00-16-b6-18-21-b8
 mac2         : 00-16-b6-18-21-b9
 boot string  : tffs:(0,0)host:/fl/vxWorks.bin h=192.168.1.100 (cough)
e=192.168.1.1:ffffff00 u=target tn=targetname f=0x8

Rewriting BOOTP block ...
Viewing modified BOOTP block ...
BOOTP block
 codep        : 0x57475635
 checksum     : 0x55c9 (calculated: 0x55c9)
 bootcode ver : 0x1000102
 model        : WRT54G
 vendor       : LINKSYS
 country      : US
 serial #     : cdfb12345678
 hardware ver : 1.0
 pciid        : 0xffff
 mac1         : 00-11-22-33-44-55
 mac2         : 00-11-22-33-44-56
 boot string  : tffs:(0,0)host:/fl/vxWorks.bin h=192.168.1.100 (cough)
e=192.168.1.1:ffffff00 u=target tn=targetname f=0x8

SDRAM_PARAMS: Utility to decode / encode SDRAM parameters

[

download] Includes c++ source. Builds with MSVC (Windows) or g++ (linux).

 sdram_params v0.11, (c)2006 Jeremy Collake <jeremy@bitsum.com>
 Bitsum Technologies http://bitsum.com

 Encoding sdram_init ...
  Generate refresh cycle [False]: T/F/Q? t
  Generate pre-charge cycle [False]: T/F/Q? f
  Generate mode register select cycle [False]: T/F/Q? f
  Enable SDRAM access control [False]: T/F/Q? t
  Perform soft reset [False]: T/F/Q? f
  Perform soft-refresh [False]: T/F/Q? f
  Perform power down [False]: T/F/Q? f
  32-bit interface [False]: T/F/Q? t
  9-bit columns [False]: T/F/Q? f
  SDRAM size of 128Mbit [False]: T/F/Q? f
  SDRAM size of 64Mbit [False]: T/F/Q? t

 Encoding sdram_config ...
  Burst length==full page [False]: T/F/Q? t
  Fast memory (CAS 2) [False]: T/F/Q? f

 Encoding sdram_refresh ...
  Refresh enable [False]: T/F/Q? t
  Refresh period (refresh rate=16 * 1/clkfreq * refresh period): 64
 (64)

 sdram_init=0x419
 sdram_config=0x0
 sdram_refresh=0x8040

 Done!

# sdram_params -d sdram_init=0x419 sdram_config=0x0 sdram_refresh=0x8040

 sdram_params v0.11, (c)2006 Jeremy Collake <jeremy@bitsum.com>
 Bitsum Technologies http://bitsum.com

 sdram_config=0x0
  burst length                   : full page
  fast memory (CAS 2)            : False

 sdram_init=0x419
  generate refresh cycle         : True
  generate pre-charge cycle      : False
  generate mode reg select cycle : False
  ext. access control enabled    : True
  external SDRAM size            : 64 Mbit
  soft reset                     : False
  self-refresh                   : False
  power down                     : False
  32-bit interface               : True
  9-bit column                   : False

 sdram_refresh=0x8040
  refresh period                 : 64
  refresh enabled                : True

 Done!

Technical Details

This project was accomplished in less than a week, but it took a bit of effort. The VxWorks BSP had to be dumped from RAM (its compressed on ROM) and disassembled to derive the checksum algorithm, and to properly document the firmware image format. Below is documentation and notes developed during this project that may be useful to others.

Firmware Image Format

A firmware image consists of a header and up to 16 different internal files of pre-defined types, up to 8 primary files and 8 'trailing' files.

Image format

Header

File1

File2

...

File8

Trailer1

Trailer2

...

Trailer8

<<EOF>>

The end file size is always aligned on a 32-bit boundary.

The primary files are the only ones of consequence, at least for the moment. The trailing files have an unknown use and aren't written to the flash.

Known primary file types are:

#define VX_FILE_ID_BOOTROMBIN 1 
#define VX_FILE_ID_VXWORKSBIN 2
#define VX_FILE_ID_IGWHTMDAT 3
#define VX_FILE_ID_LANGPAK_EN 6

The header itself is designed to be endian neutral. Integers are stored big endian and are intended to be read by endian neutral code (that is, read as they are stored).

As stated above, the checksum algorithm includes the header, so no field of the header can be changed without updating the checksum.

Latest header defintion (for full source with other comments download wrt_vx_imgtool):

////////////////////////////////////////////////////////////////
// Linksys VxWorks based firmware image format
// Author: Jeremy Collake (http://bitsum.com)
// WARNING: Work In Progress. Mistakes and guesses are present.
//
#pragma pack(1)

typedef struct _VxFileDescriptor
{         
  DWORD nFileId_BigEnd;     // file type (see below)
  DWORD nFileSize_BigEnd;   
} VxFileDescriptor, *pVxFileDescriptor;

typedef struct _VxLinksysHeader
{
  DWORD nCodePattern;                        
  BYTE cUnknown_4[4];
  BYTE cYear;       
  BYTE cMonth;      
  BYTE cDay;        
  BYTE nProductVersion_0;   
  BYTE nMinorVersion_0;   
  BYTE cZUnknown_0D;
  BYTE cImageFormatVersion[4];    
  BYTE cZUnknown_12[238];  
  //
  // offset 0x100  -- begining of an secondary header?
  //  
  // After this point, all integers are stored big endian 
  // and should be read by endian neutral code 
  // (that is, read as big endian). 
  //
  BYTE nProductVersion_1;   
  BYTE nMinorVersion_1;     
  WORD nMajorVersion_1;       
  BYTE cZUnknown_104[2];  
  WORD nHeaderSizeBigEnd;
  DWORD nChecksumBigEnd; 
  BYTE cZUnknown_10B[2];  
  WORD nUnknown_10D;     
  BYTE cZUnknown_110[0x30]; 
  BYTE cModelName[0x20]; 
  BYTE cVendorName[0x20];
  VxFileDescriptor TrailingFiles[8]; 
    // parts of file that follow primary file descriptors 
  VxFileDescriptor FileDescriptors[8]; 
    // primary file descriptors, immediately follow header  
} VxLinksysHeader, *pVxLinksysHeader;

Firmware image checksum algorithm

The checksum algorithm is an endian neutral 32-bit unsigned sum of the entire firmware image, including the header, with the checksum field itself excluded (set to NULL).

Here's my implementation:

/////////////////////////////////////////////////////////////
// Checksum_Linksys_WRT54Gv5_v6
//
// unsigned 32bit checksum of 32bit unsigned integer - endian neutral
//
unsigned long
Checksum_Linksys_WRT54Gv5_v6(unsigned long *pStart, unsigned long *pEnd)
{
        unsigned long nChecksum=0;
        while(pStart<pEnd)
        {        
                nChecksum+=big_endian_l(*pStart++);        
        }
        return ~(nChecksum-1); // return two's compliment
}

VxWorks BOOTP block format

The BOOTP block was easily documented. Here is my latest definition:

#pragma pack(1)

///////////////////////////////////////////////////////////
// BOOTP pre-requisities
//
typedef struct _MY_MAC_ADDR
{
        unsigned __int8 addr[6]; // big endian
} MY_MAC_ADDR, *PMY_MAC_ADDR;

////////////////////////////////////////////////////////////
// VxWorks BSP BOOTP definition
// by Jeremy Collake <jeremy@bitsum.com>
// WARNING: This is not an official definition.
//
typedef struct _BOOTP_BLOCK
{
        unsigned __int32 dwCodePattern;
        unsigned __int16 wChecksum;
        unsigned __int16 wUnknown0;
        unsigned __int32 dwBootcodeVersion;
        SBYTE szDevice[0x40];
        SBYTE szVendor[0x40];
        SBYTE szCountry[0x20];


        SBYTE szSerial[0x20];
        unsigned __int8 VersionMajor;
        unsigned __int8 VersionMinor;
        unsigned __int16 wpciid; 
        unsigned __int32 dwConfig;
        _MY_MAC_ADDR macAddr1;
        _MY_MAC_ADDR macAddr2;
        _MY_MAC_ADDR macAddr4; /* dunno if this really is a mac */
        _MY_MAC_ADDR macAddr3;
        SBYTE cUnknown3[0x12]; 
        SBYTE szBootString[770];
} BOOTP_BLOCK, *PBOOTP_BLOCK;

BOOTP checksum algorithm

I was able to guess at the BOOTP checksum algorithm. Here's my implementation, used in my BSPTOOL utility:

unsigned __int16 bootp_checksum(BOOTP_BLOCK *pbootp)
{
        unsigned __int16 nSum=0;
        unsigned char *p1=(unsigned char *)pbootp;
        unsigned __int16 nOldchecksum=pbootp->wChecksum;
        pbootp->wChecksum=0xffff; 
        for(int nI=0;nI<sizeof(BOOTP_BLOCK);nI++,p1++)
        {
                nSum+=*p1;                
        }
        pbootp->wChecksum=nOldchecksum;
        return nSum+2; // not sure where the +2 is coming from..
}

Default NVRAM changes

These are the ideal nvram changes from the WAP54Gv3 CFE base. Note that this is only the differing NVRAM variables.

G v5-v6:

boardnum=42
boardflags=0x2558
boardrev=0x10
vlan0ports=3 2 1 0 5*
vlan1ports=4 5
wl0gpio0=2             
wl0gpio1=5 
wl0gpio2=0 
wl0gpio3=0
vxkilled=g

GS v5-v6:

boardnum=42
boardflags=0x2758
boardrev=0x10
vlan0ports=3 2 1 0 5*
vlan1ports=4 5
wl0gpio0=2   
wl0gpio1=5     
wl0gpio2=0 
wl0gpio3=0
sdram_init=0x0A
vxkilled=gs

Bricked router recovery

If you somehow managed to brick your router, there are various ways to recover it. The end-all solution to bricked routers is a JTAG cable. These are easily constructed, or cheaply bought. A generous member of this community has offered them for sale on ebay or direct sale, at a very reasonable price. To purchase a pre-built cable with necessary pin headers included, email [

anectine17 - abessey@runbox.com].

Supporting this project

Donations

I spent considerable time on this project, but did so for my own enjoyment, not to profit. However, if you would like to encourage me to continue this work, or give thanks for work already done email me at jeremy@bitsum.com (or donate via paypal to that address).

New Hardware support

I have been emailed a few times asking if support can be extended to this or that unit. I'm happy to work on any unit as I get time, but can't afford to buy these units. Email me at jeremy (at) bitsum.com if you want to donate hardware.

Jobbie Jobs

Give me a holler if you need some work done. I'm broke. Email jeremy@bitsum.com.

Downloads

Utilities:

[WRT_VX_IMGTOOL v0.99 beta] Utility to view,extract,fix, and build WRT54G/GS v5 and v6 firmware images. Includes C++ source code. Compatible with Windows and Linux for certain.
[VxWorks Killer Image Tool GUI v0.011 alpha] Embeds a MAC address into a CFE and builds a VxWorks compatible image for the WRT54G/GS v5-v6. Currently in beta testing.
[IMGTOOL_NVRAM v0.1 alpha] Utility to set/change default NVRAM variables inside a CFE image. Includes C++ source and Win32 binary.

[BSPTOOL v0.4 alpha] Utility to manipulate BOOTP parameters. Full c++ source included. Compatible with MSVC++ and gnu/linux g++.

[SDRAMS_PARAMS v0.1] Utility to encode and decode sdram parameters on BCM47xx boards.

Flash images:

VxWorks Killing Preparation (flash clear, for good measure)

[VxWorks_Prep_v03.zip] - Preparatory firmware image for the WRT54Gv5 and WRT54Gv6. This should be flashed before vxworks_killer.bin.
[VxWorks_Prep_gs_v03.zip] - Preparatory firmware image for the WRT54Gv5 and WRT54Gv6. This should be flashed before vxworks_killer.bin.

VxWorks Killing

[VxWorks_Killer_g_v06.zip] - Pre-built firmware image that upgrades a WRT54G v5, v5.1, or v6.
[vxworks_killer_gs_v08.zip] - Pre-built firmware image that upgrades a WRT54GS v5, v5.1 (brand new version with 16MB RAM support)

VxWorks Restoring

[vxworks_revert_v01.zip] VxWorks reversion firmware for the WRT54G v5 and v6. Do not use on the WRT54GS v5 or v6, unless you want your router to effectively be a WRT54G from now on (and accept 'G' firmwares).
[http://dl2.bitsum.com/files/vxworks_reversion_g_v04.zip] VxWorks reversion with MAC and serial restoration for the WRT54G. This is also a good firmware to use if you need to update your CFE for some reason since it removes the normal protections on the MTD0 partition.
[[ http://dl2.bitsum.com/files/vxrevert_manual_gs_v06.zip]] VxWorks reversion with MAC and serial restoration for the WRT54GS. This is also a good firmware to use if you need to update your CFE for some reason since it removes the normal protections on the MTD0 partition.

DD-WRT downloads:

[About DD-WRT]
[DD-WRT] In the downloads area, find the MICRO build for the WRT54G or WRT54GS.

Acknowledgements

Ex_Cyber, who put up with my delerium on irc while I spent endless hours in IDA, trying to fix a problem that didn't exist ;).
To all those users who have expressed interest in this project and/or contibuted helpful information.

Number of page hits: 1273376 (+ Y*x (where Y is the number of years after we quit counting, at least 3, where x is the average hits per year for that period))

Summary : WRT54G/GS v5-v6 flash to linux without hardware modifications