mmc: Read eMMC partition access bits before card reset

Sun Jun 11 15:03:04 CEST 2023

On Thursday 25 May 2023 14:57:32 Stefan Roese wrote:
> Hi Tony,
> Hi Pali,
> 
> On 5/18/23 22:55, Tony Dinh wrote:
> > Hi Stefan,
> > 
> > On Wed, May 17, 2023 at 1:26 AM Stefan Roese <sr at denx.de> wrote:
> > > 
> > > Hi Pali,
> > > 
> > > On 5/17/23 00:30, Pali Rohár wrote:
> > > > 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.
> > > 
> > > Hmmm, I don't know what to make of this. Pali, I really appreciate all
> > > your great work in the Marvell / MVEBU area and others as well. Very
> > > important fixes and good improvements indeed. And I pushed many patches
> > > (many hundreds!) from you to mainline in the last years. I'm not aware
> > > of bigger counts of patches from you that are "completely ignored". And
> > > they don't show up in my patchworks list either. So what are these
> > > "completely ignored" patches your are referring to?
> > 
> > Pardon me for chiming in unsolicited!
> 
> No problem. Help is always appreciated.
> 
> > I think many PowerPC patches
> > from Pali have been around for quite a long time (I had some interests
> > so I did follow that topic for a while). Probably the problem is that
> > Wolfgang was the maintainer and he had been inactive before passing
> > away, and we don't have a 2nd maintainer or a replacement.
> 
> Agreed. It's sometimes a problem with "unmaintained" areas and patches
> not being reviewed and applied here on a regular basis.
> 
> Pali, I will try to pull these not applied patches - if there are not
> issues of course. Could you please send me a list of these patches so
> that I can take look? Please note that I will probably not be able to
> work on this this week. But next week should be possible.
> 
> Thanks,
> Stefan

Hello!

These patches are on the list for year:
https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabel@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-pali@kernel.org/

And these patches waiting for two months:
https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-pali@kernel.org/

For other issues I added you to CC.