PING?
On Saturday 01 April 2023 18:43:45 Pali Rohár wrote:
Can anybody help with this?
On Saturday 25 March 2023 13:25:06 Pali Rohár wrote:
CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with this issue? Expected usage is following: BootROM reads and execute SPL from eMMC (BootROM has its own code for reading eMMC), SPL initialize mmc driver and after SPL finish its work it returns control back to BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue is that after SPL returns control back to BootROM it looks like that BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts (timeout takes 5 minutes!) and after it correctly reads proper U-Boot from eMMC and continues booting proper U-Boot. I guess that there is an issue that SPL's mmc driver changes eMMC state into something which BootROM does not expect.
On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
On Thu, 23 Mar 2023 at 19:01, Pali Rohár pali@kernel.org wrote:
There is issue with that 5 minutes delay. But I think it should be fixed by the patch which I sent earlier, which restore partition config based on mmc->part_config in board_return_to_bootrom(). Could you test it? https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/ Now when mmc->part_config is correctly initialized it should restore configuration and BootROM does not have to get that "Timeout waiting card ready" error.
Still takes about 5 minutes. The output is below with MMC tracing. I confirmed the value of mmc->part_config used for restore_emmc_boot_part_config is the same as what is initially detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and zeroed boot0).
ERROR: Invalid kwbimage v1 mmc_load_image_raw_sector: mmc block read error spl: mmc: wrong boot mode Trying to boot from BOOTROM CMD_SEND:6 ARG 0x03b30a00 MMC_RSP_R1b 0x00000900 CMD_SEND:13 ARG 0x00010000 MMC_RSP_R1,5,6,7 0x00000900 CURR STATE:4 Returning to BootROM (return address 0xffff05c4)...
I looked at the BootROM disassembled code and error message "Timeout waiting card ready" is printed when following mmc command cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts.
0xd is in U-Boot MMC_CMD_SEND_STATUS
0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY which looks like U-Boot's MMC_RSP_R2 with BUSY bit set
It looks like U-Boot function mmc_send_status() where that "something" in cmdarg is mmc->rca.
If command does not timeout then BootROM next checks if response has BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are truth then BootROM mark call as successful.
If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints "Status Error: " with hex response value and mark call as unsuccessful.
I'm looking at the U-Boot code and this BootROM logic looks very similar to U-Boot function mmc_poll_for_busy(), just without first call mmc_wait_dat0().
BIT(8) is MMC_STATUS_RDY_FOR_DATA 0x1e00 is MMC_STATUS_CURR_STATE 0xe00 is MMC_STATE_PRG 0xfdf94080 is MMC_STATUS_MASK
I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing in BootROM after U-Boot returns control back to the BootROM.