Hi Andre,
On 5/12/25 2:39 PM, Andre Przywara wrote:
On Tue, 22 Apr 2025 16:30:04 +0200
Quentin Schulz <quentin.sch...@cherry.de> wrote:
Hi Quentin,
just found this in my draft folder. It's not really related to this
patch anymore, but you seemed to be interested, and I am happy to
explain some of the specialities for sunxi in U-Boot, since it differs
in many things from other platforms.
So see below...
Thanks for taking the time to share this with me :)
[...]
Jonas has started to support "generic" images for Rockchip boards based
on the recommended hardware design specified by Rockchip themselves.
Most companies do mostly respect it, so that seems to be working quite
nicely.
I wouldn't be aware of a "recommended" board design for Allwinner, but
as a matter of fact many companies copy their reference design -
probably more out of laziness ;-). This brings the variation down to a
manageable level, so we can define default values in Kconfig, so
defconfigs stay small.
Yeah I meant reference design and not recommended design :)
I assume it's not necessarily laziness, but also makes it less prone to
HW issues and also hit "SW currently doesn't support that despite the
datasheet saying the HW does".
Depending on what exactly you want to support with U-Boot, a DM-less SPL
may be difficult. e.g. if you want to support a fallback storage medium
for loading u-boot.itb (or proper, don't know what's being used on
Allwinner) that differs from the one used to load the SPL by the
BootROM, then you possibly cannot rely on the BootROM initializing the
PHYs, controllers, pinmuxes and pinconfs.
We do not rely on any of those bits being setup, actually, but we
naturally follow the BootROM in its decision process. The BROM stores
the boot media used in a byte in SRAM, so we know where we have been
loaded from, so can continue loading from there. But this is just a
decision between SD card, eMMC, NOR flash and FEL mode (maskROM in RK
lingo). We know that SD card boot must have been from MMC0 on the PortF
pins, and NOR flash is only SPI0 on PortC, on so on. The mux values and
MMIO base addresses are per SoC, so those two values are easily stored
in a header or in Kconfig, where we put them *once*, when we add
support for a new SoC - and they are also quite stable across
generations. So there is really not a strong case for DT here. In fact
so far the mux *value* required isn't even stored in the DT, but in a
table in the pinctrl driver.
I meant if for example U-Boot proper stored on the eMMC (when the BROM
loads SPL from eMMC) may be corrupted, and U-Boot should be able to try
loading from other storage media, e.g. SD or SPI-NOR. If you don't have
DT, you have to setup the controllers, PHYs, resets, etc... by hand in C
files instead. Not very convenient when you have something that is made
for that: DT :)
I'm often bringing this topic because I went through the pain of
supporting this fallback mechanism on our RK3399 Puma board which has 9
booting scenarios (TPL+SPL on eMMC/SD/SPI and U-Boot on eMMC/SD/SPI and
you can boot proper from any of the TPL+SPL if the same medium as
TPL+SPL somehow is corrupted). It could actually be more if/when there's
support for USB loading mainline U-Boot.
KConfig may be usable for this
but that will make things cumbersome to support.
There is tons of work and cleanup to do on the sunxi side, and were
already have quite some backlog, so I want to avoid introducing more
construction sites.
Fair, it also doesn't mean that what's currently added cannot be
migrated later on :)
Sure, but at the moment we are severely review limited, so unless that
changes dramatically, I don't see that happening any time soon.
"Later on" has no deadline :) It was also not a way to pressure you into
doing it (now or later).
Cheers,
Quentin
