[PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

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