OSDev.org

Posted: **Thu Dec 29, 2022 6:47 pm**

It's my first post here so please be kind and please guide me reformatting my question if something seems wrong to you !

Hello there,

I'm having a hard time figuring out how a BPB is used within a bootloader... Let's take the example of a FAT-16 formatted disk.I understand that the BPB is giving informations about how many sectors per clusters they are, how many FAT's, ... But what I don't get it is why do many bootloaders use dummy values for the BPB ?!

Taken from The Limine bootsect.asm :

Code: Select all

.bpb:
    times 3-($-$$) db 0
    .bpb_oem_id:            db "LIMINE  "
    .bpb_sector_size:       dw 512
    .bpb_sects_per_cluster: db 0
    .bpb_reserved_sects:    dw 0
    .bpb_fat_count:         db 0
    .bpb_root_dir_entries:  dw 0
    .bpb_sector_count:      dw 0
    .bpb_media_type:        db 0
    .bpb_sects_per_fat:     dw 0
    .bpb_sects_per_track:   dw 18
    .bpb_heads_count:       dw 2
    .bpb_hidden_sects:      dd 0
    .bpb_sector_count_big:  dd 0
    .bpb_drive_num:         db 0
    .bpb_reserved:          db 0
    .bpb_signature:         db 0
    .bpb_volume_id:         dd 0
    .bpb_volume_label:      db "LIMINE     "
    .bpb_filesystem_type:   times 8 db 0

Let's say I write a bootloader with "default values" for a FAT16 disk, how can I be sure that my BPB perfectly reflects the BPB created with a partition-formatting tool such as GParted ?

Similarly, a disk that is 4gb and another that is 8Gb can't have the same BPB. Like the Total number of sectors is clearly different in both of them ! So how come using defaults/garbages values for a bpb is manageable for a bootloader ?

Isn't this a preferable way to use the BPB that was created by a partitioning tool ? :

Code: Select all

%define bsOemName   bp+0x03         ; OEM label (dq)
%define bsBytesPerSec   bp+0x0B     ; bytes/sector (dw)
%define bsSecsPerClust   bp+0x0D    ; sectors/allocation unit (db)
%define bsResSectors   bp+0x0E      ; # reserved sectors (dw)
%define bsFATs      bp+0x10         ; # of FATs (db)
%define bsRootDirEnts   bp+0x11     ; Max # of root dir entries (dw)
%define bsSectors   bp+0x13         ; # sectors total in image (dw)
%define bsMedia    bp+0x15          ; media descriptor (db)
%define bsSecsPerFat   bp+0x16      ; # sectors in a fat (dw)
%define bsSecsPerTrack   bp+0x18    ; # sectors/track
%define bsHeads      bp+0x1A        ; # heads (dw)
%define bsHidden    bp+0x1C         ; # hidden sectors (dd)
%define bsSectorHuge   bp+0x20      ; # sectors if > 65536 (dd)
%define bsDriveNumber   bp+0x24     ; drive number, 0x80 of 0x81 for HDD(dw)
%define bsSigniture   bp+0x26       ; reserved (db)
%define bsVolumeSerial   bp+0x27    ; used for tracking volume between computers(dd)
%define bsVolumeLabel   bp+0x2B     ; disc label, padded with spaces(11)
%define bsSysID      bp+0x36        ; filesystem id(8)

Surely, I'm missing something here but I can't get my head around the BPB and why many bootloaders tends to overwrite a BPB created for a particular drive and prefer using one with defaults value that would potentially not reflect the real layout of the drive...

To add one more thing. I plan to write a bootloader that uses a FAT16 layout that's why I'm asking this question before getting my hands dirty and here is how I see things but apparently I'm wrong :

1. Format a disk using FAT16 (BPB is written in first sector)
2. Write my bootloader that keeps the BPB created before
3. Simply use dd or any other tool to overwrite the first sector (this operation should't modify the BPB)
4. Copy my kernel.bin to the drive
5. Find kernel.bin and load it since I have the BPB

Many thanks for your attention to my question !

Posted: **Tue Jan 03, 2023 9:33 pm**

bodanor wrote:But what I don't get it is why do many bootloaders use dummy values for the BPB ?!

That's for non-FAT filesystems. Some BIOSes won't correctly boot a USB flash drive without a BPB.

bodanor wrote:To add one more thing. I plan to write a bootloader that uses a FAT16 layout that's why I'm asking this question before getting my hands dirty and here is how I see things but apparently I'm wrong :

No, you're right. If your filesystem has a BPB, you shouldn't overwrite it. The dummy BPB is only for filesystems that don't include a BPB.

Posted: **Wed Jan 04, 2023 5:30 am**

Octocontrabass wrote:
bodanor wrote:But what I don't get it is why do many bootloaders use dummy values for the BPB ?!
That's for non-FAT filesystems. Some BIOSes won't correctly boot a USB flash drive without a BPB.

I heard about it that some bioses wouldn't boot if no bpb was present but I didn't know it was only for FAT filesystem ! Good that I asked about it then.

Octocontrabass wrote:
bodanor wrote:To add one more thing. I plan to write a bootloader that uses a FAT16 layout that's why I'm asking this question before getting my hands dirty and here is how I see things but apparently I'm wrong :
No, you're right. If your filesystem has a BPB, you shouldn't overwrite it. The dummy BPB is only for filesystems that don't include a BPB.

Since I've posted this, I've made some more researches and I think I have something that should work. Since I want to boot my kernel off a USB drive and additionally want to save my work on the USB itself, I'll formatted it with an MBR partition table and format the whole drive with a FAT16 partition. So I'll have to write code for the MBR to relocate itself and load the first 512 bytes of the fat16 partition (which will be the real bootloader btw). My next question is will this solution by AndyB be applicable ? viewtopic.php?f=1&t=26135

My first guess that, yes it should be applicable and I'll either write a makefile to create the image file and just have to burn to the USB drive. Additionally I guess if I change my mind and want to use an ext filesystem I could update my bootloader to recognize the filesystem that is being used and act accordingly to that I can load multiple filesytems later on. Can this be done ?

Again many thanks

Posted: **Wed Jan 04, 2023 12:05 pm**

bodanor wrote:My next question is will this solution by AndyB be applicable ? viewtopic.php?f=1&t=26135

I haven't tried it, but that will probably work for you. You might need to modify those steps to make sure the disk image will fit on your USB drive.

bodanor wrote:Additionally I guess if I change my mind and want to use an ext filesystem I could update my bootloader to recognize the filesystem that is being used and act accordingly to that I can load multiple filesytems later on. Can this be done ?

It can, but probably not in a single sector. I split my bootloader into two stages: the first stage fits in the VBR and only supports one filesystem, and the second stage is a file on the disk and supports as many filesystems as I like.

Posted: **Wed Jan 04, 2023 2:09 pm**

Octocontrabass wrote:bodanor wrote:
My next question is will this solution by AndyB be applicable ? viewtopic.php?f=1&t=26135

I haven't tried it, but that will probably work for you. You might need to modify those steps to make sure the disk image will fit on your USB drive.

bodanor wrote:

Of course 500mib seems way too much, but isn't there any technique to generate an image file that is can't of "dynamic" ? By dynamic I mean not having to specify the size manually and having dd can't off automatically determine the right size like a formula as : kernel size/ 512. Maybe I should compile my kernel and pass the size off it to dd now that I'm thinking about it...

bodanor wrote: It can, but probably not in a single sector. I split my bootloader into two stages: the first stage fits in the VBR and only supports one filesystem, and the second stage is a file on the disk and supports as many filesystems as I like.

Tha'ts actually a good strategy, work with a particular filesystem then load additional filesystems if needed. Many thanks !

Posted: **Wed Jan 04, 2023 2:36 pm**

bodanor wrote:Of course 500mib seems way too much, but isn't there any technique to generate an image file that is can't of "dynamic" ? By dynamic I mean not having to specify the size manually and having dd can't off automatically determine the right size like a formula as : kernel size/ 512. Maybe I should compile my kernel and pass the size off it to dd now that I'm thinking about it...

You can do that, but you need extra space for filesystem overhead, and there's usually a minimum partition size. For FAT16, the minimum partition size is about 4.1 MiB (with 512-byte sectors).

OSDev.org

Is it save to write a BPB with dummy values ?

Is it save to write a BPB with dummy values ?

Re: Is it save to write a BPB with dummy values ?

Re: Is it save to write a BPB with dummy values ?

Re: Is it save to write a BPB with dummy values ?

Re: Is it save to write a BPB with dummy values ?

Re: Is it save to write a BPB with dummy values ?