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