mmc: Read eMMC partition access bits before card reset

Stefan Roese sr at denx.de
Wed May 17 10:26:45 CEST 2023 

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?

Thanks,
Stefan

More information about the U-Boot mailing list