FSINFO on FAT32

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi freaks,

 

Could someone tell me where is the FSINFO structure is stored in the FAT32 filing system.  My guess is its that it's after the Reserve Section...

 

Wm. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely it's wherever the BPB says it is? Apart from the MBR/BPB almost nothing else in FAT has a fixed position. Having said that isn't it normally something lime 6 sectors after the BPB? To be honest it thrashes memory and because it's effectively optional it might be best avoided on any kind of media that is prone to wearing out.

 

PS isn't all this stuff on Wikipedia anyway?

 

EDIT answering my own question, yes it is https://en.m.wikipedia.org/wiki/... - in fact I think you'd be pretty hard pushed in FAT to find anything that isn't explained in FATgen103, Wikipedia or both. (I'd always look to fatgen103 first if I were you)

Last Edited: Sun. Dec 2, 2018 - 02:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Clawson.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One other question, I've looked at sample SD cards that I've formatted and they have data, "lots of zeros" at the start.  I also have a book, however both these differ on the Reserve Region, aka the Boot Sector.

The book starts with the Reserve Region, however the sample SD cards start with the BIOS parameter block where all the zeros are found.

 

Can I assume that I don't require BIOS parameter block?

 

 

EDITED: it must only be used on partitioned devices

Last Edited: Sun. Dec 2, 2018 - 07:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

FAT partitions come in two forms. When an FS starts to read a FAT device it does not have any idea where to look for anything. So all it can do is read sector 0 and hope to find something of use there. There are two options:

 

1) this is a "multi-partition device" (which can also mean a multi-partition device that has only ONE partition in fact!!) in which case sector 0 is an MBR (Master Boot record). If this were a PC then there'd actually be some initial x86 code in the MBR but as SD/MMC are generally used on all kinds of other devices (phones, cameras, microwave ovens, etc etc) these days then often there is no boot code so the only thing of interest is the (up to) 4 entry parition table at offset 0x1BE. Each entry is 16 bytes. On an SD/MMC card (assuming there is an MBR) it's often just the entry from 0x1BE to 0x1CD that is used. While the partition table entry holds old style CHS offsets you can ignore those - LBA took over 30+ years ago so the only real field of interest are the 4 bytes that give the LBA of the absolute sector start of the partition. So you would then read that and move on to...

 

2) many cards/storage devices don't bother with an MBR in which case sector 0 is a BPB or if (as in (1)) sector 0 was an MBR then the offset field of the first partition (big assumption!) will give the absolute sector where the BPB is located.

 

FAT all centers around the BIOS Parameter Block (BPB). As explained in the (mandatory read!!) FatGen103.[doc|pdf] from Microsoft this key table of info tells everything necessary to locate all the other important areas of the storage - how many FATs there are, how big they are, where the first sector of the root dir is and so on.

 

So you have completely misunderstood FAT12/16/32 is you ask the question "Can I assume that I don't require a BIOS Parameter Block". Maybe you meant "Can I assume I don't require an MBR?"? Yes, that is OK, as I say, FAT reading systems are happy for (2) the sector 0 to be a BPB rather than an MBR which then requires an indirection to read the BPB.

 

BTW I will mention this:

 

https://spaces.microchip.com/gf/...

 

and in particular:

 

https://spaces.microchip.com/gf/...

 

because, AFAIK, that is the absolute minimum you need to read a file from a FAT formatted storage device. As my pretty picture shows:

That shows the exact sequence required to find/read one file in the root directory. My code does make the sector 0 = MBR or BPB decision when it does:

  156         BPBSec = 0;
  157         disk_read(BPBSec); // first sector is either an MBR or a boot sector.

  158         // Offset 11,12 in BS/BPB is BPB_BytesPerSec and will be 512 (if BPB not MBR)

  159         p16 = (uint16_t *)&Buff[BPB_BytsPerSec];
  160         BytesPerSec = *p16;
  161         if (BytesPerSec != (uint16_t)512) {
  162             // We almost certainly have an MBR so need to get "sectors preceding partition 1" at offset 0x1C6

  163             p32 = (uint32_t *)&Buff[MBR_Table + 8];
  164             // then read the BS/BPB

  165             BPBSec = *p32;
  166             disk_read(BPBSec);
  167         }
  168         // With any luck we're here with a BS/BPB in the buffer

So I'm using the fact that the BytesPerSec field in a BPB will hold 512. If I've read an MBR not a BPB at 0 then that will not be true so then I use the LBA to BPB fiels of the first partition table entry to locate the BPB.

 

From then on it's all just implementing the formulae in FatGen103

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow clawson, lol

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you've ever use a Sky+ box I am the guy who used to try and diagnose the FAT faults in the 2..3 million box population (at that time) of Amstrad DRX boxes to try understand why last Thursday's episode of Coronation Street did not record correctly so about 5 years of my life were spent writing ananlysis tools and trying to understand FAT format (in fact Sky used a two partition FAT system - a small "normal" FAT section up near the front of the disk with 32K clusters or something sensible like that to hold the program index information(*) then a second set of "hidden" FATs called the VFATs that used 1.5MB clusters to store the huge video files. (it didn't want to keep jumping back and forth to the FATs to make stupid little 32KB allocations when GBs were being recorded).

 

(*) interesting fact- the main index file in a Sky box is called "Jopa". This is actually because Sky originally had a couple of Russian contract engineers do the work on the filing system and when they got a bit pissed off with Sky they called the index file "Jopa" which, it turned out later, is apparently Russian for "arse" !! cheeky

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Clawson, thanks entirely to you I understand th Reserve Region, aka BPB.  The next structure I need help on is called the FAT Region, the book I have only dedicates a page to it.  I'll research it in the mean time but if you could help me I would just love that.  

 

I understand Files/Directories Region.

 

Thanks, Wills

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Again just use Fatgen103 and Wikipedia. You MUST have a copy of Fatgen103 to understand FAT. Microsoft explain everything about their filing system there.

 

EDIT this is the bible... https://staff.washington.edu/dit...

Last Edited: Mon. Dec 3, 2018 - 07:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perfect Clawson, I'll read that tonight.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson, I read that document pertaining to the FAT Data Structure.  I gather that its a special file, directory really.  And that it consists of 32 integer directory entry.

Could you give me an example and explain the reasoning of the data?

 

I usually learn by "monkey see monkey do".

 

Wills

 

EDITED 1: Would it be the root directory entry?

EDITED 2: The Root is after the last FAT, so what the hell is the two FATS for?

EDITED 3: Does it contain the link list of clusters of the files and directories on the system.  i.e. from this we can traverse the link list???

Last Edited: Tue. Dec 4, 2018 - 07:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for late reply but I was away for a short two day break in Munich and Venice.
.
The best way (in my opinion) to learn about FAT is to round up as many USB memory sticks, SD cards and others as you can find. Connect each up to a PC running WIN Hex from X ways software and use it alongside Wikipedia and Fatgen103 to decode the stored image. Win hex has templates for reading MBR, BPB etc.
.
And yes FATs are effectively linked lists where the entry either holds the entry number of the next entry in the chain or the (FFFF)FFF8 end marker. It's the location of the entry in the FAT that tells you the offset of the cluster to be read each time. The directory entry has the forst cluster number that therefore tells you where to start your search for the chain in the FAT.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson, I've compared some example sd cards and usb sticks and some specified the start offset or bootstrap.  But some just start of at what seems to be a random offset without any information to say so.

 

Should I search for the start of the bootstrap?  i.e. look for 0xeb, 0x58, 0x90???

 

Wills

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, you always read sector 0 first. It will either be an MBR or a BPB. If it's an MBR it xan look very sparse. In fact there might only be a 4 byte LBA. (Oh and the 55, AA valiďity marker)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does one really need to understand all this detail to use a FAT32 file system?  Seems like it would take a good deal of programming time if it is this complicated.

 

I ask because I need to add an SD Card in project redesign.  I see there is a library for the Aduino but I am using my own GCC code and Studio 7 on an ATMEGA 2560. Is there a readialy available library I can put in to my code (using Studio 7, gcc, with a ATmega 2560)?  I've got a few years of hardware and firmware development on this so I'm not about to switch to an Aduino platform.  For my project I only need to write data that will be read by a PC.  Nothing else will be written to the card except what my board writes.

 

I had been considering using a V2NC FTDI chip for the USB and the spec sheet says "the VNC2 transparently handles the FAT file structure using a simple to implement command set."  In addition to the USB interfaces it also has some SPI interfaces.  Not sure if the complication of the additional hardware or the software will be worse.  (money is not a problem so the cost of the chips and additional layout is moot compared with the time and risk).

 

Advice on which way to proceed would be appreciate.

Thanks

Last Edited: Tue. Dec 11, 2018 - 03:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

He's not asking to USE one, he's asking to WRITE one! So, yes, this level of detail has to be understood.
.
If you read Fianawarrior's previous threads you will see he's slowly but surely writing an OS for 32 bit micros.
.
For your requirements just do what everyone else does and use the existing FatFs. It's unlikely anyone is going to come up with a "better" implementation of FAT that can be used on 8 bit micros.

Last Edited: Tue. Dec 11, 2018 - 09:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Clawson, I've finished the Kernel.  Want to write a nice GUI for it but I'm adding somethings you'd expect to come with a kernel.

 

It's a crime of passion.  ;)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson, I have a offset in the Master Boot Record, first sector = 0x800.

This points to 0x10000000.

 

What is the equation that gives the offset.  I know this might be a very stupid question. ;)

 

Wm.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 0x800 is an LBA (logical block address) so it means sector 0x800 that is sector 2048. Sectors at 512 bytes so if you were looking at the entire drive image as a binary image this would be 512x2048 which is 1048576 = 1MB = 0x100000. The 0x10000000 you quoted would appear to have too many zeros (like two too many!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shit, I had that calculation, however I have a more cryptic offset to work out.  I'll get to that later.  But could you have a look at this BPB and tell me where is next in the operation after this?

I have one file on the sd card.  How do I get to it from the BPB?

 

EDITED, there is a bug in the software I'm using, "Active Disk Editor".  Anyway, Root is 0x02 and it points to 0x1000000.  How does it calculate the address from 0x02???

Attachment(s): 

Last Edited: Mon. Dec 17, 2018 - 04:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't stress FatGen103 strongly enough. It is the complete (and accurate!) description of how to navigate a FAT system.
.
As I've also shown previously i basically stripped the FatGen103 info to the bone to create the absolute most minimal code on a bootloader that just starts at sector 0 and finds BPB (possibly via a simple MBR decode first) it the uses BPB info to find FAT1, root dir and data area. It then scans the 32 byte root entries to find the file of interest and then uses the "first cluster" entry in that to find the first cluster in the data area and if the file size is such that it spans a cluster boundary it goes back to FAT1 to follow the cluster chain for the file.
.
That is the absolute minimum you can get away with to read a file's content and even then I'm making a load of assumptions such as the file entry being in the furst sector of the root (one sector, 512 bytes, can hold the details of 512/32 = 16 files)
.
Be thankful that FAT is actually pretty simple. I've worked with other filing sytems like NTFS and EXT4 and they are astronomically more complex!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Clawson, I've looked at the fatgen103.pdf but still can't grasp how cluster 2 starts at 0x1,000,000?

 

I found the following equation:

 

FirstSectorofCluster = ((N –2) * BPB_SecPerClus) + FirstDataSector

 

whereby N = 2 for the root.

so first FirstDataSector must equal 0x1,000,000, but WHY?

Last Edited: Mon. Dec 17, 2018 - 08:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you think BPB_SecPerCluster and FirstDataSector are then? The first is simply a field in the BPB and in your PNG I can see it is 32 but how are you getting FirstDataSector?

 

My picture above shows:

in which I calculate D as N + R + (F * S).

 

From your BPB I see R as 2,348, F as 2 and S as 15,210. So the data area should start at the number of the BPB sector plus 2348 + (2 * 15210) so BPB + 32768 (interesting number don't you think? It's almost as if R were chosen to place the data area in a very obvious place!). Still not seeing where your 0x1000000 comes from?

 

Oh, wait a minute, 32768 * 512 = 16MB = 0x1000000

 

Suggest you work in either sectors or bytes but don't mix them.

 

Anyway, if you are working in bytes not LBAs then what's wrong with 0x1000000?

 

Oh and a clue... in FAT32 the root dir is a FAT chain so it is the very first cluster in the data area which often makes it easily locatable!

 

Edit, I see from your picture that the BPB itself is at byte offset 1MB so that is sector 2048 so I expect the data area to start at sector 2048 + 32768 which is 34,816 which is byte 17,825,792 or in hex 0x1100000. (17MB).

Last Edited: Tue. Dec 18, 2018 - 05:01 PM