Booting from CD under FDD emulation

[johnsa]

Well one of things i was trying to accomplish here, is that the 2 stage loader is unified, as in the exact same image works on cd, emulations, fdd, hdd.. not really needing pxe/network for now.. but it would be nice.

I already do a drive > 80h before attempting to use 13h extensions.. the problem is specifically this:
drive is = 00h (emulated FDD via cd-rom still reports as drive 0 from the bios). So the code doesn't know the difference between a real FDD and an emulated one.
The probing works well for real fdd's.. but seems to break badly when using a cdrom-fdd boot.. i have a bpb in the stage1 loader, purely for compatability sake even though i'll never use it.. the idea i have in mind for my fs doesn't require the traditaional fat12/32 layout, and my info would come afterwards.
I guess I could populate the bpb correctly when transfer the image to a disk (via a windows tool) if it's a floppy.. in which case the probing is totally unnecssary.
That said... how many ppl boot of floppies anymore? i haven't had a floopy drive in a machine for close on 6 years now

[Brendan]

Hi,

Well one of things i was trying to accomplish here, is that the 2 stage loader is unified, as in the exact same image works on cd, emulations, fdd, hdd..

In this case, the first stage creates some sort of "hand-off state" that the second stage relies on (which is unavoidable); and maybe this "hand-off state" could be improved. For example, maybe the first stage could put the drive number, sector size, sectors per track and number of heads into specific registers before jumping to the second stage (where the hard disk first stage can figure it out from BIOS functions and the floppy disk first stage can get the information from it's BPB).

Of course the first stage would need to do a bit more once you start supporting boot devices that can't be described by "drive number, sector size, sectors per track and number of heads". For example (for my own boot code), the first stage loads everything into RAM before starting the second stage.


Cheers,

Brendan

[johnsa]

Thats sort of how I have it now.. here is the flow I'm using as well as my thoughts (correct where wrong)..

Notes:
I assume that having the BPB is essential for two reason, one some bioses wont boot usb-fdd emulation without it (proven).. and two it is necessary to allow
the bioses function 08h to obtain the drive geometry info without probing. It is safe to leave it there for NON-FDD boots as it'll just be ignored.. IE hdd, usb-hdd, cdrom no emulation (mostly proven).

Stage#1
1) gets drive number in DL
2) if drive number < 80h
3) ; must be floppy (real, emulated USB-FDD or el-torito FDD-CDROM)
4) Obtain drive info from bios 08h/13h ; I presume this function in this case has relied on the BPB being present (which it is)
5) If that fails, use the probing loop assuming 2 heads, 80 cyl and working out SPT..
6) store these values to our info space for loading and stage#2... as well as a flag to indicate the mode..
7) else
; drive number is >= 80h so it must be a real HDD or USB-HDD, or el-torito HDD-CDROM)
9) Check for int 13h extensions
10) if extensions present
11) obtain int13h extensions drive geometry info
12) ; some times int13h extensions present but drive info fails.. in which case jump to else block (legacy fallback)
13) store these values to our info space for loading and stage#2.. also storing a flag to indicate which mode we're in..
14) else
15) fallback to getting drive info from bios 08h/13h
16) store these values etc.. etc.... as well as a boot/disk reading mode value..
17) end if

Stage#2 will obtain all these params and the boot mode from the info space in mem that stage 1 setup.. so it can in theory just safely use the same method..

So here are 2 questions...
1) How would I go about implement PXE/network booting into this flow (tbh i haven't read up anything on it yet)
and 2) Surely if the BPB was present in the stage 1 loader, the bios would load its values from there and even if the 512byte boot code was removed or replaced the bios would still be able to access this disk as it should've obtained the info it needs already? either when it loads the boot-sector, or perhaps when calling func 08h?

It seems to me as if that flow should handle any boot-scenario, based on the fact that the load-sectors code also takes into account if the reported sector size
is not 512 byte (it'll do the necessary divs to say work out how many 2kb sectors to load... I've also made sure that all resources, stage2, kernel etc are multiples of 2kb not 512byte to ensure that it can be loaded under either size sector)

[Brendan]

Hi,

Stage#1
1) gets drive number in DL
2) if drive number < 80h
3) ; must be floppy (real, emulated USB-FDD or el-torito FDD-CDROM)
4) Obtain drive info from bios 08h/13h ; I presume this function in this case has relied on the BPB being present (which it is)
5) If that fails, use the probing loop assuming 2 heads, 80 cyl and working out SPT..
6) store these values to our info space for loading and stage#2... as well as a flag to indicate the mode..

Why? If the drive is a floppy disk and the information in the BPB is correct and already in memory, then you've already got drive geometry and don't need to attempt to get it from the BIOS (or probe).

So here are 2 questions...
1) How would I go about implement PXE/network booting into this flow (tbh i haven't read up anything on it yet)

For PXE there's a "PXE API" you use. First you get the IP address for the TFTP server ("Get PXE Cached Info DHCP ACK Packet"). Then you use this IP address to open a file on the TFTP server, and once it's opened you read from the file (one packet at a time), then close the file. You don't use any of the BIOS disk I/O functions, DL contains nothing useful when the boot loader starts (there is no "drive number" because there's no drive). Instead the address of a "!PXE" structure is on the stack (which you use to find the PXE API entry point).

It seems to me as if that flow should handle any boot-scenario, based on the fact that the load-sectors code also takes into account if the reported sector size is not 512 byte (it'll do the necessary divs to say work out how many 2kb sectors to load... I've also made sure that all resources, stage2, kernel etc are multiples of 2kb not 512byte to ensure that it can be loaded under either size sector)

Here's a quick summary:

• Floppy: Get drive geometry from the BPB that's already in RAM and use "int 0x13, ah = 0x02" to read sectors. BIOS only loads the first sector of the boot loader from disk. Sectors are almost always 512 bytes.
  Hard disk: Need to support Int 0x13 extensions. Support for "int 0x13, ah = 0x08" and "int 0x13, ah = 0x02" is mostly optional now. Need to worry about partitions (e.g. code to figure out which partition you're booting from). Boot sector doesn't need a BPB but may need space reserved for a partition table. BIOS only loads the first sector of the boot loader from disk. Sectors are almost always 512 bytes.
  PXE/network: Entirely different in all possible ways. PXE ROM loads the entire boot loader from the network, not just one packet/sector. Packets typically contain 1024 bytes of file data (can be more or less, depending on the network).
  CD-ROM (no emulation): No need to bother with legacy functions (if El Torito is supported, then so is Int 0x13 extensions). Good idea to support ISO9660 (use the ISO9660 directory structure to find any files you need). No BPB and no partition table. BIOS is (meant to) load the entire boot loader from CD, not just one sector. Sectors are 2048 bytes.

These are all slightly similar, but different enough that attempting to support different devices with the same boot loader is a major pain in the neck.

Now, here's how I do things:

• Completely different boot loader for each type of boot device (optimized specifically for the type of boot device).
• Each boot loader loads everything the OS needs into RAM *before* it starts the next stage.
• Stage#2 doesn't need to care how to access the disk/network, and doesn't need to care which boot loader was used.

This is much more flexible - anyone could write a new boot loader without changing the second stage or anything else. For example, currently I support GRUB (as a legacy thing, for people who dual-boot and already have GRUB installed), and in the past (previous versions of the OS) I've had code to boot directly from the motherboard's ROM (although booting from a PCI card's ROM might be more practical). I'm planning to add support for UEFI/EFI one day too; and I'll eventually implement a "fast reboot" option (where the OS loads stuff into memory and jumps to the second stage).


Cheers,

Brendan

[johnsa]

Started looking at the PXE spec, and I can definately see that there is no way I'm going to unify that with the other boot-loaders.. a) due to how different it is.. and b) the extra work for the 1st stage to be able to determine that it's pxe and do something about it.. that assuming it's limited to 512 bytes (to be generic).
So PXE boot loader is definately going to be a different version.
The one thing that I'm thinking of with regards to simplifying the other versions is that if I am going to write this onto a real HD, I don't need to support partitions as I would never use it. So in both fdd/hdd and emulated usb cases etc all the necessary parts for the OS are not files as such but just sequential at the start of the disk... 1 sector stage1, 32 sectors stage2 and so on... my stage 2 loader contains the necessary info on where to locate the file-system control structures..
.. But now that I say that I'm starting to think maybe having different loaders isn't a bad idea.. except what would happen if you write the loader to a usb for example, you have no way of knowing if it's going to try and load it as a hdd or fdd emulation (depends on the bios in question)..so at the very least
the one loader should be able to handle fdd/hdd and int13 extensions and all that in one.. just in case