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

Thu Feb 23 19:02:23 CET 2023

On Thursday 23 February 2023 12:11:46 Martin Rowe wrote:
> > > > Have you tried booting from eMMC boot partition or eMMC user data
> > > > partition? Because all 3 options should work, but I'm not fully sure if
> > > > BootROM choose partition from eMMC register or if tries all 3 in some
> > > > order. This is something which needs to be checked and verified.
> > >
> > > I only tested from boot0, but will test the others as well. I've only
> > > ever seen it fallback, but I'll check the new changes and see if they
> > > can select the boot device.
> >
> > Ok. When testing, ensure that you erase uboots from other partitions or
> > check that it boots the correct version from the correction partition.
> 
> BootROM always tries boot0, boot1, then user, regardless of partconf
> setting. SPL does use the partconf setting, though. So when I
> configure:
> boot0 - zeroed
> boot1 - u-boot (with local version 'boot1')
> user - u-boot (with local version 'user')
> mmc partconf 0 0 7 0
> I see the output below. Note that BootROM tries boot0 first with two
> addresses, switches to boot1 (see 'boot1' following 2023.04-rc2),
> loads SPL, which then loads u-boot from user (see 'user' following
> 2023.04-rc2)

Ok, I was not sure how that bootrom is choosing initial partition as I
have not fully understood bootrom mmc code. So from this it looks like
that bootrom ignores MMC EXT_CSD[179] register, try booting from BOOT0
and then it really switch to the next partition. (My understanding of
that bootrom binary was that "Switching BootPartitions." does nothing.)

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?

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.

> =================================================
> 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
> 
> 
> U-Boot 2023.04-rc2user-00098-g93408c61cd-dirty (Feb 23 2023 - 19:44:54 +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 - ae:50:98:34:2e:3e
> eth1: ethernet at 70000
> Warning: ethernet at 30000 (eth2) using random MAC address - 0a:66:2b:f7:45:09
> , eth2: ethernet at 30000
> Warning: ethernet at 34000 (eth3) using random MAC address - d2:8e:11:7e:64:c0
> , eth3: ethernet at 34000
> Hit any key to stop autoboot:  0
> =>
> =================================================
> 
> > > > Could you try to use SolidRun eMMC patch which SolidRun has for years in
> > > > its repository?
> > > >
> > > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
> > > >
> > > > Probably same functionality is needed to implement also into
> > > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> > > > other boards how they use CONFIG_OF_BOARD_FIXUP.
> > > >
> > > > And if ... you can try to put this logic in board_late_init() function.
> > > > For inspiration look into Espressobin board which deactivates eMMC at
> > > > runtime by checking existence of eMMC:
> > > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c
> 
> I've not been able to get this to work. I enable CONFIG_OF_BOARD_FIXUP
> in my config and add the following to
> board/solidrun/clearfog/clearfog.c:
> +int board_fix_fdt(void *blob)
> +       {
> +       int offset;
> +       offset = fdt_path_offset(blob, "/soc/internal-regs/sdhci at d8000");
> +       if (offset >= 0) {
> +               printf("offset");
> +               fdt_delprop(blob, offset, "cd-gpios");
> +               fdt_setprop_empty(blob, offset, "non-removable");
> +       }
> +       return 0;
> +}
> Then I boot from MMC and get the following:
> =================================================
> BootROM - 1.73
> 
> Booting from MMC
> 
> U-Boot SPL 2023.04-rc2-00098-g93408c61cd-dirty (Feb 23 2023 - 21:32:01 +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
> MMC: no card present
> spl: mmc init failed with error: -123
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...

After this line, SPL give control to the BootROM...

> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Image checksum verification FAILED
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Invalid header checksum
> Switching BootPartitions.
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Invalid header checksum
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Invalid header checksum
> Switching BootPartitions.

...and bootrom tried to load main U-Boot. But apparently SPL
reconfigured MMC controller in such way that it cannot access eMMC
anymore.

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

> =================================================
> This is exactly the same error as I get without the board_fix_fdt
> change. I tried adding some printfs and returning 1 from the function,
> but I can't see any evidence that it is getting called in the SPL at
> all.

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.

> I also see that SolidRun has dropped the patch you linked to in
> newer a38x branches, but can't see how else they're handling the eMMC
> detection.
> 
> I could wrap the dts change with a kconfig, but anyone enabling that
> kconfig would also need to patch the kernel dtb, unless u-boot has a
> hook to patch the file before passing it to the kernel.

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