mmc: Read eMMC partition access bits before card reset
Tom Rini
trini at konsulko.com
Sun May 7 18:45:11 CEST 2023
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230507/1a723b7f/attachment.sig>
More information about the U-Boot
mailing list