RFC: Support for U-Boot phases in Kconfig

[Tom Rini]

On Wed, Aug 11, 2021 at 08:26:38AM -0600, Simon Glass wrote:
> 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

Well, all of the DM migrations that have deadlines, and the there's
probably some that don't still.  And the high level size concern about
using DM on platforms where dynamic selection/detection isn't a
functional win.

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

Ah, yes, so there's two things it does.  One is buildman.  Two is "spit
an error out if a defconfig lacks a MAINTAINER entry".  The latter is
important but could be its own tool, and then of course looking at
MAINTAINER files is how to see what config header a given defconfig
uses.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210811/d1d5b96b/attachment.sig>