The WRT54G and like Broadcom devices seem to allow a boot_wait option where we can fix any broken flash remotely by TFTP without opening the router. Currently our only solution is opening the device and installing a serial connection, with use of a TTL RS232 converter. This isn't within the ability of many end-users.
An easier solution to the serial add-on is to acquire a USB-Serial converter such as that built into a typical e-bay Nokia CA-42 clone cable and use that to do the level conversion. You will need to hook up TX, RX and GND - see Serial Port.
U-boot has no TFTP server. It only has a client. U-Boot maintainers like it this way and see no point in a server. Well, they're mostly right. Anything could be done using scripting of environment variables and starting a TFTP client. So let's see if we can somewhat mimic other routers with what we have…
Note that the built in tftp client in Windows and OSX won't work - TFTPD32 for Windows and TFTPServer for OSX do work.
If you're just looking to replace the firmware that is on the device and did create the necessary serial port connections, you don't need to read all the ramblings below.
You can set the PC to IP 192.168.0.250, place the firmware in the TFTPD root directory with the name vmlinuz-8668 and simply type run update_kernel at the ADM8668 prompt.
If we issue a 'tftpboot' command to U-boot it will attempt over and over to boot. But, we can attempt a TFTP download if and only if $serverip is alive on WAN. Here is example, executed at serial console:
ADM8668 # set if_tftp 'ping $(serverip)' ADM8668 # set do_tftp 'run tftp_boot' ADM8668 # set bootcmd 'run if_tftp do_tftp; run flash_flash' ADM8668 # save Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... done Erased 1 sectors Writing to Flash... done Protected 1 sectors
Then upon a normal boot:
Hit any key to stop autoboot: 0 TX error status2 = 0x04000008 Using adm8668_net device ping failed; host 10.42.43.1 is not alive ## Booting image at b0040000 ...
If I bring up my TFTP server (I set mine to 10.42.43.1 as you see, since my cable company allows internal IPs to be visible locally, WTF!)
Hit any key to stop autoboot: 0 TX error status2 = 0x04000008 Using adm8668_net device host 10.42.43.1 is alive TX error status2 = 0x04000008 Using adm8668_net device TFTP from server 10.42.43.1; our IP address is 10.42.43.10 Filename 'vmlinuz-8668'. Load address: 0x600000 Loading: T T ######################etc...
Now this will only execute an image from RAM. More helpful would be to replace do_tftp with command such as 'run update_kernel' to actually flash it.
But there is a big problem. Say I kept default IP, which I think was 192.168.0.1, and there is a device on the WAN port that answers to this. You will receive the following:
TX error status2 = 0x04000008 Using adm8668_net device host 192.168.0.1 is alive TX error status2 = 0x04000008 Using adm8668_net device TFTP from server 192.168.0.1; our IP address is 192.168.0.2 Filename 'vmlinuz-8668'. Load address: 0x600000 Loading: T T T T T T T T T T Retry count exceeded; starting again TX error status2 = 0x04000008 Using adm8668_net device TFTP from server 192.168.0.1; our IP address is 192.168.0.2 Filename 'vmlinuz-8668'. Load address: 0x600000 Loading: T T T T T T T T T T Retry count exceeded; starting again
Indefinitely So this is a dumb idea. But looking at U-boot sources, we can set netretry to either no or once let's try that:
ADM8668 # set netretry no ADM8668 # run bootcmd TX error status2 = 0x04000008 Using adm8668_net device host 10.42.43.1 is alive TX error status2 = 0x04000008 Using adm8668_net device TFTP from server 10.42.43.1; our IP address is 10.42.43.10 Filename 'vmlinuz-8668'. Load address: 0x600000 Loading: T T T T T T T T T T Retry count exceeded; starting again ## Booting image at 80600000 ... Bad Header Checksum #####Boot failed! ##### ##### Trying to boot from b0600000 ... ## Booting image at b0600000 ... Bad Magic Number ## Booting image at b0040000 ...
Well, seems like it'll get out of the tftp loop, but it still tried to boot from 0x600000. This is because that command wasn't part of a magic 'run' command which only continues upon success. This wouldn't be good if I used update_kernel because it would go ahead and erase your flash. Also, we still have to wait the extremely long timeouts before it boots from flash! But some more craftiness with variables, we can just attempt TFTP to RAM, if success, erase flash and do a memory copy from RAM to flash…hmm?
ADM8668 # set netretry no ADM8668 # set if_pingable 'ping $(serverip)' ADM8668 # set if_tftp_success 'tftpboot 600000 $(bootfile)' ADM8668 # set do_upgrade 'erase $(kernel_addr) +$(filesize); cp.b $(fileaddr) $(kernel_addr) $(filesize)' ADM8668 # set bootcmd 'run if_pingable if_tftp_success do_upgrade; bootm $(kernel_addr)' ADM8668 # saveenv
Seems the memory copy command cp deals correctly with flash. yay! one thing goes right. ;) Also, the bootm command is ran regardless of outcome of previous commands. So failing the upgrade in the ping/tftp parts, we'll still boot what's in flash (or at least try heh). I found that $fileaddr and $filesize are set after any tftp transfer, so we only erase enough of flash memory to make file fit now as well.
Note that by default, the device will want to have 192.168.0.10 with the TFTP server at 192.168.0.250, connected through the WAN port.
Here is an abbreviated successful upgrade (before using the $filesize variable – note the extra sectors erased):
ADM8668 # run bootcmd host 10.42.43.1 is alive Using adm8668_net device TFTP from server 10.42.43.1; our IP address is 10.42.43.10 Filename 'vmlinuz-8668'. Load address: 0x600000 Loading: T T ###etc.. done Bytes transferred = 2328692 (238874 hex) ..................... done Erased 48 sectors Copy to Flash... done ## Booting image at b0040000 ...
But we still have these problems:
Guess we can deal with these. Now, to include the uboot-envtools into an image, and set this up from within Linux…. Stay tuned… Even better would be to chainload a newer U-boot with netconsole support! :)
I compiled u-boot environmental utilities and posted binary (sorry not packaged yet) at http://wrt.scottn.us/fw_printenv. The same program named fw_setenv will set variables. Previous builds didn't have a writable nvram partition tho. So it's also kinda required to be using X-WRT build 3. It's in the /root directory for you and a small readme.. I guess I could/should also make a module that'll enable the nvram partition in older builds, so you can enable this function before an upgrade. hmm, always finding more work to do, and less time to do it.