OSDev.org

What do i need to do to find a file with a specified name on a fat12 partitioned disk in the boot sector

Read the root directory into memory and search for the file with the correct name. If you want to load that file, follow the cluster chain in the FAT.

Microsoft published a specification for FAT12 (and FAT16 and FAT32) as part of the EFI specification. Here's a copy of that specification converted to PDF. You can download the original Word document directly from Microsoft.

I've written code to load a file from a FAT12 partition on a hard disk. You can find it here if you're interested. (I've made a few updates recently that haven't yet made it onto Github... nothing important, though; just changing the load address.)

I don't think that is possible within the limited space of the boot sector. You need to load a second stage loader (from fixed sectors) in the boot sector, and then load the file in the second stage loader.

rdos wrote:I don't think that is possible within the limited space of the boot sector.

Sure it is! See http://www.brokenthorn.com/Resources/OSDev6.html

nexos wrote:

rdos wrote:I don't think that is possible within the limited space of the boot sector.

Sure it is! See http://www.brokenthorn.com/Resources/OSDev6.html

OK, it might be possible but it is still not a good idea. By keeping stage2 in the root directory you risk it getting deleted or corrupted, so a better idea is to place it in reserved sectors directly after the boot sector. Additionally, you might decide to format your boot partition as FAT32, EXT or NTFS, and then you need a new boot sector to load the second stage, and it might not be possible to handle reading the root directory of EXT or NTFS from the boot sector.

rdos wrote:By keeping stage2 in the root directory you risk it getting deleted or corrupted,

Everything is in the root directory! By that logic, you shouldn't store any part of your OS as files on the disk because that risks it getting deleted or corrupted.

rdos wrote:it might not be possible to handle reading the root directory of EXT or NTFS from the boot sector.

That's why EXT2 and NTFS have more than one sector for the boot "sector".

rdos wrote:it might not be possible to handle reading the root directory of EXT or NTFS from the boot sector.

That's why EXT2 and NTFS have more than one sector for the boot "sector".[/quote]
Well, you say that, but my previous attempt to write a real-mode ext2 file loader finally clocked in at 2048 bytes. Unfortunately, ext2 only gives me 1024 bytes of space (irrespective of block size, by the way).

However, those 1024 bytes are enough to load i-node 5 (which is the ext2 reserved i-node for the boot loader). So if I had gone that route, I would have had routines to load sectors in the first 512 bytes, routines to load i-nodes in the second 512 bytes, then skip 1024 bytes for superblock and block group descriptors, then routines to traverse directories in however much memory was needed.

But I never finished it. My main goal was to only use the first 1024 bytes. But it seems like that is just not enough space for

• enabling A20-gate
• testing if the CPU is acceptable
• loading second bootloader block and superblock
• traversing directories to find a programmable path name
• finally loading that one to the 1MB line
• mapping it as an ELF file
• doing the rest of stuff my kernel needs
• and finally transitioning to 64-bit mode

nullplan wrote:But it seems like that is just not enough space for

• enabling A20-gate
• testing if the CPU is acceptable
• loading second bootloader block and superblock
• traversing directories to find a programmable path name
• finally loading that one to the 1MB line
• mapping it as an ELF file
• doing the rest of stuff my kernel needs
• and finally transitioning to 64-bit mode

I don't think anyone is suggesting that you do all of those things within the EXT2 boot block; just finding and loading the second stage is enough.

Octocontrabass wrote:

rdos wrote:By keeping stage2 in the root directory you risk it getting deleted or corrupted,

Everything is in the root directory! By that logic, you shouldn't store any part of your OS as files on the disk because that risks it getting deleted or corrupted.

Not in my design. I can have several bootable images in the root directory, and if one is deleted or corrupt I can always boot the other. That's why I call the second one for "safe". However, the second stage loader only exists in a single instance, and it is never modified, so it's better placed in reserved sectors.

For UEFI boot, things are a bit more safe since the loaders & images are on it's own UEFI system partition.

You can have a separate boot partition on legacy BIOS too.

Late to the party, but here is also a fat32 implementation which loads a file in the "stage1": https://bitbucket.org/AlexOSAdventurer/ ... ot_stage1/ . This is if you're wanting something that will work with a large fat system. I heavily commented it to death too so it should be straightforward to understand the process.

ScropTheOSAdventurer wrote:Late to the party, but here is also a fat32 implementation which loads a file in the "stage1": https://bitbucket.org/AlexOSAdventurer/ ... ot_stage1/ . This is if you're wanting something that will work with a large fat system. I heavily commented it to death too so it should be straightforward to understand the process.

Well, it has no Bios Parameter Block (BPB), which can cause problems in non-Linux environments. I prefer to use the BPB and set hidden sectors so I can write the 2:nd stage loader directly after the boot sector instead of trying to push everything into a single sector.

My second stage loader includes a menu to select a boot file, and works with FAT12, FAT16 and FAT32. It also knows how to switch to protected mode, enable A20, and find the kernel device driver in the boot file so it can jump to it. It also knows how to scan for ACPI and to create a memory map from BIOS. My second stage loader is 7220 bytes (15 sectors), and there is no way to fit that into the boot sector.

I have no plans to support booting from EXT or NTFS, but I do have plans to support EXT as a filesystem.

The use of the BPB and hidden sectors is particularly useful for USB discs, as I can write the boot sector & loader, and format the boot partition with my OS, and then use my ordinary Windows PC to place boot images on them. This will not work with EXT hacks.

Hi,

Can just reference our fat32 boot code here which does have a BPB. It can be done, it just requires a lot of optimization to minimize the code as much as possible. Is it worth it? Honestly, probably not. It took a lot of effort to minimize the code to fit within the 512 bytes. Did learn a few new tricks though. Its been some time but my 2nd stage is easily >30k. Dont think anyone is suggesting to put that in 512 bytes.

I just made a major update to BootProg.
It may help with FAT-based booting (BootProg supports both CHS and LBA, FAT1x and FAT32).