Tool/software: Linux
Dear TI team,
we've run into a problem with U-Boot (based on git.ti.com/.../ti-u-boot-2018.01 when booting our custom board from OSPI.
We've managed to get all three stages of U-Boot to boot (R5, A53 SPL, A53), but when the final stage tries to initialize the external SD card (on MMC1, similar to AM65x EVM) U-Boot fails with a timeout error:
sdhci_send_command: MMC: 1 busy timeout increasing to: 200 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 400 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 800 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 1600 ms.
sdhci_send_command: MMC: 1 busy timeout increasing to: 3200 ms.
sdhci_send_command: MMC: 1 busy timeout.
This has been reported in a previous thread, and in that thread it was linked to some known-issue LCPD-13666 in 05_01_00_11. According to the latest release notes (05_02_00_10) this should be solved, but our U-Boot is already based on the sources from the latest release. Is it possible to find out what the root source for that issue was, and how it got solved?
When using the same U-Boot sources (different device tree) to boot our AM65x_IDK to boot from OSPI we didn't see this problem.
We haven't yet had a chance to try this on a second board of our own hardware.
We managed to track the issue down to the power domain for MMC1 being eanbled via a SCI message. If we place a breakpoint right BEFORE the mbox_post call the sends the message to the DMSC and continue from there we get the timeout. If we place the breakpoint AFTER the mbox_post call and continue from there (i.e. create an considerable delay of several seconds) the initialization works just fine and the card is accessible. Unfortunately due to the SCI firmware being a BLOB we don't know what that call really does on the device level.
Regards,
Dominic
