Re: [PATCH v2 2/3] sunxi: add "fake" FEL pin support

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Andre,

On 5/12/25 2:39 PM, Andre Przywara wrote:
> On Tue, 22 Apr 2025 16:30:04 +0200
> Quentin Schulz <quentin.schulz@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