Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
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.
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
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.
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
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.
ANT - NT-like OS for x64 and arm64. efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).
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).
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
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!
key takeaway after spending yrs on sw industry: big issue small because everyone jumps on it and fixes it. small issue is big since everyone ignores and it causes catastrophy later. #devilisinthedetails
