mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

On Tuesday 16 May 2023 14:56:46 Tom Rini wrote:
> On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote:
> > On Tuesday 16 May 2023 11:36:20 Tom Rini wrote:
> > > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote:
> > > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote:
> > > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote:
> > > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote:
> > > > > > > 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 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
> > > > > > > 
> > > > > > > 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.
> > > > > > 
> > > > > > 
> > > > > > OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it
> > > > > > tries uSD.  In this case, full U-Boot also fails:
> > > > > > Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on
> > > > > > cmd inhibit to clear
> > > > > > ** Bad device specification mmc 0 **
> > > > > > 
> > > > > > Note that N900 in QEMU passes, but I suspect that's a matter of the
> > > > > > emulator not being faithful to some undocumented bug/feature of the
> > > > > > chipset and that it would also fail like this on real HW or that we
> > > > > > aren't relying on MMC in such a way that the QEMU tests actually report
> > > > > > failure.  When I booted the above, it was not a lock-up since we can
> > > > > > continue on in this case, rather than failure to load U-Boot itself.
> > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > Tom
> > > > > 
> > > > > Ok, I have tested it on Nokia N900 HW and interesting is that SD card is
> > > > > also working fine. But its initialization is slower and prints warning:
> > > > > 
> > > > >  omap_hsmmc_send_cmd: timeout waiting on cmd inhibit to clear
> > > > 
> > > > Ok, so what with it?
> > > 
> > > Seems like this change is a real bad idea to introduce on ARCH_OMAP2PLUS
> > > platforms, and probably ARCH_BCM283X too, so rework with a Kconfig
> > > option that defaults to on except for the above as I suggested?
> > > 
> > > -- 
> > > Tom
> > 
> > Ok, patch is on the list... I'm curious if patch stay here on the list
> > more than one year like some other...
> 
> I mean, since I asked you to spin a new patch and you posted a patch on
> top of the previously rejected one, someone will need to pick it up and
> fold it together. I don't know how motivated Stefan is to clear out the
> original patch.
> 
> -- 
> Tom

As I see that most of my patches are completely ignored, I have no
motivation to do something more in this area. I really would not do
something which would be also ignored like anything else.