[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.r...@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.r...@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@70000 (eth1) using random MAC address - be:13:3f:c3:c2:19 > eth1: ethernet@70000 > Warning: ethernet@30000 (eth2) using random MAC address - be:4c:72:3e:eb:bc > , eth2: ethernet@30000 > 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 look into, plus the bubt and defconfig stuff. > I'll let you know how I go or if I get stuck again.