Requiring SPL_DM for new boards?

Simon Glass sjg at chromium.org
Mon Oct 31 20:27:06 CET 2022


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

Regards,
Simon


More information about the U-Boot mailing list