beaglebone boot from eMMC

[Tim Kientzle]

> On Mar 18, 2015, at 11:16 AM, Guy Yur <guyyur at gmail.com> wrote:
> 
> Hi,
> 
> On Wed, Mar 18, 2015 at 9:23 AM, Hellmuth Michaelis
> <hm at hellmuth-michaelis.de> wrote:
>> 
>> Its really weird. I fetched the Angstroem flasher to put back an original image onto the eMMC and that worked. I dumped the MBR for Linux and the MBR which was generated by the install script and they are both pretty OK and legal. I reordered files on the MSDOS partition. I played with different „BIOS“ geometries (because Linux and FreeBSD have a rather different sight on this) to produce the partitions.
>> 
>> Nothing helps - it does not boot FreeBSD from the eMMC MSDOS Partition. The only thing which made a difference was, when i used the Linux-generated MSDOS partition, removed the files in it and populated it with the FreeBSD-generated MLO and things - then it booted from it. I failed completely to add an UFS partition after the Linux-generated MSDOS partition, tried gpart, fdisk, bsdlabel. The UFS mmcsd1s2a can be generated, populated, fsck’d, tested, checked - after the next powercycle it simply disappeared.
>> 
>> It seems to me that there is a bit more magic involved than only generate the partitions. In the Linux script to generate the image onto the eMMC, they check for:
>> 
>> HEADER=$(hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -s 5 -n 3)
>> 
>> and possibly write to an eeprom - has someone an idea why this is needed ?
>> 
>> Hellmuth
>> 
>> 
> 
> Is your msdosfs slice on the eMMC aligned to 1 MB?
> 
> I had the same "CCC" problem when I aligned the partition
> and used newfs_msdos.
> Removing the sector count adjustment calculation in newfs_msdos
> as was done in NetBSD worked for me.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183234

Fortunately, the AM335x TRM from TI documents the exact checks made by the ROM before it will recognize a valid MSDOS partition.  So you don’t need to guess; you can compare a hex dump of your disk with the docs and see exactly what’s gone wrong.

As I recall, the ROM is very unforgiving:

* The CHS geometry used in the MBR has to exactly match the MSDOS format geometry.  Attempts to align the partition on round boundaries can screw this up badly.

* The FAT format type (12, 16, or 32) has to match the ROM expectations

If any of the ROM checks fail, it will assume the device is not usable and try a different device (ultimately ending up with CCCC on the serial port).

The corresponding code in Crochet uses

$ gpart add -a 63 -b 63 -s 2m -t ‘!12’ <device>

to create the MSDOS partition and then uses

$ newfs_msdos -L <label> -F 12 <device>

Note: Use -F 12 for an MSDOS partition of 16MB or less, otherwise use -F 16.

Tim