• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 987 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: SD card causes boot failure

Jeff Andich
Intellectual 890 points
Part Number: AM5728

Tool/software: Linux

Hi,

  • Our custom board is baselined off of the  572x EVM rev a3 schematic, and runs both the TI SDK Linux firmware and BeagleBoard Linux firmware.
  • Our BSP is running from internal eMMC on our board and our application logs data to an external SD card plugged into the board's external SD card slot.
  • We have a shell script which expects that SD card to have a single partition of some type, and then the script reformats that single partition to fat32/vfat using mkfs.vfat.
  • Everything works ok (thus far) depending on which utilities were used to format that SD card.
  • However, if you use certain utilities like the default Windows formatter (for fat32) or gparted on Linux, the board apparently won't boot Linux when the SD card inserted in the slot is incorrectly formatted.  Everything just mysteriously locks-up.
  • I say apparently won't boot Linux because you see no characters printed on the Linux console port with a suspect-formatted SD card in the slot.
  • If we use SD Card Formatter utility (approved by the SD card industry), or fdisk on Linux (formatting the partition to Linux) everything works great. 
  • We're using the jumper setting which prioritizes SD card then eMMC as the boot device.

I'm not sure if the failure to see any console messages means that the ROM boot loader is bootstrapping junk data into the internal SRAM and the 5728 is trying to execute that OR our u-boot-spl (before the UARTS are initialized) is trying to bootstrap junk data from the card. I would suspect the ROM boot loader is "fooled" into thinking that there's executable code on the Windows machine formatted SD cards.

Could you please point us in the right direction to help us figure out if this is a 5728 ROM boot loader issue or further on in the chain than that?

If its a ROM boot loader issue, could you please provide us some links/resources to determine how SD cards should be formatted if you want to use those cards for external storage instead of for bootstrapping Linux.

Note: We need to use SD cards plugged into the SD card slot (mmc0) as the storage mechanism - not SD cards plugged into a USB<->SD Card adaptor. 

Thanks!!

Jeff Andich

  • 0
    TI__Genius 15510 points

    Hi Jeff,

    If you use the create-sdcard.sh script in the SDK, it uses parted to create the partitions. I just made a card and did a hexdump -C /dev/sdc

    00000000  eb 58 90 6d 6b 66 73 2e  66 61 74 00 02 01 20 00  |.X.mkfs.fat... .|
    00000010  02 00 00 00 00 f8 00 00  3e 00 7a 00 00 08 00 00  |........>.z.....|
    00000020  00 30 02 00 4f 04 00 00  00 00 00 00 02 00 00 00  |.0..O...........|

    The boot ROM does a simple check of the first word and if it is not 0x00000000 or 0xFFFFFFFF, it tries to boot from the card. So you get an exception since it is trying to load what it thinks is a large image to some odd address.

    If I use dd if=/dev/zero of=/dev/sdc bs=1M count=2048

    And then I use fdisk on Linux, I'm prompted where to start the first sector. The default is 2048

    First sector (2048-7744511, default 2048):

    hexdump -C /dev/sdc

    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001b0  00 00 00 00 00 00 00 00  3f c8 9b 6b 00 00 00 21  |........?..k...!|
    000001c0  03 00 83 69 de ff 00 08  00 00 00 24 76 00 00 00  |...i.......$v...|
    000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
    00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00100000  eb 58 90 6d 6b 66 73 2e  66 61 74 00 02 01 20 00  |.X.mkfs.fat... .|

    So the boot ROM will read 0x00000000 and move on to the eMMC.

    The reason for the dd is to clear out anything that was already there. fdisk would just skip to the 2048 sector and not touch anything before it so if anything was in there, it would still be there after fdisk and you would fail booting again.

    Now taking that same card and formatting using Windows fdisk, hexdump shows

    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001b0  00 00 00 00 00 00 00 00  3f c8 9b 6b 00 00 00 21  |........?..k...!|
    000001c0  03 00 0b 69 de ff 00 08  00 00 00 24 76 00 00 00  |...i.......$v...|
    000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
    00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00100000  eb 58 90 4d 53 44 4f 53  35 2e 30 00 02 08 0c 05  |.X.MSDOS5.0.....|

    So you should be able to boot from the eMMC, even with the card inserted.

    I hope this helps.

    Steve K.

  • 0 in reply to Steve Kipisz
    Intellectual 890 points
    Thank you Steve! That's awesome!

    Now for those utilities which claim the first n sectors are unallocated, I now know how to check if they're 0 or ffff, and /dev/zero them.

    Will give all of this a try and let you know if I have questions..

    Regards,

    Jeff