Re: [PATCH v2 u-boot-mvebu 4/4] arm: mvebu: clearfog: Update eMMC/SD/SATA instructions
On Thu, 13 Apr 2023 at 20:58, Pali Rohár wrote: > > BootROM and neither SPL does not use eMMC boot acknowledgement or boot > enable bits in EXT_CSD_PART_CONF eMMC register. And also fixed SATA disk > sector 0x141 is not used at all. > > Signed-off-by: Pali Rohár SPL successfully loads u-boot from the same partition as SPL. SD card and UART continue to boot. Thanks Pali! Tested-by: Martin Rowe > --- > board/solidrun/clearfog/README | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README > index ed4a712c5aa2..c86b37061a30 100644 > --- a/board/solidrun/clearfog/README > +++ b/board/solidrun/clearfog/README > @@ -1,7 +1,7 @@ > Update from original Marvell U-Boot to mainline U-Boot: > --- > > -Generate the U-Boot image with these commands: > +Generate the U-Boot image for eMMC/SD with these commands: > > $ make clearfog_defconfig > $ make > @@ -9,7 +9,7 @@ $ make > The resulting image including the SPL binary with the > full DDR setup is "u-boot-with-spl.kwb". > > -Now all you need to do is copy this image on a SD card. > +Now all you need to do is copy this image on a SD card's sector 1. > For example with this command: > > $ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 > @@ -20,12 +20,6 @@ of "/dev/sdX" here! > Install U-Boot on eMMC: > --- > > -To make SPL load the main U-Boot image from the eMMC boot partition enable > -eMMC boot acknowledgement and boot partition with the following U-Boot > -command: > - > - mmc partconf 0 1 1 0 > - > Install U-Boot on eMMC boot partition from Linux running on Clearfog: > >echo 0 > /sys/block/mmcblk0boot0/force_ro > @@ -37,8 +31,14 @@ Consider initial boot from UART (see below). > Install U-Boot on SATA: > --- > > -When loading the main U-Boot image from raw SATA sector, set > -CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR to 0x141. > +Generate the U-Boot image for SATA with these commands: > + > +$ make clearfog_sata_defconfig > +$ make > + > +Copy image on a SATA disk's sector 1: > + > +$ sudo dd if=u-boot-with-spl.kwb of=/dev/sdX bs=512 seek=1 > > Boot selection: > --- > -- > 2.20.1 >
Re: [PATCH u-boot-mvebu 7/7] arm: mvebu: spl: Allow to build SATA kwbimage for 4K Native disks
On Wed, 29 Mar 2023 at 19:28, Pali Rohár wrote: > Add a new config option CONFIG_MVEBU_SPL_SATA_BLKSZ for specifying block > size of SATA disk. This information is used during building of SATA > kwbimage and must be correctly set, otherwise BootROM does not load SPL. > > For 4K Native disks CONFIG_MVEBU_SPL_SATA_BLKSZ must be set to 4096. > > Signed-off-by: Pali Rohár I only have 512 drives to test with, but there are no regressions with MMC (SD and eMMC), SPI, UART, or SATA (512) booting on Clearfog. Tested-by: Martin Rowe > --- > arch/arm/mach-mvebu/Kconfig | 10 ++ > arch/arm/mach-mvebu/Makefile| 5 + > arch/arm/mach-mvebu/kwbimage.cfg.in | 3 +++ > 3 files changed, 18 insertions(+) > > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig > index 1f0dbef1c68a..e6e911f8af7d 100644 > --- a/arch/arm/mach-mvebu/Kconfig > +++ b/arch/arm/mach-mvebu/Kconfig > @@ -380,6 +380,16 @@ config MVEBU_SPL_NAND_BADBLK_LOCATION > Value 0x0 = SLC flash = BBI at page 0 or page 1 > Value 0x1 = MLC flash = BBI at last page in the block > > +config MVEBU_SPL_SATA_BLKSZ > + int "SATA block size" > + depends on MVEBU_SPL_BOOT_DEVICE_SATA > + range 512 32768 > + default 512 > + help > + Block size of the SATA disk in bytes. > + Typically 512 bytes for majority of disks > + and 4096 bytes for 4K Native disks. > + > config MVEBU_EFUSE > bool "Enable eFuse support" > depends on HAVE_MVEBU_EFUSE > diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile > index 90f88337bc10..0584ed2be5b4 100644 > --- a/arch/arm/mach-mvebu/Makefile > +++ b/arch/arm/mach-mvebu/Makefile > @@ -73,6 +73,11 @@ KWB_CFG_NAND_BLKSZ = $(CONFIG_SYS_NAND_BLOCK_SIZE) > KWB_CFG_NAND_BADBLK_LOCATION = $(CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION) > endif > > +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),) > +KWB_REPLACE += SATA_BLKSZ > +KWB_CFG_SATA_BLKSZ = $(CONFIG_MVEBU_SPL_SATA_BLKSZ) > +endif > + > ifneq ($(CONFIG_SECURED_MODE_IMAGE),) > KWB_REPLACE += CSK_INDEX > KWB_CFG_CSK_INDEX = $(CONFIG_SECURED_MODE_CSK_INDEX) > diff --git a/arch/arm/mach-mvebu/kwbimage.cfg.in > b/arch/arm/mach-mvebu/kwbimage.cfg.in > index 90cf00c5b984..588c259202bb 100644 > --- a/arch/arm/mach-mvebu/kwbimage.cfg.in > +++ b/arch/arm/mach-mvebu/kwbimage.cfg.in > @@ -16,6 +16,9 @@ VERSION 1 > #@NAND_BLKSZ > #@NAND_BADBLK_LOCATION > > +# SATA configuration > +#@SATA_BLKSZ > + > # Enable BootROM output via DEBUG flag on SoCs which require it > #@DEBUG > > -- > 2.20.1 >
[PATCH v3 3/3] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
[upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
The Clearfog devices have only one SDHC device. This is either eMMC if
it is populated on the SOM or SDHC if not. The Linux device tree assumes
the SDHC case. Detect if the device is an eMMC and fixup the device-tree
so it will be detected by Linux.
Ported from vendor repo at https://github.com/SolidRun/u-boot
Signed-off-by: Martin Rowe
---
Resend with correct header
Fixed spacing and removed __maybe_unused
arch/arm/mach-mvebu/Kconfig| 1 +
board/solidrun/clearfog/clearfog.c | 33 ++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 1f0dbef1c6..b1f2e97ae7 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -107,6 +107,7 @@ config TARGET_CLEARFOG
bool "Support ClearFog"
select 88F6820
select BOARD_LATE_INIT
+ select OF_BOARD_SETUP
config TARGET_HELIOS4
bool "Support Helios4"
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index 03adb591d8..6edb422155 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -261,3 +262,35 @@ int board_late_init(void)
return 0;
}
+
+static bool has_emmc(void)
+{
+ struct mmc *mmc;
+
+ mmc = find_mmc_device(0);
+ if (!mmc)
+ return 0;
+ return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
+}
+
+/*
+ * The Clearfog devices have only one SDHC device. This is either eMMC
+ * if it is populated on the SOM or SDHC if not. The Linux device tree
+ * assumes the SDHC case. Detect if the device is an eMMC and fixup the
+ * device-tree, so that it will be detected by Linux.
+ */
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ int node;
+
+ if (has_emmc()) {
+ node = fdt_node_offset_by_compatible(blob, -1,
"marvell,armada-380-sdhci");
+ if (node < 0)
+ return 0; /* Unexpected eMMC device; patching not
supported */
+
+ puts("Patching FDT so that eMMC is detected by OS\n");
+ return fdt_setprop_empty(blob, node, "non-removable");
+ }
+
+ return 0;
+}
--
2.40.0
Re: [PATCH v2 3/3] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
On Mon, 27 Mar 2023 at 07:26, Stefan Roese wrote:
>
> Hi Martin,
>
> On 3/25/23 01:02, Martin Rowe wrote:
> > [upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
> >
> > The Clearfog devices have only one SDHC device. This is either eMMC if
> > it is populated on the SOM or SDHC if not. The Linux device tree assumes
> > the SDHC case. Detect if the device is an eMMC and fixup the device-tree
> > so it will be detected by Linux.
> >
> > Ported from vendor repo at https://github.com/SolidRun/u-boot
> >
> > Signed-off-by: Martin Rowe
> > ---
> > arch/arm/mach-mvebu/Kconfig| 1 +
> > board/solidrun/clearfog/clearfog.c | 32 ++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> > index fb3cff43f7..773635d691 100644
> > --- a/arch/arm/mach-mvebu/Kconfig
> > +++ b/arch/arm/mach-mvebu/Kconfig
> > @@ -107,6 +107,7 @@ config TARGET_CLEARFOG
> > bool "Support ClearFog"
> > select 88F6820
> > select BOARD_LATE_INIT
> > + select OF_BOARD_SETUP
> >
> > config TARGET_HELIOS4
> > bool "Support Helios4"
> > diff --git a/board/solidrun/clearfog/clearfog.c
> > b/board/solidrun/clearfog/clearfog.c
> > index 03adb591d8..0087fea7db 100644
> > --- a/board/solidrun/clearfog/clearfog.c
> > +++ b/board/solidrun/clearfog/clearfog.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -261,3 +262,34 @@ int board_late_init(void)
> >
> > return 0;
> > }
> > +
> > +static bool has_emmc(void)
> > +{
> > + struct mmc *mmc;
>
> Nitpicking: Please add an empty line after the variable declaration
> section.
>
> > + mmc = find_mmc_device(0);
> > + if (!mmc)
> > + return 0;
> > + return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
> > +}
> > +
> > +/*
> > + * The Clearfog devices have only one SDHC device. This is either eMMC
> > + * if it is populated on the SOM or SDHC if not. The Linux device tree
> > + * assumes the SDHC case. Detect if the device is an eMMC and fixup the
> > + * device-tree, so that it will be detected by Linux.
> > + */
> > +int ft_board_setup(void *blob, struct bd_info *bd)
> > +{
> > + __maybe_unused int node;
>
> Is this "__maybe_unused" really needed here?
>
> Otherwise:
>
> Reviewed-by: Stefan Roese
>
> Thanks,
> Stefan
Hmm, I fixed these two things and thought I submitted with In-Reply-To
this thread, but it's gone and created a new untitled series in
patchwork for the fix. Is there anything I can do to fix that up?
Sorry for the hassle.
> > +
> > + if (has_emmc()) {
> > + node = fdt_node_offset_by_compatible(blob, -1,
> > "marvell,armada-380-sdhci");
> > + if (node < 0)
> > + return 0; /* Unexpected eMMC device; patching not
> > supported */
> > +
> > + puts("Patching FDT so that eMMC is detected by OS\n");
> > + return fdt_setprop_empty(blob, node, "non-removable");
> > + }
> > +
> > + return 0;
> > +}
[PATCH v3 3/3] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
[upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
The Clearfog devices have only one SDHC device. This is either eMMC if
it is populated on the SOM or SDHC if not. The Linux device tree assumes
the SDHC case. Detect if the device is an eMMC and fixup the device-tree
so it will be detected by Linux.
Ported from vendor repo at https://github.com/SolidRun/u-boot
Signed-off-by: Martin Rowe
---
Fixed spacing and removed __maybe_unused
arch/arm/mach-mvebu/Kconfig| 1 +
board/solidrun/clearfog/clearfog.c | 33 ++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 1f0dbef1c6..b1f2e97ae7 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -107,6 +107,7 @@ config TARGET_CLEARFOG
bool "Support ClearFog"
select 88F6820
select BOARD_LATE_INIT
+ select OF_BOARD_SETUP
config TARGET_HELIOS4
bool "Support Helios4"
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index 03adb591d8..6edb422155 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -261,3 +262,35 @@ int board_late_init(void)
return 0;
}
+
+static bool has_emmc(void)
+{
+ struct mmc *mmc;
+
+ mmc = find_mmc_device(0);
+ if (!mmc)
+ return 0;
+ return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
+}
+
+/*
+ * The Clearfog devices have only one SDHC device. This is either eMMC
+ * if it is populated on the SOM or SDHC if not. The Linux device tree
+ * assumes the SDHC case. Detect if the device is an eMMC and fixup the
+ * device-tree, so that it will be detected by Linux.
+ */
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ int node;
+
+ if (has_emmc()) {
+ node = fdt_node_offset_by_compatible(blob, -1,
"marvell,armada-380-sdhci");
+ if (node < 0)
+ return 0; /* Unexpected eMMC device; patching not
supported */
+
+ puts("Patching FDT so that eMMC is detected by OS\n");
+ return fdt_setprop_empty(blob, node, "non-removable");
+ }
+
+ return 0;
+}
--
2.40.0
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sat, 25 Mar 2023 at 13:30, Pali Rohár wrote: > > On Saturday 04 March 2023 11:50:30 Pali Rohár wrote: > > Improve code for checking strapping pins which specifies boot mode source. > > > > Martin, could you test if Clearfog can be still configured into UART > > booting mode via HW switches and if it still works correctly? First > > patch is reverting UART related commit for Clearfog which I think it not > > needed anymore. > > > > Also could you check if SATA booting is still working correctly? > > > > Tony, should address problems with SPI booting when it is configured to > > different configuration. In fourth commit I added all possible boot mode > > strapping pin configurations which are recognized by A385 bootrom (and > > not the only one described in the HW spec, which is incomplete). > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > adding it for completeness in the last sixth patch. > > > > Pali Rohár (6): > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > arch/arm/mach-mvebu/cpu.c | 20 ++--- > > arch/arm/mach-mvebu/include/mach/soc.h | 41 -- > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > -- > > 2.20.1 > > > > Is something else needed to do with this patch series? > > Because the discussion in this patch thread just pointed to different > issues, not related this this patch series. Tested this patch with everything that just went into next, plus the switch fix, and all boot successfully: - MMC - eMMC - SD card - UART via kwboot - SATA (including UART via kwboot) - SPI (including UART via kwboot) - UART Tested-by: Martin Rowe
[PATCH v2 3/3] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
[upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
The Clearfog devices have only one SDHC device. This is either eMMC if
it is populated on the SOM or SDHC if not. The Linux device tree assumes
the SDHC case. Detect if the device is an eMMC and fixup the device-tree
so it will be detected by Linux.
Ported from vendor repo at https://github.com/SolidRun/u-boot
Signed-off-by: Martin Rowe
---
arch/arm/mach-mvebu/Kconfig| 1 +
board/solidrun/clearfog/clearfog.c | 32 ++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index fb3cff43f7..773635d691 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -107,6 +107,7 @@ config TARGET_CLEARFOG
bool "Support ClearFog"
select 88F6820
select BOARD_LATE_INIT
+ select OF_BOARD_SETUP
config TARGET_HELIOS4
bool "Support Helios4"
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index 03adb591d8..0087fea7db 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -261,3 +262,34 @@ int board_late_init(void)
return 0;
}
+
+static bool has_emmc(void)
+{
+ struct mmc *mmc;
+ mmc = find_mmc_device(0);
+ if (!mmc)
+ return 0;
+ return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
+}
+
+/*
+ * The Clearfog devices have only one SDHC device. This is either eMMC
+ * if it is populated on the SOM or SDHC if not. The Linux device tree
+ * assumes the SDHC case. Detect if the device is an eMMC and fixup the
+ * device-tree, so that it will be detected by Linux.
+ */
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ __maybe_unused int node;
+
+ if (has_emmc()) {
+ node = fdt_node_offset_by_compatible(blob, -1,
"marvell,armada-380-sdhci");
+ if (node < 0)
+ return 0; /* Unexpected eMMC device; patching not
supported */
+
+ puts("Patching FDT so that eMMC is detected by OS\n");
+ return fdt_setprop_empty(blob, node, "non-removable");
+ }
+
+ return 0;
+}
--
2.40.0
[PATCH v2 2/3] arm: mvebu: clearfog: Add defconfig for SPI booting
This new clearfog_spi_defconfig file is a copy of existing
clearfog_defconfig file modified to instruct build system to generate
final kwbimage for SPI booting and to store the environment in SPI.
Signed-off-by: Martin Rowe
---
configs/{clearfog_defconfig => clearfog_spi_defconfig} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
copy configs/{clearfog_defconfig => clearfog_spi_defconfig} (98%)
diff --git a/configs/clearfog_defconfig b/configs/clearfog_spi_defconfig
similarity index 98%
copy from configs/clearfog_defconfig
copy to configs/clearfog_spi_defconfig
index 8cd35f9f1a..9dcf16fe92 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -9,7 +9,7 @@ CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
+CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
CONFIG_SPL_TEXT_BASE=0x4030
CONFIG_SPL_SERIAL=y
--
2.40.0
[PATCH v2 1/3] arm: mvebu: clearfog: Fix MMC detection
A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
both. Setting the device to non-removable in the u-boot.dtsi allows both
to correctly detect the device.
Signed-off-by: Martin Rowe
---
arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
index fb27a3b96f..906d8f2e67 100644
--- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
@@ -10,6 +10,7 @@
{
bootph-pre-ram;
+ non-removable; /* assume that the card is always present, required for
eMMC variant */
};
{
--
2.40.0
[PATCH v2 0/3] arm: mvebu: clearfog: defconfig and eMMC updates
Minor defconfig and eMMC updates for SolidRun's A388 Clearfog devices.
Changes since v1:
- Omitted defconfig canonicalization changes
- Removed unneeded defconfig changes
- Set non-removable in u-boot dtsi instead of MMC_BROKEN_CD
- Reworked FDT patch logic
Changes since initial discussion:
https://lists.denx.de/pipermail/u-boot/2023-February/510492.html
- CONFIG_SPL_SPI selected for SPI defconfig
- Runtime patching of kernel FDT added for eMMC detection
Note that this patch depends on this patch series (has been merged to
u-boot-marvell/next):
https://lists.denx.de/pipermail/u-boot/2023-March/511038.html
Signed-off-by: Martin Rowe
Martin Rowe (3):
arm: mvebu: clearfog: Fix MMC detection
arm: mvebu: clearfog: Add defconfig for SPI booting
arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 1 +
arch/arm/mach-mvebu/Kconfig | 1 +
board/solidrun/clearfog/clearfog.c| 32 +++
...arfog_defconfig => clearfog_spi_defconfig} | 2 +-
4 files changed, 35 insertions(+), 1 deletion(-)
copy configs/{clearfog_defconfig => clearfog_spi_defconfig} (98%)
--
2.40.0
Re: [PATCH u-boot-mvebu 0/5] mvebu: Fix UART booting
On Thu, 23 Mar 2023 at 19:58, Pali Rohár wrote: > > This patch series contains kwboot fixes for booting non-UART-generated > images over UART. > > Pali Rohár (5): > tools: kwbimage: Fix invalid UART kwbimage v1 headersz > tools: kwboot: Fix invalid UART kwbimage v1 headersz > tools: kwboot: Fix inserting UART data checksum without -B option > tools: kwboot: Fix sending very small images > tools: kwboot: Workaround A38x BootROM bug for images with a gap > > tools/kwbimage.c | 10 ++ > tools/kwboot.c | 38 ++ > 2 files changed, 48 insertions(+) > > -- > 2.20.1 > Tested-by: Martin Rowe
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Thu, 23 Mar 2023 at 19:01, Pali Rohár wrote: > > On Thursday 23 March 2023 12:24:13 Martin Rowe wrote: > > On Wed, 22 Mar 2023 at 19:09, Pali Rohár wrote: > > > > > > On Wednesday 22 March 2023 18:59:45 Pali Rohár wrote: > > > > On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote: > > > > > On Wed, 22 Mar 2023 at 12:38, Martin Rowe > > > > > wrote: > > > > > > > > > > > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: > > > > > >> > > > > > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: > > > > > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > > > > > >> > > > > > > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > > > > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár > > > > > >> > > > wrote: > > > > > >> > > > > > > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > > > > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár > > > > > >> > > > > > wrote: > > > > > >> > > > > > > > > > > >> > > > > > > Could you try to print mmc->part_config (ideally as > > > > > >> > > > > > > early as > > > > > >> > > possible)? > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > In SPL mmc->part_config is 255 > > > > > >> > > > > > In main u-boot at the start of clearfog.c board_init() > > > > > >> > > mmc->part_config > > > > > >> > > > > is > > > > > >> > > > > > 255 > > > > > >> > > > > > In main u-boot at the start of clearfog.c checkboard() > > > > > >> > > mmc->part_config > > > > > >> > > > > is > > > > > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > > > > >> > > > > > > > > > >> > > > > 255 is uninitialized value. > > > > > >> > > > > > > > > > >> > > > > > If I set partition_enable to 2, I get the same result > > > > > >> > > > > > except the > > > > > >> > > value is > > > > > >> > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of > > > > > >> > > > > > 8 for the > > > > > >> > > last > > > > > >> > > > > value > > > > > >> > > > > > > > > > >> > > > > Try to change "access" bits. > > > > > >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > BootROM - 1.73 > > > > > >> > > > > > > > > > > >> > > > > > Booting from MMC > > > > > >> > > > > > > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 > > > > > >> > > > > > 2023 - > > > > > >> > > 10:05:32 > > > > > >> > > > > > +1000) > > > > > >> > > > > > High speed PHY - Version: 2.0 > > > > > >> > > > > > EEPROM TLV detection failed: Using static config for > > > > > >> > > > > > Clearfog Pro. > > > > > >> > > > > > Detected Device ID 6828 > > > > > >> > > > > > board SerDes lanes topology details: > > > > > >> > > > > > | Lane # | Speed | Type | > > > > > >> > > > > > > > > > > >> > > > > > | 0| 3 | SATA0 | > > > > > >> > > > > > | 1| 0 | SGMII1 | > > > > > >> > > > > > | 2| 5 | PCIe1 | > > &
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Wed, 22 Mar 2023 at 19:09, Pali Rohár wrote: > > On Wednesday 22 March 2023 18:59:45 Pali Rohár wrote: > > On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote: > > > On Wed, 22 Mar 2023 at 12:38, Martin Rowe wrote: > > > > > > > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: > > > >> > > > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: > > > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > > > >> > > > > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > > > >> > > > > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár > > > >> > > > > > wrote: > > > >> > > > > > > > > >> > > > > > > Could you try to print mmc->part_config (ideally as early > > > >> > > > > > > as > > > >> > > possible)? > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > In SPL mmc->part_config is 255 > > > >> > > > > > In main u-boot at the start of clearfog.c board_init() > > > >> > > mmc->part_config > > > >> > > > > is > > > >> > > > > > 255 > > > >> > > > > > In main u-boot at the start of clearfog.c checkboard() > > > >> > > mmc->part_config > > > >> > > > > is > > > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > > >> > > > > > > > >> > > > > 255 is uninitialized value. > > > >> > > > > > > > >> > > > > > If I set partition_enable to 2, I get the same result except > > > >> > > > > > the > > > >> > > value is > > > >> > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 > > > >> > > > > > for the > > > >> > > last > > > >> > > > > value > > > >> > > > > > > > >> > > > > Try to change "access" bits. > > > >> > > > > > > > >> > > > > > > > > >> > > > > > BootROM - 1.73 > > > >> > > > > > > > > >> > > > > > Booting from MMC > > > >> > > > > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > > >> > > 10:05:32 > > > >> > > > > > +1000) > > > >> > > > > > High speed PHY - Version: 2.0 > > > >> > > > > > EEPROM TLV detection failed: Using static config for > > > >> > > > > > Clearfog Pro. > > > >> > > > > > Detected Device ID 6828 > > > >> > > > > > board SerDes lanes topology details: > > > >> > > > > > | Lane # | Speed | Type | > > > >> > > > > > > > > >> > > > > > | 0| 3 | SATA0 | > > > >> > > > > > | 1| 0 | SGMII1 | > > > >> > > > > > | 2| 5 | PCIe1 | > > > >> > > > > > | 3| 5 | USB3 HOST1 | > > > >> > > > > > | 4| 5 | PCIe2 | > > > >> > > > > > | 5| 0 | SGMII2 | > > > >> > > > > > > > > >> > > > > > High speed PHY - Ended Successfully > > > >> > > > > > mv_ddr: 14.0.0 > > > >> > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath > > > >> > > > > > Window > > > >> > > > > > mv_ddr: completed successfully > > > >> > > > > > spl.c spl_boot_device part_config = 255 > > > >> > > > > > Trying to boot from MMC1
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Wed, 22 Mar 2023 at 18:09, Pali Rohár wrote: > > On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote: > > On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > > > > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > > > > > > > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which > > > specifies > > > > > boot > > > > > > > > mode > > > > > > > > > > > source. > > > > > > > > > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still > > > configured > > > > > into > > > > > > > > UART > > > > > > > > > > > > > booting mode via HW switches and if it still works > > > > > correctly? > > > > > > > > First > > > > > > > > > > > > > patch is reverting UART related commit for Clearfog > > > which I > > > > > > > > think it > > > > > > > > > > > not > > > > > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef > > > before > > > > > the > > > > > > > > switch > > > > > > > > > > > that > > > > > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > > > > > processed. It > > > > > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > > > > > probably > > > > > > > > because > > > > > > > > > > > of > > > > > > > > > > > > the invalid boot workaround for broken UART selection > > > that > > > > > you > > > > > > > > > > > identified. > > > > > > > > > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode > > > > > > > > > > > works. > > > > > > > > > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or > > > if I > > > > > select > > > > > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work > > > with > > > > > the MMC > > > > > > > > or > > > > > > > > > > > SATA > > > > > > > > > > > > defconfigs. I get the same result without this patch > > > series > > > > > > > > applied, > > > > > > > > > > > though. > > > > > > > > > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > > > > > header > > > > > > > > patching > > > > > > > > > > > > output) until after sending boot image data is complete. > > > The > > > > > > > > output stops > > > > > > > > > > > > after: > > > > > > > > > > > > >
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Wed, 22 Mar 2023 at 12:38, Martin Rowe wrote: > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: >> >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: >> > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: >> > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: >> > > > > > >> > > > > > > Could you try to print mmc->part_config (ideally as early as >> > > possible)? >> > > > > > > >> > > > > > >> > > > > > In SPL mmc->part_config is 255 >> > > > > > In main u-boot at the start of clearfog.c board_init() >> > > mmc->part_config >> > > > > is >> > > > > > 255 >> > > > > > In main u-boot at the start of clearfog.c checkboard() >> > > mmc->part_config >> > > > > is >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0) >> > > > > >> > > > > 255 is uninitialized value. >> > > > > >> > > > > > If I set partition_enable to 2, I get the same result except the >> > > value is >> > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the >> > > last >> > > > > value >> > > > > >> > > > > Try to change "access" bits. >> > > > > >> > > > > > >> > > > > > BootROM - 1.73 >> > > > > > >> > > > > > Booting from MMC >> > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - >> > > 10:05:32 >> > > > > > +1000) >> > > > > > High speed PHY - Version: 2.0 >> > > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. >> > > > > > Detected Device ID 6828 >> > > > > > board SerDes lanes topology details: >> > > > > > | Lane # | Speed | Type | >> > > > > > >> > > > > > | 0| 3 | SATA0 | >> > > > > > | 1| 0 | SGMII1 | >> > > > > > | 2| 5 | PCIe1 | >> > > > > > | 3| 5 | USB3 HOST1 | >> > > > > > | 4| 5 | PCIe2 | >> > > > > > | 5| 0 | SGMII2 | >> > > > > > >> > > > > > High speed PHY - Ended Successfully >> > > > > > mv_ddr: 14.0.0 >> > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window >> > > > > > mv_ddr: completed successfully >> > > > > > spl.c spl_boot_device part_config = 255 >> > > > > > Trying to boot from MMC1 >> > > > > > >> > > > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 >> > > +1000) >> > > > > > >> > > > > > SoC: MV88F6828-A0 at 1600 MHz >> > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) >> > > > > > clearfog.c board_init part_config = 255 >> > > > > > Core: 38 devices, 22 uclasses, devicetree: separate >> > > > > > MMC: mv_sdh: 0 >> > > > > > Loading Environment from MMC... *** Warning - bad CRC, using >> > > > > > default >> > > > > > environment >> > > > > > >> > > > > > Model: SolidRun Clearfog A1 >> > > > > > clearfog.c checkboard part_config = 8 >> > > > > > Board: SolidRun Clearfog Pro >> > > > > > Net: >> > > > > > Warning: ethernet@7 (eth1) using random MAC address - >> > > > > 32:16:0e:b4:d1:d8 >> > > > > > eth1: ethernet@7 >> > > > > > Warning: ethernet@3 (eth2) using random MAC address - >> > > > > 72:30:3f:79:07:12 >> > > > > > , eth2: ethernet
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: > On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: > > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > > > > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > > > > > > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > > > > > > > > > > > > > Could you try to print mmc->part_config (ideally as early as > > > possible)? > > > > > > > > > > > > > > > > > > > In SPL mmc->part_config is 255 > > > > > > In main u-boot at the start of clearfog.c board_init() > > > mmc->part_config > > > > > is > > > > > > 255 > > > > > > In main u-boot at the start of clearfog.c checkboard() > > > mmc->part_config > > > > > is > > > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > > > > > > > > > 255 is uninitialized value. > > > > > > > > > > > If I set partition_enable to 2, I get the same result except the > > > value is > > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the > > > last > > > > > value > > > > > > > > > > Try to change "access" bits. > > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > > > > > Booting from MMC > > > > > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > > 10:05:32 > > > > > > +1000) > > > > > > High speed PHY - Version: 2.0 > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > Pro. > > > > > > Detected Device ID 6828 > > > > > > board SerDes lanes topology details: > > > > > > | Lane # | Speed | Type | > > > > > > > > > > > > | 0| 3 | SATA0 | > > > > > > | 1| 0 | SGMII1 | > > > > > > | 2| 5 | PCIe1 | > > > > > > | 3| 5 | USB3 HOST1 | > > > > > > | 4| 5 | PCIe2 | > > > > > > | 5| 0 | SGMII2 | > > > > > > > > > > > > High speed PHY - Ended Successfully > > > > > > mv_ddr: 14.0.0 > > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > > > > mv_ddr: completed successfully > > > > > > spl.c spl_boot_device part_config = 255 > > > > > > Trying to boot from MMC1 > > > > > > > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > 10:05:32 > > > +1000) > > > > > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > > > clearfog.c board_init part_config = 255 > > > > > > Core: 38 devices, 22 uclasses, devicetree: separate > > > > > > MMC: mv_sdh: 0 > > > > > > Loading Environment from MMC... *** Warning - bad CRC, using > default > > > > > > environment > > > > > > > > > > > > Model: SolidRun Clearfog A1 > > > > > > clearfog.c checkboard part_config = 8 > > > > > > Board: SolidRun Clearfog Pro > > > > > > Net: > > > > > > Warning: ethernet@7 (eth1) using random MAC address - > > > > > 32:16:0e:b4:d1:d8 > > > > > > eth1: ethernet@7 > > > > > > Warning: ethernet@3 (eth2) using random MAC address - > > > > > 72:30:3f:79:07:12 > > > > > > , eth2: ethernet@3 > > > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > > > > 82:fb:71:23:46:4f > > > > > > , eth3: ethernet@34000 > > > > > > Hit any key to stop autoboot: 0 > > > > > > => mmc partconf 0 > > > > > > EXT_CSD[179], PARTITION_CONFIG: > > > > > > BOOT_ACK: 0x0 > > > > > &g
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > > > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár > wrote: > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which > specifies > > > boot > > > > > > mode > > > > > > > > > source. > > > > > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still > configured > > > into > > > > > > UART > > > > > > > > > > > booting mode via HW switches and if it still works > > > correctly? > > > > > > First > > > > > > > > > > > patch is reverting UART related commit for Clearfog > which I > > > > > > think it > > > > > > > > > not > > > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef > before > > > the > > > > > > switch > > > > > > > > > that > > > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > > > processed. It > > > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > > > probably > > > > > > because > > > > > > > > > of > > > > > > > > > > the invalid boot workaround for broken UART selection > that > > > you > > > > > > > > > identified. > > > > > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or > if I > > > select > > > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work > with > > > the MMC > > > > > > or > > > > > > > > > SATA > > > > > > > > > > defconfigs. I get the same result without this patch > series > > > > > > applied, > > > > > > > > > though. > > > > > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > > > header > > > > > > patching > > > > > > > > > > output) until after sending boot image data is complete. > The > > > > > > output stops > > > > > > > > > > after: > > > > > > > > > > > > > > > > > > > > 98 % > > > > > > > [. > > > > > > > > > > ] > > > > > > > > > > Done > > > > > > > > > > Finishing transfer > > > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very strange because > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART > > > just > > > > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > > > > > > > If I'm looking at the output correctly then SPL was > booted, it > > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár wrote: > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > wrote: > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which specifies > boot > > > > mode > > > > > > > source. > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still configured > into > > > > UART > > > > > > > > > booting mode via HW switches and if it still works > correctly? > > > > First > > > > > > > > > patch is reverting UART related commit for Clearfog which I > > > > think it > > > > > > > not > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before > the > > > > switch > > > > > > > that > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > processed. It > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > probably > > > > because > > > > > > > of > > > > > > > > the invalid boot workaround for broken UART selection that > you > > > > > > > identified. > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I > select > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with > the MMC > > > > or > > > > > > > SATA > > > > > > > > defconfigs. I get the same result without this patch series > > > > applied, > > > > > > > though. > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > header > > > > patching > > > > > > > > output) until after sending boot image data is complete. The > > > > output stops > > > > > > > > after: > > > > > > > > > > > > > > > > 98 % > > > > [. > > > > > > > > ] > > > > > > > > Done > > > > > > > > Finishing transfer > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > > > > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART > just > > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > > > If I'm looking at the output correctly then SPL was booted, it > > > > correctly > > > > > > > trained DDR RAM, returned back to bootrom, kwboot continued > sending > > > > main > > > > > > > u-boot and bootrom confirmed that transfer of both SPL and main > > > > u-boot > > > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I was > sure > > > > was > > > > > > > > working after the last patches but I can no longer reproduce > a > > > > successful > > > > > > > > boot. > > > > > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot from > > > > version > > > > > > > with applying _all_ my patches r
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Mon, 20 Mar 2023 at 19:42, Pali Rohár wrote: > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > Dedicated UART still works, patching an MMC for UART with kwboot still > > hangs after finishing transfer; no change. > > One more question. Did you set boot mode HW switches to UART position? > Or are they in MMC position and magic boot pattern from kwboot triggers > UART boot? > HW switches to UART position.
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > > > > > > > > > Could you try to print mmc->part_config (ideally as early as > possible)? > > > > > > > > > > > > > In SPL mmc->part_config is 255 > > > > In main u-boot at the start of clearfog.c board_init() > mmc->part_config > > > is > > > > 255 > > > > In main u-boot at the start of clearfog.c checkboard() > mmc->part_config > > > is > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > > > > > 255 is uninitialized value. > > > > > > > If I set partition_enable to 2, I get the same result except the > value is > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the > last > > > value > > > > > > Try to change "access" bits. > > > > > > > > > > > BootROM - 1.73 > > > > > > > > Booting from MMC > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > 10:05:32 > > > > +1000) > > > > High speed PHY - Version: 2.0 > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > > > Detected Device ID 6828 > > > > board SerDes lanes topology details: > > > > | Lane # | Speed | Type | > > > > > > > > | 0| 3 | SATA0 | > > > > | 1| 0 | SGMII1 | > > > > | 2| 5 | PCIe1 | > > > > | 3| 5 | USB3 HOST1 | > > > > | 4| 5 | PCIe2 | > > > > | 5| 0 | SGMII2 | > > > > > > > > High speed PHY - Ended Successfully > > > > mv_ddr: 14.0.0 > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > > mv_ddr: completed successfully > > > > spl.c spl_boot_device part_config = 255 > > > > Trying to boot from MMC1 > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 > +1000) > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > clearfog.c board_init part_config = 255 > > > > Core: 38 devices, 22 uclasses, devicetree: separate > > > > MMC: mv_sdh: 0 > > > > Loading Environment from MMC... *** Warning - bad CRC, using default > > > > environment > > > > > > > > Model: SolidRun Clearfog A1 > > > > clearfog.c checkboard part_config = 8 > > > > Board: SolidRun Clearfog Pro > > > > Net: > > > > Warning: ethernet@7 (eth1) using random MAC address - > > > 32:16:0e:b4:d1:d8 > > > > eth1: ethernet@7 > > > > Warning: ethernet@3 (eth2) using random MAC address - > > > 72:30:3f:79:07:12 > > > > , eth2: ethernet@3 > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > > 82:fb:71:23:46:4f > > > > , eth3: ethernet@34000 > > > > Hit any key to stop autoboot: 0 > > > > => mmc partconf 0 > > > > EXT_CSD[179], PARTITION_CONFIG: > > > > BOOT_ACK: 0x0 > > > > BOOT_PARTITION_ENABLE: 0x1 > > > > PARTITION_ACCESS: 0x0 > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > Booting from MMC > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > 10:05:32 > > > > +1000) > > > > High speed PHY - Version: 2.0 > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > > > Detected Device ID 6828 > > > > board SerDes lanes topology details: > > > > | Lane # | Speed | Type | > > > > > > > > | 0| 3 | SATA0 | > > > > | 1| 0 | SGMII1 | > > > > | 2| 5 | PCIe1 | > > > > | 3| 5 | USB3 HOST1 | > > > > | 4| 5 | PCIe2 | > > > > | 5|
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár wrote: > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > > > > > > > > > > > Improve code for checking strapping pins which specifies boot > mode > > > > source. > > > > > > > > > > > > Martin, could you test if Clearfog can be still configured into > UART > > > > > > booting mode via HW switches and if it still works correctly? > First > > > > > > patch is reverting UART related commit for Clearfog which I > think it > > > > not > > > > > > needed anymore. > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the > switch > > > > that > > > > > you refactored in cpu.c/get_boot_device is all that gets > processed. It > > > > > decides there is an error and returns BOOT_DEVICE_UART, probably > because > > > > of > > > > > the invalid boot workaround for broken UART selection that you > > > > identified. > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I select > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC > or > > > > SATA > > > > > defconfigs. I get the same result without this patch series > applied, > > > > though. > > > > > > > > > > The failed cases have the same output (other than kwboot header > patching > > > > > output) until after sending boot image data is complete. The > output stops > > > > > after: > > > > > > > > > > 98 % > [. > > > > > ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > If I'm looking at the output correctly then SPL was booted, it > correctly > > > > trained DDR RAM, returned back to bootrom, kwboot continued sending > main > > > > u-boot and bootrom confirmed that transfer of both SPL and main > u-boot > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I was sure > was > > > > > working after the last patches but I can no longer reproduce a > successful > > > > > boot. > > > > > > > > Can you check that you are using _both_ mkimage and kwboot from > version > > > > with applying _all_ my patches recently sent to ML? Because both > mkimage > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > I tested using the latest next branch which has those changes in it. > Steps: > > > - Set UART boot mode on device > > > - make clean > > > - make clearfog_defconfig > > > - make > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > For me it looks like that either mkimage generated incorrect image size > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > Detected kwbimage v1 with SDIO boot signature > > > Patching image boot signature to UART > > > Aligning image header to Xmodem block size > > > Sending boot message. Please reboot the target...\ > > > Sending boot image header (113408 bytes)... > > > 0 % > > > > [..] > > > > > > 94 % [.. > > > ] > >
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > > > > > Could you try to print mmc->part_config (ideally as early as possible)? > > > > > > > In SPL mmc->part_config is 255 > > In main u-boot at the start of clearfog.c board_init() mmc->part_config > is > > 255 > > In main u-boot at the start of clearfog.c checkboard() mmc->part_config > is > > 8 (ack: 0, partition_enable: 1, access: 0) > > 255 is uninitialized value. > > > If I set partition_enable to 2, I get the same result except the value is > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the last > value > > Try to change "access" bits. > > > > > BootROM - 1.73 > > > > Booting from MMC > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 > > +1000) > > High speed PHY - Version: 2.0 > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > Detected Device ID 6828 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > > > | 0| 3 | SATA0 | > > | 1| 0 | SGMII1 | > > | 2| 5 | PCIe1 | > > | 3| 5 | USB3 HOST1 | > > | 4| 5 | PCIe2 | > > | 5| 0 | SGMII2 | > > > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > spl.c spl_boot_device part_config = 255 > > Trying to boot from MMC1 > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000) > > > > SoC: MV88F6828-A0 at 1600 MHz > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > clearfog.c board_init part_config = 255 > > Core: 38 devices, 22 uclasses, devicetree: separate > > MMC: mv_sdh: 0 > > Loading Environment from MMC... *** Warning - bad CRC, using default > > environment > > > > Model: SolidRun Clearfog A1 > > clearfog.c checkboard part_config = 8 > > Board: SolidRun Clearfog Pro > > Net: > > Warning: ethernet@7 (eth1) using random MAC address - > 32:16:0e:b4:d1:d8 > > eth1: ethernet@7 > > Warning: ethernet@3 (eth2) using random MAC address - > 72:30:3f:79:07:12 > > , eth2: ethernet@3 > > Warning: ethernet@34000 (eth3) using random MAC address - > 82:fb:71:23:46:4f > > , eth3: ethernet@34000 > > Hit any key to stop autoboot: 0 > > => mmc partconf 0 > > EXT_CSD[179], PARTITION_CONFIG: > > BOOT_ACK: 0x0 > > BOOT_PARTITION_ENABLE: 0x1 > > PARTITION_ACCESS: 0x0 > > > > > > > > BootROM - 1.73 > > > > Booting from MMC > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 > > +1000) > > High speed PHY - Version: 2.0 > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > Detected Device ID 6828 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > > > | 0| 3 | SATA0 | > > | 1| 0 | SGMII1 | > > | 2| 5 | PCIe1 | > > | 3| 5 | USB3 HOST1 | > > | 4| 5 | PCIe2 | > > | 5| 0 | SGMII2 | > > > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > spl.c spl_boot_device part_config = 255 > > Trying to boot from MMC1 > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000) > > > > SoC: MV88F6828-A0 at 1600 MHz > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > clearfog.c board_init part_config = 255 > > Core: 38 devices, 22 uclasses, devicetree: separate > > MMC: mv_sdh: 0 > > Loading Environment from MMC... *** Warning - bad CRC, using default > > environment > > > > Model: SolidRun Clearfog A1 > > clearfog.c checkboard part_config = 16 > > Board: SolidRun Clearfog Pro > > Net: > > Warning: ethernet@7 (eth1) using random MAC address - > 92:5a:fc:14:e8:f6 > > eth1: ethernet@7 > > Warning: ethernet@3 (eth2) using random MAC address - > 42:9c:d8:3a:cb:b2 > > , eth2:
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sun, 5 Mar 2023 at 11:55, Pali Rohár wrote: > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > > > > > Improve code for checking strapping pins which specifies boot mode > source. > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > booting mode via HW switches and if it still works correctly? First > > > patch is reverting UART related commit for Clearfog which I think it > not > > > needed anymore. > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch > that > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > decides there is an error and returns BOOT_DEVICE_UART, probably because > of > > the invalid boot workaround for broken UART selection that you > identified. > > Ok, so I figured out correctly how this invalid mode works. > > > UART only works if I use the clearfog_spi_defconfig or if I select > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or > SATA > > defconfigs. I get the same result without this patch series applied, > though. > > > > The failed cases have the same output (other than kwboot header patching > > output) until after sending boot image data is complete. The output stops > > after: > > > > 98 % [. > > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > instruct mkimage what to put into kwbimage header. > > If I'm looking at the output correctly then SPL was booted, it correctly > trained DDR RAM, returned back to bootrom, kwboot continued sending main > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > is complete. But then there is no output from main u-boot. > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > working after the last patches but I can no longer reproduce a successful > > boot. > > Can you check that you are using _both_ mkimage and kwboot from version > with applying _all_ my patches recently sent to ML? Because both mkimage > and kwboot have fixes for SATA and SDIO images. > I tested using the latest next branch which has those changes in it. Steps: - Set UART boot mode on device - make clean - make clearfog_defconfig - make - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 For me it looks like that either mkimage generated incorrect image size > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > from kwbimage header and sent smaller image. > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 % [..] 94 % [.. ] Done U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | | 0| 3 | SATA0 | | 1| 0 | SGMII1 | | 2| 5 | PCIe1 | | 3| 5 | USB3 HOST1 | | 4| 5 | PCIe2 | | 5| 0 | SGMII2 | High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0x05c4)... Sending boot image data (474564 bytes)... 0 % [..] 98 % [ ] Done Finishing transfer [Type Ctrl-\ + c to quit] du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb If I make menuconfig and set the boot mode to UART before making I get: ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot mess
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Mon, 6 Mar 2023 at 18:40, Pali Rohár wrote: > On Monday 06 March 2023 11:15:35 Martin Rowe wrote: > > On Sun, 5 Mar 2023 at 16:04, Pali Rohár wrote: > > > Could you try another test by completely erasing BOOT0, BOOT1 and USER > > > > data? And see what BootROM prints. > > > > > > > = > > BootROM - 1.73 > > > > Booting from MMC > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad header at offset 0020 > > Switching BootPartitions. > > BootROM: Bad header at offset > > BootROM: Bad h > > Trying Uart > > = > > Originally I though that I did not understand disassembled bootrom code > correctly but this logs proves that I did it correctly. Log is very > strange. > > There is a loop which tries partition numbers 0x1, 0x2, ... 0x9, 0xa. > > And if I'm looking at the bootrom code correctly it does bit-AND > operation on partition number with constant 0x7 and result is set into > mmc register 179 (partition_config). > > So if I understand it correctly it means that bootrom automatically > clears boot_ack and boot_partition. And into partition_access it sets > the partition number. Hence numbers 0x9 and 0xa are trimmed and > aliased to 0x1 and 0x2; and number 0x8 overflows to 0x0. > > Completely strange behavior and probably against how HW mmc boot > partitions should be used. > > eMMC spec defines: > partition_access (low 3 bits of mmc 179/partition_config register): > 0x0 : No access to boot partition (default) > 0x1 : R/W boot partition 1 > 0x2 : R/W boot partition 2 > 0x3 : R/W Replay Protected Memory Block (RPMB) > 0x4 : Access to General Purpose partition 1 > 0x5 : Access to General Purpose partition 2 > 0x6 : Access to General Purpose partition 3 > 0x7 : Access to General Purpose partition 4 > I can only set 0, 1, 2, and 7; the others result in `exit not allowed from main input shell.` > I guess that you do not have general purpose partitions layout on emmc > and RPMB is not used too. So technically only 0x0, 0x1, and 0x2 are > available. > > To confirm my theory, could you try to do following tests? > > 1. Check u-boot's "mmc partconf" settings are not preserved across > reboots. > The only part that seems to be preserved is the partition_enable; ack and access both reset to 0. > 2. Put valid image into userdata partition; erase boot 0 and boot 1; and > post bootrom output. There should be 7 invalid attempts with Switching > BootPartitions message. > 7 invalid attempts before it finds u-boot in the userdata partition: BootROM - 1.73 Booting from MMC BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000) > 3. Take valid image, invalidate kwb header checksum and put it on boot0; > plus erase boot1 and user. Bootrom should print "Invalid header > checksum" message and it should be two times. Once for 0x1 and second > time for overflowed 0x9. > Changing just the checksum at 0x1F results in BootROM producing no output and just hanging. I've tried on each boot partition (with the others zeroed) and can't get any results at all. I also tried a valid header and zeroes for the rest of the image; same result.
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > On Monday 06 March 2023 11:15:35 Martin Rowe wrote: > > On Sun, 5 Mar 2023 at 16:04, Pali Rohár wrote: > > > > > On Sunday 05 March 2023 12:46:34 Pali Rohár wrote: > > > > On Sunday 05 March 2023 02:24:27 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:40, Pali Rohár wrote: > > > > > > > > > > > Boot configuration stored in EXT_CSC register is completely > ignored > > > by > > > > > > BootROM: > > > > > > > > > > > > > > > > https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8dm...@mail.gmail.com/ > > > > > > > > > > > > Reflect this eMMC booting in documentation and in the code. > > > > > > > > > > > > Martin, can you test this patch series if SPL and main U-Boot is > > > loaded > > > > > > from the same eMMC HW partition? > > > > > > > > > > > > > > > > boot0: u-boot > > > > > > > > > > Works fine, no issues. > > > > > > > > > > > > > > > boot0: zeroed > > > > > boot1: u-boot > > > > > user: zeroed > > > > > > > > > > It succeeds, eventually... > > > > > == > > > > > BootROM - 1.73 > > > > > > > > > > Booting from MMC > > > > > BootROM: Bad header at offset > > > > > BootROM: Bad header at offset 0020 > > > > > Switching BootPartitions. > > > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - > 11:50:45 > > > > > +1000) > > > > > High speed PHY - Version: 2.0 > > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > > > > Detected Device ID 6828 > > > > > board SerDes lanes topology details: > > > > > | Lane # | Speed | Type | > > > > > > > > > > | 0| 3 | SATA0 | > > > > > | 1| 0 | SGMII1 | > > > > > | 2| 5 | PCIe1 | > > > > > | 3| 5 | USB3 HOST1 | > > > > > | 4| 5 | PCIe2 | > > > > > | 5| 0 | SGMII2 | > > > > > > > > > > High speed PHY - Ended Successfully > > > > > mv_ddr: 14.0.0 > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > > > mv_ddr: completed successfully > > > > > Trying to boot from MMC1 > > > > > ERROR: Invalid kwbimage v1 > > > > > mmc_load_image_raw_sector: mmc block read error > > > > > spl: mmc: wrong boot mode > > > > > Trying to boot from BOOTROM > > > > > Returning to BootROM (return address 0x05c4)... > > > > > Timeout waiting card ready > > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 > > > +1000) > > > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > > Core: 38 devices, 22 uclasses, devicetree: separate > > > > > MMC: mv_sdh: 0 > > > > > Loading Environment from MMC... *** Warning - bad CRC, using > default > > > > > environment > > > > > > > > > > Model: SolidRun Clearfog A1 > > > > > Board: SolidRun Clearfog Pro > > > > > Net: > > > > > Warning: ethernet@7 (eth1) using random MAC address - > > > 12:07:8b:f9:7a:6f > > > > > eth1: ethernet@7 > > > > > Warning: ethernet@3 (eth2) using random MAC address - > > > ee:ed:f3:bb:c2:af > > > > > , eth2: ethernet@3 > > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > > ae:34:b9:bb:28:c6 > > > > > , eth3: ethernet@34000 > > > > > Hit any key to stop autoboot: 0 > > > > > => > > > > > == > > > > > > > > > > Between "Returning to BootROM" and "Timeout waiting card r
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Sun, 5 Mar 2023 at 16:04, Pali Rohár wrote: > On Sunday 05 March 2023 12:46:34 Pali Rohár wrote: > > On Sunday 05 March 2023 02:24:27 Martin Rowe wrote: > > > On Sat, 4 Mar 2023 at 10:40, Pali Rohár wrote: > > > > > > > Boot configuration stored in EXT_CSC register is completely ignored > by > > > > BootROM: > > > > > > > > > https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8dm...@mail.gmail.com/ > > > > > > > > Reflect this eMMC booting in documentation and in the code. > > > > > > > > Martin, can you test this patch series if SPL and main U-Boot is > loaded > > > > from the same eMMC HW partition? > > > > > > > > > > boot0: u-boot > > > > > > Works fine, no issues. > > > > > > > > > boot0: zeroed > > > boot1: u-boot > > > user: zeroed > > > > > > It succeeds, eventually... > > > == > > > BootROM - 1.73 > > > > > > Booting from MMC > > > BootROM: Bad header at offset > > > BootROM: Bad header at offset 0020 > > > Switching BootPartitions. > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 > > > +1000) > > > High speed PHY - Version: 2.0 > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > > Detected Device ID 6828 > > > board SerDes lanes topology details: > > > | Lane # | Speed | Type | > > > > > > | 0| 3 | SATA0 | > > > | 1| 0 | SGMII1 | > > > | 2| 5 | PCIe1 | > > > | 3| 5 | USB3 HOST1 | > > > | 4| 5 | PCIe2 | > > > | 5| 0 | SGMII2 | > > > > > > High speed PHY - Ended Successfully > > > mv_ddr: 14.0.0 > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > mv_ddr: completed successfully > > > Trying to boot from MMC1 > > > ERROR: Invalid kwbimage v1 > > > mmc_load_image_raw_sector: mmc block read error > > > spl: mmc: wrong boot mode > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0x05c4)... > > > Timeout waiting card ready > > > BootROM: Image checksum verification PASSED > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 > +1000) > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > Core: 38 devices, 22 uclasses, devicetree: separate > > > MMC: mv_sdh: 0 > > > Loading Environment from MMC... *** Warning - bad CRC, using default > > > environment > > > > > > Model: SolidRun Clearfog A1 > > > Board: SolidRun Clearfog Pro > > > Net: > > > Warning: ethernet@7 (eth1) using random MAC address - > 12:07:8b:f9:7a:6f > > > eth1: ethernet@7 > > > Warning: ethernet@3 (eth2) using random MAC address - > ee:ed:f3:bb:c2:af > > > , eth2: ethernet@3 > > > Warning: ethernet@34000 (eth3) using random MAC address - > ae:34:b9:bb:28:c6 > > > , eth3: ethernet@34000 > > > Hit any key to stop autoboot: 0 > > > => > > > == > > > > > > Between "Returning to BootROM" and "Timeout waiting card ready" takes > > > around 315 seconds. That's long enough that I thought it had hung > > > completely and I only noticed it continue because I left it running > while > > > working on something else. I tried several things to reduce this > timeout, > > > including reverting to the "non-removable" dts for shdci, but nothing > seems > > > to affect it. > > > > Ok. So now it is in the state that it is working but is slow. Better > > than nothing. > > > > Message "Returning to BootROM" is printed by SPL and message > > "Timeout waiting card ready" is printed by BootROM. After printing > > "Returning to BootROM" is SPL jumping back to the BootROM so the delay > > is for sure in the BootROM. So seems that SPL reconfigures eMMC into > > state in which BootROM cannot work with it. Something timeouts, BootROM > > reconfigure/retry it and then it work again. It would be needed to > > inv
Re: [PATCH 4/4] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
On Sun, 5 Mar 2023 at 12:43, Pali Rohár wrote:
> On Sunday 05 March 2023 21:31:00 Martin Rowe wrote:
> > [upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
> >
> > The Clearfog devices have only one SDHC device. This is either eMMC if
> > it is populated on the SOM or SDHC if not. The Linux device tree assumes
> > the SDHC case. Detect if the device is an eMMC and fixup the device-tree
> > so it will be detected by Linux.
> >
> > Ported from vendor repo at https://github.com/SolidRun/u-boot
> >
> > Signed-off-by: Martin Rowe
> > ---
> > board/solidrun/clearfog/clearfog.c | 42 ++
> > configs/clearfog_defconfig | 1 +
> > configs/clearfog_sata_defconfig| 1 +
> > configs/clearfog_spi_defconfig | 1 +
> > 4 files changed, 45 insertions(+)
> >
> > diff --git a/board/solidrun/clearfog/clearfog.c
> b/board/solidrun/clearfog/clearfog.c
> > index 03adb591d8..cafead3a1a 100644
> > --- a/board/solidrun/clearfog/clearfog.c
> > +++ b/board/solidrun/clearfog/clearfog.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -261,3 +262,44 @@ int board_late_init(void)
> >
> > return 0;
> > }
> > +
> > +static bool has_emmc(void)
> > +{
> > + struct mmc *mmc;
> > + mmc = find_mmc_device(0);
> > + if (!mmc)
> > + return 0;
> > + return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
> > +}
> > +
> > +/*
> > + * The Clearfog devices have only one SDHC device. This is either eMMC
> > + * if it is populated on the SOM or SDHC if not. The Linux device tree
> > + * assumes the SDHC case. Detect if the device is an eMMC and fixup the
> > + * device-tree so it will be detected by Linux.
> > + */
> > +int ft_board_setup(void *blob, struct bd_info *bd)
> > +{
> > + __maybe_unused int offset, rc;
> > +
> > + if (has_emmc()) {
> > + puts("Patching FDT so that eMMC is detected by kernel\n");
> > + offset = fdt_path_offset(blob,
> "/soc/internal-regs/sdhci@d8000");
>
> Do not use fixed DT paths when parsing Linux kernel DT files. Linux
> developers often changes DT node names in their DTS files which cause
> changing of DT paths and hence this code in bootloader stops working.
>
> I would suggest to find node offset by compatible string
> ("marvell,armada-380-sdhci"). Look for inspiration what I done in past:
>
> https://source.denx.de/u-boot/u-boot/-/commit/7cd67018dd7f754c66cf08a76397bbee254b32aa
>
Makes sense, I'll rework the patch.
> > + if (offset >= 0) {
> > + rc = fdt_delprop(blob, offset, "cd-gpios");
> > + if (rc == -FDT_ERR_NOTFOUND)
> > + return 0; /* Assume that the device tree
> is already customized for eMMC */
>
> I would suggest to always add "non-removable" property when it does not
> exist.
>
OK, that makes sense, too. I'll test that out.
> + if (rc) {
> > + printf("Unable to remove cd-gpios for
> eMMC, err=%s\n", fdt_strerror(rc));
> > + return rc;
>
> Normally it is not a good idea to return non-zero value from
> ft_board_setup() function because it "crashes" u-boot and stops booting
> kernel.
>
I think this might be an exception. If the board has eMMC there's a
reasonable chance that it's used for the root device. By the time Linux
tries and fails to mount the root device there are already reams of printks
on the serial console that make it hard to see the root cause all the way
back in u-boot. Failing early with an appropriate error message would be
more beneficial while troubleshooting this problem.
There's a corner case where you have an eMMC board and never use the eMMC
device (like my use case), so you wouldn't want to have it fail for
something that you don't use. I think we'll cause more issues for people
that can't mount their root device than for people that get an error for a
device they don't use.
Given I'm going to rework the logic here anyway it's likely this first
'return rc' will be removed, but I think it is worth retaining the one
below.
> + }
> > + rc = fdt_setprop_empty(blob, offset,
> "non-removable");
> > + if (rc) {
> > + printf("Unable to add non-removable for
> eMMC
Re: [PATCH 3/4] arm: mvebu: clearfog: Add defconfig for SPI booting
On Sun, 5 Mar 2023 at 12:29, Pali Rohár wrote:
> On Sunday 05 March 2023 21:30:59 Martin Rowe wrote:
> > This new clearfog_spi_defconfig file is a copy of existing
> > clearfog_defconfig file modified to instruct build system to generate
> > final kwbimage for SPI booting and to store the environment in SPI.
> >
> > Signed-off-by: Martin Rowe
> > ---
> > configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> > copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (96%)
> >
> > diff --git a/configs/clearfog_sata_defconfig
> b/configs/clearfog_spi_defconfig
> > similarity index 96%
> > copy from configs/clearfog_sata_defconfig
> > copy to configs/clearfog_spi_defconfig
> > index b11d8746b0..d6695f31e6 100644
> > --- a/configs/clearfog_sata_defconfig
> > +++ b/configs/clearfog_spi_defconfig
> > @@ -10,7 +10,7 @@ CONFIG_NR_DRAM_BANKS=2
> > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
> > CONFIG_TARGET_CLEARFOG=y
> > -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > +CONFIG_ENV_SECT_SIZE=0x1
> > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> > CONFIG_SPL_TEXT_BASE=0x4030
> > CONFIG_SPL_MMC=y
> > @@ -19,6 +19,7 @@ CONFIG_SPL_STACK=0x4002c000
> > CONFIG_SPL=y
> > CONFIG_DEBUG_UART_BASE=0xf1012000
> > CONFIG_DEBUG_UART_CLOCK=25000
> > +CONFIG_SPL_LIBDISK_SUPPORT=y
>
> I think you do not need libdisk support in SPL which loads main u-boot
> from SPI.
>
Makes sense, I'll remove
> > CONFIG_SYS_LOAD_ADDR=0x80
> > CONFIG_DEBUG_UART=y
> > CONFIG_AHCI=y
> > @@ -48,6 +49,7 @@ CONFIG_CMD_USB=y
> > CONFIG_CMD_TFTPPUT=y
> > CONFIG_CMD_CACHE=y
> > CONFIG_CMD_TIME=y
> > +CONFIG_MVEBU_SATA_BOOT=y
>
> Should not be default bubt location SPI for SPI booting?
>
Yes, I'll fix
> CONFIG_ENV_OVERWRITE=y
> > CONFIG_ENV_MIN_ENTRIES=128
> > CONFIG_ARP_TIMEOUT=200
> > --
> > 2.39.2
> >
>
Re: [PATCH 2/4] arm: mvebu: clearfog: Align defconfigs
On Sun, 5 Mar 2023 at 12:27, Pali Rohár wrote: > On Sunday 05 March 2023 21:30:58 Martin Rowe wrote: > > Ensure that functionality of generated configs is identical between SATA > > and MMC defconfigs for Clearfog boards. The only expected difference is > > the boot mode and environment location. > > > > Signed-off-by: Martin Rowe > > --- > > configs/clearfog_defconfig | 1 + > > configs/clearfog_sata_defconfig | 11 +++ > > 2 files changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig > > index 24e7c16ac7..f9cfa94e77 100644 > > --- a/configs/clearfog_defconfig > > +++ b/configs/clearfog_defconfig > > @@ -46,6 +46,7 @@ CONFIG_CMD_USB=y > > CONFIG_CMD_TFTPPUT=y > > CONFIG_CMD_CACHE=y > > CONFIG_CMD_TIME=y > > +CONFIG_MVEBU_SATA_BOOT=y > > MVEBU_*_BOOT is the default target for the bubt command. I guess that > you do not want to set default one to SATA for eMMC/SD boot. > Correct, I'll remove it. Anyway, when you are doing cleanup of clearfog defconfig files, what > about renaming clearfog_defconfig to clearfog_mmc_defconfig? > I considered this but left it as is since we have several years worth of support with that original name. It will make bisects easier if we keep it the same, but I don't feel strongly either way. Happy to rename it if you'd prefer. > > CONFIG_ENV_OVERWRITE=y > > CONFIG_ENV_MIN_ENTRIES=128 > > CONFIG_ARP_TIMEOUT=200 > > diff --git a/configs/clearfog_sata_defconfig > b/configs/clearfog_sata_defconfig > > index e9b36150ea..b11d8746b0 100644 > > --- a/configs/clearfog_sata_defconfig > > +++ b/configs/clearfog_sata_defconfig > > @@ -3,14 +3,19 @@ CONFIG_ARCH_CPU_INIT=y > > CONFIG_SYS_THUMB_BUILD=y > > CONFIG_ARCH_MVEBU=y > > CONFIG_TEXT_BASE=0x0080 > > +CONFIG_SPL_GPIO=y > > CONFIG_SPL_LIBCOMMON_SUPPORT=y > > CONFIG_SPL_LIBGENERIC_SUPPORT=y > > CONFIG_NR_DRAM_BANKS=2 > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > CONFIG_TARGET_CLEARFOG=y > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > > CONFIG_SPL_TEXT_BASE=0x4030 > > +CONFIG_SPL_MMC=y > > SPL contains code just for loading main u-boot. So I think you do not > need MMC support in SPL code (symbols prefixed by CONFIG_SPL) which > loads u-boot from SATA. > Correct, I'll remove it. That's actually all of the changes removed (the rest are canonicalization or the resolved MMC issue), so I'll drop this patch completely in v2. > CONFIG_SPL_SERIAL=y > > +CONFIG_SPL_STACK=0x4002c000 > > CONFIG_SPL=y > > CONFIG_DEBUG_UART_BASE=0xf1012000 > > CONFIG_DEBUG_UART_CLOCK=25000 > > @@ -18,8 +23,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 > > CONFIG_DEBUG_UART=y > > CONFIG_AHCI=y > > CONFIG_DISTRO_DEFAULTS=y > > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > CONFIG_BOOTDELAY=3 > > CONFIG_USE_PREBOOT=y > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > @@ -31,7 +34,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 > > CONFIG_SPL_BSS_MAX_SIZE=0x4000 > > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > > -CONFIG_SPL_STACK=0x4002c000 > > CONFIG_SPL_I2C=y > > CONFIG_SYS_MAXARGS=32 > > CONFIG_CMD_TLV_EEPROM=y > > @@ -46,7 +48,6 @@ CONFIG_CMD_USB=y > > CONFIG_CMD_TFTPPUT=y > > CONFIG_CMD_CACHE=y > > CONFIG_CMD_TIME=y > > -CONFIG_CMD_MVEBU_BUBT=y > > CONFIG_ENV_OVERWRITE=y > > CONFIG_ENV_MIN_ENTRIES=128 > > CONFIG_ARP_TIMEOUT=200 > > @@ -59,6 +60,8 @@ CONFIG_DM_I2C=y > > CONFIG_SYS_I2C_MVTWSI=y > > CONFIG_I2C_EEPROM=y > > CONFIG_SPL_I2C_EEPROM=y > > +CONFIG_MMC_BROKEN_CD=y > > +CONFIG_SPL_DM_MMC=y > > CONFIG_SUPPORT_EMMC_BOOT=y > > CONFIG_MMC_SDHCI=y > > CONFIG_MMC_SDHCI_SDMA=y > > -- > > 2.39.2 > > >
Re: [PATCH 1/4] arm: mvebu: clearfog: Fix MMC detection
On Sun, 5 Mar 2023 at 12:19, Pali Rohár wrote:
> On Sunday 05 March 2023 21:30:57 Martin Rowe wrote:
> > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
>
> When you are sending defconfig changes, please do not put there
> unrelated canonicalization changes. Canonicalization of defconfigs are
> done semi-automatically when Tom regenerates them. So avoid
> CONFIG_SUPPORT_EMMC_BOOT and CONFIG_CMD_MVEBU_BUBT changes for eMMC
> related change.
>
Noted. I'll fix it up.
Anyway, I have looked at how MMC_BROKEN_CD is working in u-boot. The
> relevant part is sdhci_get_cd() function in drivers/mmc/sdhci.c file and
> in mmc_of_parse() function in drivers/mmc/mmc-uclass.c file.
>
> So instead of MMC_BROKEN_CD would not it be better the following u-boot
> specific patch? cd-gpios is completely ignored by u-boot when
> non-removable is set.
>
Both are fine with me. I initially went with MMC_BROKEN_CD since it seemed
like the established way. I've tested the patch below and the only issue is
in the corner case of non-MMC boot while expecting something from MMC, but
the error message is helpful enough ("Card did not respond to voltage
select! : -110"). I'll resubmit with your patch instead.
> diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> index 96629294be4b..e725770c1899 100644
> --- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> +++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
> @@ -10,6 +10,7 @@
>
> {
> u-boot,dm-spl;
> + non-removable; /* assume that the card is always present, required
> for eMMC variant */
> };
>
> {
>
>
> > Signed-off-by: Martin Rowe
> > ---
> > configs/clearfog_defconfig | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> > index 8cd35f9f1a..24e7c16ac7 100644
> > --- a/configs/clearfog_defconfig
> > +++ b/configs/clearfog_defconfig
> > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > CONFIG_CMD_TFTPPUT=y
> > CONFIG_CMD_CACHE=y
> > CONFIG_CMD_TIME=y
> > -CONFIG_CMD_MVEBU_BUBT=y
> > CONFIG_ENV_OVERWRITE=y
> > CONFIG_ENV_MIN_ENTRIES=128
> > CONFIG_ARP_TIMEOUT=200
> > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
> > CONFIG_SYS_I2C_MVTWSI=y
> > CONFIG_I2C_EEPROM=y
> > CONFIG_SPL_I2C_EEPROM=y
> > -CONFIG_SUPPORT_EMMC_BOOT=y
> > +CONFIG_MMC_BROKEN_CD=y
> > CONFIG_MMC_SDHCI=y
> > CONFIG_MMC_SDHCI_SDMA=y
> > CONFIG_MMC_SDHCI_MV=y
> > --
> > 2.39.2
> >
>
[PATCH 4/4] arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
[upstream of vendor commit 19a96f7c40a8fc1d0a6546ac2418d966e5840a99]
The Clearfog devices have only one SDHC device. This is either eMMC if
it is populated on the SOM or SDHC if not. The Linux device tree assumes
the SDHC case. Detect if the device is an eMMC and fixup the device-tree
so it will be detected by Linux.
Ported from vendor repo at https://github.com/SolidRun/u-boot
Signed-off-by: Martin Rowe
---
board/solidrun/clearfog/clearfog.c | 42 ++
configs/clearfog_defconfig | 1 +
configs/clearfog_sata_defconfig| 1 +
configs/clearfog_spi_defconfig | 1 +
4 files changed, 45 insertions(+)
diff --git a/board/solidrun/clearfog/clearfog.c
b/board/solidrun/clearfog/clearfog.c
index 03adb591d8..cafead3a1a 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -261,3 +262,44 @@ int board_late_init(void)
return 0;
}
+
+static bool has_emmc(void)
+{
+ struct mmc *mmc;
+ mmc = find_mmc_device(0);
+ if (!mmc)
+ return 0;
+ return (!mmc_init(mmc) && IS_MMC(mmc)) ? true : false;
+}
+
+/*
+ * The Clearfog devices have only one SDHC device. This is either eMMC
+ * if it is populated on the SOM or SDHC if not. The Linux device tree
+ * assumes the SDHC case. Detect if the device is an eMMC and fixup the
+ * device-tree so it will be detected by Linux.
+ */
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ __maybe_unused int offset, rc;
+
+ if (has_emmc()) {
+ puts("Patching FDT so that eMMC is detected by kernel\n");
+ offset = fdt_path_offset(blob,
"/soc/internal-regs/sdhci@d8000");
+ if (offset >= 0) {
+ rc = fdt_delprop(blob, offset, "cd-gpios");
+ if (rc == -FDT_ERR_NOTFOUND)
+ return 0; /* Assume that the device tree is
already customized for eMMC */
+ if (rc) {
+ printf("Unable to remove cd-gpios for eMMC,
err=%s\n", fdt_strerror(rc));
+ return rc;
+ }
+ rc = fdt_setprop_empty(blob, offset, "non-removable");
+ if (rc) {
+ printf("Unable to add non-removable for eMMC,
err=%s\n", fdt_strerror(rc));
+ return rc;
+ }
+ }
+ }
+
+ return 0;
+}
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index f9cfa94e77..45b093c6d8 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -21,6 +21,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTDELAY=3
CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
index b11d8746b0..081ebd7e7a 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_sata_defconfig
@@ -23,6 +23,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTDELAY=3
CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig
index d6695f31e6..6b9e817f68 100644
--- a/configs/clearfog_spi_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -24,6 +24,7 @@ CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTDELAY=3
CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
--
2.39.2
[PATCH 3/4] arm: mvebu: clearfog: Add defconfig for SPI booting
This new clearfog_spi_defconfig file is a copy of existing
clearfog_defconfig file modified to instruct build system to generate
final kwbimage for SPI booting and to store the environment in SPI.
Signed-off-by: Martin Rowe
---
configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (96%)
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
similarity index 96%
copy from configs/clearfog_sata_defconfig
copy to configs/clearfog_spi_defconfig
index b11d8746b0..d6695f31e6 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -10,7 +10,7 @@ CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
+CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
CONFIG_SPL_TEXT_BASE=0x4030
CONFIG_SPL_MMC=y
@@ -19,6 +19,7 @@ CONFIG_SPL_STACK=0x4002c000
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xf1012000
CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
@@ -48,6 +49,7 @@ CONFIG_CMD_USB=y
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
+CONFIG_MVEBU_SATA_BOOT=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_MIN_ENTRIES=128
CONFIG_ARP_TIMEOUT=200
--
2.39.2
[PATCH 2/4] arm: mvebu: clearfog: Align defconfigs
Ensure that functionality of generated configs is identical between SATA and MMC defconfigs for Clearfog boards. The only expected difference is the boot mode and environment location. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 1 + configs/clearfog_sata_defconfig | 11 +++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 24e7c16ac7..f9cfa94e77 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,6 +46,7 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y +CONFIG_MVEBU_SATA_BOOT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..b11d8746b0 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -3,14 +3,19 @@ CONFIG_ARCH_CPU_INIT=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_MVEBU=y CONFIG_TEXT_BASE=0x0080 +CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 +CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +23,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +34,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +48,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +60,8 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y +CONFIG_SPL_DM_MMC=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y -- 2.39.2
[PATCH 1/4] arm: mvebu: clearfog: Fix MMC detection
A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y -- 2.39.2
[PATCH 0/4] arm: mvebu: clearfog: defconfig and eMMC updates
Minor defconfig and eMMC updates for SolidRun's A388 Clearfog devices.
Changes since initial discussion:
https://lists.denx.de/pipermail/u-boot/2023-February/510492.html
- CONFIG_SPL_SPI selected for SPI defconfig
- Runtime patching of kernel FDT added for eMMC detection
Note that this patch depends on this patch series (has been merged to
u-boot-marvell/next):
https://lists.denx.de/pipermail/u-boot/2023-March/511038.html
Signed-off-by: Martin Rowe
Martin Rowe (4):
arm: mvebu: clearfog: Fix MMC detection
arm: mvebu: clearfog: Align defconfigs
arm: mvebu: clearfog: Add defconfig for SPI booting
arm: mvebu: clearfog: Detect MMC vs SDHC and fixup fdt
board/solidrun/clearfog/clearfog.c| 42 +++
configs/clearfog_defconfig| 5 ++-
configs/clearfog_sata_defconfig | 12 --
...arfog_defconfig => clearfog_spi_defconfig} | 10 -
4 files changed, 61 insertions(+), 8 deletions(-)
copy configs/{clearfog_defconfig => clearfog_spi_defconfig} (91%)
--
2.39.2
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote: > Improve code for checking strapping pins which specifies boot mode source. > > Martin, could you test if Clearfog can be still configured into UART > booting mode via HW switches and if it still works correctly? First > patch is reverting UART related commit for Clearfog which I think it not > needed anymore. > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified. UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though. The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: 98 % [. ] Done Finishing transfer [Type Ctrl-\ + c to quit] It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot. > Also could you check if SATA booting is still working correctly? > SATA works correctly. > Tony, should address problems with SPI booting when it is configured to > different configuration. In fourth commit I added all possible boot mode > strapping pin configurations which are recognized by A385 bootrom (and > not the only one described in the HW spec, which is incomplete). > > Stefan, do you have some AXP board with SATA boot source? Because I'm > adding it for completeness in the last sixth patch. > > Pali Rohár (6): > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > arm: mvebu: Convert BOOT_FROM_* constants to function macros > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > arch/arm/mach-mvebu/cpu.c | 20 ++--- > arch/arm/mach-mvebu/include/mach/soc.h | 41 -- > 2 files changed, 35 insertions(+), 26 deletions(-) > > -- > 2.20.1 > >
Re: [PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros
On Sat, 4 Mar 2023 at 10:51, Pali Rohár wrote:
> This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one
> macro. And also allows to extend other BOOT_FROM_* macros for other
> variants.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/mach-mvebu/cpu.c | 16 +---
> arch/arm/mach-mvebu/include/mach/soc.h | 25 -
> 2 files changed, 21 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> index daa84c03fcdc..cb3f3afad269 100644
> --- a/arch/arm/mach-mvebu/cpu.c
> +++ b/arch/arm/mach-mvebu/cpu.c
> @@ -98,24 +98,26 @@ u32 get_boot_device(void)
> val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
> boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
> debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
> - switch (boot_device) {
> #ifdef BOOT_FROM_NAND
> - case BOOT_FROM_NAND:
> + if (BOOT_FROM_NAND(boot_device))
> return BOOT_DEVICE_NAND;
> #endif
> #ifdef BOOT_FROM_MMC
> - case BOOT_FROM_MMC:
> - case BOOT_FROM_MMC_ALT:
> + if (BOOT_FROM_MMC(boot_device))
> return BOOT_DEVICE_MMC1;
> #endif
> - case BOOT_FROM_UART:
> +#ifdef BOOT_FROM_UART
> + if (BOOT_FROM_UART(boot_device))
> return BOOT_DEVICE_UART;
> +#endif
> #ifdef BOOT_FROM_SATA
> - case BOOT_FROM_SATA:
> + if (BOOT_FROM_SATA(boot_device))
> return BOOT_DEVICE_SATA;
> #endif
> - case BOOT_FROM_SPI:
> +#ifdef BOOT_FROM_SPI
> + if (BOOT_FROM_SPI(boot_device))
> return BOOT_DEVICE_SPI;
> +#endif
> default:
> return BOOT_DEVICE_BOOTROM;
> };
>
This doesn't compile for me: the switch has only partially been converted
so I get:
arch/arm/mach-mvebu/cpu.c: In function 'get_boot_device':
arch/arm/mach-mvebu/cpu.c:118:9: error: 'default' label not within a switch
statement
118 | default:
| ^~~
arch/arm/mach-mvebu/cpu.c: At top level:
arch/arm/mach-mvebu/cpu.c:121:1: error: expected identifier or '(' before
'}' token
121 | }
| ^
Maybe remove the default and closing bracket lines and just return
BOOT_DEVICE_BOOTROM if nothing else worked? That worked for me.
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> b/arch/arm/mach-mvebu/include/mach/soc.h
> index 5fdce8fe4e7e..aa42db36a1ee 100644
> --- a/arch/arm/mach-mvebu/include/mach/soc.h
> +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> @@ -143,8 +143,8 @@
> #define BOOT_DEV_SEL_OFFS 3
> #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_UART 0x30
> -#define BOOT_FROM_SPI 0x38
> +#define BOOT_FROM_UART(x) (x == 0x30)
> +#define BOOT_FROM_SPI(x) (x == 0x38)
>
> #define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(20))
> ? \
> 2 : 16600)
> @@ -160,12 +160,11 @@
> #define BOOT_DEV_SEL_OFFS 4
> #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_NAND 0x0A
> -#define BOOT_FROM_SATA 0x2A
> -#define BOOT_FROM_UART 0x28
> -#define BOOT_FROM_SPI 0x32
> -#define BOOT_FROM_MMC 0x30
> -#define BOOT_FROM_MMC_ALT 0x31
> +#define BOOT_FROM_NAND(x) (x == 0x0A)
> +#define BOOT_FROM_SATA(x) (x == 0x2A)
> +#define BOOT_FROM_UART(x) (x == 0x28)
> +#define BOOT_FROM_SPI(x) (x == 0x32)
> +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
>
> #define CONFIG_SYS_TCLK((readl(CONFIG_SAR_REG) & BIT(15))
> ? \
> 2 : 25000)
> @@ -182,9 +181,9 @@
> #define BOOT_DEV_SEL_OFFS 11
> #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_NAND 0x1
> -#define BOOT_FROM_UART 0x2
> -#define BOOT_FROM_SPI 0x3
> +#define BOOT_FROM_NAND(x) (x == 0x1)
> +#define BOOT_FROM_UART(x) (x == 0x2)
> +#define BOOT_FROM_SPI(x) (x == 0x3)
>
> #define CONFIG_SYS_TCLK2 /* 200MHz */
> #elif defined(CONFIG_ARMADA_XP)
> @@ -204,8 +203,8 @@
> #define BOOT_DEV_SEL_OFFS 5
> #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
>
> -#define BOOT_FROM_UART 0x2
> -#define BOOT_FROM_SPI 0x3
> +#define BOOT_FROM_UART(x) (x == 0x2)
> +#define BOOT_FROM_SPI(x) (x == 0x3)
>
> #define CONFIG_SYS_TCLK25000 /* 250MHz */
> #endif
> --
> 2.20.1
>
>
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Sat, 4 Mar 2023 at 10:40, Pali Rohár wrote: > Boot configuration stored in EXT_CSC register is completely ignored by > BootROM: > > https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8dm...@mail.gmail.com/ > > Reflect this eMMC booting in documentation and in the code. > > Martin, can you test this patch series if SPL and main U-Boot is loaded > from the same eMMC HW partition? > boot0: u-boot Works fine, no issues. boot0: zeroed boot1: u-boot user: zeroed It succeeds, eventually... == BootROM - 1.73 Booting from MMC BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | | 0| 3 | SATA0 | | 1| 0 | SGMII1 | | 2| 5 | PCIe1 | | 3| 5 | USB3 HOST1 | | 4| 5 | PCIe2 | | 5| 0 | SGMII2 | High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from MMC1 ERROR: Invalid kwbimage v1 mmc_load_image_raw_sector: mmc block read error spl: mmc: wrong boot mode Trying to boot from BOOTROM Returning to BootROM (return address 0x05c4)... Timeout waiting card ready BootROM: Image checksum verification PASSED U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 +1000) SoC: MV88F6828-A0 at 1600 MHz DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) Core: 38 devices, 22 uclasses, devicetree: separate MMC: mv_sdh: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment Model: SolidRun Clearfog A1 Board: SolidRun Clearfog Pro Net: Warning: ethernet@7 (eth1) using random MAC address - 12:07:8b:f9:7a:6f eth1: ethernet@7 Warning: ethernet@3 (eth2) using random MAC address - ee:ed:f3:bb:c2:af , eth2: ethernet@3 Warning: ethernet@34000 (eth3) using random MAC address - ae:34:b9:bb:28:c6 , eth3: ethernet@34000 Hit any key to stop autoboot: 0 => == Between "Returning to BootROM" and "Timeout waiting card ready" takes around 315 seconds. That's long enough that I thought it had hung completely and I only noticed it continue because I left it running while working on something else. I tried several things to reduce this timeout, including reverting to the "non-removable" dts for shdci, but nothing seems to affect it. When bootloader is stored on Boot 0, then SPL should take care of > loading and executing main U-Boot. When it is stored on Boot 1 or User > Data then SPL should return back to BootROM and let BootROM to load and > execute main U-Boot. > > Pali Rohár (2): > tools: kwboot: Fix MMC HW boot partitions info > arm: mvebu: spl: Load proper U-Boot from eMMC Boot 0 partition > > arch/arm/mach-mvebu/Kconfig | 1 + > arch/arm/mach-mvebu/spl.c | 13 +++-- > tools/kwboot.c | 6 +++--- > 3 files changed, 11 insertions(+), 9 deletions(-) > > -- > 2.20.1 > >
Re: [PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros
On Sat, 4 Mar 2023 at 11:20, Pali Rohár wrote: > On Saturday 04 March 2023 11:50:34 Pali Rohár wrote: > > Disassembling A385 BootROM binary reveal how BootROM interprets strapping > > pins for Boot Device Mode. All possible options are: > > > > 0x00..0x07 -> Parallel NOR > > 0x08..0x15 -> Parallel NAND > > 0x16..0x17 -> Parallel NOR > > 0x18..0x25 -> Parallel NAND > > 0x26..0x27 -> SPI NAND > > 0x28..0x29 -> UART xmodem > > 0x2a..0x2b -> SATA > > 0x2c..0x2d -> PCI Express > > 0x2e..0x2f -> Parallel NOR > > 0x30..0x31 -> SD / eMMC > > 0x32..0x39 -> SPI NOR > > 0x3a..0x3c -> Parallel NOR > > 0x3d..0x3e -> UART debug console > > 0x3f -> Invalid > > Clearfog has 5-bit DIP switch and seems that it is directly mapped to > the Boot Device mode with most significant bit of boot mode pulled to > high (sixth bit not present on the switch) and flipped second, third and > fifth bits of the boot mode. > > Based on documentation Clearfog DIP switch should be set to 11100 for > SATA booting, by flipping bits it is 01010, by adding MSB it is 101010, > which is hex 0x2a --> matches A385 SATA boot mode. > The Clearfog schematics indicate the switch is internally pulled to 0x36 / 110110. 110110 XOR 11100 = 101010 = 0x2a. The math checks out and corresponds to the documented modes as well as the enumeration I did a few years ago: 0 nothing [0x36] 1 nothing [0x37] 00010 SPI [0x34] (documented SPI) 00011 SPI [0x35] 00100 SPI [0x32] 00101 SPI [0x33] 00110 MMC (Card did not respond to voltage select!) [0x30] 00111 MMC [0x31] (documented SD/eMMC) 01000 nothing [0x3e] 01001 UART [0x3f] (documented UART) 01010 NOR [0x3c] 01011 nothing [0x3d] 01100 NOR [0x3a] 01101 NOR [0x3b] 01110 nothing [0x38] 0 nothing [0x39] 1 nothing [0x26] 10001 nothing [0x27] 10010 NAND [0x24] 10011 NAND [0x25] 10100 NAND [0x22] 10101 NAND [0x23] 10110 NAND [0x20] 10111 NAND [0x21] 11000 NOR [0x2e] 11001 nothing [0x2f] 11010 PEX0 (00) [0x2c] 11011 PEX0 (1A) [0x2d] 11100 nothing [0x2a] (I don't think I had a SATA card attached, but this is documented SATA) 11101 nothing [0x2b] 0 nothing [0x28] 1 nothing [0x29] Where "nothing" indicates no BootROM output > Can somebody check if UART debug console boot mode works on Clearfog? > It is boot mode when BootROM enters into simple debug console with few > commands. Via kwboot it is possible to enter into this mode (it sends > magic sequence) but from this information it looks like that it should > be possible also without magic sequence, just by configuring boot mode. > I didn't know about this before. I tried with the magic sequence and it works (though it needs the A38x output workaround mentioned here [1]. The boot mode is the one set by 0x3d / 01 or 0x3e / 10, right? 0x3d: 01 XOR 110110 = 01011 0x3e: 10 XOR 110110 = 01000 Neither of those gives an interactive serial console, and even if the output workaround is entered there is never anything that appears in the console. It doesn't even echo the data I type in. [1] https://manpages.debian.org/testing/u-boot-tools/kwboot.1.en.html > > Note that Boot Device Mode Options in A38x Hardware Specifications is > > incomplete. > > > > Signed-off-by: Pali Rohár > > --- > > arch/arm/mach-mvebu/include/mach/soc.h | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h > b/arch/arm/mach-mvebu/include/mach/soc.h > > index aa42db36a1ee..698b70339436 100644 > > --- a/arch/arm/mach-mvebu/include/mach/soc.h > > +++ b/arch/arm/mach-mvebu/include/mach/soc.h > > @@ -160,11 +160,14 @@ > > #define BOOT_DEV_SEL_OFFS4 > > #define BOOT_DEV_SEL_MASK(0x3f << BOOT_DEV_SEL_OFFS) > > > > -#define BOOT_FROM_NAND(x)(x == 0x0A) > > -#define BOOT_FROM_SATA(x)(x == 0x2A) > > -#define BOOT_FROM_UART(x)(x == 0x28) > > -#define BOOT_FROM_SPI(x) (x == 0x32) > > +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || > x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) > > +#define BOOT_FROM_NAND(x)((x >= 0x08 && x <= 0x15) || (x >= 0x18 && > x <= 0x25)) > > +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) > > +#define BOOT_FROM_UART(x)(x == 0x28 || x == 0x29) > > +#define BOOT_FROM_SATA(x)(x == 0x2A || x == 0x2B) > > +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) > > #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) > > +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39) > > > > #define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) > ? \ > >2 : 25000) > > -- > > 2.20.1 > > >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Mon, 27 Feb 2023 at 08:04, Pali Rohár wrote: > On Monday 27 February 2023 08:44:30 Stefan Roese wrote: > > Hi Pali, > > > > On 2/25/23 23:00, Pali Rohár wrote: > > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote: > > > > This patch series contains various improvements and fixes for > existing > > > > logical errors. Boot phase was adjusted to match behavior of Armada > 385 > > > > BootROM by inspecting and disassembling of BootROM binary dump > itself. > > > > Important information are included in documentation patch for kwboot. > > > > Most of the changes are untested, hence this patch series is just > RFC. > > > > So please test changes before applying, idealy on SPI, SATA and > SD/MMC. > > > > Nevertheless all patches on github passed CI testing in this PR: > > > > https://github.com/u-boot/u-boot/pull/275 > > > > > > Patches were tested on more boards and seems there is no reported > issue, > > > but other improvements. > > > > > > So do you need something to modify in this relatively big patch series? > > > If it is not really needed I would like to not send it again because > > > denx servers are not able to handle it. And it take me lot of time to > > > send patches over emails to denx servers. > > > > I'm fine with applying the series as-is. I'm a bit hesitant though, if > > it should be applied to master or to next. As Tom clearly noticed, that > > only fixes should be added after rc2 this time. > > > > What is your thinking on this? > > Well, I do not know. AFAIK more patches here are fixing broken mvebu > boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment? > A388 Clearfog was definitely broken prior to this patchset. There is quite a bit of churn that this has caused for some OpenWRT users [1] as well as for me. It would be nice to have a stable build for these boards. [1] https://github.com/openwrt/openwrt/issues/11661 > > Thanks, > > Stefan > > > > > > > > > > > > > Pali Rohár (59): > > > >tools: kwbimage: Fix generating, verifying and extracting SDIO > > > > kwbimage > > > >tools: kwboot: Fix parsing SDIO kwbimage > > > >arm: mvebu: spl: Fix parsing SDIO kwbimage > > > >cmd: mvebu/bubt: Fix parsing SDIO kwbimage > > > >tools: kwbimage: Fix generating, verifying and extracting SATA > > > > kwbimage > > > >tools: kwboot: Fix parsing SATA kwbimage > > > >arm: mvebu: spl: Fix parsing SATA kwbimage > > > >cmd: mvebu/bubt: Fix parsing SATA kwbimage > > > >arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and > > > > BOOT_DEVICE_MMC2_2 > > > >arm: mvebu: spl: Load proper U-Boot from selected eMMC boot > partition > > > >spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION > > > >arm: mvebu: spl: Fix support for loading U-Boot proper from SD > card > > > >tools: kwboot: Add more documentation references > > > >tools: kwboot: Add image type documentation > > > >tools: kwboot: Fix parsing UART image without data checksum > > > >tools: kwboot: Validate optional kwbimage v1 headers > > > >tools: kwboot: Add check that kwbimage contains DDR init code > > > >tools: kwboot: Fix patching of SPI/NOR XIP images > > > >tools: kwboot: Show image type and error parsing reasons > > > >cmd: mvebu/bubt: Add support for selecting eMMC HW partition > > > >cmd: mvebu/bubt: Add support for writing image to SATA disk > > > >cmd: mvebu/bubt: Add support for reading image from the SATA disk > > > > partition > > > >cmd: mvebu/bubt: Rename variable image_size to hdr_size > > > >cmd: mvebu/bubt: Mark all local symbols as static > > > >cmd: mvebu/bubt: Do not modify image in A8K check_image_header() > > > >cmd: mvebu/bubt: Check also A8K boot image checksum > > > >cmd: mvebu/bubt: Set correct default image name for 32-bit Armada > SoCs > > > >cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option > > > >cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and > > > > 'fuse_read_u64' defined but not used > > > >cmd: mvebu/bubt: Enable command by default > > > >tools: kwbimage: Fix dumping register set / DATA commands > > > >tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE > > > >tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION > > > >tools: kwbimage: Fix dumping NAND_BLKSZ > > > >tools: kwbimage: Fix generating of kwbimage v0 header checksum > > > >tools: kwbimage: Fix endianity when printing kwbimage header > > > >tools: kwbimage: Reject mkimage -F option > > > >tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images > > > >tools: kwbimage: Print binary image offset as size > > > >tools: kwbimage: Print image data offset when printing kwbimage > header > > > >tools: kwbimage: Simplify add_secure_header_v1() > > > >tools: kwbimage: Rename imagesz to dataoff > > > >tools: kwbimage: Fix generating secure boot data image signature > > > >tools: kwbimage: Fix
Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
On Sun, 26 Feb 2023 at 11:18, Pali Rohár wrote: > On Sunday 26 February 2023 01:45:16 Martin Rowe wrote: > > On Sat, 25 Feb 2023 at 22:14, Pali Rohár wrote: > > > On Saturday 25 February 2023 22:49:56 Pali Rohár wrote: > > > > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote: > > > > > A388 Clearfog MMC is either SD Card or eMMC with different > behaviour for > > > > > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. > > > > > > > > > > Signed-off-by: Martin Rowe > > > > > > > > It looks like a hack but I think we do not have a better option for > now. > > > > > > > > If I understand the issue correctly then card-detect pin is > unconnected > > > > for eMMC variant and used for checking if SD card is present for SD > > > > variant. Unconnected pin seems to have some internal pull-up/down > which > > > > reports not-present state for eMMC variant. eMMC does not have any > > > > presence signal, so card-detect pin must be ignored for eMMC. > > > > > > > > This looks like a chicken and egg problem and the only option to > support > > > > both variants is to ignore card-detect pin and always try to > initialize > > > > device connected to mmc controller (which may be eMMC or SD). > > > > > > Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi > > > file and add there this? /delete-property/ cd-gpios; > > > > I just tried this and the device is not detected again; adding > > "non-removable" seems to be required if changing the dts. > > > > > > I do not know if there is a better option for ignoring card-detect > pin > > > > in u-boot, so: > > > > I should point out that I did investigate runtime detection. > > But how you want to do that runtime detection? As I pointed above I > think it is impossible do runtime detection because it is chicken and > egg problem. > > You can patch fdt only after u-boot initialize mmc, so this can be used > just for patching kernel fdt. > I was just trying to address your concerns about the solution looking like a "hack". I did investigate it, and that work confirmed the issues you expected, so that's confirmation that there isn't a better option. I think we're saying the same thing :) I'll look at runtime patching the kernel fdt, but it might not be as quick a turn around as the defconfig work. If anyone looks at it before me, the fdt memory allocation needs to be increased by 2 to fit "non-removable" in the space left by removing the "cd-gpios". > Patching > > the fdt alone didn't seem to work using the hooks that were available, > > so I started looking into how MMC was being initialised to figure out > > if there was something changing the state of the device before it was > > returned to BootROM. I ended up in drivers/mmc/mmc.c mmc_start_init > > trying to figure out how we always end up with the "MMC: no card > > present" message in the eMMC case. I was going to write some extra > > logic around the mmc_getcd call, but realised there was already an > > ifndef with a config that seemed like this exact use-case. Given that > > config solved the problem it seemed like the cleanest solution. > > > > > > Acked-by: Pali Rohár > > > > > > > > > --- > > > > > configs/clearfog_defconfig | 3 +-- > > > > > configs/clearfog_sata_defconfig | 8 > > > > > 2 files changed, 5 insertions(+), 6 deletions(-) > > > > > > > > > > diff --git a/configs/clearfog_defconfig > b/configs/clearfog_defconfig > > > > > index 8cd35f9f1a..24e7c16ac7 100644 > > > > > --- a/configs/clearfog_defconfig > > > > > +++ b/configs/clearfog_defconfig > > > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > > > > > CONFIG_CMD_TFTPPUT=y > > > > > CONFIG_CMD_CACHE=y > > > > > CONFIG_CMD_TIME=y > > > > > -CONFIG_CMD_MVEBU_BUBT=y > > > > > CONFIG_ENV_OVERWRITE=y > > > > > CONFIG_ENV_MIN_ENTRIES=128 > > > > > CONFIG_ARP_TIMEOUT=200 > > > > > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y > > > > > CONFIG_SYS_I2C_MVTWSI=y > > > > > CONFIG_I2C_EEPROM=y > > > > > CONFIG_SPL_I2C_EEPROM=y > > > > > -CONFIG_SUPPORT_EMMC_BOOT=y > > > > > +CONFIG_MMC_BROKEN_CD=y > > > > > CONFIG_MMC_SDHCI=y > > > > > CONFIG_
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
> > > I'm not sure how to run proper timing tests on the process, but > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the > > > direct from SPI around 4 seconds. I thought the goal of loading from > > > SPI directly was speed, but returning to BootROM is significantly > > > faster on this board. > > > > You should check SPI speed in DTS file and also in the defconfig. > > I think we have probably seen this slowdown before. There is a TODO in > the way the DTS nodes are parsed by DM uclass. So this config must be > set in defconfig to get around that bug: > CONFIG_SF_DEFAULT_SPEED=5000 That works and is much faster now. I'll submit it in a V2 for these two patches once Pali's mvebu changes are accepted. Only question I have is: should the faster speed be applied to all three defconfigs? CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the MMC and SATA configs at the moment.
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Sat, 25 Feb 2023 at 21:16, Pali Rohár wrote: > I think that the remaining part is to patch linux DTB file at runtime > for emmc support. So if u-boot mmc device is of eMMC type then fixup > linux dtb file and others do nothing. One question I didn't think of when suggesting this: does runtime patching the kernel's dtb break signed/verified booting? The reason I ask is because we now only need to patch the kernel dtb, not the u-boot one. If we needed to do both, then it would make sense to handle them in the same way through u-boot. The barrier to creating a patched kernel dtb file on its own is very low, so I'm not sure adding some "magic" to u-boot to make it work is the best solution, especially if it might break verified boot.
Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
On Sat, 25 Feb 2023 at 22:14, Pali Rohár wrote: > On Saturday 25 February 2023 22:49:56 Pali Rohár wrote: > > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote: > > > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for > > > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. > > > > > > Signed-off-by: Martin Rowe > > > > It looks like a hack but I think we do not have a better option for now. > > > > If I understand the issue correctly then card-detect pin is unconnected > > for eMMC variant and used for checking if SD card is present for SD > > variant. Unconnected pin seems to have some internal pull-up/down which > > reports not-present state for eMMC variant. eMMC does not have any > > presence signal, so card-detect pin must be ignored for eMMC. > > > > This looks like a chicken and egg problem and the only option to support > > both variants is to ignore card-detect pin and always try to initialize > > device connected to mmc controller (which may be eMMC or SD). > > Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi > file and add there this? /delete-property/ cd-gpios; I just tried this and the device is not detected again; adding "non-removable" seems to be required if changing the dts. > > I do not know if there is a better option for ignoring card-detect pin > > in u-boot, so: I should point out that I did investigate runtime detection. Patching the fdt alone didn't seem to work using the hooks that were available, so I started looking into how MMC was being initialised to figure out if there was something changing the state of the device before it was returned to BootROM. I ended up in drivers/mmc/mmc.c mmc_start_init trying to figure out how we always end up with the "MMC: no card present" message in the eMMC case. I was going to write some extra logic around the mmc_getcd call, but realised there was already an ifndef with a config that seemed like this exact use-case. Given that config solved the problem it seemed like the cleanest solution. > > Acked-by: Pali Rohár > > > > > --- > > > configs/clearfog_defconfig | 3 +-- > > > configs/clearfog_sata_defconfig | 8 > > > 2 files changed, 5 insertions(+), 6 deletions(-) > > > > > > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig > > > index 8cd35f9f1a..24e7c16ac7 100644 > > > --- a/configs/clearfog_defconfig > > > +++ b/configs/clearfog_defconfig > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > > > CONFIG_CMD_TFTPPUT=y > > > CONFIG_CMD_CACHE=y > > > CONFIG_CMD_TIME=y > > > -CONFIG_CMD_MVEBU_BUBT=y > > > CONFIG_ENV_OVERWRITE=y > > > CONFIG_ENV_MIN_ENTRIES=128 > > > CONFIG_ARP_TIMEOUT=200 > > > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y > > > CONFIG_SYS_I2C_MVTWSI=y > > > CONFIG_I2C_EEPROM=y > > > CONFIG_SPL_I2C_EEPROM=y > > > -CONFIG_SUPPORT_EMMC_BOOT=y > > > +CONFIG_MMC_BROKEN_CD=y > > > CONFIG_MMC_SDHCI=y > > > CONFIG_MMC_SDHCI_SDMA=y > > > CONFIG_MMC_SDHCI_MV=y > > > diff --git a/configs/clearfog_sata_defconfig > > > b/configs/clearfog_sata_defconfig > > > index e9b36150ea..84f900bf50 100644 > > > --- a/configs/clearfog_sata_defconfig > > > +++ b/configs/clearfog_sata_defconfig > > > @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 > > > CONFIG_SPL_LIBCOMMON_SUPPORT=y > > > CONFIG_SPL_LIBGENERIC_SUPPORT=y > > > CONFIG_NR_DRAM_BANKS=2 > > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > > CONFIG_TARGET_CLEARFOG=y > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > > > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > > > CONFIG_SPL_TEXT_BASE=0x4030 > > > CONFIG_SPL_SERIAL=y > > > +CONFIG_SPL_STACK=0x4002c000 > > > CONFIG_SPL=y > > > CONFIG_DEBUG_UART_BASE=0xf1012000 > > > CONFIG_DEBUG_UART_CLOCK=25000 > > > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 > > > CONFIG_DEBUG_UART=y > > > CONFIG_AHCI=y > > > CONFIG_DISTRO_DEFAULTS=y > > > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff > > > CONFIG_BOOTDELAY=3 > > > CONFIG_USE_PREBOOT=y > > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 > > > CONFIG_SPL_BSS_MAX_SIZE=0x4000 > > > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > > > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > > > -CONFIG_SPL_STACK=0x4002c000 > > > CONFIG_SPL_I2C=y > > > CONFIG_SYS_MAXARGS=32 > > > CONFIG_CMD_TLV_EEPROM=y > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > > > CONFIG_CMD_TFTPPUT=y > > > CONFIG_CMD_CACHE=y > > > CONFIG_CMD_TIME=y > > > -CONFIG_CMD_MVEBU_BUBT=y > > > CONFIG_ENV_OVERWRITE=y > > > CONFIG_ENV_MIN_ENTRIES=128 > > > CONFIG_ARP_TIMEOUT=200 > > > @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y > > > CONFIG_SYS_I2C_MVTWSI=y > > > CONFIG_I2C_EEPROM=y > > > CONFIG_SPL_I2C_EEPROM=y > > > +CONFIG_MMC_BROKEN_CD=y > > > CONFIG_SUPPORT_EMMC_BOOT=y > > > CONFIG_MMC_SDHCI=y > > > CONFIG_MMC_SDHCI_SDMA=y > > > -- > > > 2.39.2 > > >
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
> While I haven't tested this patchset - I have tested SPI booting with > v2022.01 after applying lots of patches. > I found that the magic value reported by bootrom when booting from SPI will > be 0x34 on clearfog. > The current sources only handle 0x32, hence having or not having SPL_SPI will > always lead to returning to the bootrom. > > Please consider pulling in this patch: > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d > I can send it separately if you like. Tested with the patch on a Clearfog Base: == Without SPL_SPI same return to BootROM ... mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0x05c4)... BootROM: Image checksum verification PASSED U-Boot 2023.04-rc2... == With SPL_SPI loads directly from SPI ... mv_ddr: completed successfully Trying to boot from SPI U-Boot 2023.04-rc2... == I'm not sure how to run proper timing tests on the process, but stopwatch timing just between seeing "Trying to boot" and "U-Boot 2023.04-rc2" showed the return to BootROM under 1 second, and the direct from SPI around 4 seconds. I thought the goal of loading from SPI directly was speed, but returning to BootROM is significantly faster on this board. > which I have tested by adding these config options: I tested the new spi_defconfig with and without SPL_SPI; no other changes
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Sat, 25 Feb 2023 at 07:41, Pali Rohár wrote:
>
> On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
> > This new clearfog_spi_defconfig file is copy of existing
> > clearfog_defconfig file and changed to instruct build system to
> > generate final kwbimage for SPI booting and to store the
> > environment in SPI as well.
> >
> > Signed-off-by: Martin Rowe
> > ---
> > .../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> > copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
> >
> > diff --git a/configs/clearfog_sata_defconfig
> > b/configs/clearfog_spi_defconfig
> > similarity index 93%
> > copy from configs/clearfog_sata_defconfig
> > copy to configs/clearfog_spi_defconfig
> > index 84f900bf50..31b1e9fce8 100644
> > --- a/configs/clearfog_sata_defconfig
> > +++ b/configs/clearfog_spi_defconfig
> > @@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
> > CONFIG_SYS_THUMB_BUILD=y
> > CONFIG_ARCH_MVEBU=y
> > CONFIG_TEXT_BASE=0x0080
> > +CONFIG_SPL_GPIO=y
> > CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > CONFIG_NR_DRAM_BANKS=2
> > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
> > CONFIG_TARGET_CLEARFOG=y
> > -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > +CONFIG_ENV_SECT_SIZE=0x1
> > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> > CONFIG_SPL_TEXT_BASE=0x4030
> > +CONFIG_SPL_MMC=y
> > CONFIG_SPL_SERIAL=y
> > CONFIG_SPL_STACK=0x4002c000
> > CONFIG_SPL=y
> > CONFIG_DEBUG_UART_BASE=0xf1012000
> > CONFIG_DEBUG_UART_CLOCK=25000
> > +CONFIG_SPL_LIBDISK_SUPPORT=y
> > +# CONFIG_SPL_SPI is not set
>
> Any reason to disable it?
It's the same as MMC and SATA defconfigs this way, it just needs to be
explicit here because of something SPI related that we've enabled.
SPL_DM_SPI is enabled in all of the configs, so I'm guessing that it
is providing driver support because everything seems to work without
SPL_SPI.
I re-tested with and without the config and it doesn't seem to change
anything. With it enabled the file is 588K instead of 580K without it,
but that's not really an issue with 4M of flash storage available.
> > CONFIG_SYS_LOAD_ADDR=0x80
> > CONFIG_DEBUG_UART=y
> > CONFIG_AHCI=y
> > @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
> > CONFIG_I2C_EEPROM=y
> > CONFIG_SPL_I2C_EEPROM=y
> > CONFIG_MMC_BROKEN_CD=y
> > +CONFIG_SPL_DM_MMC=y
> > CONFIG_SUPPORT_EMMC_BOOT=y
> > CONFIG_MMC_SDHCI=y
> > CONFIG_MMC_SDHCI_SDMA=y
> > --
> > 2.39.2
> >
[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
This new clearfog_spi_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate final kwbimage for SPI booting and to store the
environment in SPI as well.
Signed-off-by: Martin Rowe
---
.../{clearfog_sata_defconfig => clearfog_spi_defconfig}| 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
similarity index 93%
copy from configs/clearfog_sata_defconfig
copy to configs/clearfog_spi_defconfig
index 84f900bf50..31b1e9fce8 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MVEBU=y
CONFIG_TEXT_BASE=0x0080
+CONFIG_SPL_GPIO=y
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff
CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
+CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
CONFIG_SPL_TEXT_BASE=0x4030
+CONFIG_SPL_MMC=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK=0x4002c000
CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0xf1012000
CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_SPL_SPI is not set
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DEBUG_UART=y
CONFIG_AHCI=y
@@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_EEPROM=y
CONFIG_SPL_I2C_EEPROM=y
CONFIG_MMC_BROKEN_CD=y
+CONFIG_SPL_DM_MMC=y
CONFIG_SUPPORT_EMMC_BOOT=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
--
2.39.2
[PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 3 +-- configs/clearfog_sata_defconfig | 8 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..84f900bf50 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y -- 2.39.2
[PATCH 0/2] arm: mvebu: clearfog: defconfig updates
Minor defconfig updates to Pali's RFC "arm: mvebu: Various fixes" for
SolidRun's A388 Clearfog devices.
Martin Rowe (2):
arm: mvebu: clearfog: Fix MMC detection
arm: mvebu: clearfog: Add defconfig for SPI booting
configs/clearfog_defconfig| 3 +--
configs/clearfog_sata_defconfig | 8
...rfog_sata_defconfig => clearfog_spi_defconfig} | 15 ++-
3 files changed, 15 insertions(+), 11 deletions(-)
copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (92%)
--
2.39.2
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
> When generating this patch, use git options -M, -C and > --find-copies-harder. It will detect that you created this file as copy > from other file and generate better diff. Will do. This thread has gotten quite long! I've: - tested all the boot modes and bubt update types - created the SPI defconfig, - fixed the eMMC detection by enabling MMC_BROKEN_CD - taken a look at the kwbimage documentation, but I don't think I can be of much help there I'm also able to help test any new changes for the MMC boot flow. Is there anything else that I've missed that I can help with while I've got it all setup? Martin
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
> Please note that this patch is sent to the list a s reply to the > RFC patchset from Pali. Something went wrong here, so that the > commit subject was not used. Also for the 2nd patch. Ah, sorry, I'm not really set up for this. The first patch branches from Pali's RFC, though, so maybe it would be best to include my two when the final mvebu changes are sent in? > You are removing the bubt cmd here. This is most likely a mistake. I had to double check this as well, but CONFIG_MMC_BROKEN_CD also enables bubt for some reason, so it's definitely still included in the config but gets removed by savedefconfig. Martin
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting This new clearfog_spi_defconfig file is copy of existing clearfog_defconfig file and changed to instruct build system to generate final kwbimage for SPI booting and to store the environment in SPI as well. Signed-off-by: Martin Rowe --- configs/clearfog_spi_defconfig | 88 ++ 1 file changed, 88 insertions(+) create mode 100644 configs/clearfog_spi_defconfig diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig new file mode 100644 index 00..31b1e9fce8 --- /dev/null +++ b/configs/clearfog_spi_defconfig @@ -0,0 +1,88 @@ +CONFIG_ARM=y +CONFIG_ARCH_CPU_INIT=y +CONFIG_SYS_THUMB_BUILD=y +CONFIG_ARCH_MVEBU=y +CONFIG_TEXT_BASE=0x0080 +CONFIG_SPL_GPIO=y +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff +CONFIG_TARGET_CLEARFOG=y +CONFIG_ENV_SECT_SIZE=0x1 +CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" +CONFIG_SPL_TEXT_BASE=0x4030 +CONFIG_SPL_MMC=y +CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 +CONFIG_SPL=y +CONFIG_DEBUG_UART_BASE=0xf1012000 +CONFIG_DEBUG_UART_CLOCK=25000 +CONFIG_SPL_LIBDISK_SUPPORT=y +# CONFIG_SPL_SPI is not set +CONFIG_SYS_LOAD_ADDR=0x80 +CONFIG_DEBUG_UART=y +CONFIG_AHCI=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_BOOTDELAY=3 +CONFIG_USE_PREBOOT=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SPL_MAX_SIZE=0x22fd0 +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y +CONFIG_SPL_BSS_START_ADDR=0x40023000 +CONFIG_SPL_BSS_MAX_SIZE=0x4000 +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set +CONFIG_SPL_I2C=y +CONFIG_SYS_MAXARGS=32 +CONFIG_CMD_TLV_EEPROM=y +CONFIG_SPL_CMD_TLV_EEPROM=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_TFTPPUT=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_TIME=y +CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_MIN_ENTRIES=128 +CONFIG_ARP_TIMEOUT=200 +CONFIG_NET_RETRY_COUNT=50 +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_OF_TRANSLATE=y +CONFIG_AHCI_MVEBU=y +CONFIG_DM_PCA953X=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_MVTWSI=y +CONFIG_I2C_EEPROM=y +CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y +CONFIG_SPL_DM_MMC=y +CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y +CONFIG_MMC_SDHCI_MV=y +CONFIG_MTD=y +CONFIG_SF_DEFAULT_BUS=1 +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_SPI_FLASH_MTD=y +CONFIG_PHY_MARVELL=y +CONFIG_PHY_GIGE=y +CONFIG_MVNETA=y +CONFIG_MII=y +CONFIG_MVMDIO=y +CONFIG_PCI=y +CONFIG_PCI_MVEBU=y +CONFIG_SCSI=y +CONFIG_SPL_DEBUG_UART_BASE=0xd0012000 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y +CONFIG_KIRKWOOD_SPI=y +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y -- 2.39.2 On Fri, 24 Feb 2023 at 06:27, Martin Rowe wrote: > > > > boot0 - zeroed > > > boot1 - u-boot (with local version 'boot1') > > > user - u-boot (with local version 'user') > > Can you check if boot_ack argument has some effect on the initial > > choice? Or if completely disabling boot partitions (boot_enable to 0) > > have some effect? > > boot_ack doesn't appear to do anything. I can only set 0 or 1 and > there's no noticeable change to the boot process. > > Setting `mmc partconf 0 0 0 0` with the same setup as described above > results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in > BOOT1 loads u-boot from the user area, which is identical to the `mmc > partconf 0 0 7 0` flow. > > > If really EXT_CSD[179] register is completely ignored we may change SPL > > to always boot from BOOT0 (when eMMC with boot partitions is used) and > > if it fails then fallback to BootROM booting. > > Is there a way of knowing where the SPL was loaded from? Because it > would make sense to me that if SPL was loaded from BOOT1 to try and > load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from > BOOT0, etc. Having u-boot loaded from a different location is not what > I expected and seems like it would cause a lot of confusion, > especially in a failed A/B rollout. BootROM seems to completely ignore > the setting, so I agree that SPL should ignore it as well, but > hardcoding BOOT0 (or even setting the partition as a compile-time > option) is probably not a great outcome. > > Two observations that might help here: > 1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS > is set to 0x0, even it it was set to something else prior to reset > 2. With the same setup as described above and `mmc partconf 0 0 1 1` > the SPL eventually times out trying to load from the zeroed BOOT0 and > returns to BootROM, which results in u-boot being loaded from BOOT1: > = >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
[PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe --- configs/clearfog_defconfig | 3 +-- configs/clearfog_sata_defconfig | 8 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..84f900bf50 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y -- 2.39.2 On Wed, 22 Feb 2023 at 21:23, Pali Rohár wrote: > > On Wednesday 22 February 2023 21:20:58 Martin Rowe wrote: > > Hi > > > > > Could you send a patch which adds appropriate defconfig file for SPI > > > boot? So this configuration would be tested in U-Boot CI automatically. > > > > Will do. Does it need to be the same as the other defconfigs > > otherwise? I suggest putting the environment in SPI as well if u-boot > > is already there (default is MMC). > > Yes, it makes sense. > > > > Have you tried booting from eMMC boot partition or eMMC user data > > > partition? Because all 3 options should work, but I'm not fully sure if > > > BootROM choose partition from eMMC register or if tries all 3 in some > > > order. This is something which needs to be checked and verified. > > > > I only tested from boot0, but will test the others as well. I've only > > ever seen it fallback, but I'll check the new changes and see if they > > can select the boot device. > > Ok. When testing, ensure that you erase uboots from other partitions or > check that it boots the correct version from the correction partition. > > > > Could you try to use SolidRun eMMC patch which SolidRun has for years in > > > its repository? > > > > > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99 > > > > > > Probably same functionality is needed to implement also into > > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for > > > other boards how they use CONFIG_OF_BOARD_FIXUP. > > > > > > And if ... you can try to put this logic in board_late_init() function. > > > For inspiration look into Espressobin board which deactivates eMMC at > > > runtime by checking existence of eMMC: > > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c > > > > This is still on my TODO from earlier discussions. > > > > > There is still missing documentation for kwbimage config file format. > > > It should be in "kwbimage" section of ./doc/mkimage.1 file but there is > > > only placeholder... It would be nice if somebody can take it and write > > > it. > > > > I'm not sure if I have the expertise for this, but can take a look as well. > > > > Martin > > Ok.
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
> > boot0 - zeroed > > boot1 - u-boot (with local version 'boot1') > > user - u-boot (with local version 'user') > Can you check if boot_ack argument has some effect on the initial > choice? Or if completely disabling boot partitions (boot_enable to 0) > have some effect? boot_ack doesn't appear to do anything. I can only set 0 or 1 and there's no noticeable change to the boot process. Setting `mmc partconf 0 0 0 0` with the same setup as described above results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in BOOT1 loads u-boot from the user area, which is identical to the `mmc partconf 0 0 7 0` flow. > If really EXT_CSD[179] register is completely ignored we may change SPL > to always boot from BOOT0 (when eMMC with boot partitions is used) and > if it fails then fallback to BootROM booting. Is there a way of knowing where the SPL was loaded from? Because it would make sense to me that if SPL was loaded from BOOT1 to try and load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from BOOT0, etc. Having u-boot loaded from a different location is not what I expected and seems like it would cause a lot of confusion, especially in a failed A/B rollout. BootROM seems to completely ignore the setting, so I agree that SPL should ignore it as well, but hardcoding BOOT0 (or even setting the partition as a compile-time option) is probably not a great outcome. Two observations that might help here: 1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS is set to 0x0, even it it was set to something else prior to reset 2. With the same setup as described above and `mmc partconf 0 0 1 1` the SPL eventually times out trying to load from the zeroed BOOT0 and returns to BootROM, which results in u-boot being loaded from BOOT1: = BootROM - 1.73 Booting from MMC BootROM: Bad header at offset BootROM: Bad header at offset 0020 Switching BootPartitions. U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 - 19:43:59 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | | 0| 3 | SATA0 | | 1| 0 | SGMII1 | | 2| 5 | PCIe1 | | 3| 5 | USB3 HOST1 | | 4| 5 | PCIe2 | | 5| 0 | SGMII2 | High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from MMC1 ERROR: Invalid kwbimage v1 mmc_load_image_raw_sector: mmc block read error spl: mmc: wrong boot mode Trying to boot from BOOTROM Returning to BootROM (return address 0x05c4)... Timeout waiting card ready BootROM: Image checksum verification PASSED U-Boot 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 - 19:43:59 +1000) SoC: MV88F6828-A0 at 1600 MHz DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) Core: 38 devices, 22 uclasses, devicetree: separate MMC: mv_sdh: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment Model: SolidRun Clearfog A1 Board: SolidRun Clearfog Pro Net: Warning: ethernet@7 (eth1) using random MAC address - be:13:3f:c3:c2:19 eth1: ethernet@7 Warning: ethernet@3 (eth2) using random MAC address - be:4c:72:3e:eb:bc , eth2: ethernet@3 Warning: ethernet@34000 (eth3) using random MAC address - 86:e7:dd:8d:c5:c1 , eth3: ethernet@34000 Hit any key to stop autoboot: 0 => = > Seems that something in mmc initialization code is buggy. You can try to > debug it by starting disabling parts of initialization code until you > find the line/function which makes those BootROM messages "Timeout for > status update!". > Hm... Yes, "offset" string is not in your output, so that function is > not called in SPL. Only in main U-Boot. > > What is in SPL called is board_early_init_f() function or > fdtdec_board_setup() function or also board_late_init() function. > Pointer to blob is in global variable gd->fdt_blob. > > Note that adding new properties/nodes into fdt blob may fail. So always > check for return values of fdt_*() function! You would probably need to > call fdt_increase_size() first to make a place for new properties. > Yes, it has a hook. It is called ft_board_setup() and is called > immediately before booting linux kernel. Basically in this hook you > should check if u-boot's blob was patched for eMMC and if yes then patch > also blob passed as argument in that function, as this blob would be > used for linux. See Turris Omnia hook for inspiration which fixups > ethernet node for linux blob based on what is in u-boot blob: > https://source.denx.de/u-boot/u-boot/-/blob/master/board/CZ.NIC/turris_omnia/turris_omnia.c Lots of great ideas to
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
> > > Have you tried booting from eMMC boot partition or eMMC user data
> > > partition? Because all 3 options should work, but I'm not fully sure if
> > > BootROM choose partition from eMMC register or if tries all 3 in some
> > > order. This is something which needs to be checked and verified.
> >
> > I only tested from boot0, but will test the others as well. I've only
> > ever seen it fallback, but I'll check the new changes and see if they
> > can select the boot device.
>
> Ok. When testing, ensure that you erase uboots from other partitions or
> check that it boots the correct version from the correction partition.
BootROM always tries boot0, boot1, then user, regardless of partconf
setting. SPL does use the partconf setting, though. So when I
configure:
boot0 - zeroed
boot1 - u-boot (with local version 'boot1')
user - u-boot (with local version 'user')
mmc partconf 0 0 7 0
I see the output below. Note that BootROM tries boot0 first with two
addresses, switches to boot1 (see 'boot1' following 2023.04-rc2),
loads SPL, which then loads u-boot from user (see 'user' following
2023.04-rc2)
=
BootROM - 1.73
Booting from MMC
BootROM: Bad header at offset
BootROM: Bad header at offset 0020
Switching BootPartitions.
U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 -
19:43:59 +1000)
High speed PHY - Version: 2.0
EEPROM TLV detection failed: Using static config for Clearfog Pro.
Detected Device ID 6828
board SerDes lanes topology details:
| Lane # | Speed | Type |
| 0| 3 | SATA0|
| 1| 0 | SGMII1|
| 2| 5 | PCIe1|
| 3| 5 | USB3 HOST1|
| 4| 5 | PCIe2|
| 5| 0 | SGMII2|
High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from MMC1
U-Boot 2023.04-rc2user-00098-g93408c61cd-dirty (Feb 23 2023 - 19:44:54 +1000)
SoC: MV88F6828-A0 at 1600 MHz
DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled)
Core: 38 devices, 22 uclasses, devicetree: separate
MMC: mv_sdh: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
Model: SolidRun Clearfog A1
Board: SolidRun Clearfog Pro
Net:
Warning: ethernet@7 (eth1) using random MAC address - ae:50:98:34:2e:3e
eth1: ethernet@7
Warning: ethernet@3 (eth2) using random MAC address - 0a:66:2b:f7:45:09
, eth2: ethernet@3
Warning: ethernet@34000 (eth3) using random MAC address - d2:8e:11:7e:64:c0
, eth3: ethernet@34000
Hit any key to stop autoboot: 0
=>
=
> > > Could you try to use SolidRun eMMC patch which SolidRun has for years in
> > > its repository?
> > >
> > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
> > >
> > > Probably same functionality is needed to implement also into
> > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> > > other boards how they use CONFIG_OF_BOARD_FIXUP.
> > >
> > > And if ... you can try to put this logic in board_late_init() function.
> > > For inspiration look into Espressobin board which deactivates eMMC at
> > > runtime by checking existence of eMMC:
> > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c
I've not been able to get this to work. I enable CONFIG_OF_BOARD_FIXUP
in my config and add the following to
board/solidrun/clearfog/clearfog.c:
+int board_fix_fdt(void *blob)
+ {
+ int offset;
+ offset = fdt_path_offset(blob, "/soc/internal-regs/sdhci@d8000");
+ if (offset >= 0) {
+ printf("offset");
+ fdt_delprop(blob, offset, "cd-gpios");
+ fdt_setprop_empty(blob, offset, "non-removable");
+ }
+ return 0;
+}
Then I boot from MMC and get the following:
=
BootROM - 1.73
Booting from MMC
U-Boot SPL 2023.04-rc2-00098-g93408c61cd-dirty (Feb 23 2023 - 21:32:01 +1000)
High speed PHY - Version: 2.0
EEPROM TLV detection failed: Using static config for Clearfog Pro.
Detected Device ID 6828
board SerDes lanes topology details:
| Lane # | Speed | Type |
| 0| 3 | SATA0 |
| 1| 0 | SGMII1 |
| 2| 5 | PCIe1 |
| 3| 5 | USB3 HOST1 |
| 4| 5 | PCIe2 |
| 5| 0 | SGMII2 |
High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from MMC1
MMC: no card present
spl: mmc init failed with error: -123
Trying to boot from BOOTROM
Returning to BootROM (return address 0x05c4)...
sdioSdhciSendCmd: Timeout for status update!
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi > Could you send a patch which adds appropriate defconfig file for SPI > boot? So this configuration would be tested in U-Boot CI automatically. Will do. Does it need to be the same as the other defconfigs otherwise? I suggest putting the environment in SPI as well if u-boot is already there (default is MMC). > Have you tried booting from eMMC boot partition or eMMC user data > partition? Because all 3 options should work, but I'm not fully sure if > BootROM choose partition from eMMC register or if tries all 3 in some > order. This is something which needs to be checked and verified. I only tested from boot0, but will test the others as well. I've only ever seen it fallback, but I'll check the new changes and see if they can select the boot device. > Could you try to use SolidRun eMMC patch which SolidRun has for years in > its repository? > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99 > > Probably same functionality is needed to implement also into > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for > other boards how they use CONFIG_OF_BOARD_FIXUP. > > And if ... you can try to put this logic in board_late_init() function. > For inspiration look into Espressobin board which deactivates eMMC at > runtime by checking existence of eMMC: > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c This is still on my TODO from earlier discussions. > There is still missing documentation for kwbimage config file format. > It should be in "kwbimage" section of ./doc/mkimage.1 file but there is > only placeholder... It would be nice if somebody can take it and write > it. I'm not sure if I have the expertise for this, but can take a look as well. Martin
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Pali,
Good news:
A388 Clearfog Base (SD card model):
- MMC from SD card works
- UART works
- SATA with new defconfig works
- SPI (if you select MVEBU_SPL_BOOT_DEVICE_SPI yourself) works
A388 Clearfog Pro (eMMC model):
- MMC from eMMC works, but still requires the dts to be patched for
eMMC (included at bottom)
I tried eMMC both with and without the dts patched, but only the
patched version boots. I am not easily able to test the other boot
methods on the Pro, but they're the same as the Base. Let me know if
you need any extra data/outputs.
Also, the extra/updated comments with these changes are great! Thanks.
Tested-by: Martin Rowe
Martin
diff --git a/arch/arm/dts/armada-388-clearfog.dts
b/arch/arm/dts/armada-388-clearfog.dts
index e4164f49b2..29a608abcf 100644
--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -101,7 +101,7 @@
sdhci@d8000 {
bus-width = <4>;
- cd-gpios = < 20 GPIO_ACTIVE_LOW>;
+ non-removable;
no-1-8-v;
pinctrl-0 = <_sdhci_pins
_sdhci_cd_pins>;
On Wed, 22 Feb 2023 at 07:58, Pali Rohár wrote:
>
> On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár wrote:
> > >
> > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár wrote:
> > > > >
> > > > > This patch series contains various improvements and fixes for existing
> > > > > logical errors. Boot phase was adjusted to match behavior of Armada
> > > > > 385
> > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > Important information are included in documentation patch for kwboot.
> > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > So please test changes before applying, idealy on SPI, SATA and
> > > > > SD/MMC.
> > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > https://github.com/u-boot/u-boot/pull/275
> > > ...
> > > > I went to patchwork and downloaded the series.
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-p...@kernel.org
> > > >
> > > > When I applied the patches set there were some rejections.
> > > >
> > > > # patch -p1 <
> > > > /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > >
> > > ...
> > > FAILED
> > > ...
> > > >
> > > >
> > > > I'm on the latest master branch (just did a git pull today). Could
> > > > some patches be out of order?
> > > >
> > > > Thanks,
> > > > Tony
> > >
> > > Well, that is because DENX mail server is broken and it crashed during
> > > processing antispam filter on my some of my patches. So some patches are
> > > missing in archive and then applying dependent patches failed.
> > >
> > > So ignore patchwork and email patches. Rather fetch changes from the
> > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > >
> > > You can do it via git command (it fetch it to the new mvebu branch):
> > >
> > > git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> >
> > Indeed! That pull request was applied without problem.
> >
> > So I did a general regression test running rebuilt kwboot binary, and
> > rebuilt u-boot images for these 2 Marvell boards:
> >
> > Thecus N2350 (Armada 385)
> > Pogo V4 (Kirkwood 88F6192).
> >
> > So for that part:
> > Tested-by: Tony Dinh
> >
> > All the best,
> > Tony
>
> Thanks for testing! Anyway do you have some A38x board which can boot
> from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> that Pogo boots from NAND but it does not use SPL.
Re: [bug] timer: orion-timer: static variable patch breaks armada-388-clearfog boot
Stefan, > Could you please test with this attached patch, if this fixes this issue > on your clearfog? Your patch resolves the issue. Thanks for your fast work! Regards Martin
Re: [bug] timer: orion-timer: static variable patch breaks armada-388-clearfog boot
Tony, > Did you build this clearfog board as is? i.e. did you make any change > in the clearfog_defconfig? clearfog_defconfig with: CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_SPL_SATA=y Plus a dts patch to sdhci@d8000 to make it work for eMMC (swap cd-gpios for non-removable) Plus a workaround that's not yet merged for a build failure with SATA from [1] Shouldn't be anything that affects the timer, but I can try a fully clean build with the defconfig if you need it. Regards Martin [1] https://lore.kernel.org/u-boot/20230110161946.3816866-8-tr...@konsulko.com/
[bug] timer: orion-timer: static variable patch breaks armada-388-clearfog boot
Hi, Commit 5387b093 was a fix for early_init_done causing issues on Pogo v4 [1]. The fix breaks armada-388-clearfog because the boot hangs indefinitely. It appears that the cause is an infinite loop in __udelay due to get_ticks() always returning 0. After adding some printf statements it became apparent that the timer was never getting initialised. git-blame identified the "timer: orion-timer: Fix problem with early static variable" patch as a likely issue. Reverting the commit restores boot for armada-388-clearfog. Patching the issue is a bit beyond me without understanding the Pogo v4 issue, but I'm happy to test any patches that are developed. Regards Martin [1] https://lore.kernel.org/u-boot/20221221091849.1018783-1...@denx.de/
Re: [U-Boot][bug report] clearfog: EMMC boot broken on clearfog pro
Hello again > So in order to move forward, the current plan is to find out/bisect first > commit after v2021.01 which has introduced this BootROM SD/eMMC/SATA boot > regression and inform involved folks (Author and Commiter) accordingly with a > proper bug report. I did try to bisect the eMMC issue, but there are a few related breakages for different reasons over the last 2 years, so it's not one commit that has done it. For example, just the 4 changes I listed for kwbimage.c are introduced by the following 5 commits: 5c61710c9880290d54db72878c4435cdaee07d78 501a54a29cc20ce7df70f290fa274b8e2ea9d6f4 e0c243c398a771df22fd3caf309b04eef3ba2683 700ea98b2e364a8107a9af962ba39f2eeadfc678 aa6943ca3122db7ea0063684f94b5dbdf9c5cf51 > Since you're able to boot from SATA, it would help to know if it's broken as > well. Having BootROM output with failing header offsets would be nice as well. SATA boot works for me up until around 2022.10-rc4. The following configs were required on top of the clearfog_defconfig: CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_SPL_SATA=y CONFIG_SPL_FS_EXT4=y UART boot and SPI boot work, too. After the commit I tested (1977d72a69f3c8d97bd25a86a6be4da27cde3724) some mvebu timer changes got merged and __udelay gets stuck in an infinite loop while probing hardware. I'm still trying to pin that one down, but it seems entirely unrelated to BootROM finding invalid headers. In case you still need it, here's the BootROM output for SATA with no u-boot installed: BootROM - 1.73 Booting from AHCI Probing HBA- 0 port 0 SATA device found BootROM: Bad header at offset 0001 BootROM: Bad header at offset 0022 BootROM: Bad header at offset 1000 BootROM: Bad header at offset 2000 BootROM: Bad header at offset 3000 BootROM: Bad header at offset 4000 BootROM: Bad header at offset 5000 BootROM: Bad header at offset 6000 BootROM: Bad header at offset 7000 Also, I found a non-eMMC clearfog base to test SD card boot. I had assumed that SD card boot was working, therefore my patches would have broken it. It appears the inverse is true. I can boot from a SD card with the same changes I posted that fix eMMC. That means my changes address two different issues: 1. eMMC not being detected, which could be fixed with a CONFIG_CLEARFOG_EMMC kconfig and ifdef for the dts file, similar to the existing clearfog kconfigs 2. MMC boot (both eMMC and SD card) not working, which is fixed by removing the special handling that converts to/from sectors in the SDIO case and allowing a 1 sector offset for CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR How 2 gets implemented depends on what subset of devices MMC boot is broken for. If all devices are broken, my changes would fix it cleanly, otherwise the changes would need to be wrapped in some kind of ifdef which would mean the kwboot tool is no longer universal but must be compiled for specific boards. Let me know if there is any other data that would be useful. Regards Martin
Re: [U-Boot][bug report] clearfog: EMMC boot broken on clearfog pro
On Mon, 9 Jan 2023 at 21:34, Petr Štetiar wrote:
>
> Martin Rowe [2023-01-03 03:20:49]:
>
> [Adding Florian, Tomasz and Oli to the Cc: loop]
>
> Hi,
>
> > I'm following up on this bug report from September (
> > https://lists.denx.de/pipermail/u-boot/2022-September/494811.html )
> > I also hit this issue on my Clearfog Pro when booting with eMMC.
>
> FYI we've recently got similar bug report in OpenWrt as well
> https://github.com/openwrt/openwrt/issues/11661
>
> There Oli is having problem to boot v2022.07 from SD card on his Clearfog Pro,
> version v2021.01 was working fine for him.
>
> > Florian's bug report was incredibly helpful in isolating the issue.
>
> Indeed, that eMMC handling looks quite different, as it seems that BootROM is
> looking at offset 0x0:
>
> -> BootROM - 1.73
> -> Booting from MMC
> -> BootROM: Bad header at offset
> -> BootROM: Bad header at offset 0020
> -> Switching BootPartitions.
> -> BootROM: Invalid HDR source addr
>
> but in Oli's SD card boot log we can see, that it looks at 0x200 offset first:
>
> BootROM - 1.73
> Booting from MMC
> BootROM: Bad header at offset 0200
> BootROM: Bad header at offset 4400
> BootROM: Bad header at offset 0020
>
> So perhaps SD and eMMC booting needs to be treated differently?
Much of the work that introduced these issues appears to have been
making a single kwboot version that works for all cases, rather than
having a board specific tool. When I tried creating a patch, that's
where I got stuck because there doesn't seem to be enough information
in the headers to decide between SD and eMMC. They both use the same
final header address, so maybe there's a possible solution, though it
still doesn't help with the sector size calculation.
> > > After binary patching the the srcaddr (srcaddr = srcaddr * 512) in the
> > > kwbimage v1 header, I got the BootROM to execute the SPL again.
>
> So this means following commit 501a54a29cc2 ("tools: kwbimage: Fix
> generation of SATA, SDIO and PCIe images") ? As reverting that commit yields
> following kwb image diff related to srcaddr changes:
>
> --- v2021.10-rc1-108-g501a54a29cc2.xxd 2023-01-09 20:37:08.250562742 +0100
> +++ v2021.10-rc1-108-g501a54a29cc2-revert.xxd 2023-01-09
> 20:37:17.902718024 +0100
> @@ -1,5 +1,5 @@
> -: ae00 0098 0600 0102 0080 4001 @...
> -0010: c0ff 7f00 8000 01c2
> +: ae00 4496 0600 0102 0080 0080 0200 D...
> +0010: c0ff 7f00 8000 0145 ...E
> 0020: 0201 60df 0200 5b00 6800 ..`.[...h...
> 0030:
> 0040: 0f00 00ea 14f0 9fe5 14f0 9fe5 14f0 9fe5
>
> Which in human readable form is following:
>
> --- v2021.10-rc1-108-g501a54a29cc2.header 2023-01-09 20:51:56.116867268
> +0100
> +++ v2021.10-rc1-108-g501a54a29cc2-revert.header 2023-01-09
> 20:52:55.987832692 +0100
> @@ -1,9 +1,9 @@
> blockid = 0xae,
> nandeccmode = 0x0,
> nandpagesize = 0x0,
> -blocksize = 0x69800,
> +blocksize = 0x69644,
> rsvd1 = 0x8201,
> -srcaddr = 0x140,
> +srcaddr = 0x28000,
> destaddr = 0x7fffc0,
> execaddr = 0x80,
> satapiomode = 0x0,
> @@ -11,4 +11,4 @@
> ddrinitdelay = 0x0,
> rsvd2 = 0x0,
> ext = 0x1,
> -checksum = 0xd8
> +checksum = 0x51
>
> Does it mean, that going back to the commit before this change, thus commit
> bd487ce08135 ("tools: kwbimage: Add constant for SDIO bootfrom") makes your
> device bootable again from SD, SATA and eMMC?
>
> In other words, it would help to know, which commit after v2021.01 breaks
> booting of SD/SATA/eMMC for you. Could you help find it?
The commit from the git bisect is one of dozens that are associated
with a major refactoring of kwboot and kwbimage; you probably want to
go back to the previous merge commit to get a working build.
> > I've gone a bit further and gotten eMMC boot working again, but I'm
> > not a C programmer so this is just a proof of concept/hack, not a
> > patch, and it would break SD card boot. Happy to test any proper
> > patches, though!
> >
> > These steps require a working u-boot from another boot medium. I used
> > SolidRun's u-boot-clearfog-pro-sata.kwb from
> > https://images.solid-run.com/A38X/U-Boot
>
> So am I parsing it properly, that you're not even able to boot v2022.10 from
> SATA?
I didn't test SATA; I used a known working image to help isolate the
problem and have a stable base to test fro
Re: [U-Boot][bug report] clearfog: EMMC boot broken on clearfog pro
Hi,
I'm following up on this bug report from September (
https://lists.denx.de/pipermail/u-boot/2022-September/494811.html )
I also hit this issue on my Clearfog Pro when booting with eMMC.
Florian's bug report was incredibly helpful in isolating the issue.
I've gone a bit further and gotten eMMC boot working again, but I'm
not a C programmer so this is just a proof of concept/hack, not a
patch, and it would break SD card boot. Happy to test any proper
patches, though!
These steps require a working u-boot from another boot medium. I used
SolidRun's u-boot-clearfog-pro-sata.kwb from
https://images.solid-run.com/A38X/U-Boot
Steps to fix eMMC boot:
# In u-boot source
1. Apply the patches at the bottom of the email to v2022.10 release
2. make clearfog_defconfig
3. make menuconfig
- Set CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1
- I also selected
CONFIG_CLEARFOG_CON3_SATA=y
CONFIG_CLEARFOG_CON2_SATA=y
CONFIG_CLEARFOG_SFP_25GB=y
CONFIG_DDR_RESET_ON_TRAINING_FAILURE=y
but they should not affect eMMC booting
4. make
5. Copy u-boot-spl.kwb to booted linux on Clearfog Pro
# In linux on Clearfog Pro
6. echo 0 > /sys/block/mmcblk0boot0/force_ro
7. dd if=/dev/zero of=/dev/mmcblk0boot0 conv=sync [probably not required]
8. dd if=u-boot-spl.kwb of=/dev/mmcblk0boot0 conv=sync
9. dd if=u-boot-spl.kwb of=/dev/mmcblk0 bs=512 seek=1
10. reboot
# In working u-boot on Clearfog Pro
11. mmc partconf 0 1 1 0 [doesn't seem to be needed, but recommended
by board/solidrun/clearfog/README]
# On board
12. Set boot select DIP to eMMC (00111)
13. Power on and boot succeeds
The instructions also work with
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x0 and step 9 changed to `dd
if=u-boot-spl.kwb of=/dev/mmcblk0 conv=sync`, but this will clobber
any partition table that exists on eMMC making it mostly useless other
than for booting.
Weirdly both the boot and the data parts of the eMMC need to have
u-boot. It looks like SPL comes from a boot partition, but then tries
to load u-boot proper from the data partition. This is also noted
here: https://wiki.debian.org/InstallingDebianOn/ClearFog
Pali Rohar appears to have made some significant improvements to mvebu
booting around July 2021, but these changes seem to only account for
an SD card for MMC boot, not eMMC which doesn't appear to need the
sector (512) multiplier. Most of the patches below remove special
handling added for the IBR_HDR_SDIO_ID case which almost certainly
breaks SD card booting. The removal of the error for
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR != 0 appears to have no side
effects for other boot modes. The dts change is a long known issue and
functionally matches a patch carried by armbian and discussed here:
https://forum.armbian.com/topic/3072-clearfog-pro-emmc-requires-sd-card-to-detect-device/
Let me know if I can help get a permanent fix merged.
Martin
diff --git a/arch/arm/dts/armada-388-clearfog.dts
b/arch/arm/dts/armada-388-clearfog.dts
index e4164f49b2..29a608abcf 100644
--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -101,7 +101,7 @@
sdhci@d8000 {
bus-width = <4>;
- cd-gpios = < 20 GPIO_ACTIVE_LOW>;
+ non-removable;
no-1-8-v;
pinctrl-0 = <_sdhci_pins
_sdhci_cd_pins>;
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index ca2d5a59d7..00334562cf 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -44,9 +44,6 @@
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is unsupported
#endif
-#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR) &&
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR != 0
-#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR must be set to 0
-#endif
#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET) && \
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET != 0
#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET must be set to 0
@@ -196,14 +193,6 @@ int spl_parse_board_header(struct spl_image_info
*spl_image,
spl_image->offset *= 512;
}
- /*
-* For SDIO (eMMC) srcaddr is specified in number of sectors.
-* This expects that sector size is 512 bytes and recalculates
-* data offset to bytes.
-*/
- if (IS_ENABLED(CONFIG_SPL_MMC) && mhdr->blockid == IBR_HDR_SDIO_ID)
- spl_image->offset *= 512;
-
if (spl_image->offset % 4 != 0) {
printf("ERROR: Wrong srcaddr (0x%08x) in kwbimage\n",
spl_image->offset);
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 94b7685392..43b51ffd1a 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1021,15 +1021,6 @@ static void *image_create_v0(size_t *imagesz,
struct
