PR#107: boards.d: Reformat ESP partition filesystem for the BeaglePlay board - arm-image-installer

arm-image-installer

#107 boards.d: Reformat ESP partition filesystem for the BeaglePlay board

Merged 2 months ago by pbrobinson. Opened 4 months ago by javierm.

javierm/arm-image-installer add-reformat-esp into main

boards.d: Reformat ESP partition filesystem for the BeaglePlay board

Javier Martinez Canillas • 2 months ago

8f08abd

arm-image-installer

file modified

+1 -1

		`@@ -550,7 +550,7 @@`

		`# determine uboot and write to disk`
		`if [ "$TARGET" != "" ]; then`
		`- if echo "$TARGET" \| grep -q 'rpi[234]' \|\| [ "$TARGET" = "olpc_xo175" ]; then`
		`+ if echo "$TARGET" \| grep -q 'rpi[234]' \|\| [ "$TARGET" = "olpc_xo175" ] \|\| [ "$TARGET" = "beagleplay" ]; then`
		`. "${BOARDDIR}/${TARGET}"`
		`elif [ -d "${PREFIX}/usr/share/uboot/${TARGET}" ]; then`
		`. "${BOARDDIR}/${TARGET}"`

boards.d/beagleplay

file added

		`@@ -0,0 +1,1 @@`
		`+ ../socs.d/am625`
		`\ No newline at end of file`

socs.d/am625

file added

+38

		`@@ -0,0 +1,38 @@`
		`+ #!/bin/bash`
		`+`
		`+ cleanup()`
		`+ {`
		`+ rm -rf /tmp/fw_bk &> /dev/null`
		`+ return`
		`+ }`
		`+`
		`+ echo "= Reformat the ESP filesystem to use the device geometry"`
		`+ if [ "$FIRMPART" == "" ] ; then`
		`+ echo "ERROR: Firmware partition not available - wrong image?"`
		`+ return`
		`+ fi`
		`+`
		`+ mkdir /tmp/fw_bk`
		`+ cp -a /tmp/fw/* /tmp/fw_bk/`
		`+ umount /tmp/fw`
		`+`
		`+ UUID="$(lsblk -no UUID $FIRMPART)"`
		`+ mkfs.vfat "$FIRMPART" &> /dev/null`
		`+ if [ $? != 0 ] ; then`
		`+ echo "ERROR: Firmware partition filesystem reformatting failed!"`
		`+ cleanup`
		`+ fi`
		`+`
		`+ # restore the old filesystem UUID to match the /etc/fstab`
		`+ printf "\x${UUID:7:2}\x${UUID:5:2}\x${UUID:2:2}\x${UUID:0:2}" \`
		`+ \| dd bs=1 seek=67 count=4 conv=notrunc of="$FIRMPART" status=none`
		`+`
		`+ # restore the firmware files from the backup directory`
		`+ mount "$FIRMPART" /tmp/fw`
		`+ cp -a /tmp/fw_bk/* /tmp/fw/`
		`+`
		`+ sync`
		`+ cleanup`
		`+`
		`+ # set console`
		`+ SYSCON=ttyS2,115200`

javierm commented 4 months ago

The bootROM for some SoCs (e.g: AM625 used in the BeaglePlay board) aren't
able to boot when the ESP partition vfat filesystem geometry doesn't match
the expected sectors/track and head numbers.

Because the Fedora images are generated using a loopback device, they have
a 63 sectors/track, 16 heads geometry but for SD block devices this should
be 32 sectors/track, 64 heads for the AM625 SoC bootROM to boot the board.

To make sure that the ESP vfat filesystem will have the correct geometry,
reformat the partition when flashing the Fedora image to the block device.

Some SoCs support loading the firmware binaries from block device sectors,
and so the files can be stored as raw data in the gap between the MBR and
the first partition. But this option is not available in the BeaglePlay
bootROM. For this reason, the only possible option is to store in the ESP.

Suggested-by: Erico Nunes nunes.erico@gmail.com
Signed-off-by: Javier Martinez Canillas javierm@redhat.com

pbrobinson commented 4 months ago

NAK, this is a terrible hack. We have enough issues already dealing with filesystems, this is not the place to deal with this.

Also if you look at the way we support things like the original BeagleBones we write the firmware out to the raw disk, we've never (other than the RPi) put firmware into the ESP. The TI devices support having the firmware on the raw disk like we do with every other Arm device.

javierm commented 4 months ago

Ok, I'll close this PR then.

Pull-Request has been closed by javierm

4 months ago

Pull-Request has been reopened by javierm

3 months ago

rebased onto 3db65ab

3 months ago

javierm commented 3 months ago

Reopen this PR because I changed the approach. Instead of adding a --reformat-esp option, I add logic that's specific to AM625 boards (and a BeaglePlay target).

That way, only the ESP partition is reformatted for boards using that SoC, since their bootROM requires to have the storage device geometry.

rebased onto f734963

3 months ago

rebased onto 1461a55

3 months ago

rebased onto f2a4d49

3 months ago

rebased onto 08f7db8

3 months ago

pbrobinson commented 2 months ago

The bootROM for some SoCs (e.g: AM625 used in the BeaglePlay board) aren't
able to boot when the ESP partition vfat filesystem geometry doesn't match
the expected sectors/track and head numbers.

Can you add a link to the TRM section in the commit for this please? I think the TI TRMs are generally public. No prob if not, it's just useful for future reference.

Because the Fedora images are generated using a loopback device, they have
a 63 sectors/track, 16 heads geometry but for SD block devices this should
be 32 sectors/track, 64 heads for the AM625 SoC bootROM to boot the board.

Just a FYI the're generated in a VM using a raw image not a loopback.

To make sure that the ESP vfat filesystem will have the correct geometry,
reformat the partition when flashing the Fedora image to the block device.

I'm not sure how the vfat reformat command in the patch achieves that, is that purely because it's happening on the device that will be used in the BeaglePlay?

the first partition. But this option is not available in the BeaglePlay
bootROM. For this reason, the only possible option is to store in the ESP.

Amusingly I seem the remember my original BeagleXM had similar characteristics.

pbrobinson commented on line 23 of socs.d/am625 2 months ago

We run cleanup again below, if the mkfs.vfat fails here should we be presenting a error to the user?

rebased onto 04d4fe8

2 months ago

javierm commented 2 months ago

The bootROM for some SoCs (e.g: AM625 used in the BeaglePlay board) aren't
able to boot when the ESP partition vfat filesystem geometry doesn't match
the expected sectors/track and head numbers.

Can you add a link to the TRM section in the commit for this please? I think the TI TRMs are generally public. No prob if not, it's just useful for future reference.

Done.

Because the Fedora images are generated using a loopback device, they have
a 63 sectors/track, 16 heads geometry but for SD block devices this should
be 32 sectors/track, 64 heads for the AM625 SoC bootROM to boot the board.

Just a FYI the're generated in a VM using a raw image not a loopback.

Ok. I've updated the commit message to make it accurate then.

To make sure that the ESP vfat filesystem will have the correct geometry,
reformat the partition when flashing the Fedora image to the block device.

I'm not sure how the vfat reformat command in the patch achieves that, is that purely because it's happening on the device that will be used in the BeaglePlay?

Correct. I've also updated the commit message to make this more clear.

the first partition. But this option is not available in the BeaglePlay
bootROM. For this reason, the only possible option is to store in the ESP.

Amusingly I seem the remember my original BeagleXM had similar characteristics.

Really? It has been a long time but I think that booted my BeagleXM by storing the SPL (then called x-loader!) and u-boot binaries as raw data in the gap between the MBR and the first partition. Which unfortunately doesn't work for the BeaglePlay as mentioned.

rebased onto 8f08abd

2 months ago

javierm commented 2 months ago

We run cleanup again below, if the mkfs.vfat fails here should we be presenting a error to the user?

Good point. I've added an error message now in case of failure.

Thanks a lot again for your feedback and comments!

pbrobinson commented 2 months ago

Amusingly I seem the remember my original BeagleXM had similar characteristics.

Really? It has been a long time but I think that booted my BeagleXM by storing the SPL (then called x-loader!) and u-boot binaries as raw data in the gap between the MBR and the first partition. Which unfortunately doesn't work for the BeaglePlay as mentioned.

I meant in the having to reformat the VFAT if using that mechanism.

Pull-Request has been merged by pbrobinson

2 months ago

javierm commented 2 months ago

Amusingly I seem the remember my original BeagleXM had similar characteristics.

Really? It has been a long time but I think that booted my BeagleXM by storing the SPL (then called x-loader!) and u-boot binaries as raw data in the gap between the MBR and the first partition. Which unfortunately doesn't work for the BeaglePlay as mentioned.

I meant in the having to reformat the VFAT if using that mechanism.

Got it. I don't think that even knew back then that the bootROM could boot from a vfat filesystem directly :)