• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 100 subscribers
  • Views 491 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.

AM5728: Windows formatted SD card prevents boot

ScottS
Intellectual 820 points
Part Number: AM5728

Hello,

We have an AM5728 based device that is working as intended. Usually it boots from internal eMMC. A recovery method allows booting from an SD card, which can completely reprogram the eMMC. This, too, is working as intended. Our device boots from one SD card slot and a second SD card slot can be used for just data.

However, we have found if a user formats a SD card for data using windows, our device will hang during boot before displaying any characters on the serial console port. In other words, the device apparently hangs before MLO starts. If we remove the SD card with the power still connected, the device then boots normally. We determined the problem is the bootstrap code in the master boot record on the SD card. (The first 440 bytes in the first sector) This happens only using the SD card slot we enabled for booting. If we put the same SD card in the "data" slot, the device boots correctly. Note this problem can be reproduced with an empty formatted card - no files were copied to the card.

Windows apparently puts assembly code in the master boot record, probably to boot from an internal hard drive if the SD card is accidentally left in the system. Apparently when our device tries to boot, it tries to execute the foreign code. This apparently crashes the arm processor, which then reboots. This apparent boot, read from SD card, crash loop continues until the SD card is removed.

We used the SD card formatter (from www.sdcard.org) and our device boots fine with that card. The code in the master boot record is all zeros. Either the device detects all zeros or that arm instruction does nothing.

We can format an SD card with windows and edit the master boot record code to be all zeros and our unit boots correctly, which confirms the problem is that boot code.

We've tested with multiple SD cards, but mostly 16GB. The SD card is formatted as FAT32 and the one partition is not marked bootable. On our SD card used for recovery, the first partition is also FAT32 but it's marked bootable. There are two linux partitions on the the recovery card.

From what we've read in the AM572x technical reference manual, the code that detects and attempts to boot from the SD card is in ROM and can't be changed. Is this correct? Is there any way to prevent the boot process from reading & executing the code in the master boot record on a data SD card? Our goal is a data only SD card doesn't interfere with booting.

Any help will be appreciated.

Thanks,

Scott

  • 0
    TI__Guru**** 163150 points

    Hi Scott,

    Recommended way is to create the SD card from Linux/Ubuntus OS. 

    ScottS said:
    the code that detects and attempts to boot from the SD card is in ROM and can't be changed. Is this correct?

    That is right.

    ScottS said:
    The SD card is formatted as FAT32 and the one partition is not marked bootable.

    Have you tried keeping the data in EXT4 partition?

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 820 points

    Hi Keerthy,

    I understand the recommended way is to format the card using Linux, but our customers don't have that. They format the SD card using windows as FAT32, download data files, and copy the files to the card.

    The problem isn't the format of the partition. The AM5728 is trying to execute the code in the master boot record.

    This doesn't happen with our other devices that use a AM571x, just the AM5728. The two processors apparently handle the master boot record differently.

    We're hoping for a solution that is better than "Don't put a data only card in the boot-able SD card slot"

    Thanks,
    Scott

  • 0 in reply to ScottS
    TI__Guru**** 163150 points

    Hi Scott,

    So basically you are suspecting a difference in RoM code behavior w.r.t handling the master boot record. I will check internally on this & get back to you.

    Regards,
    Keerthy

  • 0 in reply to Keerthy J
    Intellectual 820 points

    Hi Keerthy,

    Is there an update on this issue?

    Thanks,
    Scott

  • 0 in reply to ScottS
    Intellectual 820 points

    Hi Keerthy,

    Is there an update on this issue?

    Thanks,
    Scott

  • 0 in reply to ScottS
    TI__Guru 56835 points

    Hi Scott,

    Sorry for the long delay is this issue still exists ?

    Regards
    Diwakar

  • 0 in reply to Diwakar Dhyani
    Intellectual 820 points

    Hello,

    Yes, the problem still exists.

    Thanks,

    Scott

  • +1 in reply to ScottS
    TI__Guru 56835 points

    Hi ScottS,

    We recommend to use Linux ,we have validated all the things on linux only.

    You can use VM on windows and install ubuntu on that ,  you can use the below steps to  prepare the sd card on linux host. 

    software-dl.ti.com/.../Processor_SDK_Linux_Formatting_SD_Card.html

    Regards
    Diwakar

  • 0 in reply to Diwakar Dhyani
    Intellectual 820 points

    Hello,

    I understand the recommended process is format the SD card using Linux, but not everyone has Linux. Also, we have no control over how a brand new SD card is pre-formatted by the manufacturer.

    We're putting data files on an SD card formatted with FAT32. In the partition table, the card is not marked bootable. However, it appears the AM5728 loads and tries to use the executable code in the boot sector. If that code crashes, the unit is in a very tight load, crash, reboot loop. This endless loop stops as soon as the SD card is removed (at least briefly) and the unit boots from spi / emmc.

    We have added code on the unit that checks the SD cards when they're inserted. If the card is not marked bootable, we zero out the executable code in the boot sector. This is a work around for the problem on future boots, but not the first boot.

    Ideally, the AM5728 boot code would not try to use executable code from a non bootable SD card. (This applies to all devices)

    Thanks,
    Scott