[PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Martin Rowe
martin.p.rowe at gmail.com
Fri Feb 24 16:07:43 CET 2023
[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 <martin.p.rowe at gmail.com>
---
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 0000000000..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=0x00800000
+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=0xff0000
+CONFIG_TARGET_CLEARFOG=y
+CONFIG_ENV_SECT_SIZE=0x10000
+CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
+CONFIG_SPL_TEXT_BASE=0x40000030
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK=0x4002c000
+CONFIG_SPL=y
+CONFIG_DEBUG_UART_BASE=0xf1012000
+CONFIG_DEBUG_UART_CLOCK=250000000
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_SPL_SPI is not set
+CONFIG_SYS_LOAD_ADDR=0x800000
+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 <martin.p.rowe at gmail.com> 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:
> =================================================
> BootROM - 1.73
>
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> 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 0xffff05c4)...
> 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 at 70000 (eth1) using random MAC address - be:13:3f:c3:c2:19
> eth1: ethernet at 70000
> Warning: ethernet at 30000 (eth2) using random MAC address - be:4c:72:3e:eb:bc
> , eth2: ethernet at 30000
> Warning: ethernet at 34000 (eth3) using random MAC address - 86:e7:dd:8d:c5:c1
> , eth3: ethernet at 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 look into, plus the bubt and defconfig stuff.
> I'll let you know how I go or if I get stuck again.
More information about the U-Boot
mailing list