This page explains what versions of firmware are compatible with which kernels. It also details the major changes in each version of the firmware. All dates are expressed in year-month-day format.
This is the most common firmware found on machines shipped until somewhere around October 1998. This version of the firmware has no support for ELF, so only a.out kernels can be used. Typically it would be the June 29 a.out shipping kernel, although later "ELF" kernels can be used if they are first converted to a.out format using the "vmelf" utility program.
This version of firmware will load the kernel directly from /dev/hda1 which should be a raw partition with the kernel located on the second block. There is no support for loading alternate kernels; if you corrupt the partition or write a bad kernel, the only recourse is to enable network booting and fetch a different kernel by tftp.
The 2.0 series of firmware supports loading of ELF kernels from a disk partition, from a filesystem, and via tftp (over the network). This means that the dedicated /dev/hda1 kernel partition is no longer needed, and instead the kernel can be stored in the /boot directory on the main filesystem (which can now be moved to /dev/hda1). The firmware allows you to select the name of the main kernel, so that it is possible to reboot even if a kernel fails. We ship a "vmlinux.rescue" kernel for this purpose.
This version of firmware also supports a multitude of options regarding the root filesystem. When network booting, one can specify the name of the server and the path on that server to be used for the boot. Previously, we relied on a DHCP server to provide this information. Now NeTTrom is independant and there is no need for a DHCP server (though one can still be used if you wish).
This version of firmware works with any of the official vmlinux-YYMMDD kernels from Oct 29 through to Dec 12, 1998.
This firmware at first glance looks very similar to 2.0.4, but there are substantial changes under the hood. The firmware is built natively on a NetWinder and this is itself in ELF format (previous firmware was cross-compiled in a.out form). The firmware is quite a bit larger as a result (about 650 kB compressed, instead of 450 kB). Therefore it takes longer to decompress upon startup.
The firmware uses a different method to pass the arguments (like the amount of ram, where to boot from, etc) to the main kernel. This firmware requires a kernel from 99/01/21 to function properly. Otherwise the arguments will not be passed properly and you may not be able to boot.
If you try to boot an older kernel with 2.0.6 firmware, that kernel will not receive the information it expects about the ram and root disk, and will therefore use its own default values. Typically these values were 8MB of RAM and a root device of /dev/hda2, stemming back from the time when we used the first partition as a dedicated kernel partition.
In the kernels made in 1999, we've changed the default values to 16MB and a root device of /dev/hda1, so even if the command line is not passed properly from the firmware, you have a reasonable chance of booting you system. Of course, not everyone has their machines configured the same way, so it is not a universal solution. Really the only "right" thing to do is to not mix older kernels or older firmware with the new versions.
The vmlinux.rescue image is now the same as the main kernel. Since it's easy to wipe out the kernel, we keep a second copy and call it vmlinux.rescue. Note that it's not the same file as the original vmlinux.rescue anymore, but the purpose is the same.
|Firmware < 2.0.6||Firmware >= 2.0.6|
|Kernel < 990121||No problems||The kernel won't understand the new-style command line and will boot using its defaults for memory and disk, which may not reflect what you actually have on your system. Typical symptoms would be: only 8mb of ram detected, and system insists on using /dev/hda2 (03:02) as the root filesystem (which will fail on all but the oldest of machines).|
|Kernel >= 990121||Should work, since the kernel is smart enough to detect when the new-style parameter structure isn't found, and it reverts back to the old style of command line args.||No problems|
Allows for a custom boot image to be displayed when the system is first powered on. The `logowrite' utility can be used to change the image. There are probably other changes too but they are locked inside Woody's brain and I haven't figured out how to extract them yet.
Update: Woody now has a document describing the logowrite utilities for putting images on the boot-up. See his page at netwinder.org/~woody.
Support added for SCSI daughtercard; uses a fixed 64kb block at the beginning (which will remain constant for ever and ever from now on). Able to handle 128M of RAM. Improvements to the param_struct that is passed to the new kernels. Serial downloading of kernels using xmodem is now possible, and at 115k it only takes two minutes.
|2.0.8a||disable debug print to COM2
made vga video bus width aware (32 vs 64 bits)
|2.0.8c||Converted "Corel" to "Netwinder", initialize parameter structure.|
|2.0.8d||permit booting without VGA chip, increased RAM window to 256M|
|2.0.8e||Added 2 bank/64M memory support, enabled debugger before minikernel and before real kernel boot.|
|2.0.8f||New xmodem CRC for uploading kernels, general cleanup. Renamed UART1 to default serial, UART2 is the second serial. Added PutByteHex function|
|2.0.8g||Compile everything with -O2 saves 11k of space, speeds boot.
Created a fixed 64k boot segment to eliminate need to update base flash block while modifying the rest of flash.
Fixes the bug where printenv on serial console would hang indefinately waiting for a keystroke at the `more' prompt. (this may have appeared in earlier versions but wasn't committed to CVS until now)
Notice: A number of these Nettrom's do NOT support tftp booting properly, due to an issue with arpa/tftp.h header file (see Scott's pages for more info). This is important because if you hose your disk you'll need working tftp support to get a kernel. At this time we know that 2.0.8e and 2.1.0 built in RPM format suffer this problem, as do some of the binaries in Woody's home directory. It is fixed in 2.1.5, but there is a new bug that doesn't allow the save-all command to work.
Note that the serial port speed is now increased to 115k from 19.2k. And the 2.1 minikernels initialized the width/height fields in the param_struct field to 640x480, but for some reason, this causes the framebuffer device to compute strange (nonstandard) scan rates for the video... resulting in squashed video, if your monitor can handle it... or no display at all.
Notice: A number of these Nettrom's do NOT support tftp booting properly, due to an issue with arpa/tftp.h header file (see Scott's pages for more info). This is important because if you hose your disk you'll need working tftp support to get a kernel. At this time we know that 2.0.8e and 2.1.0 built in RPM format suffer this problem, as do some of the binaries in Woody's home directory. As of version 2.1.5 this is fixed, but the "save-all" command is broken until 2.1.6..
Woody is getting way ahead of my ability to keep up with him, so for the time being, please consult his notes users/w/woody/nettrom.log directly.