No subject

for the fallback image to be appended. It didn't work because you didn't
have a fallback image at the top of the flash (the end of the image file).

Ron Minnich expanded on fallback vs. primary:

You need to build TWO linuxbioses, a fallback and a primary. The fallback 
is 64k. The primary is (romsize-64k). 

To build a romimage, you build the fallback, build the primary, then:

cat primary/romimage fallback/romimage > final_romimage

flash_rom final_romimage

Steve Gehlbach wrote about using BOOT_IDE:
See pcchips787.config in util/config for complete configuration.

option BOOT_IDE=1
This enables booting from IDE, the file to use is linux.bin.gz:

option IDE_BOOT_DRIVE=2
If you do not use drive 0  (default), then you can set which drive to 
boot; (0,1,2,3) are the four standard PC drives:

option ONE_TRACK=32
The linux.bin.gz file is put in raw form at partition 1, ie, the first 
partition on the disk.  This is located just past the partition table. 
The partition table size varies, it is "one track" from the beginning of 
the disk.  "one track" in c/h/s notation is "s" or the number of sectors 
per track.  ONE_TRACK is in sectors, the software multiplies by 512. 
Most disks are 63 sectors per track (the default), but my CF is 32 
sectors per track.  eg, the partion table is 63x512 or 32x512 bytes.

You can partition your disk as you want, but Linux goes raw in partition 
1; just make sure partition 1 is big enough, not a problem on today's 
disks.  You could put the Linux root file system on partition 2, for 
example.  In pcchips787.config, I put the Linux root file system on IDE 
0, partition 2 (I was experimenting with Linux in partition 1), but I 
eventually put Linux on drive 2 using CF.  You are right, copying of 
linux.bin.gz raw to the partition is dangerous, and something like "cat 
linux.bin.gz > /dev/hda1" will definitely screw the disk if you put the 
wrong disk or partition.  I recommend a shell script, fingers cannot be 
trusted.  You can also use "dd" but "cat" works.

Greg Watsons had some good comments on on the boot process and file layout:
There seem to be two main parts to linuxbios. The first is 
arch/{arch}/config/ctr0.base which does the very low level 
initialization, like turning on memory, etc. The second is 
arch/{arch}/lib/c_start.S which does whatever else is necessary to 
call the C function hardwaremain(). hardwaremain() then does whatever 
else is necessary to load Linux.

c_start.S is linked with linuxbios.a, a library containing generic 
support routines (those found in the lib directory) and anything 
specified using the 'object'  directive in a Config file (and other 
stuff). The resultant 'executable' is called linuxbios_c. The loader 
script used to link linuxbios_c is config/linuxbios_c.ld, and is 
configured to be loaded relative to _RAMBASE.

crt0.base is not linked against anything. Any additional assembly 
routines you need must be specified using the 'mainboardinit' 
directive in a Config file. This causes the specified assembly file 
to be added to "crt0_includes.h" which is in turn included at the 
start of crt0.base (or at the end in the case of the ppc version). 
The loader script used to link crt0.base is in 
arch/{arch}/config/ldscript.base. The resultant 'executable' is 
called linuxbios and will be loaded at _ROMBASE. The tricky thing is 
that this loader script will also load the linuxbios_c 'executable' 
at a location called _payload in this file. The main task of 
crt0.base is then to initialize enough hardware so that this payload 
can be copied from ROM into ram (which may also involve uncompressing 
code). Then control is transferred to _start, which is the first 
location in linuxbios_c.

To get an idea of how crt0.base works, look at the following files. 
This is the order of execution specified by the configuration file 
for sis735.

cpu/i386/entry16.inc
cpu/i386/entry32.inc
superio/sis/950/setup_serial.inc
pc80/serial.inc
arch/i386/lib/console.inc
cpu/k7/earlymtrr.inc
northsouthbridge/sis/735/raminit.inc
arch/i386/config/crt0.base

Next look at c_start.S which will show you what happens once control 
is transferred to _start. Finally, look at 
arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get 
Linux loaded.

Most other files are specific to particular hardware, so it can be 
pretty confusing to just browse the tree.

Hope this helps,

Greg