Boards with 1MB Flash

The early Bifferboards had only 1MB of flash, but were still useful for some applications. Here are a collection of links to assist with solving problems with 1MB boards. This board configuration isn't being actively developed, so there probably won't be any more kernel patches to help with this. It's therefore recommended to stick with if possible.

Start here

In order to run a Linux system in 1MB (and leave enough space for your application) it's necessary to use every trick in the book to reduce the firmware size. Kernel and initrd must be combined, so that they are both compressed together. Follow the link for a guide detailing how to compile your kernel and initrd.

Storing Data

1MB flash only leaves a couple of sectors over for storing data. Most people use the Biffconfig kernel patch to store per-machine configuration values in the kernel command-line, and then read them back with a script to parse /proc/cmdline at boot time. Follow the link for discussion related to this.

Kernel Patches, (may apply to later kernels)

These patches are of particular importance when running 1MB systems, so are noted here.

Block device precedence

The kernel won't boot from an initrd system if the block layer has been enabled. If the kernel has support for block devices then the bootloader needs to supply a 'proper' ramdisk as an argument to the kernel boot. Biffboot doesn't have support for this, and only knows how to boot a kernel. This allows one to have a Biffboot-compatible initrd, but then later access USB storage devices (e.g. for NAS applications).

Boot without maths emulation

Normally, when a system doesn't have an FPU the kernel makes a check for the kernel FPU emulation code. If not present the kernel refuses to boot. For embedded systems the overhead of having FPU emulation code (~20kbytes) that no user processes make use of can be unacceptable. The patch allows removal of FPU emulation on 486SX CPUs while still getting a boot.