Requiring SPL_DM for new boards?

[Andre Przywara]

On Mon, 31 Oct 2022 15:43:01 -0400
Tom Rini <trini at konsulko.com> wrote:

Hi Tom, Simon,

> On Mon, Oct 31, 2022 at 01:27:06PM -0600, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Sun, 30 Oct 2022 at 11:53, Tom Rini <trini at konsulko.com> wrote:  
> > >
> > > On Sat, Oct 29, 2022 at 07:44:01PM -0600, Simon Glass wrote:  
> > > > Hi Tom,
> > > >
> > > > On Fri, 21 Oct 2022 at 10:26, Tom Rini <trini at konsulko.com> wrote:
> > > >  
> > > > >
> > > > > On Fri, Oct 14, 2022 at 09:56:44AM -0600, Simon Glass wrote:
> > > > >  
> > > > > > Hi,
> > > > > >
> > > > > > What do people think about requiring SPL_DM for new boards?
> > > > > > Would that cause any problems?
> > > > > >
> > > > > > There is not much use of of-platdata (compiling the DT into C
> > > > > > to save space) - is that because it doesn't work for people?
> > > > > >
> > > > > > I am particularly keen to drop the old block interface from
> > > > > > SPL. It seems to me that boards that can use that might have
> > > > > > enough space to enable SPL_DM and SPL_DM_BLK? What do people
> > > > > > think?  
> > > > >
> > > > > I don't think this works. The problem is we aren't seeing new
> > > > > SoCs that have a large initial amount of memory but rather many
> > > > > continuing to have 32KiB or similar tiny sizes. So, I'd rather
> > > > > continue to go with saying it's optional, but that we won't
> > > > > introduce new SPL functionality that can be DM or not DM, but
> > > > > only new functionality that needs SPL_DM and if platforms want
> > > > > it, but have limited memory, we need to go TPL->SPL in that
> > > > > case.  
> > > >
> > > > OK I see.
> > > >
> > > > What do you think of a migration method for boards which don't use
> > > > SPL_DM, so they migrate to TPL? Would that cause a lot of
> > > > problems?  
> > >
> > > I'm not sure what it gains us. Maybe the first step here is to see
> > > what the list of non-DM_SPL platforms / SoCs are?  
> > 
> > OK:
> > 
> > $./tools/moveconfig.py -b
> > 
> > $ ./tools/moveconfig.py -f SPL ~SPL_DM
> > 323 matches
> > ...
> > 
> > $ ./tools/moveconfig.py -f SPL_DM
> > 333 matches
> > ...  
> 
> OK, if we start parsing things out, PowerPC is one chunk of that and
> won't change. Another chunk of that is sunxi which is a "still making
> new SoCs with very small SRAM" and it's worth talking with Andre for
> thoughts there.

Most newer SoCs are not that seriously limited anymore - though that's
not universal, since Allwinner is still making a lot of new "small"
SoCs (with single Cortex-A7s (or older!) and embedded DRAM). And
regardless of that, until recently the BROM wouldn't load more than 32 KB
into SRAM, anyway.
So I cannot say for sure what the situation for new "boards" (rather
SoCs?) will be, but we are stuck with the current legacy SPL for existing
SoCs, for sure.
Samuel has been working on SPL_DM for the D1 (RISC-V) port, though I am
not a big fan of it:
- We would still need the legacy SPL code, since older SoCs are still
  bound to the 32K limit. That is already a stretch for SoCs like the
  A64, where we are already very close to that limit.
- It adds to the test matrix, since we now need to support and
  maintain DM/proper, legacy SPL and SPL-DM.
- Forcing a DT and DM code into that very restricted space requires too
  many compromises for my taste. I like nice driver frameworks and love
  DT, but one must be able to afford all of this. If you have 100s of
  KBs or MBs available, that's all fine, but cutting corners to make it
  fit into 32K takes away much of the beauty and flexibility. The DT
  changes (u-boot,dm-pre-reloc) we need to make are some sign of it.
- We actually don't gain much, because the information the SPL needs is
  mostly not in the DT to begin with:
  - The whole DT clock node is opaque, it basically just says "it's this
    SoC's CCU". That is OK for a single image kernel like Linux, but the
    SPL knows that already - either by build time config or by reading the
    SOCID register. And the SPL does *basic* clock setup, which we cannot
    really describe in the DT at all.
  - The situation is similar for pinctrl: the actual mux value for a
    certain function is not in the DT, but hardcoded in the driver. We
    already tried to hack this down for U-Boot, and only got away with
    quite some squinting.
  - The DRAM controller isn't even mentioned in the DT. And while we could
    add that, the information we need is very minimal.
  - For storage devices (MMC, SPI-NOR) we can use the same fixed per-SoC
    values as the BROM does, so just need the base address. There are only
    like four different values across all Allwinner SoCs. The rest of the
    DT node is either not useful (opaque clock handles) or not needed
    (interrupts).

Yes, there are some boards which require regulator setup in the SPL, which
is described in the DT, but again this still requires regulator
knowledge in the code, and is also quite universal (mostly by SoC again).

So in summary: it would be a lot of work, which we cannot extend to older
SoCs because of technical limitations. But more importantly I think we
don't gain much to make it worth.

Historically we more naturally shared code between SPL and U-Boot proper,
because U-Boot proper used to look much like the SPL looks today (clock
code, for instance). But much of this is mostly obsolete, because there is
not much overlap, code-wise, the only exception being the common MMC protocol
handling, maybe. So I am actually more tempted to spell this out more
openly, and separate and trim down the SPL code, avoiding full-featured
(DM) drivers at all, if possible (like the SPI NOR code does).

We can look into parsing the DT to gather base addresses (and putting them
into generated headers), or to enable Kconfig options (board needs a
regulator), but I would very much like to keep the SPL lean and mean.

The BROM is able to do all the loading without *any* board information
whatsoever. All that the BROM is missing is the DRAM init, which requires
just two or three parameters (LPDDR vs. DDR, frequency). So we could
actually live with a *per-SoC* SPL: we know where the BROM booted from, so
can continue doing so using the same fixed settings as the BROM used (for
SD card, eMMC, SPI, FEL). We actually exercise this idea already in
arch/arm/mach-sunxi/spl_spi_sunxi.c, which is separate from the normal
SPI-NOR code, just focusing on some conservative read-only command to get
the FIT image into DRAM.
I would rather go into this direction than forcing DM into the SPL.

Cheers,
Andre.