the following is a record of a problem I had with the devkit8000
board. It has now been resolved, and so this post is intended only to
help others who may experience the same problem.
The devkit8000 board booted from NAND, and from its included, 512M
flash card; but it failed to do so from a 4G SD card. It hung within
u-boot. Debugging showed that its x-loader code was incorrectly
reading the partition table. Fixing its offset resulted in proper
Devkit8000 comes as a complete kit, including a 512M flash card. The
latter is pre-loaded with WinCE, whereas the board NAND has Angstorm;
both boot perfectly. The included CD has pre-built images of
angstrom, x-loader 1.41 and u-boot 1.3.3-svn. I wrote these images
into a 4G SD flash card, and tried to boot.
The card was partitioned according to the TI/devkit8000 instructions:
Disk /dev/sdb: 3965 MB, 3965190144 bytes
255 heads, 63 sectors/track, 482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 6 47171 c W95 FAT32 (LBA)
/dev/sdb2 7 482 3823470 83 Linux
u-boot hung. This is all that the serial console showed:
Texas Instruments X-Loader 1.41
Starting on with MMC
Reading boot sector
Error: reading boot sector
Starting OS Bootloader...
U-Boot 1.3.3-svn (Feb 6 2010 - 16:29:12)
OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 DevKit8000 Board + LPDDR/NAND
Debugging showed that the x-loader code was using an incorrect offset
into the partition table.
There is no need for me to submit a patch; the code is already out
Temporarily, I will point you to Steve Sakoman's x-loader unification
Though I have not yet tested his tree, he does have the fix in
part_offset = buffer[DOS_PART_TBL_OFFSET+8] ...
I'll be testing his release RSN, and will update this thread.
NB The mainline uboot code does not have this. I need to dig further
into Sakoman's and Aneesh V's
(not to mention u-boot's mainline) before I'll know how, if at all,
u-boot may get affected.
Note also that there are various user-posts on the Net which suggest
that FAT16 or W95 FAT16 (as opposed to FAT32) file systems for the
flash card may help. Neither did! In fact, IIRC, FAT32 is assumed into