Hi Tony,
Hi Pali,
On 5/18/23 22:55, Tony Dinh wrote:
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!
No problem. Help is always appreciated.
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.
Agreed. It's sometimes a problem with "unmaintained" areas and patches
not being reviewed and applied here on a regular basis.
Pali, I will try to pull these not applied patches - if there are not
issues of course. Could you please send me a list of these patches so
that I can take look? Please note that I will probably not be able to
work on this this week. But next week should be possible.
Thanks,
Stefan
