2010-02-24

2010-02-24 - Bootloading from a FAT Filesystem

Finished entering the code that I came up with last night, added a few tweaks to improve it, and also fixed some invalid pushes and pops.  First test suggests that it was successful, but an examination of the memory says it wasn't.  This problem was quickly tracked down to not having reset BX (the buffer address) back to 0, so it should have gone to 0x0600:0600 (or 0x06600).  After fixing that and a quick test, it loads the block successfully.  \ o /

Next I need to put a disk to the bootblock so that it is complete.  I think actually putting a kernel on may be a good start, and a load of other files just so that I can tell if sectors have loaded (instead of all zeroes).

The calculations for the start and length in blocks of the root directory have been successful, but the load is failing.  Going to examine the parameters being passed to the BIOS INT 0x13 call

The Drive and Head parameters were the wrong way round in DX.  Fixed that.  It's now loading the Root directory correctly, searching for the file, then loading the FAT correctly.  I don't think the search is quite correct though, it found the file even when I changed the filename to something wrong.

With one small exception, the first draft is complete, using 440 bytes of 512

First block of the file is being loaded correctly, but the FAT read to find the next cluster seems to have yielded incorrect results.

Fixed up the FAT reading code, there were a number of errors, and it seems to have read all the sectors of the Kernel into memory.  Just need to get the counter incrementing correctly so that they are not all written on top of each other, and it will be done.

Also need to test reading beyond Cylinder 0

\ o /  The counter is now incrementing correctly, and the kernel had been loaded, and I've put in the call to jump to the Kernel, and it's loaded up ... with 40 bytes of bootblock to spare

I am limited to the first 8Gb for loading the kernel by the BIOS, and I am also limited to 43'690 clusters by the cluster computation algorithm.  In fairness though, FAT12 is going to give up long before my code does.

As for performance, not so much.  The primary problem here is that I load the entire root directory into memory, scan that, then load the entire FAT into memory and scan that whilst loading the kernel.  Given that loading sectors from a disk is going to be quite slow, this may well be a significant performance hit.

Having done "the math" against a Windows XP formatted 1.44Mb floppy, the FAT occupies 9 sectors and the Root Directory occupies 14, so the "entire data" load that I was worried about clocks in at just under 12Kb, less than 0.5% of the disk ... so meh.

I still need to add retry code and a few failure paths, so I'll probably eat my 40 bytes fairly quickly.

In any case, I'm happy, I have a full FAT12 file finder and loader in 389 bytes of code (with some more for data)

The other avenue that this presents is the possibility that I could create a small FAT12 Partition on the Hard drive in my test machine and put my boot block in the first block of the partition, then have my OS booting from the hard drive (with a few tweaks).  I could then PXE boot a new kernel, and then get the kernel to save itself out of memory onto the disk.  It's no Windows Update ... but then again, this would work

Looks like I have some more debugging to do, just dropped the latest (~85Kb) kernel onto the disk image and it's failing to load.  Could be either filesize, or the location of the sectors, or both. :S  Back to the debugging ...

It has loaded 66 sectors, it is about to try to load cluster 0x034C, which I think is block 875, but I have tried to test them individually, and them seem to work.

No comments:

Post a Comment