OSDev.org

Jump starting my os design project this week after long pause. Took me a whole day to re-familiarize.
Looks like I need to take the mini-fat32 driver more seriously and need to come up with several api-s.

I am almost certain on this: to read the next (2nd cluster No.) after obtaining first one from boot sector of volume, you basically offset into by 1st cluster No and read the 4 bytes for fat32 right?

here is the pseudo plan for load file from fat32 volume:

function load_file (in cluster_no_1st, in memDest)
----currCluster = cluster_no_1st
----start loop
--------read cluster currCluster into memDest
--------memDest+=ClusterSize
--------find next cluster No. (get it from fat32 table) - offset into curCluster in FAT and read the 4 bytes, that is your next cluster) -> nextCluster
--------currCluster = nextCluster
--------terminate and exit loop if currCluster is empty, bad or EOF.

It looks correct. What exactly is your question?

i was not sure my assumption was right regarding how to read second cluster and so on.
I had to boot to efi shell and dblk to search through a bunch of blocks and deciphering those hex-s to verify my assumption was right.
it was grueling task.

FAT documentation. it exists, it is small and it's a very easy reading. try it.)
PS.

after obtaining first one from boot sector of volume,

You take 1st cluster number of an entity from DIR_FstClusLO and DIR_FstClusHI fields of a directory entry. The only 1st cluster number in the BPB is the root dir's 1st cluster, on FAT32. And on FAT32, significant bytes are 28 not 32.

Looks like I need to take the mini-fat32 driver more seriously

yup, you do.

is it good approach to load all of FAT to memory? I initially thinking to load just 1 sector worth of FAT (128 entries) into memory at a time but it has too much complicacy:
if FAT pointer falls outside the current sectors and have to do a mathematical calculation to get which sector to load etc.,
Instead I just declared 64KB area for entire FAT assuming this is the limit (current size I see is much less than that).

zaval wrote:FAT documentation. it exists, it is small and it's a very easy reading. try it.)
PS.

after obtaining first one from boot sector of volume,

You take 1st cluster number of an entity from DIR_FstClusLO and DIR_FstClusHI fields of a directory entry. The only 1st cluster number in the BPB is the root dir's 1st cluster, on FAT32. And on FAT32, significant bytes are 28 not 32.

Looks like I need to take the mini-fat32 driver more seriously

yup, you do.

Yes i got it from directory entry. Initially (or probably just set it as permanent limitation), I am going to design such that only can work with directory entries in the root folder, but even though it was quite a bit, reading all these BPB-s and root dir entries and having to shuffle those numbers between CPU registers! I decided to use memory variables freely otherwise it is just too much!

I decided to use memory variables

I mean... that's kind of the point of memory.