Due to all the reported problems and confusion regarding Maintenance
Mode in Unslung 4.20, the development team is considering a proposal
to remove Maintenance Mode altogether and use the built-in RedBoot
Upgrade Mode to perform all firmware upgrades. This email will
describe that proposal and seek comments. In the absence of serious
technical objections, the proposal will be implemented in the next
release of the Unslung firmware.
What this all means is that the current web upgrade page would be
replaced by a new page which does not actually upgrade the firmware,
but simply puts the NSLU2 into the built-in RedBoot Upgrade Mode
(alternately flashing red and green status LED) ready for the firmware
to be "pushed" to it using the Windows SerComm Upgrade tool or the
Linux UpSlug tool. There would no longer be any means to upgrade
firmware using the web interface alone - you would always require
either the Windows SerComm Upgrade tool, or the Linux UpSlug tool, or
RedBoot telnet access, to flash new firmware onto the NSLU2.
The major benefit of this proposal is that the RedBoot Upgrade Mode
works irrespective of which version of the Linksys, Unslung or
OpenSlug firmware you have previously loaded, so it is guaranteed to
work the same for all future versions, and we can finally document a
single, simple upgrade procedure. You can also enter the RedBoot
Upgrade Mode by holding in the reset button at power-on, or by typing
"upgrade" at the RedBoot command line. The RedBoot Upgrade Mode is
part of the built-in bootloader, which is not modified when you flash
The only potential downside of this proposal is if a user is unable to
get the Windows SerComm Upgrade tool or the Linux UpSlug tool to work
in their environment. At that point, they still have the fallback
option of flashing the new firmware via RedBoot telnet access. Note
that the ability to access RedBoot via telnet is a pre-condition of
using the Unslung firmware (it is rule #5 on the www.nslu2-linux.org
homepage, and has been listed in the README file for every version of
Unslung since day one), so we are guaranteed that anyone who has
loaded Unslung firmware also has verified RedBoot telnet access (if
they don't, then they didn't follow the rules, and therefore don't
deserve to be running Unslung firmware).
Also, note that once the RedBoot Upgrade Mode has been entered, you
cannot go back to the previously loaded firmware- you *must* flash new
firmware onto the device. There will be sufficient warnings on the
upgrade web page to make sure that users are aware of this fact.
The technical details follow:
1/ There would be a single upgrade.htm file which would be identical
in both the jffs2 rootfs and any external rootfs. A single "Enter
Upgrade Mode" button would call a new upgrademode.cgi script.
2/ The existing maintmode.cgi script would be replaced with a new
upgrademode.cgi script, and that new script would simply overwrite the
last block of the flash partition (/dev/mtdblock5) with all zeros
(thereby removing the SerComm trailer checkmark), and then reboot the
3/ When the NSLU2 reboots, the RedBoot bootloader will recognise that
the SerComm trailer checkmark has been removed, and will automatically
enter RedBoot Upgrade Mode.
4/ RedBoot Upgrade Mode waits (indefinitely) for a connection from
either the Windows SerComm Upgrade Tool, or the Linux UpSlug tool, and
receives the new firmware from that tool. There is no easy way to get
past this point without flashing new firmware which restores the
SerComm trailer checkmark.
5/ The NSLU2 reboots into the new firmware, and all is good with the world.
We are looking for serious technical objections only. Objections
along the lines of "I can't be bothered working out how to get RedBoot
telnet access" or "I can't be bothered downloading the Windows SerComm
Upgrade tool or the Linux UpSlug tool" will be met with a response of
"We can't be bothered having you as a community member - good luck and
goodbye". If you have a genuine technical situation where either of
those tools is not sufficient, then we are happy to discuss that.
Note that getting your Windows IP or subnet address wrong, or using a
10MB hub, are not valid problem situations.
Please post serious technical objections to the nslu2-linux mailing
list only (as that is the place were changes to the firmware are