On recent GNU/Linux distributions such as Ubuntu 22.04 and 22.10, you may hit an issue creating a bootable FAT partition for embedded boards, at least with the TI AM335x processor, such as the 32 bit Beagle Bone boards.
So, suppose you plugged your SD card in a USB card reader, and your SD card is associated to the /dev/sdb block device file (for example).
Here’s the command that no longer works:
mkfs.vfat -F 32 -n boot /dev/sdb1
This happened to me while porting the new version of our embedded Linux course to the BeagleBone Black board, using Ubuntu 22.04 as the host platform.
If you prepare an SD card, create a bootable partition, format it with the FAT32 filesystem with the above command, copy a bootloader to this partition, the romcode in the TI AM335x chip won’t recognize it and your board will remain completely silent.
I investigated the problem and found that it happens with mkfs.vfat version 4.2 released on 2021-01-31, and which is shipped in recent GNU/Linux distributions such as Ubuntu 22.04 and 22.10.
Looking at the source code didn’t help right away, but I eventually found a dosfstools bug report which explains the cause of this issue.
Thanks to this bug report and its associated comment thread, an easy workaround was found. You just need to add the -a option to the mkfs.vfat command line:
mkfs.vfat -a -F 32 -n boot /dev/sdb1
I eventually also realized that the issue doesn’t happen if you access the SD card through a regular MMC/SD slot which has the device represented as a /dev/mmcblk device.
So, if your computer has such a slot as most do, you can just use the regular command without the -a option:
mkfs.vfat -F 32 -n boot /dev/mmcblk0p1
In my case, I was using an external USB card reader because I was running experiments from a VirtualBox virtual machine. I didn´t know how to access my host’s MMC/SD card reader from the VM, but accessing a USB device was very straightforward.
Why the difference? That’s because the MMC/SD interface exposes different information from what a USB mass storage device does. That’s a different interface.
The issue is also reported on the TI AM3874 chip. Don’t hesitate to post a comment here if you have a board with yet another TI chip that is impacted too. This could help other users.
Hi there,
I’ve this “completely silent” issue as well on my BBB. The difference is that I use Windows 10 to flash SD cards.
Any idea on how to solve this in a Windows 10 environment?
Best regards, Pedro
Hi Pedro
Do you mean you’re running mkfs.vfat from Windows? Which version?
If I were you, I would do this from a Linux virtual machine. VirtualBox for example can access USB devices on the host machine, so the SD card could be plugged in an USB card reader.
Cheers
Michael.
Hi Michael,
thank you for the reply. Sorry to give you the wrong impression, I’m using the Etcher tool to flash the images.
But your hint is something I’ve completed neglected. I use VirtualBox for playing with vulnerable VMs and never took into consideration that of course it’s possible to access SD cards from the VM as well. My bad :).
I will try it out in the next few days, or I hope so.
Best regards, Pedro
Thank you for posting this!
I’ve encountered the same issue for another TI SoC (AM62A), managed to isolate the problem to mkfs.vfat 4.2 and found this article. I was glad to find out there is a simple workaround.