beaglebone boot from eMMC

Tim Kientzle tim at kientzle.com
Mon Mar 23 03:41:53 UTC 2015


For those following along at home:

There seem to be at least three problems preventing eMMC booting on BeagleBone Black right now. (For reference, I’m working with up-to-date -CURRENT and the Crochet copy-to-emmc.sh script.  I started with a Crochet-built SD image from an amd64 system, then did a native build to upgrade before experimenting with ways to format and populate the eMMC image.)

1) FAT partition format.  newfs_msdos trims the FAT format to an even number of tracks, but the AM335x ROM insists that a valid FAT format exactly fill the partition.

Following a suggestion from Luiz Otavio O Souza, I’ve adjusted the copy-to-emmc.sh script in Crochet with parameters that seem to result in the FAT partition being aligned on a track boundary.

Real Solution:  Fix newfs_msdos to not trim or at least provide an option.

Guy Yur has filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183234 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183234>
with some ideas on this.

2) Ubldr not finding boot device.  I’m running into this now.  This could be related to U-Boot (ubldr uses U-Boot to identify and access drives), but U-Boot seems to have no trouble reading the eMMC (in particular, it loads ubldr successfully), so I’m skeptical that’s the problem.

3) Geom rejects BSD labels with more than 255 sectors per track.  The BBB eMMC reads as 1024 sectors per track.   Would it make sense to remove the check in g_part_bsd.c that rejects labels with more than 255 sectors?


Related:  Could someone please add GEOM_LABEL to the BEAGLEBONE kernel?  The eMMC shows up as either mmcsd0 or mmcsd1 depending on how you boot, so label-based mounting is pretty essential.



More information about the freebsd-arm mailing list