0

I am currently working on a simple operating system (GitHub: https://github.com/Nutty000/PlanetOS)

I would like to make the os work on real hardware, but I am having trouble doing it because of the file system... I want my OS to be based on the FAT32 file system, but I need to somehow not overwrite the BPB which is on the MBR. I thought about writing a program that copies the existent BPB and puts it in the beginning of my .bin bootable file, but:

  1. I have no idea how to make that program, disk related stuff is too hard and confusing for me

  2. The BPB is too large and if I copy it then my bootloader code wont fit in 512 bytes

  3. I don't know what parts of the existent MBR code I should copy

I am trying to solve this for hours so excuse me if I make any grammatical mistakes.

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Nutty
  • 33
  • 6
  • When BIOS loaded your boot sector at the linear address 0x07C00, your [BPB](https://euroassembler.eu/maclib/bioss.htm#BPB_FAT32) is already present at 0x07C0B, its size is 79 bytes. – vitsoft Oct 25 '21 at 20:55
  • Copying an existing BPB into your `.bin` should be done like `dd conv=notrunc`, overwriting in-place not appending. It doesn't change the file size. Look at some example MBRs that leave room for a BPB with a bunch of `dw` data fields near the start that they `jmp` over. e.g. [Is the BPB necessary for a bootloader to load correctly in Bochs?](https://stackoverflow.com/q/29257695) / [Why does my bootloader code works everywhere except my laptop if I have a BIOS Parameter Block?](https://stackoverflow.com/q/62589966) / [this](https://stackoverflow.com/a/42144059) – Peter Cordes Oct 25 '21 at 22:30

2 Answers2

3

There's no BPB in the MBR. You are mixing two types of bootsector.

The MBR (Master Boot Record) is the very first sector on the disk. It contains partition info in its partition table that starts at offset 01BEh. In this kind of bootsector, the first 446 bytes (512-64-2) are available for the bootsector program whose task it is to load the DBR.
The DBR (DOS Boot Record) is the first sector on the partition that was set bootable from the partition table. This kind of bootsector does contain a BPB (BIOS Parameter Block). For FAT32, it occupies the first 90 bytes. Considering the mandatory bootsector signature at the end, you have 420 bytes (512-90-2) available.

I have no idea how to make that program, disk related stuff is too hard and confusing for me

That's too bad for someone that wants to create their own OS.

The BPB is too large and if I copy it then my bootloader code wont fit in 512 bytes

You'll have to optimize your code for codesize. The required structures are what they are.

I don't know what parts of the existent MBR code I should copy

First copy the existing DBR from disk to a file eg. 'MyDBR.bin'. Then write your bootsector like this (FASM):

  jmp begin
  nop
  FILE 'MyDBR.bin':3,87
Begin:

  ...

  times 510-($-$$) db 0
  dw 0AA55h
Sep Roland
  • 33,889
  • 7
  • 43
  • 76
  • 2
    The MBR has a BPB if the disk is a floppy disk. – fuz Oct 26 '21 at 14:12
  • 1
    @fuz: A larger storage unit formatted like a floppy diskette, with a BPB in the first sector, is also called a "superfloppy". – ecm Oct 26 '21 at 15:57
3

For MBR

The only case where the MBR "should" (see note) have a BPB is for un-partitioned disks, where the first sector of the disk is also the first sector of the file system. This is primarily old floppy disks and nothing else (everything else either uses partitions or a file system like ISO9660 that has different rules).

Note: "should" means some operating systems (e.g. Windows) will whine about the disk being unformatted if there's no BPB. There's no strict requirement from firmware or hardware for a BPB to exist; and your OS can make up its own rules for what it wants.

For old floppy disks, typically an OS developer does the reverse - e.g. they'll have (or write) a utility to create floppy disk image/s that are the right/desired size (e.g. 1440 KiB for standard 3.5 inch floppy disks) that creates a suitable BPB for that floppy disk format; then copy the image into whatever floppy disks they want without caring about the floppy disk's previous contents (possibly immediately after, or as part of, formatting the floppy disk). More often (now that floppy disks themselves are so obsolete that they effectively don't exist in practice) the floppy disk image is used directly in an emulator, or incorporated into a CD image/ISO and used for floppy emulation, where no physical floppy disk (and no "previous contents") is involved.

If you ever actually do need to write a new first sector of the disk while preserving an existing BPB; then you can write a utility to do it (e.g. read the old 1st sector into a buffer, then overwrite the first few bytes before the BPB and the remainder after the BPB in the buffer, then write the modified buffer back to disk); or you might be able to use existing tools (specifically, the dd utility on most *nix systems).

Also note that FAT32 doesn't make sense for floppy disks (due to the tiny size of the volume you'd want FAT12 instead).

For 1st sector of FAT32 partition (not MBR)

For partitioned disks, if you use FAT32, the first sector of the partition may contain the 1st sector of a boot loader (for BIOS, not UEFI) in addition to the BPB (required by FAT32 file system). In this case it's mostly the same solutions applied to a different sector (e.g. overwrite with a good BPB to suit the partition/disk, or use tools to preserve old BPB and only modify the "non-BPB" portions of the 1st sector).

Note that eventually you'll end up writing some kind of OS installer that allows the user to create partition/s, format partition/s and install the OS on the new partition/s (including boot loader/s and lots of other files). Typically the OS installer you write will run on top of the OS you wrote (and be booted from CD or USB); and will recycle a bunch of utilities you wrote for your OS (e.g. partition management tools, etc) in addition to using your kernel, your drivers, etc.

  1. I don't know what parts of the existent MBR or 1st sector of partition code I should copy

The location and size of the BPB depends on which version it is. Fortunately they're all described on wikipedia (at https://en.wikipedia.org/wiki/BIOS_parameter_block ).

Mostly, to cover "worst/largest case", you want to ensure that your boot loader doesn't use offsets 0x000B to 0x0059 (and that whatever tool/s you use to merge the boot loader's 1st sector with a pre-existing BPB preserves the bytes from offsets 0x000B to 0x0059).

Of course with a 512 byte sector size, losing about 80 bytes for the BPB can make it even harder for 1st sector of boot loader to contain the code needed to find the right partition and then either load the remainder of itself or 2nd stage (especially if there's adequate sanity/error checks and adequate error messages). Sometimes people alleviate the problem by setting some variables (e.g. "LBA of 2nd sector in partition") when the boot loader is installed (which is relatively easy if you wrote your own boot loader installer).

Brendan
  • 35,656
  • 2
  • 39
  • 66
  • 1
    No requirement from the firmware for a BPB to boot an MBR, but some BIOSes will overwrite bytes of your MBR with unwanted BPB bytes in some cases, according to Michael Petch. [Bootloader works in emulators but not on real hardware](https://stackoverflow.com/q/41911606) / [Custom bootloader booted via USB drive produces incorrect output on some computers](https://stackoverflow.com/q/47277702) show it booting but doing weird things. Perhaps those bootloaders happened to have a couple bytes somewhere the looked like a BPB signature to a rough heuristic, or maybe those BIOSes just blindly copy. – Peter Cordes Oct 26 '21 at 05:54
  • 1
    @PeterCordes: Yes. For those cases the correct solution is to partition the USB so that firmware doesn't have to try to emulate obsolete junk (and so that you don't have to compress "many MiB" of kernel+drivers+everything else" into a measly max. of 2.88 MiB of emulated floppy space). ;-) – Brendan Oct 26 '21 at 06:10
  • 2
    Sure, just wanted to make the point that it's possible that a BIOS will boot your MBR but mess it up. The way that early part of your answer described things wouldn't remind future readers to consider that possibility when seeing if things worked without leaving BPB space in their MBR. Since bare PC hardware doesn't have debug facilities, it's not something you'd just notice when single-stepping because you can't do that easily. – Peter Cordes Oct 26 '21 at 06:18
  • 1
    I didnt expect such long and useful answers on my question, thank you so much for helping me out, i was trying to solve this problem for hours! – Nutty Oct 26 '21 at 06:38