Raspberry Pi 3B boot partition filesystem

General Discussions
, ,
1

From what I have read, a raspberry pi 3b should be able to boot with the boot partition’s file system either FAT16 or FAT32.
My issue is that some of my raspberry pis don’t boot unless I remake the filesystem as FAT32 and replace the files of the boot partition.
This happens with my yocto build and also the mender raspberry pi demo images found here https://docs.mender.io/2.1/getting-started/download-test-images. I’ve also tried previous versions 1.6 and 1.7.

Is there a way to set the filesystem type to FAT32 for the boot partition instead of FAT16?
Changing the mkfs call of the sdcard_image-rpi within meta-raspberrypi doesn’t seem to work since rpi-sdimg is removed from IMAGE_FSTYPES in conf/local.conf.

Where/when is the uboot.env populated with the boot partition files?
Correct me if I’m wrong, with the raspberrypi, the boot partition is rawcopy from uboot.env within mender-part-image.bbclass.

All suggestions are greatly appreciated.
My apologizes if there is a enforced forum format which I have not followed.

2

Hi @conker00, welcome to Mender hub.
I think you should be able to set the “MENDER_BOOT_PART_FSTYPE” bitbake variable to handle this.

Drew

3

Hi @drewmoseley
Thank you for the suggestion. Unfortunately, changing the MENDER_BOOT_PART_FSTYPE variable didn’t help. It appears to only change the entry within fstab.

I’ve done some more reading about my issue and it seems to be a rare occurrence on the cm3 as described in the troubleshooting section here

which reads:

For a small percentage of Raspberry Pi Compute Module 3s, booting problems have been reported. We have traced these back to the method used to create the FAT32 partition; we believe the problem is due to a difference in timing between the BCM2835/6/7 and the newer eMMC devices. The following method of creating the partition is a reliable solution in our hands.

$ sudo parted /dev/
(parted) mkpart primary fat32 4MiB 64MiB
(parted) q
$ sudo mkfs.vfat -F32 /dev/
$ sudo cp -r /*

I have tried a build with MACHINE = “raspberrypi-cm3” with the same results.

My current workaround is to recreate the filesystem as described in the same troubleshooting section directly on the built image using loop devices.

$sudo fdisk -lu core-image-base.sdimg
$sudo losetup --offset $((<sector size> * <boot partition start>)) --sizelimit $((<sector size> * <sectors in boot partition>)) --show --find core-image-base.sdimg
$sudo mkdir -p /mnt/img
$sudo mount /dev/loopX /mnt/img # where loopX is the device from losetup
$mkdir backup
$sudo cp -r /mnt/img/* backup/
$sudo umount /mnt/img
$sudo mkfs.vfat -F32 /dev/loopX
$sudo mount /dev/loopX /mnt/img
$sudo cp -r backup/* /mnt/img/
$sudo umount /mnt/img
$sudo losetup -d /dev/loopX
4

@conker00 is the only difference the forcing if 32-bit using “-F32” with mkfs.vfat?

I do see that mender-part-images.bbclass always uses type vfat instead of MENDER_BOOT_PART_FSTYPE. @kacf is that intentional or should we update it to use MENDER_BOOT_PART_FSTYPE there?

Although it sounds like in this case it wouldn’t help since it appears to be hardware-releated. The bbclass uses WIC to create the file so that logic would somehow need to force 32-bit if that is indeed the fix.

Drew

5

@drewmoseley

From my understanding, yes. Just forcing with mkfs.vfat -F32 fixes the issue. The partition was not altered.

6

I believe that should be changed, yes. Be aware that MENDER_BOOT_PART_FSTYPE is often set to auto though, since it is primarily used in /etc/fstab at the moment. There is some similar handling for MENDER_DATA_PART_FSTYPE, which can be used for inspiration.

7

Great. I created Boot fs type by drewmoseley · Pull Request #1035 · mendersoftware/meta-mender · GitHub which should allow the boot partition type and options to be customized.

@conker00 once this is merged you can specify:

MENDER_BOOT_PART_FSOPTS_append = " -F 32 "

to avoid the post processing step. If you have a chance to test it and confirm whether it works for you or not that would be most helpful.

Drew