Hi Stefan, On Wed, May 17, 2023 at 1:26 AM Stefan Roese <s...@denx.de> wrote: > > 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 <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... > >> > >> 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?
Pardon me for chiming in unsolicited! I think many PowerPC patches from Pali have been around for quite a long time (I had some interests so I did follow that topic for a while). Probably the problem is that Wolfgang was the maintainer and he had been inactive before passing away, and we don't have a 2nd maintainer or a replacement. All the best, Tony > > Thanks, > Stefan