A38x BootROM MMC_CMD_SEND_STATUS timeouts (Was: Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot)

From: "Pali Rohár" <pali@kernel.org>
To: Peng Fan <peng.fan@nxp.com>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Martin Rowe <martin.p.rowe@gmail.com>
Cc: u-boot@lists.denx.de
Subject: A38x BootROM MMC_CMD_SEND_STATUS timeouts (Was: Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot)
Date: Sat, 25 Mar 2023 13:25:06 +0100	[thread overview]
Message-ID: <20230325122506.yoopsks4voy6wiv5@pali> (raw)
In-Reply-To: <CAOAjy5SN0mgKpw9-RYCBHj6dj4R=wE1Z6LzANzQWuwqr8imw3w@mail.gmail.com>

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.