Loading ...
Sorry, an error occurred while loading the content.

The Compleat Unbricking

Expand Messages
  • Pete Verdon
    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
    Message 1 of 7 , Sep 3, 2004
    View Source
    • 0 Attachment
      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
    • jkpeters_37
      Three notes: 1) redboot also supports HTTP; all you have to do is add -m http to your load command and specify a full path (from the doc root) to the file
      Message 2 of 7 , Sep 3, 2004
      View Source
      • 0 Attachment
        Three notes:

        1) redboot also supports HTTP; all you have to do is add '-m http' to
        your 'load' command and specify a full path (from the doc root) to the
        file you want ('/firm/myfirmware.bin', for example).

        2) Linux allows you to add an IP address to an existing ethernet card.
        In my case, I've got 'eth0' so I typed:

        # ifconfig eth0:1 192.168.0.2

        As long as you're not already using the 192.168.0 network, this won't
        confuse anything and will only exist until you reboot (or 'ifconfig
        eth0:1 down')

        3) The redboot command 'reset' will reboot without having to power-cycle.

        (And for the pedantimaniac in me, the order of the firmware sections
        is redboot, sysconfig, kernel, ramdisk, trailer.)

        --- In nslu2-linux@yahoogroups.com, Pete Verdon <nslu2@v...> 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.
        >
        > [...]
      • smakofsky
        Excellent document, Pete. Thanks for putting this together. This is the same route that I ended up going with to FINALLY get my box unbricked. I d also like to
        Message 3 of 7 , Sep 3, 2004
        View Source
        • 0 Attachment
          Excellent document, Pete. Thanks for putting this together.

          This is the same route that I ended up going with to FINALLY get my
          box unbricked.

          I'd also like to say thanks to Rod, who spent ALOT of time with me
          in IRC working through my unix-naivete, not to mention the tons of
          work he's done on the NSLU2 already.

          --- In nslu2-linux@yahoogroups.com, Pete Verdon <nslu2@v...> 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
          > 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
        • Mark Rakes
          Pete, 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
          Message 4 of 7 , Sep 3, 2004
          View Source
          • 0 Attachment
            Pete,
            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.

            hth,
            -mark

            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
            > 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
          • smiler_d
            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
            Message 5 of 7 , Sep 3, 2004
            View Source
            • 0 Attachment
              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 nslu2-linux@yahoogroups.com, Pete Verdon <nslu2@v...> wrote:
              > Extensive and extremely helpful instructions removed.
            • irfan29200
              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
              Message 6 of 7 , Sep 4, 2004
              View Source
              • 0 Attachment
                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.
              • Pete Verdon
                ... Do people really have problems connecting telnet at the right time, then? As I said in my instructions, I just start telnet more or less as I press the
                Message 7 of 7 , Sep 4, 2004
                View Source
                • 0 Attachment
                  On 4 Sep 2004, at 05:45, Mark Rakes wrote:

                  > Pete,
                  > 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.

                  Do people really have problems connecting telnet at the right time,
                  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.

                  Pete
                Your message has been successfully submitted and would be delivered to recipients shortly.