OSDev.org

Hi,

I am still tinkering with my FAT32 bootloader. It works well, but it makes the assumption that when it loads stage 2, it will find it in the first cluster of the root directory. I am trying to remove this assumption, so if the RD is longer than one cluster, it can lookup the FAT, find the next cluster, load it and continue.

I'm having problems reading from the FAT. I am using INT 13, AH 0x42 to read sectors. During startup, I set these values: My FAT starts at sector 0x20 (relative to the start of the partition), and the partition starts at 0x3F.
DAP is setup like this: I have tried several different ways to read from 07C0:1200, all of which are wrong. What's the best way to do this?

The RD cluster is located at the second entry of the FAT, so I think I need to read a DWORD from 07C0:1202. Is this correct, or do I have a misunderstanding?


Thankyou for your help

for one, sizeof(DWORD) != 2. - it's 4 bytes

Combuster wrote:sizeof(DWORD) != 2. - it's 4 bytes

Yes, I was aware of that. But as you have pointed out, I was adding 2 for the number of entries, not the size of two entries.

Works now. Thank you

My OS boot tools have FAT32 boot sector which loads kernel file from any location and file doesn't need to be in the first cluster of root directory. Will that help you?

Also boot loader should not process a directory infinitely long MS recommends to use limit 2 mb for this.

Doesn't FAT32 actually respect the reserved sectors count so you could use that for second stage? As opposed to FAT12 for example where support for it is dodgy at best.

bubach wrote:Doesn't FAT32 actually respect the reserved sectors count so you could use that for second stage?

Since that reserved sector count is hardly predicted and may be any value from 2 to 2^16 it is unfair to rely on that space. If you intend to place second stage loader there and there are no enough reserved sectors you need to reformat file system. Also what would you do for FAT16? I think that the better solution is to place second stage loader into file.

Yes, but as I said earlier, in FAT32 ReservedSectors value almost always greater than 2. Usually at least 12 sectors are available. So we can use 5 sectors for boot loader without any problems: 12/2 (2 copies) - 1 (FSInfo) = 5. My FAT32 boot loader size is 1 kb. My FAT1x boot loader size is same but its second sector usually is located in file or in reserved cluster because MS recommends to use ReservedSectors value 1 for FAT1x.

I have just upgrade my boot loader to support dual booting ELF32 or ELF64 kernel with CPU detection. If anyone interested I may just share it here. it's about 600 lines of mixed 16/32/64 bits assembly.
Tested on qemu-system-i386, qemu-system-x86_64(westmere host CPU) and macbook1,1 (oldest dual core)

Yoda wrote:My OS boot tools have FAT32 boot sector which loads kernel file from any location and file doesn't need to be in the first cluster of root directory. Will that help you?

egos wrote:Also boot loader should not process a directory infinitely long MS recommends to use limit 2 mb for this.

I'm trying to do similar things. Currently, if stage2.bin is in the first or second cluster of the root directory, it can be loaded without any problems. However, if I dump 150 files on the disk first, and then put in stage2.bin, I can't get it to load.

I think I need a better way of figuring out which sector of the FAT to load into memory. My current method is to get the RD entry, divide the cluster number by 128 (FAT entries per FAT sector). The quotient is the FAT sector number, the remainder is the entry in that sector.

eg, if the RD cluster is 0x2, 2/128 = FAT sector 0, entry 2
if the RD cluster is 0x83, 131/128 = FAT sector 1, entry 3.

I work with root dir by the rules. I'm reading root dir cluster by cluster, each cluster sector by sector to find required dir entries. Your method is right to get a next cluster link/EOF mark. Use a cache for FAT sector and this will be all right.