OSDev.org

I got my bootloader working. Next thing is to load the file from the hdd from regular fat32 partition. currently i copied everything in raw sector format.
Seems like I need to implement small fat32 driver that knows how to traverse the partition and locate file from root dir and loaded. I had linux ext2 experience in the past, contemplated using ext2 but decided to go for fat32 since my dev environment is Windows.
Once get over this and bootloader is working, no need to copy the binaries that has been built with raw copy. Just file copy to target disk and test.

At least initially, i am just going to do very basic support for fat32:
- ability to load any file from root directory on fat32 only.
- only fat32 support, no fat16, extfs etc., and no other file system.

I looked around web, the best info I got so far seems wikipedia.
https://en.wikipedia.org/wiki/Design_of ... ile_system

I am looking to find a good book or other links to give very comprehensive information on FAT, that is not too complicated or too basic. Since FAT driver is not my main objective, I am thinking to do a very fast and quick development on this one.

Thanks.,

A good book that contains many basics including FAT32 and FAT in general is "Repairing and Upgrading PCs", 15th Edition or maybe a newer one.

It tells you which cluster numbers are reserved, which represent bad clusters, which are for EOF. It tells you how a deleted file looks like.

Other documents you will need are:
Long File Name LFN Specificaton ([url]htttp://www.osdever.net/documents/LongFileName.pdf[/url])
The Skinny on FAT, for floppies but can give you an excellent overview of the basics (http://scottie.20m.com/fat.htm)
FAT32 Specification (https://staff.washington.edu/dittrich/m ... gen103.pdf)



Also, try to create a disk image and try to format it with FAT32, then see if you can read and write files and directories. Then mount it (OSFMount in Windows, or mount commands in Linux).

You could make a test program using a formal library and other using your own code. Then you could compare the produced structures from 2 different FAT32 disk images and correct from there, from every doubt as to how to implement a fundamental feature and from any bug you get to distinguish, find and fully identify.

I could try to help making such code if you intend to make it immediately. Otherwise, it will probably be a long time before I also get to write a good tutorial about it because I don't know where to start without a full base or without further practical questions at the implementation and documentation level...

thanks, definitely will make use of it.!

ggodw000 wrote:Seems like I need to implement small fat32 driver that knows how to traverse the partition and locate file from root dir and loaded.

Super simple and easy - see disk.asm in the MikeOS-4.5_FAT32 and bootload.asm for the lowdown on The 1.44MB FAT32 floppy disk image.

mikegonta wrote:

ggodw000 wrote:Seems like I need to implement small fat32 driver that knows how to traverse the partition and locate file from root dir and loaded.

Super simple and easy - see disk.asm in the MikeOS-4.5_FAT32 and bootload.asm for the lowdown on The 1.44MB FAT32 floppy disk image.

Sweet Christ please stop posting this terrible hack everywhere.

There's a really good reason Windows will see that awful floppy disk and go "Oh, it has 32 megs of space", and that's because the minimum partition size FAT32 was designed for was 32 MB, using 512-byte disk sectors. Any real FAT32 driver will choke on that disk image because it'll try to write more than 1440 KiB of data to the disk and run out of sectors, even though the filesystem says there's plenty of room to go.

You are literally breaking several aspects of the FAT32 filesystem spec with this horrible example of "just because you found a way doesn't mean you ever should".

It's always good to know intricate details (like a minimum size of 32 Megabytes for a FAT32 partition).

Things are already long ago too plastic, so it's better to make the effort to develop things like this at the OS level and see what effects it has.

The opposing attitude is the one that made everything much duller since Windows XP, and I suspect that that's the point in time where most regular developers took the attitude to not explore and to artificially and excessively protect every subsystem and software product, leaving almost no reasonable room to make these sort of interesting tests.

Anyway, there is enough protection in existing software and if it's made well it won't fail, so we better keep making these sort of low-level tests to bring more specialized and key knowledge like in the 90's and 2000's.

Lately things have become very redundant, and about this topic, what we should be doing (including myself) would be to describe a FAT32 tutorial that teaches reusable elements at the implementation level (as in implementation-oriented programming and tutorial-oriented programming).

That's a better way to obtain information from others, and requires considerably more effort, but it's possible if done gradually, step by step and reported in the immediate term, and it's long missed (just see how little good material has been written lately and how few key tutorials are available in this decade or in the last 5 years).

Kazinsal wrote:

mikegonta wrote:

ggodw000 wrote:Seems like I need to implement small fat32 driver that knows how to traverse the partition and locate file from root dir and loaded.

Super simple and easy - see disk.asm in the MikeOS-4.5_FAT32 and bootload.asm for the lowdown on The 1.44MB FAT32 floppy disk image.

There's a really good reason Windows will see that awful floppy disk and go "Oh, it has 32 megs of space", and that's because the minimum
partition size FAT32 was designed for was 32 MB, using 512-byte disk sectors. Any real FAT32 driver will choke on that disk image because
it'll try to write more than 1440 KiB of data to the disk and run out of sectors, even though the filesystem says there's plenty of room to go.

That's not nice - saying that Windows doesn't have a real FAT32 driver.



You do realize that it is an actual floppy disk.

fatgen103.pdf wrote:The FAT type—one of FAT12, FAT16, or FAT32—is determined by the count of clusters on the volume and nothing else....
To begin, let’s discuss exactly how the “count of clusters” value is determined. This is all done using the BPB fields for the volume.

Kazinsal wrote:You are literally breaking several aspects of the FAT32 filesystem spec

You have the link, please show us these aspects.

wow that is a lot argc***.

I am going to write from beginning, it is easier that way than integrating other code.

~'s reference from UW was particularly useful. thanks.
used Esxi VM efi shell's dblk command to read and analyze disk blocks.
I have tried to use RW everything, does not seem to work well.

~ wrote:A good book that contains many basics including FAT32 and FAT in general is "Repairing and Upgrading PCs", 15th Edition or maybe a newer one.

It tells you which cluster numbers are reserved, which represent bad clusters, which are for EOF. It tells you how a deleted file looks like.

Other documents you will need are:
Long File Name LFN Specificaton ([url]htttp://www.osdever.net/documents/LongFileName.pdf[/url])
The Skinny on FAT, for floppies but can give you an excellent overview of the basics (http://scottie.20m.com/fat.htm)
FAT32 Specification (https://staff.washington.edu/dittrich/m ... gen103.pdf)



Also, try to create a disk image and try to format it with FAT32, then see if you can read and write files and directories. Then mount it (OSFMount in Windows, or mount commands in Linux).

You could make a test program using a formal library and other using your own code. Then you could compare the produced structures from 2 different FAT32 disk images and correct from there, from every doubt as to how to implement a fundamental feature and from any bug you get to distinguish, find and fully identify.

I could try to help making such code if you intend to make it immediately. Otherwise, it will probably be a long time before I also get to write a good tutorial about it because I don't know where to start without a full base or without further practical questions at the implementation and documentation level...

I had constructed some code to do following:
found boot.bin from the file system root folder and load to memory and execute. I did it in the MBR (which could be strange and violation) but I did not care it anyways. The only issue is I am not sure the tiny 512-64 bytes of space can fit the code because after typing wow it looks like a lot of code, i havent even tried to compile it yet, is what i did here silly trying to fit all those into MBR?:

; Here are the memory layout of needed sectors:
; 0000:7c00h - MBR
; 0000:8000h - 1st partition's 1st sector
; 0000:8200h - root directory entries (during search for boot.bin)
; 0000:9000h - executable binary, 1st 64KB. If executable binary is more
; than this size, it needs to relocate itself by allocating memory from
; BIOS E820h

How I figure out FAT32 struct from the spec is I actually created VM with one Windows installation (FAT32) and one target FAT32 4GB partition that is used for analysis and I did it all from efi shell using dblk command.

So overall:
P1=4GB partition in MBR had following info: 800h sector start, 9fe800h (size)
Loaded up sector 800h which is boot sector which contain all critical data for browsing root dir.

From there first data sector was calc-d using formula: Reserved_sector_count + 2xFAT size. which is found in my example to be:
103a+2x27e3=6000h. But this was relative to boot sector 800h so added 800h to get 6800th sector.

Dumped one more time the 6800h and all the content of the root directory was there.
I codified all these, i think it blew past 512 bytes easily.

Looking further, i see boot sector has a jump instruction on offset 00:04 which was hardcoded EB5890 which disasm-d to
jmps 05a
nop
It looks like relative jump to offset 90 (5ah) which makes sense since the FAT32 specification tells that the BPB and BS fields in boot sector continues exactly up to offset 90.
That seems to leave 612-90 bytes if I cram the boot code in there or I can try fitting in the MBR which has 512-64.

Give my BootProg a try (see boot32.asm).

hah I ll give it s try. I was also thinking what are those big reserved area before fat record? based on my calculation first sector of that area appears to be a boot sector. Not sure rest can be used for storing more larger code.

You may have gaps between partitions and you may have reserved sectors in FAT. AFAIK, reserved sectors are often used for big bootloaders/bootsectors. AFAIR, the Windows 9x "bootsector" is actually two or three sectors long.

that makes sense. the spec does not mention anything specific regarding how reserved area is used. So I presumed it is free to be used for any purpose. I see large No. of sectors available. So far I havent looked deeper into how it sits in regards to FAT partitions (between FAT? within FAT or before FAT etc). I only used the sum of fat1/2+rsvd to get to root directory content. It looks like a convenient place to put large bootloader related code.

ggodw000 wrote:I see large No. of sectors available. [...] It looks like a convenient place to put large bootloader related code.

The number of reserved sectors varies depending on the tool used to format the disk. Most tools provide only 32 reserved sectors (this number includes the boot sector, fsinfo sector, and backup boot sector).

Microsoft's FAT32 bootloaders use 2 sectors in total: the boot sector and one additional reserved sector. If you need more than that, you should probably store the rest of your bootloader as a file on the disk.