Please pull u-boot-marvell/master

Please pull u-boot-marvell/master

[Stefan Roese]

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=results

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(-)

Re: Please pull u-boot-marvell/master

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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);

Re: mmc: Read eMMC partition access bits before card reset

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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.

Re: mmc: Read eMMC partition access bits before card reset

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3416 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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.

Re: mmc: Read eMMC partition access bits before card reset

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4782 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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.

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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.

Re: mmc: Read eMMC partition access bits before card reset

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6072 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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

Re: mmc: Read eMMC partition access bits before card reset

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 7049 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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.

Re: mmc: Read eMMC partition access bits before card reset

[Stefan Roese]

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

Re: mmc: Read eMMC partition access bits before card reset

[Tony Dinh]

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

Re: mmc: Read eMMC partition access bits before card reset

[Stefan Roese]

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

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabel@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-pali@kernel.org/

And these patches waiting for two months:
https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-pali@kernel.org/
https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-pali@kernel.org/

For other issues I added you to CC.

Re: mmc: Read eMMC partition access bits before card reset

[Stefan Roese]

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@kernel.org/

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-kabel@kernel.org/

AFAICT, this patch has some open issues still.

> https://patchwork.ozlabs.org/project/uboot/patch/20220802100655.17965-1-pali@kernel.org/

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@kernel.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-pali@kernel.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-pali@kernel.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-pali@kernel.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-pali@kernel.org/

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

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

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@kernel.org/
> 
> 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@kernel.org/

> > https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabel@kernel.org/
> 
> 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@kernel.org/
> 
> 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@kernel.org/
> > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-2-pali@kernel.org/
> > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-3-pali@kernel.org/
> > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-4-pali@kernel.org/
> > https://patchwork.ozlabs.org/project/uboot/patch/20230413211057.10975-5-pali@kernel.org/
> 
> 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

Re: mmc: Read eMMC partition access bits before card reset

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

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@kernel.org/
> > 
> > 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@kernel.org/

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-kabel@kernel.org/
> > 
> > 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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: mmc: Read eMMC partition access bits before card reset

[Marek Behún]

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@kernel.org/  
> > > 
> > > 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@kernel.org/  
> 
> 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

Re: mmc: Read eMMC partition access bits before card reset

[Pali Rohár]

On Monday 12 June 2023 14:11:41 Tom Rini wrote:
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20220828151929.32588-1-kabel@kernel.org/
> > > 
> > > 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

Re: mmc: Read eMMC partition access bits before card reset

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

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-kabel@kernel.org/
> > > > 
> > > > 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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]