FSINFO on FAT32

Go To Last Post
14 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)