beaglebone boot from eMMC

[Guy Yur]

On Thu, Mar 19, 2015 at 5:41 AM, Tim Kientzle <tim at kientzle.com> wrote:
>
>> On Mar 18, 2015, at 11:16 AM, Guy Yur <guyyur at gmail.com> wrote:
>>
>> Hi,
>>
>>
>> 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.
>

I didn't see anything in the TI document about alignment and
it works fine for me with 1MB on eMMC with patched newfs_msdos.
The problem is with the check that requires the number of sectors
to equal the partition size.
newfs_msdos trims the sector count so the condition isn't met.

Page 4574 - Figure 26-22. FAT Detection Procedure
BPB_TotSec16 or
BPB_TotSec32
=
MBR_Partition_Size


> * 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
>
>

On my BeagleBone Black Rev A5C eMMC C/H/S is 20/183/1024 not NN/255/63.

Alignment on sector 63 and newfs_msdos will create a
FAT boot sector with incorrect number of sectors.
Before kern.geom.part.mbr.enforce_chs was introduced "-a 63"
didn't really align on sector 63 when C/H/S was different.


# diskinfo -v /dev/mmcsd0
/dev/mmcsd0
        512             # sectorsize
        1920991232      # mediasize in bytes (1.8G)
        3751936         # mediasize in sectors
        524288          # stripesize
        0               # stripeoffset
        20              # Cylinders according to firmware.
        183             # Heads according to firmware.
        1024            # Sectors according to firmware.
        ........        # Disk ident.


Example with md device:
# dd if=/dev/zero of=disk.img bs=524288 count=3664
# mdconfig -a -u 0 -t vnode -S 512 -x 1024 -y 183 -f disk.img

# gpart create -s MBR md0
# gpart add -a 63 -b 63 -s 2m -t '\!12' md0

# newfs_msdos -L label -F 12 md0s1
newfs_msdos: trim 1023 sectors to adjust to a multiple of 1024
/dev/md0s1: 3021 sectors in 3021 FAT12 clusters (512 bytes/cluster)
BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512
Sectors=3072 Media=0xf0 FATsecs=9 SecPerTrack=1024 Heads=183 HiddenSecs=0

With kern.geom.part.mbr.enforce_chs=0 (default on head)
# gpart show md0
=>   1024  3750912  md0  MBR  (1.8G)
     1024       47       - free -  (24K)
     1071     4095    1  !12  (2.0M)
     5166  3746770       - free -  (1.8G)


3072 != 4095 causing the boot to fail.


With kern.geom.part.mbr.enforce_chs=1
# gpart show md0
=>   1024  3750912  md0  MBR  (1.8G)
     1024     1024       - free -  (512K)
     2048     3072    1  !12  (1.5M)
     5120  3746816       - free -  (1.8G)

# newfs_msdos -L label -F 12 md0s1
/dev/md0s1: 3021 sectors in 3021 FAT12 clusters (512 bytes/cluster)
BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512
Sectors=3072 Media=0xf0 FATsecs=9 SecPerTrack=1024 Heads=183 HiddenSecs=0



Guy