Re: [Etherboot-developers] image file format and BIOS use

[Ken Y. <ke...@nl...>]

|Isn't there another one called multiboot?  As for ELF, I will look for the

Multiboot is just a variant of ELF or a.out.

|documentation, but could anyone give me a brief description how it works
|regarding specifying parameters to be passed to the kernel (i.e. command
|line, initrd parameters)?

This explanation is valid for both ELF and tagged images, the only
difference between the types is the structure of the directory and the
segments:

The initial kernel parameters are specified to mknbi or mkelf. This is
stored in a segment of the image and loaded to 0x93400 (check first32.c
or mknbi for exact address). Etherboot then passes control to first32.c.
first32.c adds any string in tag 129 of the BOOTP/DHCP structure
(provided tag 128 is present and correct). It then scans the string for
special parameters: vga=, nfsroot=, and ip= then does the appropriate
substitution if it finds these. Other parameters are passed unchanged.
It then writes the offset of the parameter block from the floppy boot
sector (loaded at 0x90000) i.e. a 16 bit value, into a field inside the
floppy boot sector. This is the standard way the Linux kernel finds the
parameters. Finally first32.c relocates the ramdisk image, if any,
to the top of memory, and tells the kernel where this is by writing a
longword inside the setup segment of the Linux kernel.

The code you should read is, of course, first32.c. The low level
functions are in start32.S. Of course, you should start with mknbi-1.1,
not mknbi-1.0.

|Do you mean mkbni-linux adds code which calls the PCI BIOS?  (As opposed to
|BIOS calls in the Etherboot code.)

No, PCI BIOS support is only needed in Etherboot, not in first32.c.

|kernel.  But am I correct in assuming that mknbi-linux adds code which
|contains calls to the BIOS which is NOT part of the kernel image but which
|is expected to be executed at the time Etherboot passes control to the code
|in the file it downloaded?  Sorry for the long sentence :)

Yes, that's how it happens. first32.c does a bit of housekeeping before
chaining to Linux.

You might want to read the developers manual, link is from the Etherboot
home page. It's still work in progress and if there is anything you
don't understand, tell me and I know what more to write about.