Re: mmc: Read eMMC partition access bits before card reset

["Pali Rohár" <pali@kernel.org>]

On Sunday 07 May 2023 10:40:44 Tom Rini wrote:
> 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@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@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

And do you see this problem in SPL or in proper U-Boot?

If omap2plus is problematic then I can do tests on Nokia N900 or at its
qemu emulated version (to which can be attached gdb). But Nokia N900 is
without SPL.