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

[Pali Rohár]

On Friday 24 February 2023 06:27:49 Martin Rowe 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.

Ok.

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

Ok.

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

I was trying to figure it out but it looks like that bootrom stores this
information into variable on the bootrom stack. So I think that this is
impossible.

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

Exactly, I want to avoid it.

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

It is a solution and nice trick to how to fix it. Reason is that if SPL
fails to load U-Boot from selected partition then it fallbacks to the
BootROM, which loads U-Boot from the correct location.

So if we hardcode partition to BOOT0 then it obviously works correctly
when SPL+U-Boot is on BOOT0. And if it is stored on BOOT1 or USER then
BootROM already has to fail load it from BOOT0, which means that on
BOOT0 is not valid U-Boot and when SPL tries to load main U-Boot from
BOOT0 it fails too, and it returns control to the BootROM which knows
that it should load it from BOOT0. And this would work also for DATA.

> 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

Ok, so access permissions are reset. I do not know if this is in MMC
standard or not.

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

Access permissions can disable access to particular partition. So it
makes sense that it timeouts. And BootROM can always load and run main
u-boot from the correct location. We are using SPL for loading main
u-boot because this is way how it was first implemented and return to
bootrom was broken in the past. Anyway, if you completely disable MMC
support in SPL then SPL just returns control to BootROM which loads main
U-Boot.

Reading main u-boot via BootROM is slower as from SPL for SPI-NOR
booting because SPL can use faster SPI transfers than BootROM. So this
is the reason why we want in SPL to use native load method and not just
BootROM. But maybe for MMC it would make sense?

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

Ok!