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