#	$OpenBSD: README.eltorito,v 1.1 1997/09/15 06:01:52 downsj Exp $
#	$From: README.eltorito,v 1.2 1997/02/23 15:44:59 eric Rel $	
What is El Torito?
------------------
Simply put, El Torito is a specification that says how a cdrom should
be formatted such that you can directly boot from it.

The "El Torito" spec says that ANY cdrom drive should work (scsi/eide)
as long as the BIOS supports El Torito. So far this has only been
tested with EIDE drives because none of the scsi controllers that has
been tested so far appears to support El Torito. The motherboard
definately has to support El Torito. The ones that do let you choose
booting from HD, Floppy, Network or CDROM.

How To Make Bootable CDs
------------------------

For the x86 platform, many BIOS's have begun to support bootable CDs.
The standard my patches for mkisofs is based on is called "El Torito".

The "El Torito" standard works by making the CD drive appear, through BIOS
calls, to be a normal floppy drive. This way you simply put an floppy
size image (exactly 1440k for a 1.44 meg floppy) somewhere in the
iso fs. In the headers of the iso fs you place a pointer to this image.
The BIOS will then grab this image from the CD and for all purposes it
acts as if it were booting from the floppy drive. This allows a working
LILO boot disk, for example, to simply be used as is.

It is simple then to make a bootable CD. First create a file, say "boot.img"
which is an exact image of the boot floppu currently in use. There is
at least one HOWTO on making bootable floppies. If you have a bootable
floppy handy, you can make a boot image with the command

dd if=/dev/fd0 of=boot.img bs=10k count=144

assuming the floppy is in the A: drive.

Place this image somewhere in the hierarchy which will be the source
for the iso9660 filesystem. It is a good idea to put all boot related
files in their own directory ("boot/" under the root of the iso9660 fs,
for example), but this is not necessary.

One caveat - Your boot floppy MUST load any initial ramdisk via LILO,
not the kernel ramdisk driver! This is because once the linux kernel
starts up, the BIOS emulation of the CD as a floppy disk is circumvented
and will fail miserably. LILO will load the initial ramdisk using BIOS
disk calls, so the emulation works as designed.

The "El Torito" specification requires a "boot catalog" to be created as 
ll.
This is a 2048 byte file which is of no interest except it is required.
My patches to mkisofs will cause it to automatically create the
boot catalog. You must specify where the boot catalog will go in the
iso9660 filesystem. Usually it is a good idea to put it the same place
as the boot image, and a name like "boot.catalog" seems appropriate.


So we have our boot image in the file "boot.image", and we are going to
put it in the directory "boot/" under the root of the iso9660 filesystem.
We will have the boot catalog go in the same directory with the name
"boot.catalog". The command to create the iso9660 fs in the file
bootcd.iso is then

mkisofs -b boot/boot.imh -c boot/boot.catalog -o bootcd.iso .

The -b option specifies the boot image to be used (note the path is
relative to the root of the iso9660 disc), and the -c option is
for the boot catalog file.

Now burn the CD and its ready to boot!

CAVEATS
-------

I don't think this will work with multisession CDs.

If your bootable floppy image needs to access the boot floppy, it has
to do so through BIOS calls. This is because if your O/S tries to talk to
the floppy directly it will bypass the "floppy emulation" the El Torito spec
creates through BIOS. For example, under Linux it is possible to
have an initial RAM disk loaded when the kernel starts up. If you let the
kernel try to read in the initial RAM disk from floppy, it will fail
miserably because Linux is not using BIOS calls to access the floppy drive.
Instead of seeing the floppy image on the CD, Linux will be looking at
the actually floppy drive.

The solution is to have the initial boot loader, called LILO, load your
initial RAM disk for you.  LILO uses BIOS calls entirely for these
operations, so it can grab it from the emulated floppy image.

I don't think making a CD bootable renders it unreadable by non-El Torito
machines. The El Torito spec uses parts of the iso9660 filesystem which
were reserved for future use, so no existing code should care what it does.

Mkisofs currently stores identification records in the iso9660 filesystem
saying that the system is a x86 system. The El Torito spec also allows
one to write PowerPC or Mac id's instead. If you look at the code in write.c
you could figure out how to change what is written.