![]() |
UpSlug2 is a tool to flash your NSLU2 from a computer on the same network. It is available for Linux and MacOS X. Windows users see below. Basic useSee below for how to obtain and install the program. To use it, first you have to put your NSLU2 into 'upgrade mode'. This is described here: UseTheResetButtonToEnterUpgradeMode. Then, to find a list of NSLU2 machines in upgrade mode, just run the upslug2 program with no options. (Note that UpSlug2 must always run as root): upslug2
If this doesn't find your Slug it means that either you have not put it in upgrade mode successfully, or the network connection between the PC and the Slug is not working (see the notes below about the network requirements). Or, if your PC has more than one network interface, you may need to specify one using If more than one Slug is detected you need to give the full ethernet MAC address (six pairs of hex digits separated by ':' characters) as the argument to the You specify the flash image using the upslug2 --target="xx:xx:xx:xx:xx:xx" --image="openslug.img"
As it runs the program will display progress information as it erases, programs and verifies the flash. When it completes it will reboot the Slug. Network RequirementsUpSlug2 requires a direct connection to the NSLU2 in the same Ethernet segment. This means it will not work if you have routers or NAT devices between your computer and the NSLU2. A WiFi connection via a wireless access point can be used, however a wireless connection is not as reliable as a wired one and some users do not recommended it for re-flashing the NSLU2. Obtaining UpSlug2If you use one of the following distributions you can install it from the usual package repositories, as follows:
If you have a Mac, you will need to build UpSlug2 from source, as described in the UpSlug2 on OSX page. Otherwise you can install from source as follows. The source code for UpSlug2 resides in the Subversion repository of the nslu2-linux project and has a standard GNU autotools configuration environment. You can fetch it from the repository at http://svn.nslu2-linux.org/svnroot/upslug2/trunk/ or you can browse it with trac. svn co http://svn.nslu2-linux.org/svnroot/upslug2/trunk upslug2
After you have downloaded the source code, use GNU autotools (i.e. cd upslug2
autoreconf -i
./configure
make
Note: On Fedora Core 1, I had to modify the configure.ac file, changing the expected versions for autoconf and automake to the following. AC_PREREQ(2.57)
AM_INIT_AUTOMAKE(1.7.8)
To build for MacOS X or other BSD-derived operating systems, see Main.UpSlug2onOSX. For other operating systems consult PortingUpslug2. Permissions
install -o root -g wheel -m 4755 upslug2 /usr/bin/upslug2
When made setuid the program only uses the root privilege to open the ethernet device ( Windows UsersIf you only have a Windows computer available you can make it run Linux temporarily just for UpSlug2, without affecting anything on its hard disk, by booting from a "Live" Linux CD such as Knoppix. Alternatively you could use the Sercomm Update Utility for Windows. Upslug2 does work with VMware Workstation. Note that the user must configure the VM to have access on the ethernet in Bridge mode. (Upslug2 requires layer 2 access on the network). You must be using version 6 or above of VMWare workstation. For a proof of Debian Etch running Upslug2 in a VMWare 6 pc, bridged network to a 64bit Vista Ultimate host, see here. Upslug2 also works from a virtual Fedora 7 on Microsoft Virtual PC / Vista. More specialized options for developers:With just the kernel image ("zImage-openslug") and the image of the JFFS2 root file system ("openslug-nslu2-date.rootfs.jffs2"): upslug2 --target="xx:xx:xx:xx:xx:xx" --kernel="zImage-openslug" --rootfs="openslug-nslu2-date.rootfs.jffs2"
To get more information about the options: upslug2 --help
If you need to use an ethernet device other than Remember you will need to run upslug2 as root in order for it to correctly access the ethernet interface on your host machine. Overwriting the boot loaderUpSlug2 has some of the functionality of The Changing the partitionsWith the options documented above a fairly standard flash layout is produced, matching that used in the OpenSlug image. It is also possible to write an old Unslung or LinkSys style image which has a Ramdisk partition and no jffs2 (Flashdisk) partition. The partition layout is as follows (assuming 0x50000000 base offset): RedBoot 0..0x3FFFF: the boot loader, cannot be changed.
SysConf 0x40000..0x5FFFF: system configuration, cannot be changed.
Kernel 0x60000..0x15FFFF: the compressed kernel, --kernel, limited to 1MByte by default. Changing the kernel to be bigger than this requires making an image with the four bytes at 0x160000..0x160003 (flash) or offset 0x10000..0x10003 in the image to be less or equal to 0x6A0000. upslug2 does not support this at present.
Ramdisk 0x160000..0x17FFFF: or larger. The ramdisk image, --ramdisk or the ramdisk payload --ram-payload. By default this is empty. With --ramdisk the given file is inserted as a compressed ramdisk image. With ram-payload the file is inserted into the partition, however the header is left at length 0 preventing RedBoot from copying a ramdisk image.
Flashdisk end of ramdisk..0x7DFFFF: variable size. The JFFS2 rootfs image, --rootfs. The partition fills the remainder of the flash (to the start of the FIS directory). The file must be smaller than the available space to allow the JFFS2 file system work space - at present an arbitrary free space minimum of one flash erase block (0x20000 bytes) is enforced.
FIS directory 0x7E0000..0x7FFFFF: the partition directory, as interpreted by the kernel. If given --payload specifies data to be included after the last partition entry. This data is preceded by a dummy partition name "\xffdat" and the length of the data file.
The image is terminated by a 16 byte signature which identifies the image as valid to RedBoot and includes the product ID, protocol ID and firmware version fields (each two bytes) plus an extra 2 byte version field. The defaults for these fields are taken from the LinkSys R29 image but may be changed by the corresponding Full information (from "upslug2 --help" output): Usage: upslug2 {options} options: -h --help: output this help message -d --device[eth0]: local ethernet device to use -t --target: NSLU2 to upgrade (MAC address) -f --from: MAC of host (this machine) -v --verify: verify only (do not write flash) -U --no-verify: upgrade only (do not verify) -n --no-reboot: do not reboot after upgrade -i --image: complete flash image to use -C --Complete-reprogram: overwrite RedBoot -k --kernel: compressed kernel image (zImage) -r --ramdisk: compressed ramdisk image (rootfs) -R --ram-payload: payload (replaces ramdisk) -j --rootfs: jffs2 (flash) rootfs -p --payload: FIS directory payload -e --endian[,b,b]: kernel and data endianness; [<kernel>],<data>[,<directory>] l: little endian p: pdp endian b: big endian -P --product-id[1]: 2 byte product id -T --protocol-id[0]: 2 byte protocol id -F --firmware-version[0x2329]: 2 byte firmware version -E --extra-version[0x90f7]: 2 byte extra version info Specify --target to upgrade an NSLU2 (or to verify a previous upgrade) without no arguments upslug2 will list the NSLU2 machines which are currently in upgrade mode (and do nothing else). Without --target upslug2 will only perform an upgrade if there is just one NSLU2 in upgrade mode. Specify --image=<file> if a complete NSLU2 flash image is available, if --Complete-reprogram is specified the whole flash image will be overwritten (the NSLU2 may become permanently unuseable if this is done), otherwise the RedBoot boot loader and the current 'SysConf' configuration is not changed. Alternatively specify --kernel and --rootfs to build the image which will be used to upgrade the NSLU2. In this case --product-id, --protocol-id and --firmware-version should be specified to set these fields in the flash image. Image endianness is detected automatically from the kernel. By default no byte swapping is performed (none is normally necessary). The --endian flag can be used to force byte swapping to occur. It takes three arguments separated by ',' characters to specify the endianness of the kernel, the data and the values in the RedBoot FIS directory (The above partition information is not accurate for Debian installations that use APEX - would someone like to update it?)
view ·
edit ·
print ·
history ·
Last edited by Tim Hastings.
Based on work by Tim Hastings, fcarolo, Reedy Boy, Ced, Meska, marceln, Phil Endecott, BrianZhou, bwalle, favorite_son, mhornsby, Rob Lockhart, Ed, jv, Michael Tomkins, Michael Tomkins michftgmailcom, tlhackque, Farhan Y, akauppi, Farhan Yousaf, PieteBrooks, hughhalf, Werner Teeling, mhomscheidt, Larry1981, cooper, vapier, Martin J Hsu, and jbowler. Originally by jbowler. Page last modified on July 19, 2008, at 09:32 PM
|