This document covers the booting strategy for a nanoEngine
running Linux according to http://recycle.lbl.gov/~ldoolitt/bse/
This version corresponds to linux-2.4.18-rmk7.

****        THIS IS NEW TERRITORY        ****
****       READ CAREFULLY, AND ASK       ****
****  QUESTIONS IF SOMETHING IS UNCLEAR  ****

The Linux kernel build is configured to boot from ROM, via
  CONFIG_ZBOOT_ROM=y
  CONFIG_ZBOOT_ROM_TEXT=11000
  CONFIG_ZBOOT_ROM_BSS=c1e00000
So _if_ you load it into Flash, it _must_ go precisely at 0x11000.
If, on the other hand, it is loaded into RAM (via tftp), it will
correctly relocate itself and run fine also.

The 4 kBytes between 0x10000 and 0x11000 are reserved for the
transition layer I call nanofix.  The boot process must jump
to this routine, which will set up a tagged parameter list in
RAM at 0xc0000100, and then jump to the Linux kernel itself.
See src/nanofix/README for more info.

To boot from the net:
Boot: BSE 2000 May 19 2001 10:41:48
> load boot01 c0800000; go c0800000

Case 1:
  boot01 is (or is a link to) a mondo file (nanofix, followed
  by the kernel zImage, and then a compressed ramdisk image).
  nanofix will notice the gzip header following the kernel,
  supply initrd.start pointing correctly to the ramdisk,
  and specify boot=/dev/ram.

Case 2:
  boot01 is (or is a link to) an 8-byte jump file, that
  jumps to 0x1000, where a combo file (nanofix followed
  by the kernel zImage, and then a word of zeros to make
  sure nanofix will _not_ find a gzip header following the
  kernel) has been loaded.  nanofix will then specify
  boot=/dev/mtdblock2 so an initrd image in Flash can be
  loaded.  See Flash partitioning info below.

To boot locally, presumably after Case 2 above has been tested:
> go 10000

To make the above boot commands happen automatically at reset
or power up, set bootcmd.  E.g.,
> set bootcmd "load boot01 c0800000; go c0800000"

To load combo and rdisk.gz files into Flash, you can
either:

> load combo 10000
> load rdisk.gz c0000

from the nanoEngine boot monitor, or

# fcp combo /dev/mtd1
# fcp rdisk.gz /dev/mtd2

from the Linux shell prompt.  The former has the obvious bootstrap
advantage, but requires access to the serial console.  The latter
is nice because it can be performed over the network.  A power or
network failure in the middle of the fcp can, however, leave you
with a corrupted Flash copy of zImage or the ramdisk image.  This
process is therefore unwise when the bootcmd is "go 10000".  If
you are configured for a network boot, you can switch from Case 2
to Case 1 (with a known good mondo file) and regain full control
over the nanoEngine without needing access to the serial console.

The above discussion assumes Flash is configured from the Linux
kernel command line as follows:
  mtdparts=sa1100:64k(param)ro,704k(kernel),1280k(initrd),-(jffs2)
which produces the following result from "cat /proc/mtd"
dev:    size   erasesize  name
mtd0: 00010000 00002000 "param"
mtd1: 000b0000 00010000 "kernel"
mtd2: 00140000 00010000 "initrd"
mtd3: 00200000 00010000 "jffs2"
That mtdparts value is hard-coded as the default in nanofix/fixup.c,
but can be overridden with a "linuxboot" parameter in the nanoEngine
boot Flash.

If your combo or rdisk.gz files get much larger than the ones I
provide, you may need to adjust this configuration.  You always need
to keep the partitions divided along 64k erase block boundaries.

Files:
  rdisk.gz                    initrd image
  linux*/arch/boot/zImage     kernel image
  build/nanofix/fixup.bin     fixup code, maximum 4k
  build/nanofix/jump.bin      "jump to 10000"
  build/nanofix/combo         combination of fixup.bin and zImage
  build/nanofix/mondo         combination of fixup.bin, zImage, and rdisk.gz

Physical Memory map summary:
  0x00000000 to 0x0003ffff    Flash (4 Meg)
  0xc0000000 to 0xc1ffffff    SDRAM (32 Meg)

  0x00000000 to 0x00007fff    reserved for BSE boot monitor and parameters
  0xc0000100 to ?             Tag blocks
  0xc0004000 to 0xc0007fff    Page tables
  0xc0008000 to 0xc003ffff    uncompressed kernel copy
  0xc1e00000 to 0xc1ffffff    scratch space for decompression step,
                                may involve a copy of uncompressed kernel

Experts can probably find other interesting and useful ways
of juggling these files and boot sequences.

Once the machine boots Linux, the busybox init program takes over,
and runs the script etc/init.d/rcS .  You should take a look at that
file to make sure it does what you want.

        - Larry