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