mmc: Read eMMC partition access bits before card reset

Stefan Roese sr at denx.de
Thu May 25 14:57:32 CEST 2023 

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

More information about the U-Boot mailing list