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