do some auxiliary functions, while dealing with the problems arising from
the history of the i386 architecture since 1978, incompatibilities, ex-
tensions, bugs, El Torito booting, Intel's Preboot Execution Environment
- (PXE) for network boot, etc. MirOS floppies use a specially limited ver-
- sion optimised for size, lacking support for any filesystem other than
- 4.2FFS and most commands.
+ (PXE) for network boot, the Multiboot Specification, etc. MirOS floppies
+ use a specially limited version optimised for size, lacking support for
+ any filesystem other than 4.2FFS and most commands.
It can be loaded either directly from the BIOS (most commonly via PXE;
earlier versions could also be loaded using El Torito), the bootxx first
implementing the COMBOOT API (specified by SYSLINUX, EXTLINUX, ISOLINUX,
PXELINUX) or MS-DOS(R) (unless DOS occupies the HMA). Once loaded, it can
be used, in a more or less limited fashion, to boot a MirOS kernel from a
- supported filesystem (4.2FFS, ISO 9660, FAT12, FAT16, FAT28, TFTP, NFS),
- inspect the filesystems, get or set machine information, or load other
- bootloaders (see below for details). It can inflate gzip(1) compressed
- files, set up serial console, and provides an interactive prompt.
+ supported filesystem (4.2FFS, ISO 9660, FAT12, FAT16, FAT28, TFTP, NFS,
+ and a pseudo filesystem called lmbmfs), inspect the filesystems, get or
+ set machine information, or load other bootloaders (see below for de-
+ tails). It can inflate gzip(1) compressed files (with LZMA compression
+ planned), set up serial console, and provides an interactive prompt.
Basic operation procedure is as follows:
- 1. Be loaded.
+ 1. Be loaded. However this is done, as the first thing we write a RETF
+ instruction to 0000:0000 and CALL FAR it (from 16-bit code), or
+ write a RET instruction to 0x00000000 and CALL it (from 32-bit
+ code), backing up the previous content of course, so that qemu+gdb
+ users can intercept via "b *0".
BIOS We are loaded to 0x07C00. The drive used to load us from
is passed in the DL register. The ES:BX and DS:SI regis-
more, we require the machine to be in Real Mode, not in
VM86 mode, so EMM386.SYS, Win32 or similar must not be
active. We ask DOS for the current drive to use this in-
- formation later.
+ formation later. DOS has set up a PSP (Program Segment
+ Prefix) for us, which may contain a command line which we
+ store away for later perusal if it is not empty.
COMBOOT We are loaded in a similar way as from DOS, except the
machine state is not changed as much from the initial
state. After determining that we are in fact loaded via
COMBOOT and not DOS, we ask SYSLINUX to terminate after
gathering information about the boot drive, partition, or
- PXE; the UNDI and PXE stacks are kept active if any.
+ PXE; the UNDI and PXE stacks are kept active if any. The
+ COMBOOT API has set up a PSP like DOS as well, which we
+ handle the same.
Multiboot We request to be loaded to 0x00100000 (the HMA) due to
GNU GRUB's limitations, save the boot device off the MBI
structure, copy ourselves to the final location, and
- switch back to Real Mode.
+ switch back to Real Mode. Modules passed to us by the
+ Multiboot compliant boot loader will be moved off to just
+ above 20 MiB in memory; their dirnames as well as any
+ command lines to the Multiboot modules are discarded. If
+ a command line is passed to the Multiboot OS kernel, i.e.
+ this bootloader, the pathname of the loader is skipped;
+ it is then cut off after a certain size limit (currently,
+ 256 bytes) and stored away for later use. The modules are
+ made available as regular files using the virtual lmbm
+ (Loadable Multiboot Modules) device and filesystem (in-
+ RAM file store, really).
During the initial operation, the stack is located about 80 KiB
behind the start of our own memory area, and switched to the final
location if the position in memory is known to be correct early.
2. System information (boot drive, potential partition table entry,
- PXENV+ and !PXE structure pointers) are stored in safe locations.
+ PXENV+ and !PXE structure pointers, multiboot module information)
+ are stored in safe locations.
3. The code is relocated to the final address once or twice if needed.
The final address is 4000:0000h with the stack beginning at
- 3000:FFFCh. The stack is shared between Real Mode and 32-bit Virtual
- Protected Address Mode. The code is mostly organised using the small
- memory model, with everything within 64 KiB (although the real limit
- is more than 256 bytes less than that due to initial loading is-
- sues), except some rather large uninitialised areas and the disc I/O
- bounce buffer, which begin at 3000:0000 and grow upwards. The heap
- begins after the bss section and grows up to just short of
- 9000:0000h.
+ 3000:FF7Ch. The 128 bytes in between, from 3000:FF80h onwards, con-
+ tains a potentially stored away PSP command line, before it is moved
+ to the buffer after the bss and ssbss sections have been initialised
+ (zeroed out). The stack is shared between Real Mode and 32-bit Vir-
+ tual Protected Address Mode. The code is mostly organised using the
+ small memory model, with everything within 64 KiB (although the real
+ limit is more than 256 bytes less than that due to initial loading
+ issues), except some rather large uninitialised areas and the disc
+ I/O bounce buffer, which begin at 3000:0000 and grow upwards, nick-
+ named the ssbss section. The heap begins after the bss section and
+ grows up to just short of 9000:0000h.
4. If the bootloader is compiled to do so, for example on a Live CD, it
displays a boot menu unless the shift key is pressed, and retains
the numeric return value for later, to replace the cfg suffix of the
- configuration file with it.
+ configuration file with it, unless a (non-empty) command line is
+ passed.
- 5. The IDT for the Protected Mode is set up.
+ 5. The system is switched to Protected Mode.
- 6. The system is switched to Protected Mode.
+ 6. If a command line was passed, it is moved from its original (Multi-
+ boot, above 1 MiB or way below in the real mode area) or temporary
+ (0x3FF80) location to cmd_buf.
7. The hardware is probed:
space, in case the BIOS reports wrong information.
+ o APM support
+ o PXE support
+ + o Loadable Multiboot Modules (if any, they are moved off to safe
+ locations and the virtual lmbm device and lmbmfs are set up)
+ + o Floppy disc drives
+ + o Hard disc drives, including El Torito CD-ROM drives
- 8. Unless a control key is held, the files /x.x.x.x/boot.cfg (where
- x.x.x.x is our own IPv4 address) and /boot.cfg (with cfg possibly
- replaced from the menu) are read and executed as if the commands had
- been entered on the loader prompt.
+ 8. If a command line was passed, it is executed. If it contained a boot
+ command, the kernel is attempted to be loaded; otherwise, or if it
+ fails, execution flow continues at the command prompt (see below)
+ with no timeout or auto-boot enabled.
- 9. The bootloader prompt
+ 9. Unless a control key is held or a command line was passed, the files
+ /x.x.x.x/boot.cfg if loaded via PXE (where x.x.x.x is our own IPv4
+ address) and /boot.cfg, with "cfg" possibly replaced from the Live
+ CD menu, are read and executed as if the commands had been entered
+ on the loader prompt.
+
+ 10. The bootloader prompt
boot> _
The cd9660, tftp and nfs filesystems do not support this command.
They will either always fail or always succeed with sane but
- unusable results. The FAT12, FAt16 and FAT28 filesystems have
+ unusable results. The FAT12, FAT16 and FAT28 filesystems have
hardcoded perms and uid/gid.
machine [command]
diskinfo Display a list of probed floppy and hard disc drives
including BIOS and geometry information.
+ exec dos Execute INT 21h, AH=4Ch, to return to DOS or SYSLINUX,
+ if possible. This will not always work and may hang
+ your system.
+
exec type image
Load a bootsector or other bootloader from an image
file and execute it. Currently known values for type:
boot> machine mem -0x100000@0x00F00000
- regs Debugging command displaying register dumps.
-
oldbios Enable or disable the so-called "Old BIOS / Soekris
helper", which restricts boot from loading more than
one sector at a time from disc.
+ pxe Forcibly scan for a PXE boot ROM.
+
+ regs Debugging command displaying register dumps.
+
macro Displays the names of all currently defined macros. Up to four
can be defined, holding up to 256 characters.
+ o fd0a:/bsd
+ o hd0o:/bsd.rd
+ o / (for "ls")
+ + o hd0a:/ (for "ls")
+ + o lmbm:/ (for "ls")
+ o cd0a:/boot/grub/stage2
+ + o tftp:/bsd.rd.i386
+ + o lmbm:/bsd4grml
+ + o /bsd
Disklabels are read from hard discs (BIOS drive >= 80h) by searching for
a primary MirOS partition first. The default partition type, 0x27, can be
Intel Corporation, Preboot Execution Environment (PXE) Specification,
Version 2.1, September 20, 1999.
+ Free Software Foundation, Inc., Multiboot Specification, Version 0.6.93.
+
HISTORY
This bootloader is based on code written by Michael Shalayeff for
OpenBSD 2.1. The separate pxeboot command first appeared in OpenBSD 3.5,
boot.cfg file was called boot.conf, it has been renamed for ISO 9660 and
FAT compatibility. A version called cdboot appeared in MirOS #8 and went
away for MirOS #10. The separate versions got merged into one bootloader,
- DOS, COMBOOT, Multiboot support, pagination, macros, the machine exec and
- cat commands, working chainbooting of bootsectors and GNU GRUB, faked
- disklabels (if none exist on disc), FAT filesystem support, and many more
- things were added or rewritten for MirOS #11 and grml by Thorsten Glaser.
+ DOS, COMBOOT, Multiboot support (including modules), pagination, macros,
+ the machine exec and cat commands, working chainbooting of bootsectors
+ and GNU GRUB, faked disklabels (if none exist on disc), FAT filesystem
+ support, and many more things were added or rewritten for MirOS #11 and
+ MirOS bsd4grml by Thorsten Glaser.
CAVEATS
The default location of the kernels and the boot.cfg file can be changed
at compile time.
-MirOS BSD #10-current February 1, 2009 6
+ FILESYSTEM SPECIFIC NOTES
+
+ ISO 9660 Filesystems above 4 GiB in size definitively do not work. We
+ do not know at this time if there is a 2 GiB or 4 GiB limit,
+ nor if this affects any other filesystems.
+
+ The ls command does not work.
+
+ lmbmfs This filesystem and device will only appear if loaded via a
+ Multiboot compliant boot loader, masquerading as Multiboot
+ compliant OS kernel, and when modules are passed. ls is possi-
+ ble only on the root directory ("/", "/."). Files keep the
+ names passed by the Multiboot boot loader, but have the direc-
+ tory part stripped, and can be accessed with any directory
+ leading. If they have no names, they are given an enumerated
+ hex number as name.
+
+ tftp, nfs These filesystems and devices will only appear of loaded via
+ PXE. They obviously do not support ls.
+
+ http There are plans to support this if pxebsd.0 is loaded from
+ gPXE, but no code yet. For now, gPXE can load boot using Mul-
+ tiboot, and any passed modules are handled via lmbmfs.
+
+ ustarfs This filesystem will be implemented soon.
+
+MirOS BSD #10-current October 27, 2009 7
projects / grml-live.git / blobdiff