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

24694Re: [nslu2-linux] newbie: firmware flash now cannot access slug

Expand Messages
  • Mike Westerhof (mwester)
    Dec 20, 2010
    • 0 Attachment
      Ok, this is getting really quite out-of-hand. I'm not sure which
      problem you are wanting solved, and I'm quite sure that the direction
      this thread has taken is going to waste a lot of your time and your money.

      Firstly, figure out what problem you want to solve, and lets focus on that.


      A) You sent a description, and video clip, that indicates that the NSLU2
      boots up, beeps, but cannot be found on the network.

      B) You've sent a lot of packet captures containing DHCP requests.

      C) You are unable to enter upgrade mode.


      The information in (A) indicates that the device is functioning as
      expected, with the exception that it cannot be found on the network. If
      this is the situation, there is a specific set of things we should do in
      sequence to progressively debug the problem. In general, we would like
      to confirm that the network port is functional from a hardware
      point-of-view, and we'd like to confirm that we can reach it through the

      The information in (B) is, to date, a complete red herring. Firstly,
      we're assuming (there's no evidence whatever) that the NSLU2 is, in
      fact, attempting DHCP. None of the packet captures show what they claim
      to show, quite frankly. But if we want to pursue this, we'd need more
      specific information -- such as the serial number of the NSLU2, which
      contains the last 3 octets of the MAC address -- and a completely
      private network consisting of nothing but a host system, the NSLU2, and
      a switch. Oh - and new cables. But even so, the absence of DHCP
      queries from the device is not a problem. If it was set to a fixed IP
      before, it is set to the same fixed IP now, so of course it won't DHCP.

      Option (C) seems to be driven by panic at this point. It was originally
      raised in order to add evidence that the device won't talk on the
      network. Somehow from there we've gotten to talking about the device
      being "bricked" and rushing off to purchase JTAG hardware (!!). How on
      earth did that happen?? The device is NOT bricked! There's still value
      in entering upgrade mode, though -- upgrade mode is driven by the
      bootloader, and its IP address cannot be changed. Therefore, it serves
      to remove variables from the testing process -- i.e. if we can enter
      upgrade mode, and one of the upgrade utilities can "find" the device on
      the network, then we know that the device is functioning, that the
      network hardware is ok on the NSLU2, and that our cables and switch are
      all ok. I'll also take this opportunity to mention that there is only
      ONE documented case of a device being unable to enter upgrade mode by
      the reset button, and that was a case where the reset button was
      damaged. So, testing that the reset button works is easy, and once we
      confirm that works, then it's simply timing and patience that will get
      the device into upgrade mode.


      So, which of the above do you want to work on? Do you want to work on
      finding the device on the network with the existing firmware (A), or do
      you want to continue to try to find evidence of its MAC address on the
      network for some reason (B), or do you want to try to reflash some
      firmware image (C)?

      Then let's focus on that single problem, and work it slowly and
      logically to a resolution (rather than the shotgun approach).

      -Mike (mwester)
    • Show all 24 messages in this topic