This section describes the stages that the NetWinder goes through when booting up, from the moment the power is applied until the login prompt appears. It also covers the common things that can go wrong.
When power is first applied, the first block of flash memory (64k) gets mapped in and executed. The first visible action is a quick probe of video ram, to determine how much memory there is. The screen is then cleared and the firmware version number and build date are displayed. Any logos that might be found are also rendered, along with the NetWinder logo animation if it is enabled. Meanwhile, the remainder of flash memory is read into RAM and the code therein is decompressed. There is a red progress meter shown at the bottom of the screen during this time. When the decompression is completed successfully, the screen fades to black, then the decompressed code is executed.
If the progress meter stops, then flash memory has been corrupted (or bad data was written to it). The only way to boot the NetWinder in this case is to hook up a serial terminal and to download a kernel via the serial port. For more details, see section 3.7 of the Firmware-HOWTO.html.
The system now boots into a small linux kernel. The screen clears and reverts back to text mode. In older versions, the full boot-up messages were displayed as the minikernel boots. In recent versions, only selected messages are shown to describe the hardware found. This kernel has the ability to mount a root filesystem in a variety of ways, as well as to fetch the main kernel in a variety of ways. There is a `firmware control menu' available here.
Normally, the minikernel loads a real kernel from the hard disk. The
parameters kerndev and kernfile specify the actual file in
this case (default values are /dev/hda1 and /boot/vmlinux
respectively).
If an invalid kernel filename is given, the firmware will stop with an error
message. The root filesystem however is a different matter: since it is not
mounted until the kernel boots, the firmware cannot report if an invalid
value is specified. So you won't find out until later, when the kernel says
VFS: Unable to mount root fs and proceeds to try booting from the
non-existent floppy disk.
After loading the main kernel into RAM, a reset is performed. Execution once again starts in the first block of flash code. However, this time it notices that its the second boot. Quickly, the RAM refresh is turned on and we jump directly to the main kernel.
If the main kernel is not bootable, the screen will stay dark at this point. This can also be caused by having inappropriate args passed from firmware to the main kernel (in particular, the amount of RAM on the system). Using old firmware with a new kernel will generally trigger this condition. Please see http://netwinder.org/~ralphs/compat.html for details on this.
The main kernel, generally loaded from disk, then goes through its normal boot sequence. Hardware is probled, devices are reported, and eventually the root filesystem gets mounted. This could fail, particularly if an NFS root is being used, for a variety of reasons.
Once the root filesystem is mounted, the kernel tries to start the
init program, which will then run through the SysV-style init
process. It will source /etc/inittab, which in turn sources
/etc/rc.d/rc.sysinit and then all of the /etc/rcN.d/S*
scripts (where N is the current runlevel, as defined in inittab).
Finally, getty's are launched on the various virtual consoles.