RFC: Support for U-Boot phases in Kconfig

[Simon Glass]

Hi Tom,

On Wed, 11 Aug 2021 at 08:17, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Aug 11, 2021 at 08:03:00AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 11 Aug 2021 at 07:47, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Wed, Aug 11, 2021 at 06:56:31AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 10 Aug 2021 at 13:38, Tom Rini <trini at konsulko.com> wrote:
> > > [snip]
> > > > > I need to take another pass at converting a bunch of symbols, to see
> > > > > where we're at.  Probably the biggest chunk of progress next would be to
> > > > > start converting CONFIG_SYS_xxx to SYS_xxx and moving defines out of
> > > > > config.h and in to something else.  I'm taking a peek at some of the
> > > > > remaining PCI ones now.
> > > >
> > > > How about we set a deadline for this? It has gone on for too long and
> > > > we just need to drop these CONFIGs. It's probably a higher priority
> > > > than a Kconfig change.
> > > >
> > > > I was expecting that the config.h files would go away and we would use
> > > > Kconfig (or DT) for everything. What sort of things don't fit into
> > > > that model?
> > >
> > > Environment is the hard one to move out from config.h and in to, well, I
> >
> > Well you know my views on that :-)
> >
> > http://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git-send-email-sjg@chromium.org/
> >
> > I still think it makes more sense than #defines and I can resurrect
> > that series if you like.
>
> That might work, yeah.  I just also want to focus on less things in
> progress at once.  That too I think has been part of why everything is
> taking so long.

OK I'll take a look. Other things in progress I can think of are:

- drop common.h  (could be done in one series if we just go for it)
- set up issue tracking so we can keep an eye on these things

>
> > > don't know what.  I think there's also a handful of symbols like
> > > CONFIG_SPL_MAX_SIZE that are a little tricky to convert directly (they
> > > do math based on other symbols) rather than just as evaluate-and-set.
> >
> > We can either evaluate them and put the answer in as the defconfig
> > value...or perhaps ask Masahiro to support evaluation in kconfig?!
>
> I do forget what kind of operations are allowed in Kconfig at this
> point, it might be possible now, yes.  And if not, something worth
> trying.

OK

>
> > > Right now, a little more than half of the unmigrated symbols are
> > > CONFIG_SYS_xxx things and those likely should become SYS_xxx things.  Of
> > > the ones that don't just go away.
> >
> > Do you mean things like this?
> >
> > arch/m68k/include/asm/immap.h:#define CONFIG_SYS_PCI_BAR0
> >  (0x40000000)
> >
> > Assuming this doesn't move to devicetree, it should be in its own asm/
> > or asm/arch header file I think, not in the config.h file at all.
> >
> > FSL layerscape should move CONFIG_SYS_PCIE3_PHYS_SIZE et al to devcetree.
>
> I started and set aside *PCI* since a bunch of that goes away once
> UCP1020 gets updated.  But yes, there are lots of CONFIG_SYS_xxx things
> that live inside and outside of config.h and step one is likely a simple
> regex.  They aren't really configurable.  We can try and figure out what
> "get this from DT" approach makes sense after.

Yes agree we can't wait for DT move.

>
> > Some of the DM migrations will help - e.g. for I2C. NAND seems to have
> > a lot - who is the NAND maintainer?
>
> There's not currently a NAND maintainer.
>
> > But really what I am asking is, can we set a deadline where all
> > config.h files will be dropped? It has been 7 years...
>
> It's going to come down once again to figuring out what to do about
> older platforms.  Since I picked on khadas platforms earlier, here's
> where meson64.h looks really good.  All of the platforms use
> include/configs/meson64.h and that's very little outside of environment
> stuff.  To go back to another part of the thread, it also shows how hard
> environment stuff is.

Well let's see.

>
> It also reminded me that buildman never got kconfiglib support directly
> and we still have genboardcfg.py to spit out boards.cfg to be parsed by
> buildman.

Ah yes, so is buildman the only reason we have that file? I do like
being able to grep it for stuff, but I suppose buildman could support
that. Is there no other user?

Regards,
Simon