mkfs.fat, issue with boot AM335x from SD-Card. (answer the total_sect differs between 4.2 and 4.1)

[KlaasVortex]

For booting an Texas-AM335x (Beagle-board) from the SD-card the cpu uses a own hard coded bootloader (by TI)
Basicly it looks for a boot partition and tries to find MLO (a boot loader) on the sdcard.

So create a bootable dos partition on the SDCARD with mkfs.fat and it works. This all worked fine with the mkfs.fat 4.1 (2017-01-24) which is included on Ubuntu 20.04

After upgrading to Ubuntu 21.04 the new version mkfs.fat 4.2 (2021-01-31) was included. Since then the AM335x will not boot anymore with the newly created cards.

After comparing the output of both programs on the Scards I found out that at offset 0x20 of the partition there is the total counts of sectors on the volume.

This has a different number on the 4.1 than the 4.2 version. So when I create a partition
sudo ./mkfs.fat -v -I -F 32 /dev/sdc1

The 4.1 will have 00 00 0C 00
The 4.2 will have EC FF 0B 00

The rest of the partition is exactly the same (beside serial number)
This test is done multiple time on the SAME SD-CARD.

The BFFEC is the correct number of sectors, but the C0000 is the one allowing the AM335x to boot. But how can the calculation differ on the same card ?

To make sure this was the problem I patched the program at line 1210

**bs.total_sect = 0x0c0000;**

This would make the SDCARD boot.

So why is this calculation (or the result) different between to program's ?

[pali]

Related bugs:

• https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/615873
• https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/746262

[pali]

Quoting from https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/615873:

Very old OMAP3 (e.g. BeagleBoard) boot ROMs and the QEMU emulation thereof don't support anything else than 255 heads in the boot partition from which the first bootloader is read (x-loader / MLO).

mkfs.fat 4.2 started using C/H/S geometry for FAT according to the SD Card Part 2 File System Specification be compliant with that standard.

So It looks like that TI boot ROMs are not compliant with SD card standards

mkfs.fat 4.2 has a new option -g for specifying custom C/H/S geometry. You could try to play with it if it helps. At least it was required for some people as reported on launchpad bug tracker.

mkfs.fat has also for a long time option -a which disables aligning. You could try it too.

Both aligning and C/H/S geometry affects total number of sectors.

[KlaasVortex]

I have build the old and new version to compare. Because I am not to sure about the head 255 problem.
So I patched a AVR part in it to make sure I have used the compiled version in testing

Line 1210 at mkfs.fat.c printf("AVR Total sectors : 0x%08X, %d\n", bs.total_sect, bs.total_sect);

So I have done two runs on the same 1GB SDCARD with100MB dos partition and 900mb ext4

My question is how come that the numbers of total sectors is different between the old and new version of mkfs.fat ?
Or how can the number of sectors differ on the same card ?

AVR Total sectors : 0x00032000, 204800 (old 100mb)
AVR Total sectors : 0x00031FE9, 204777 (new 100mb)

100MB partition (1GB Disk)

sudo ./mkdosfs /dev/sdc1 -F 32 -I -v

mkdosfs 3.0.12 (29 Oct 2011)
AVR Total sectors : 0x00032000, 204800
/dev/sdc1 has 32 heads and 61 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 204800 sectors;
file system has 2 32-bit FATs and 1 sector per cluster.
FAT size is 1576 sectors, and provides 201616 clusters.
There are 32 reserved sectors.
Volume ID is 3f461abd, no volume label

sudo ./mkfs.fat /dev/sdc1 -F 32 -I -v

mkfs.fat 4.2+git (2021-01-31)
AVR Total sectors : 0x00031FE9, 204777
/dev/sdc1 has 32 heads and 61 sectors per track,
hidden sectors 0x0800;
logical sector size is 512,
using 0xf8 media descriptor, with 204777 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 1 sector per cluster.
FAT size is 1575 sectors, and provides 201595 clusters.
There are 32 reserved sectors.
Volume ID is 3c5b1eb6, no volume labe

[pali]

My question is how come that the numbers of total sectors is different between the old and new version of mkfs.fat ?

As I said in my previous post:

Both aligning and C/H/S geometry affects total number of sectors.

So if you have 61 sectors per track then on disk with 3357 tracks you will have 61*3357=204777 total number of sectors. And on disk with 3358 tracks you will have 61*3358=204838 sectors.

Older version of mkfs.fat did not aligned number of sectors,

[KlaasVortex]

Ok, thanks that explains it better. I am not an expert in file formats :-)

[pali]

So you need to play with -g and -a parameters to figure out what TI OMAP3x/AM3x BootROM expects. Linked bug reports contains lot of other information.

[KlaasVortex]

Maybe I just keep on using the old one to make sdcards. Since I dont know anything about partitions it will take a lot of time to try-and-error this.

[pali]

Well, if you do not do these tests and checks parameters, how can I help with resolving this issue?

[pali]

I have downloaded OMAP3 bootrom dump from http:https://droid-dev.mobi/wiki/File:Omap_3430.bin.gz and looked at it.

At address 0x4D3A seems to be code which checks if read block is valid FAT12/16/32 partition. And seems there is nothing suspicious or special. Just that there is requirement for 2 FAT tables and sector size must be 512 bytes.

At address 0x1AFC seems to be some FAT "fixup" function and instructions at addresses 0x1B48, 0x1B4A and 0x1B4E are erasing the least significant bit of total number of FAT32 sectors. So there can be an issue if total number of FAT32 sectors is odd number.

Can you try to format it with even number of sectors per track and even number of heads?

[KlaasVortex]

I will try your idea in the weekend. For some more info of the partition you can look at https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
At page 5059 there is the information about the boot partition an the other stuff needed for a valid partition. Like I said I dont know much about partition stuff.

[pali]

https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf

• BPB_SecPerTrk - Number of sectors per track, 63 for SD/MMC
• BPB_NumHeads - Number of heads, 255 for SD/MMC
• First the ROM Code checks if the BPB_Signature is equal to AA55h. Then it checks some fields which must have some specific values (BPB_BytsPerSec, BPB_SecPerClus, BPB_RsvdSecCnt, BPB_NumFATs, BPB_RootEntCnt)
• If the geometry of the device is known (valid CHS for device size < 4Gbytes) then it is compared against BPB_SecPerTrk and BPB_NumHeads fields.
• If an MBR was found before, the partition size is also checked
• BPB_BytsPerSec = 512
• BPB_SecPerClus = 1, 2, 4, 8, 16, 32, 64 or 128
• BPB_RsvdSecCnt > 0
• BPB_NumFATs = 2
• BPB_RootEntCnt multiple of BPB_BytsPerSec/32 or 0
• Was there an MBR? BPB_TotSec16 or BPB_TotSec32 = MBR_Partition_Size

[pali]

So it looks like that it requires / expects that number of heads is 255 (like it was already described in launchpad bug report) and number of sectors per track is 63. This can be achieved by mkfs.fat -g parameter.

Then there is interesting information that if C/H/S is known, which can be decoded only from MBR table, it is checked. So could mean that C/H/S for <<4GB cards needs to be correctly set also in MBR.

And the last thing is that partition size in MBR must match total number of sectors.

So for me it looks like that number of heads must be 255 (in both FAT and calculated in MBR), sectors per track must be 63 (again in both FAT and MBR), MBR partition size must be aligned to the total number of FAT sectors, which then implies that needs to be aligned to C/H/S.

Totally insane... I thought that C/H/S is not used for 20+ years...

So erase all partitions and try to create a new partition via fdisk, it supports this C/H/S mode via options -c=dos -u=cylinders and to specify num of heads and sectors per track -H 255 -S 63. Also ensure that partition is marked as active/bootable.

And then format partition as FAT12/16/32 via mkfs.fat with option -g 255/63 to specify num of heads and sectors per track.

[KlaasVortex]

Tried your suggestion as follows.

sudo fdisk -c=dos -u=cylinders -H 255 -S 63 /dev/sdc

o - create DOS Partition
n - new partition
primairy - 1 first partition - 1 first cyl - 30 last cyl (I need a second partition for root file sys)
t - 0b type fat32

a - boot
w - writeout

---

sudo mkfs.fat -g 255/63 /dev/sdc1

---

The end result was a bootable disk. Thanks a lot this fixes the problem.

[pali]

Ok, thanks for testing. So now we know that 255/63 geometry is really needed (as written in that TI doc) and also C/H/S alignment.

[KlaasVortex]

Thanks a lot for the help. You were totally on top of it. Ultra fast response on this item !

[hmwel]

I also run into this issue, but we use bigger sd-cards (8 and 16GB).
i have tryed to recreate the fat partition using only

sudo mkfs.fat -g 255/63 /dev/sdc1

and using

sudo fdisk -c=dos -u=cylinders -H 255 -S 63 /dev/sdc

o - create DOS Partition
n - new partition
primairy - 1 first partition - 1 first cyl - 30 last cyl (I need a second partition for root file sys)
t - 0b type fat32

a - boot
w - writeout

sudo mkfs.fat -g 255/63 /dev/sdc1

but both are still resulting in an not bootable sd-card

sudo mkfs.fat --help
mkfs.fat 4.2 (2021-01-31)

[KlaasVortex]

Hmwel, I dont know much about this program. So I cannot help you on that.

When I first encountered the problem I went back to the 2011-Version of mkfs.fat
That solved the problem. If this works for you (2011version) that would help solving the problem.

It is not a fix, but it will help to find a solution.

[pali]

@hmwel See my above comment #165 (comment) It applies for size < 4Gbytes. I'm not sure how to interpret it for bigger cards...

[gsmecher]

On an am3874-based board, adding the "-a" option fixed boot failures on a 32GB flash card. I am (naively and optimistically) choosing to believe that this is more SD-card-agnostic than explicitly specifying geometry.

[pali]

@gsmecher If you look into the documentation for -a option you will find that it just disables alignments. So it changes how FAT layout is calculated. And therefore it just proves that this bootrom has some special requirements about layout and geometry.

Recently I sent patch to util-linux's fdisk tool to try reconstruct geometry (number-of-heads and sectors-per-track) from MBR table and fills correct C/H/S values in MBR table when creating/updating partitions. I could probably extend mkfs.fat to try read this geometry from MBR in the same way how util-linux's fdisk, which could help with these issues (so number-of-heads and sectors-per-track in MBR would match them in FAT). But this works only when MBR partition ends in first 8GB (when C/H/S in MBR values do not overflow)

[michaelopdenacker]

Hello
Thanks for all the research work
Using mkfs.fat 4.2 on Ubuntu 22.04 (Ubuntu 22.10 has the same version), I tested "mkfs.vfat -a -F 32" on a 64 MB partition, and it worked fine on the BeagleBone Black (TI AM 335x).
The partition table was created normally with the "cfdisk" command. I tested with both 8 GB and 64 GB SD cards.
However, I recompiled the sources using the latest commit (53ef9ad) in the git tree, and I didn't need the "-a" option to get a FAT partition that works for the TI AM 335x chip.
What could be the commit(s) that changed this?
Thanks again
Michael

[pali]

What could be the commit(s) that changed this?

I do not know about any changes in master branch after v4.2 tag which could change behavior or fix that issue.

I guess that you could format disk differently and C/H/S in MBR or in FAT could have been filled differenty.

[michaelopdenacker]

OK, good to know that the new version is not supposed to help.
This helped me to understand the issue better...

When I was testing with the master branch, I was on another machine and I was formatting my partition through the MMC interface (/dev/mmcblk0p1). If I use a USB card reader (using /dev/sdb1) as in my other tests, I still have the issue. So, this confirms that the latest commits don't fix the issue as you suspected.

So, actually version 4.2 works when you access the partition through the MMC interface instead of using a USB card reader

[michaelopdenacker]

I guess the MMC interface (/dev/mmcblk0p1) exposes more information than the standard block device through USB mass storage (/dev/sdb1), and that could make a difference for mkfs.vfat. Could this be correct?
Thanks for everything.

[pali]

Not more information but different information. And it could be the reason.