A38x BootROM MMC_CMD_SEND_STATUS timeouts

[Pali Rohár]

On Friday 28 April 2023 15:39:20 Peng Fan wrote:
> 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.

Requirement is ENV access which is stored on eMMC too and without
initializing SPL eMMC driver, SPL cannot access ENV.

Another thing is that loading proper U-Boot via SPL eMMC driver is
sometimes faster than via BootROM eMMC code. I guess this is BootROM
does not full speed.

Also another fact is that SPL on mvebu works in this "hybrid" mode
(initialize and access boot device; plus let BootROM to use it) for all
other bootable storages.

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

Unfortunately there is no BootROM API for these processors. All issues
which are being resolved in this (and also other) discussions are done
by inspecting BootROM code and trying to understand how it behaves and
how it choose the eMMC boot partition. As this stuff has poor
documentation and even this documentation has documented erratas... So
nobody knows what exactly is and what not supported.

What we need to do is to write mvebu specific SPL code which is
compatible with BootROM.

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