mmc: Read eMMC partition access bits before card reset

[Tom Rini]

On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote:
> On Sunday 07 May 2023 09:54:52 Tom Rini wrote:
> > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote:
> > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote:
> > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote:
> > > > 
> > > > > Hi Tom,
> > > > > 
> > > > > please pull this next batch of mostly Marvell related patches:
> > > > 
> > > > NAK.  With commit:
> > > > commit 461fa17970de418a93832f734a595031c0b72128
> > > > Author: Pali Rohár <pali at kernel.org>
> > > > Date:   Thu Apr 13 22:57:48 2023 +0200
> > > > 
> > > >     mmc: Read eMMC partition access bits before card reset
> > > >     
> > > >     eMMC specification in section "Access partitions" says that all reset
> > > >     events will restore the access bits in PARTITION_CONFIG CSD register to
> > > >     default User Data Area value (0b000).
> > > >     
> > > >     So read partition access bits from PARTITION_CONFIG CSD register before
> > > >     issuing card reset. This allows SPL/U-Boot to get information which eMMC
> > > >     partition was in use before SPL/U-Boot was booted. For some platforms this
> > > >     is the way how to determinate boot partition from which BootROM loaded SPL.
> > > >     
> > > >     Signed-off-by: Pali Rohár <pali at kernel.org>
> > > > 
> > > > My am335x_evm now fails to boot with:
> > > > 
> > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - 13:10:10 -0400)
> > > > Trying to boot from MMC1
> > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear
> > > > spl: mmc init failed with error: -110
> > > > SPL: failed to boot from all boot devices
> > > > ### ERROR ### Please RESET the board ###
> > > > 
> > > > I can provide more details / test patches as needed.
> > > > 
> > > > -- 
> > > > Tom
> > > 
> > > I do not know what to do with this... The only idea is to hide this code
> > > behind CONFIG symbol and enable it only for mvebu. For example by this:
> > 
> > Well, maybe the problem is we're trying this on uSD cards? The failure I
> > reported was uSD and not eMMC.
> 
> Maybe it is that reason. Problem is that at this stage we do not know if
> card is SD or MMC.
> 
> Martin, can you check if booting from SD card is working fine on mvebu
> clearfog?
> 
> > I see a failure with this commit on
> > rpi_3_32b, also from uSD boot.  This time it's:
> > Loading Environment from FAT... fsm 0, hsts 00000000
> > fsm 0, hsts 00000000
> > ...
> > 
> > once in U-Boot itself.  Going to the commit prior to the above one and
> > the board is fine again.
> > 
> > -- 
> > Tom
> 
> Immediately after that "problematic code" is card reset function. So
> another reason for failure is that card reset functionality does not
> work correctly on your board / platform.

Well, we're at two different platforms and controllers that this change
breaks things on, so I'm not sure where the fault is exactly.  My
mx6cuboxi is still fine booting from uSD.  Another TI platform from the
same general era as am335x fails the same way (not a surprise), amlogic
libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are
also fine with this.  So maybe the Kconfig is fine, but we just want
default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms
that work are not ARCH_OMAP2PLUS).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230507/fded2b24/attachment.sig>