24694Re: [nslu2-linux] newbie: firmware flash now cannot access slug
- Dec 20, 2010Ok, 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).
- << Previous post in topic Next post in topic >>