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 <p...@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 <p...@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 But what is worse that testing on N900 HW is problematic now because bootmenu rendering in upstream U-Boot is broken and it just prints ASCII sequence garbage on the phone display.
