A38x BootROM MMC_CMD_SEND_STATUS timeouts

[Peng Fan]

On 4/2/2023 12:43 AM, Pali Rohár wrote:
> Can anybody help with this?

I expected Jaehoon would say some words.

> 
> 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.

A general question is since BootROM will still using eMMC, why let
SPL to initialize eMMC? SPL's configuration may not match ROM's expection.

For example i.MX, there is ROM API, SPL use ROM API to ask ROM to ask
ROM help loading images, and SPL not touch relevant USB/EMMC.

Regards,
Peng.

>>
>> On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
>>> On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali at 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.