Yet another set of unbricking instructions, drawing on the previous
ones to create what is, hopefully, a guide that anyone can follow. If
some of it is teaching you to suck eggs, remember that not everybody
has your knowledge. Most of this was new to me today.

== Situation ==
You have "bricked" your slug, meaning that some part of the firmware is
corrupt and hence the device will not boot into Linux.

The firmware is in four sections:

o Redboot, the bootloader that runs when the device is first started,
loads things into memory
and starts Linux. Redboot is quite sophisticated, and has a user
interface that you can access
by serial connection or telnet. You can use it to load things into
memory by TFTP, write to flash,
and similar tasks.

o Linux kernel. This is a more-or-less opaque (to me, anyway) vmlinuz
file containing a
compressed kernel.

o Ramdisk. This is the conventional Linux file tree - /bin, /etc, and
all the rest of them - in
compressed form. It's stored in flash, but gets loaded into RAM by
Redboot when Linux is run.
You can modify its contents, but any changes will be lost when you
reboot, as a fresh copy is
loaded into RAM from flash

o SysConf. This portion of the flash contains the sort of data you can
modify through the Web
interface, such as the hostname.

There is also a small "trailer" at the end of the firmware file that
the slug can check.

Of these sections, hopefully Redboot at least is still intact. If it is
not, these instructions will not help you, and you'll need to talk to
the hard-core JTAG people.

== The Procedure ==

1. The first thing you will need to do is set up a TFTP server, if you
do not already have one installed. I work mostly on OS X, so I can't
give detailed instructions for Linux (I did try, briefly, to install a
TFTP RPM on my Linux machine, but though it claimed to be client and
server only the client seemed to be installed). If you're using OS X,
feel free to contact me for details. You should set up the server with
a directory to serve from; this will need to be world-readable, *as
will any files you place in it* if you want them to be served.

2. Obtain the firmware and place it in the TFTP serving directory. If
you've bricked your slug I suggest you start by getting it back to
default configuration by installing Linksys's firmware - you can always
upload a fancier one via the Web interface once you've got it working.
Download the firmware from their site if you haven't already
( http://www.linksys.com/download/firmware.asp?fwid=217 )
and place the 8MB firmware file found in the zip file into the TFTP
directory.

3. Connect to Redboot via Telnet. When the slug starts up, for a few
seconds it listens for a telnet connection on port 9000. Redboot will
insist on being 192.168.0.1 for this, whatever you've set the Linux
portion of your slug to be. Since this will conflict with other
equipment on many people's LANs, you may like to connect directly with
a crossover cable and ignore the network for the moment. NB: If you
have a fancy network card with auto-MDI (ie you don't need to worry
about crossover or straight-through, as with all new Macs, for
instance) you may end up missing the brief telnet window as the card
tries to work out what sex it should be today. Consider connecting via
a cheap hub which doesn't have such hangups. You will also need to
change your computer's ip address to one on the 19.168.0 subnet if it
isn't already.

Type the command telnet 192.168.0.1 9000 into a terminal window, but
don't press return just yet. Turn off the slug (pulling out the power
if need be, then plugging it in) and be ready to turn it on with the
power button. Press the button, then press return on your computer to
start the telnet connection. Some people report that they have to start
telnet at just the right moment to "catch it" - I find mine will sit
there with "trying 192.168.0.1..." as long as necessary until the slug
starts listening.

What you do need to be ready with is a finger on ctrl-c, as when the
Redboot prompt appears you will have between 2 and 0.1 of a second to
hit it. It's something of a reaction test - hold down control when you
start telnet, and be ready to mash C as soon as anything appears on the
screen. You should then get a Redboot> prompt that you can type at. If
you miss it, simply cycle the slug and try again.

4. Load the firmware. At the Redboot prompt, type the following command:
ip_address -h 192.168.0.99
where 192.168.0.99 is of course your computer. This tells Redboot where
to get stuff from. You should get your prompt back after each command;
I occasionally had it hang, in which case restart and do the ctrl-c
dance again.

Now do:
load -r -v -b 0x01000000 NSLU2_V23R25.bin
(assuming, of course, that you're using the R25 firmware). This will
load the firmware into the slug's RAM over the network.

For safety's sake, you can now do a checksum on the file to ensure it
didn't get corrupted in transit. Simply type:
cksum
and you should get a set of numbers calculated from the file. For the
R25 firmware, these should be: 3007264634 8388608 . If not (and you're
not using a newer firmware version), you should probably try loading
the file again.

5. Burn the firmware to the flash. Cross your fingers and do
fis write -f 0x50060000 -b 0x01060000 -l 0x7a0000
This will write the kernel, ramdisk and trailer portions of the
firmware to the right position in the flash. When it's finished and you
get your Redboot prompt back, your slug should be unbricked. Reboot it
to find out, and be ready to celebrate when you hear that strangled
little beep it makes as it finishes booting.

Because you didn't overwrite the SysConfig part of the flash, your slug
will still be using the same IP address as before you bricked it.
Remember to set your subnets appropriately, and ensure you're looking
for it in the right place.




== Acknowledgements ==
None of this is original material - my job has just been to collate it
in one place. So thanks to those who originally discovered and posted
it, in particular Irfan29200, Smakofsky, and Rod.

Pete