Re: [nslu2-linux] The Compleat Unbricking
An easier way to "catch" the telnet window is:
sudo arping -f 192.168.0.1; telnet 192.168.0.1 9000
then, the telnet starts trying as soon as the IP address on the
'slug will respond, and all you have to do is remember to press ^C. :)
this may not help you right away (no "arping" on OS X by default),
but anyone with a linux box can probably use it now.
On Sep 3, 2004, at 5:53 PM, Pete Verdon wrote:
> 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
> 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
> 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:
> 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.
- Wow! Thanks!
Barely had the thing out of the box before I thought it was toasted. =)
I was just trying the standard Linksys firmware upgrade and something
went wrong and bricked it. This fixed it and took care of the upgrade
all at once. :)
Can't wait to see what I can get this thing to do.
--- In email@example.com, Pete Verdon <nslu2@v...> wrote:
> Extensive and extremely helpful instructions removed.
- When I first bricked my NSLU2, I contacted Linksys. They told me that
I should download thier upgrade utility for some Router and use that
utiltiy to force an upgrade on NSLU2. They did not respond to any
further questions. The utility was named BEFSR41V3_TFTP.EXE. I tried
and it did not work.
Since then I have unbricked my unit as described in Pete's post. But
I wonder if that utility was actually a TFTP server + telnet client +
some code that sends the ^C to redboot and interactively sends all
the commands to NSLU2 to set IP, load firmware and program the
portions of firmware using "fis" command.
I did not work for me probably since I did not do the timing of
pressing upgrade button and power button correctly. Or maybe as Pete
described the thing about the delay in confugring auto-midx sex of
the ethernet adapter.
I dont want to take the risk of trying it now since it was quite a
hardwork fixing it in the first place. But if somesome can dare try,
the utility is available on Linksys website as an upgrade utiltiy for
BEFSR41 ver 3.
- On 4 Sep 2004, at 05:45, Mark Rakes wrote:
> Pete,Do people really have problems connecting telnet at the right time,
> An easier way to "catch" the telnet window is:
> sudo arping -f 192.168.0.1; telnet 192.168.0.1 9000
> then, the telnet starts trying as soon as the IP address on the
> 'slug will respond, and all you have to do is remember to press ^C. :)
> this may not help you right away (no "arping" on OS X by default),
> but anyone with a linux box can probably use it now.
then? As I said in my instructions, I just start telnet more or less as
I press the power button, and it sits there waiting to connect until
the slug decides to listen. I'm just wondering if this is a difference
between Linux and BSD (ie OS X) telnet clients.