mmc: Read eMMC partition access bits before card reset

Thu May 18 22:55:58 CEST 2023

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

All the best,
Tony

>
> Thanks,
> Stefan