Solving the OMAP3/4 boot mystery

[Vladimir Pantelic]

Hi,

The OMAP3/4 ROM code seems to have the most picky
implementation of a FAT file system ever seen.

In order to recognize a valid FAT partition, amongst
other things it also checks that the partition size
given in the FAT boot block (BPB) matches the partition
size as given in the MBR

This is quoted from a TI doc that I am sadly not
allowed to disclose:

"BPB_TotSec16 = MBR_Partition_Size
or
BPB_TotSec32 = MBR_Partition_Size"

(see http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector
and offsets 0x13 and 0x20 for BPB_TotSec16 and BPB_TotSec32)

Now, using e.g. mkdosfs to prepare a FAT partition to
boot and read MLO from, the above requirement is not
always met.

Internally, mkdosfs calculates in "blocks" and one
block is BLOCK_SIZE bytes large, which is given as:

/usr/include/linux/fs.h:#define BLOCK_SIZE_BITS 10
/usr/include/linux/fs.h:28:#define BLOCK_SIZE (1<<BLOCK_SIZE_BITS)

BLOCK_SIZE is 1024, but FAT sectors are counted
in 512 multiples.

So, if you have an odd partition size, mkdosfs will
truncate it by 1 and write a wrong value into
BPB_TotSec16 or BPB_TotSec32.

And then OMAP3/4 rom code will not boot .....

example:

# fdisk /dev/sdc

Command (m for help): p

Disk /dev/sdc: 3957 MB, 3957325824 bytes
255 heads, 63 sectors/track, 481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 * 1 8 64228+ 6 FAT16
/dev/sdc2 9 211 1630597+ 83 Linux

Command (m for help): x

Expert command (m for help): p

Disk /dev/sdc: 255 heads, 63 sectors, 481 cylinders

Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 80 1 1 0 254 63 7 63 128457 06
2 00 0 1 8 254 63 210 128520 3261195 83
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 0 00

the partition size is exactly 128457 sectors, but mkdosfs
writes 128456 into the FAT BPB.

this little tool checks MBT partition size vs fat BPB size:

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main( int argc, char **argv )
{
if ( argc < 2 ) {
printf("check /dev/sdX\n");
return 1;
}
int fd = open( argv[1], O_RDONLY );

lseek( fd, 0 + 446 + 8, SEEK_SET );

int start;
int num_mbr;
read( fd, &start, 4 );
read( fd, &num_mbr, 4 );

int num_bpb = 0;

lseek( fd, start * 512 + 0x13, SEEK_SET );
read( fd, &num_bpb, 2 );

if( num_bpb == 0 ) {
lseek( fd, start * 512 + 0x20, SEEK_SET );
read( fd, &num_bpb, 4 );
}

printf( "start: %d mbr: %d bpb: %d -> %s\n",
start, num_mbr, num_bpb,
num_mbr == num_bpb ? "PASS" : "FAIL!" );

return num_mbr == num_bpb;
}

[Vladimir Pantelic]

update below...

(UPDATE:)

128456 in fact seems to match the actual FAT specification from
M$ which says that BPB_TotSec16/32 is the sum of the 4 "regions"
of the FAT:

0 � Reserved Region
1 � FAT Region
2 � Root Directory Region (doesn�t exist on FAT32 volumes)
3 � File and Directory Data Region

which in my example adds up to 128456.

So, now I rather think that the ROM code is *wrong* to assume that
BPB_TotSec16/32 has to exactly match the partition size!

Interestingly, Windows seems to write that value also not
according to the M$ spec ..... sigh

BTW, I did more tests and these confirm that the ROM code totally
ignores the actual C/H/S values from the MBR, setting all of the
to 0xFF or 0x00 made the card boot just as well.

>
>
> this little tool checks MBT partition size vs fat BPB size:
>
> #include<stdio.h>
> #include<sys/types.h>
> #include<unistd.h>
> #include<sys/types.h>
> #include<sys/stat.h>
> #include<fcntl.h>
>
> int main( int argc, char **argv )
> {
> if ( argc< 2 ) {
> printf("check /dev/sdX\n");
> return 1;
> }
> int fd = open( argv[1], O_RDONLY );
>
> lseek( fd, 0 + 446 + 8, SEEK_SET );
>
> int start;
> int num_mbr;
> read( fd,&start, 4 );

> read( fd,&num_mbr, 4 );

>
> int num_bpb = 0;
>
> lseek( fd, start * 512 + 0x13, SEEK_SET );

> read( fd,&num_bpb, 2 );

>
> if( num_bpb == 0 ) {
> lseek( fd, start * 512 + 0x20, SEEK_SET );

> read( fd,&num_bpb, 4 );

[Jon Masters]

On Thu, 2010-11-25 at 21:20 +0100, Vladimir Pantelic wrote:

> > In order to recognize a valid FAT partition, amongst
> > other things it also checks that the partition size
> > given in the FAT boot block (BPB) matches the partition
> > size as given in the MBR
> >
> > This is quoted from a TI doc that I am sadly not
> > allowed to disclose:
> >
> > "BPB_TotSec16 = MBR_Partition_Size
> > or
> > BPB_TotSec32 = MBR_Partition_Size"
> >
> > (see http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector
> > and offsets 0x13 and 0x20 for BPB_TotSec16 and BPB_TotSec32)

Hey, thanks for this. Clearly I'm not (entirely) nuts then. So it is
possible to make a larger partition, we just need to document what it
wants to see. It's ok if it's quirky, as long as we know roughly how.

Michael (copied) might want to update this page with some notes, or link
to this specific Google thread for those who come along later:

http://free-electrons.com/blog/beagle-mmc-boot/

Jon.

[Vladimir Pantelic]

Well, at least on a Panda(OMAP4), the active flag *is* checked by the
rom code and thus *is* needed to boot.

With regards to the 255/63 cargo cult, it is correct that it is
not needed for the rom code to boot, in fact the rom code does not
care for the C/H/S value at all. It might stem from the fact that MLO
aka x-loader had a hard coded start of partition 1 at sector 63, but
never versions do not have this limitation any more.

[Jon Masters]

On Thu, 2010-11-25 at 21:20 +0100, Vladimir Pantelic wrote:

Did anyone from TI ever officially comment on the limitations of the
boot loading logic in the OMAP silicon (ROM)?

Jon.

[Vladimir Pantelic]

the limitations are stated in an "official" looking PDF that I
have access too :)

[Michael Malyshev]

Vladimir, could you please share the name of the document with me? I
have official contacts in TI but I need to know what to ask for

Thanks,
Michael