FAT32 Bootloader

[Firestryke31]

Hello OSDev.org!

I develop on Windows, and don't want to have to boot into another operating system, or install file system drivers, and I especially don't want to write file system drivers for Windows. So I've decided that, for now, I'll just use a FAT32 drive for my O.S. It's pretty well documented, and I managed to understand what the various fields are. So I created a 63MB disk image, downloaded some software to let me mount it in Windows, formatted it, and tried installing a FAT32 version of GRUB. And failed repeatedly. Fed up, I decided to write my own FAT32 boot loader. The biggest requirement was to not have a fixed location for the second stage that would be a pain to update.

After a few days of writing and rewriting my code, I managed to get the attached file.

Pros:
Parses the root directory to find the file, meaning I don't have to do anything special to the second stage. Just drag and drop in Windows.
13 whole extra bytes!

Cons:
Makes a few assumptions
My first non-trivial assembly program
Not LBA (I tried and failed, so stuck with what already worked)

I wanted to put it up here to see if I could get help making it better. The two biggest things I need help with are handling when the drive is partitioned, and better optimization.

[Firestryke31]

...

Surely one of the 10 people that have downloaded this so far has a comment on it? Perhaps a "This code is a steaming pile" or a "I would do this part differently" or best of all a "Well, this code could be done in 4 lines instead of 8"?

I'm sorry if I sound rude, but I kind of want tips on how to improve it instead of just being glanced over and forgotten...

[AJ]

Hi,

Surely one of the 10 people that have downloaded this so far has a comment on it?

You need to remember that we are all doing this as a hobby. Certainly for myself, I download a file, but it can take a bit of time before I take the chance to read through code.

While I haven't attempted to compile and run your code, a couple of things that strike me about it on first glance are:

1) Very nicely laid out and commented - very readable and you have broken the code down in to functions in a very logical way, IMO.
2) What I don't like is the use of hex in the bpb for character arrays - that only serves to create more work for you (converting) and for the reader (converting back again!).
3) I think you should attempt more drive reads before jumping to readError.

If I get chance, I'll have a closer look later.

Cheers,
Adam

[Firestryke31]

1) Thank you! Honestly, I wrote code first ant went back for the comments
2) All of the values I put in the BPB are temporary values not ment to be copied and resolve to 0x01010101. I chose this value because it was easy to distinguish from the actual code, which was useful for the manual copy/paste of the compiled hex to my disk image's MBR. I should probably change them to 0s
3) I first wanted to get it working in the 420ish bytes available, then do all of the fancy error checking later. I should probably used some of those 13 extra bytes for this, though.

Thank you for you opinions, and I can't wait for more!

[Firestryke31]

Hey everyone, it's me again.

I've gone ahead and made it try the disk read a few more times in case of failure. This took me down to only 3 free bytes, but that's okay, it's what they're there for. I also, just for the fun of it, formatted one of my USB sticks and copied it (and FBOOT.SYS) and rebooted it up. I'm happy to say it works on a real computer, and now I just have to figure out how to handle a partitioned drive. Does Windows make the various sector and cluster offsets relative to the beginning of the partition or the disk? If it's the disk, then I think this will work on a partitioned drive, too. If not, then how would I go about figuring where on the disk I am?

I've attached the new code. Once again, optimization tips are welcome!

[AltexPape]

How did you compile it?

NASM is giving me operand errors...

Is it TASM?

[Troy Martin]

I believe it's FASM.

[Firestryke31]

I completely forgot about this! I've made a few changes over the past several months that make it smaller, but I don't really have anything to do with the extra space. I standardized my coding practices too, so it should be a bit easier to read. I've had another idea for making it even smaller but I'm not sure if I want to do it, since it requires a bunch of changes and testing.

Also, I use YASM for all of my assembly.

[AlexRocha]

I want your permission to use your bootloader with my own kernel. I´m starting to develop it and I was using GRUB, but I want another bootloader.

I copied the bootloader binary code to a FAT32 pendrive's bootsector (with a heximal editor), and used the following batch code to make an HD image:

Code: Select all

C:
cd "C:\Arquivos de Programas\Oracle\VirtualBox\"
VBoxManage internalcommands createrawvmdk -filename "C:\Documents and Settings\Alexandre\VirtualBox VMs\Universal System\usb.vmdk" -rawdisk \\.\PhysicalDrive5
pause>null

In Virtual Box,I choose this image to be my HD. When I tried to boot, the program gives me:
FATAL! No bootable medium found! System halted!

Please, someone help me!!

[bubach]

Wow this is an old post, chances are you won't get a reply. And here I was about to tell him not to use 32-bit registers in 16-bit mode, saving in on all those 0x66 prefixes added all over the place.

[VolTeK]

I want your permission to use your bootloader with my own kernel. I´m starting to develop it and I was using GRUB, but I want another bootloader.

Why not write your own? You would have a much better learning experience, that is guaranteed.

[jbemmel]

Could consider to align the stack by 4 by using 0x8002 instead of 0x8000

Also, be aware that on FAT32 the last 64 bytes before 0x55AA contain the partition table (4 x 16 bytes). If you write this bootcode to a USB stick, you render it unreadable

[Solar]

This thread was already decomposed when it was last necro'ed...

[Firestryke31]

Could consider to align the stack by 4 by using 0x8002 instead of 0x8000

0x8002 % 4 != 0, so 0x8002 is not 4-byte aligned. 0x8000 is, though.

Also, be aware that on FAT32 the last 64 bytes before 0x55AA contain the partition table (4 x 16 bytes). If you write this bootcode to a USB stick, you render it unreadable

That's the MBR, not the VBR. USB sticks are either 'superfloppies' (whole stick is one big FAT32 blob) or partitioned like a normal HDD but with only one partition (unless the user pokes at it like I did with my Linux recovery stick). Although it's been a while since I've last even seen that code so I have no idea if the code given is an MBR or a VBR.

I appreciate that you're trying to help, but please ensure that your information is correct before trying to assert it as such.

[jbemmel]

Could consider to align the stack by 4 by using 0x8002 instead of 0x8000

0x8002 % 4 != 0, so 0x8002 is not 4-byte aligned. 0x8000 is, though.

If you read the code, you will see that the first thing pushed is bx, followed by a bunch of 32-bit pushes. The stack is currently misaligned for the latter cases.

That's the MBR, not the VBR. USB sticks are either 'superfloppies' (whole stick is one big FAT32 blob) or partitioned like a normal HDD but with only one partition (unless the user pokes at it like I did with my Linux recovery stick). Although it's been a while since I've last even seen that code so I have no idea if the code given is an MBR or a VBR.

I appreciate that you're trying to help, but please ensure that your information is correct before trying to assert it as such.

My bad - I should have said "*may* contain the partition table". And thank you for educating me...