Please pull u-boot-marvell/master
Hi Tom,
please pull this next batch of mostly Marvell related patches:
---------------------------------------------------------------- - kwboot/mmc: Misc fixes for eMMC booting (Pali) - mvebu: avoid buffer overflow in hws_serdes_topology_verify (Heinrich) ----------------------------------------------------------------
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=300&view=resu...
Thanks, Stefan
The following changes since commit 30f6305e0cdcf59b0247b057f04374818d7c76e6:
Merge branch '2023-05-01-assorted-powerpc-updates' (2023-05-02 12:50:42 -0400)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-marvell.git
for you to fetch changes up to a61a56a4a50d73ff747ee3fff3c680886ce76d07:
arm: mvebu: avoid buffer overflow in hws_serdes_topology_verify (2023-05-03 08:39:23 +0200)
---------------------------------------------------------------- Heinrich Schuchardt (1): arm: mvebu: avoid buffer overflow in hws_serdes_topology_verify
Pali Rohár (4): tools: kwboot: Fix MMC partitions documentation mmc: Read eMMC partition access bits before card reset arm: mvebu: spl: Load proper U-Boot from correct eMMC partition arm: mvebu: clearfog: Update eMMC/SD/SATA instructions
.../mach-mvebu/serdes/a38x/high_speed_env_spec.c | 4 +-- arch/arm/mach-mvebu/spl.c | 10 +++++-- board/solidrun/clearfog/README | 20 +++++++------- drivers/mmc/mmc.c | 31 +++++++++++++++++++--- tools/kwboot.c | 9 ++++--- 5 files changed, 54 insertions(+), 20 deletions(-)
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.
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:
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index ac484c73f62d..fe691cd435e7 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -353,6 +353,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC imply SPL_GPIO imply SPL_LIBDISK_SUPPORT imply SPL_MMC + select MMC_ENABLE_PART_ACCESS if SPL_MMC select SUPPORT_EMMC_BOOT if SPL_MMC select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC select SPL_BOOTROM_SUPPORT diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index de01b9687bad..c28598fc295c 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -107,6 +107,16 @@ config MMC_HW_PARTITIONING This adds a command and an API to do hardware partitioning on eMMC devices.
+config MMC_ENABLE_PART_ACCESS + bool "Support for MMC partition access bits" + help + Read partition access bits from partition config register before card reset command + because these bits are reset to default value (User Data Area) during card reset. + This allows us to preserve original value of partition access bits used by the code + which loaded us (for example BootROM) and use it for board specific boot purposes. + . + This is required when U-Boot is using EXT_CSD_EXTRACT_PARTITION_ACCESS macro. + config SUPPORT_EMMC_RPMB bool "Support eMMC replay protected memory block (RPMB)" imply CMD_MMC_RPMB diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 9915610d82b1..fa3c4d1937c1 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2864,6 +2864,7 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet) retry: mmc_set_initial_state(mmc);
+#ifdef CONFIG_MMC_ENABLE_PART_ACCESS /* * Read partition access bits from partition config register before card reset command * because these bits are reset to default value (User Data Area) during card reset. @@ -2878,6 +2879,7 @@ retry: ext_csd[EXT_CSD_BOOT_MULT])) mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & PART_ACCESS_MASK; } +#endif
/* Reset the Card */ err = mmc_go_idle(mmc);
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. 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.
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.
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).
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.
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 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.
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.
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 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.
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.
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 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.
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?
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.
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 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.
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?
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 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.
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...
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 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.
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.
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 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.
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.
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 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. > > > 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?
Thanks, Stefan
Hi Stefan,
On Wed, May 17, 2023 at 1:26 AM Stefan Roese sr@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 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. >> >> >> 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
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 sr@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 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. >>> >>> >>> 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
On Thursday 25 May 2023 14:57:32 Stefan Roese wrote:
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 sr@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 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. > > > > > > > > > > > > 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
Hello!
These patches are on the list for year: https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-pali... https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabe... https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-pali...
And these patches waiting for two months: https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-pali@... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-pali...
For other issues I added you to CC.
Hi Pali,
(added Peng for PowerPC and Jaehoon for MMC to Cc)
On 6/11/23 15:03, Pali Rohár wrote:
<snip>
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
Hello!
These patches are on the list for year: https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-pali...
This patch fails with multiple problems. Reason is, that it's very "old" and many of the Kconfig stuff was changed, which is of course not your fault. Still, I'm not in the right position to make these changes I'm afraid.
Peng, this patch is now assigned to you in patchwork. Could you please also take a look? And if Pali (or someone else) sends an updated version, could you please make sure that it's reviewed (and applied if no issues arise) in due time?
https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabe...
AFAICT, this patch has some open issues still.
https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-pali...
This one is now in next. I've updated here the patchwork status.
And these patches waiting for two months: https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-pali@... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-pali...
Jaehoon, could you please take a look at these MMC related patches? And if no issues arise, pull them into next?
For other issues I added you to CC.
Thanks, Stefan
On Monday 12 June 2023 11:22:12 Stefan Roese wrote:
Hi Pali,
(added Peng for PowerPC and Jaehoon for MMC to Cc)
On 6/11/23 15:03, Pali Rohár wrote:
<snip>
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
Hello!
These patches are on the list for year: https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-pali...
This patch fails with multiple problems. Reason is, that it's very "old" and many of the Kconfig stuff was changed, which is of course not your fault. Still, I'm not in the right position to make these changes I'm afraid.
Peng, this patch is now assigned to you in patchwork. Could you please also take a look? And if Pali (or someone else) sends an updated version, could you please make sure that it's reviewed (and applied if no issues arise) in due time?
Updated version was already sent but again no response... https://patchwork.ozlabs.org/project/uboot/patch/20220817205622.26644-1-pali...
https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabe...
AFAICT, this patch has some open issues still.
There were suggestion to make (that new kconfig option) enabled for everything. But nobody respond if it is possible to have it unconditionally enabled for every one board. Hence new config option in that patch was introduced.
https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-pali...
This one is now in next. I've updated here the patchwork status.
Perfect! Finally some response here.
And these patches waiting for two months: https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-pali@... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-pali... https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-pali...
Jaehoon, could you please take a look at these MMC related patches? And if no issues arise, pull them into next?
For other issues I added you to CC.
Thanks, Stefan
On Mon, Jun 12, 2023 at 07:39:20PM +0200, Pali Rohár wrote:
On Monday 12 June 2023 11:22:12 Stefan Roese wrote:
Hi Pali,
(added Peng for PowerPC and Jaehoon for MMC to Cc)
On 6/11/23 15:03, Pali Rohár wrote:
<snip>
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
Hello!
These patches are on the list for year: https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-pali...
This patch fails with multiple problems. Reason is, that it's very "old" and many of the Kconfig stuff was changed, which is of course not your fault. Still, I'm not in the right position to make these changes I'm afraid.
Peng, this patch is now assigned to you in patchwork. Could you please also take a look? And if Pali (or someone else) sends an updated version, could you please make sure that it's reviewed (and applied if no issues arise) in due time?
Updated version was already sent but again no response... https://patchwork.ozlabs.org/project/uboot/patch/20220817205622.26644-1-pali...
I was expecting Marek Behún to follow up and take this as he's the one that volunteered to take over one of the powerpc custodian trees and push this through. I've replied now with more feedback.
https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabe...
AFAICT, this patch has some open issues still.
There were suggestion to make (that new kconfig option) enabled for everything. But nobody respond if it is possible to have it unconditionally enabled for every one board. Hence new config option in that patch was introduced.
Yes, the feedback was to change things so that the behavior is the default, since it looks like what we're doing now is wrong. And you have access to a few platforms to test things on to see if it breaks other platforms, and then putting it in to -next or early in the merge cycle on master would shake out any other problems with the approach. So if you're still interested in that platform, please make it a generic change or report back where it does fail so we can see what's going on elsewhere. Making the init_sequence_f table even more difficult to read is something we do want to avoid.
On Mon, 12 Jun 2023 14:11:41 -0400 Tom Rini trini@konsulko.com wrote:
On Mon, Jun 12, 2023 at 07:39:20PM +0200, Pali Rohár wrote:
On Monday 12 June 2023 11:22:12 Stefan Roese wrote:
Hi Pali,
(added Peng for PowerPC and Jaehoon for MMC to Cc)
On 6/11/23 15:03, Pali Rohár wrote:
<snip>
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
Hello!
These patches are on the list for year: https://patchwork.ozlabs.org/project/uboot/patch/20220516090119.20217-1-pali...
This patch fails with multiple problems. Reason is, that it's very "old" and many of the Kconfig stuff was changed, which is of course not your fault. Still, I'm not in the right position to make these changes I'm afraid.
Peng, this patch is now assigned to you in patchwork. Could you please also take a look? And if Pali (or someone else) sends an updated version, could you please make sure that it's reviewed (and applied if no issues arise) in due time?
Updated version was already sent but again no response... https://patchwork.ozlabs.org/project/uboot/patch/20220817205622.26644-1-pali...
I was expecting Marek Behún to follow up and take this as he's the one that volunteered to take over one of the powerpc custodian trees and push this through. I've replied now with more feedback.
Please also look at my reply at https://lists.denx.de/pipermail/u-boot/2023-June/520031.html
To recapitulate - Pali worked on this over a year ago, he has done quite a lot of work - it wasn't accepted at the time due to how some things changed in U-Boot - things regarding the conversion of CONFIG_ options, which Pali disagreed with since some of it was done in a wrong way. He wanted those changes to be reverted whole - I promised Pali to work it out, once I had time to look into it. I expected to be able to do it in october / november. Unfortunately I wasn't able to, things have been quite hectic since then (I was working on my diploma thesis and afterwards when I returned to work, more pressing things took precedence)
Thus I quite understand why Pali is frustrated, since he has done the work over a year ago. I am awfully sorry about this :-(
By no means I have forgotten about this. We at Turris still want to work on this, since we are still interested in maintaining Turris 1.x. We are currently in the process of hiring new kernel developers, and so hopefully I will be able to work on this issue soon.
Marek
On Monday 12 June 2023 14:11:41 Tom Rini wrote:
https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabe...
AFAICT, this patch has some open issues still.
There were suggestion to make (that new kconfig option) enabled for everything. But nobody respond if it is possible to have it unconditionally enabled for every one board. Hence new config option in that patch was introduced.
Yes, the feedback was to change things so that the behavior is the default, since it looks like what we're doing now is wrong.
Sorry, but from the discussion I have not deduced this fact. Instead from long silence it looks like that we cannot do any global change and so config option was proposed there.
And you have access to a few platforms to test things on to see if it breaks other platforms,
Unfortunately I do not have any other platform which is booting XIP booting, which could be affected by that patch.
and then putting it in to -next or early in the merge cycle on master would shake out any other problems with the approach. So if you're still interested in that platform, please make it a generic change or report back where it does fail so we can see what's going on elsewhere. Making the init_sequence_f table even more difficult to read is something we do want to avoid.
-- Tom
On Sat, Jun 24, 2023 at 11:26:42AM +0200, Pali Rohár wrote:
On Monday 12 June 2023 14:11:41 Tom Rini wrote:
https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabe...
AFAICT, this patch has some open issues still.
There were suggestion to make (that new kconfig option) enabled for everything. But nobody respond if it is possible to have it unconditionally enabled for every one board. Hence new config option in that patch was introduced.
Yes, the feedback was to change things so that the behavior is the default, since it looks like what we're doing now is wrong.
Sorry, but from the discussion I have not deduced this fact. Instead from long silence it looks like that we cannot do any global change and so config option was proposed there.
I thought it was clearer, sorry for the confusion.
And you have access to a few platforms to test things on to see if it breaks other platforms,
Unfortunately I do not have any other platform which is booting XIP booting, which could be affected by that patch.
Well, making the change for everyone would effect the platforms you have, and is what I'm asking you to test. I don't know that there is any other platform that has the specific case you're describing.
participants (5)
-
Marek Behún -
Pali Rohár -
Stefan Roese -
Tom Rini -
Tony Dinh