linaro-media-create speedup

[Dave Martin]

Hi,

On Wed, Oct 13, 2010 at 10:58 AM, Loïc Minier <loic.minier at linaro.org> wrote:
> On Wed, Oct 13, 2010, Arnd Bergmann wrote:
>> You can also manually align the FAT and the start of data to individual
>> sectors, which is how some SD cards do it when they use the 255/63
>> geometry.
>
>  Yup
>
>  1 MiB is the value I use myself when creating partitions manually, but
>  I didn't know Windows used this; sounds like a good idea to use that
>
>  Let's go for 255/63 and a boot part starting at a 1 MiB: (130,138,8)

As far as I can make out, the partition must be an exact number of
"cylinders", must have enough sectors for a FAT32 filesystem and must
start at sector 63.  This gives a minumum size is 5 cylinders (80262
sectors), which seems to work OK.
Anything else causes the ROM to print out the characters "60" and
halt, at least on my board.

Of course, if you follow TI's instructions for setting up the board,
you do get the right (if silly) layout.

Conversely, if the FAT partition doesn't start at sector 63, you get this:

Error: reading boot sector
u-boot.bin not found or blank nand contents - attempting serial boot . . .

...which suggests that the ROM is maybe making an assumption and
reading sector 63 regardless of what the partition table says.

Notwithstanding this, it looks like the rootfs partition can have any
configuration you like, so long as it doesn't overlap the FAT
partition.  This configuration worked for me, for example:
   Device Boot      Start         End      Blocks   Id  System
/dev/sdg1   *          63       80324       40131    c  W95 FAT32 (LBA)
/dev/sdg2           81920     7843839     3880960   83  Linux

So, unfortunately to avoid other people wasting a lot of time ... I
think the boot partition must start at sector 63, with size 63*(255*n
- 1) sectors, and minimum size 80262 sectors (n=5).  Perhaps there are
some (in)sanity checks and/or assumptions in the ROM which are
requiring this.  For the filesystem partition, I guess aligning up to
the next 1MB boundary is indeed the sensible thing to do (as in the
above example).

We should check it works with non-xM boards too...

Cheers
---Dave