Re: RFC: Support for U-Boot phases in Kconfig

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3782 bytes --]

On Wed, Aug 11, 2021 at 04:14:51PM -0400, Sean Anderson wrote:
> 
> 
> On 8/11/21 10:17 AM, Tom Rini 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@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@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.
> 
> This would be nice. I was thinking about doing something like this for
> LIL, to make writing tests easier.

I was thinking of mentioning LIL, even, here.  Converting (to start
with, just a board or two) that implement distro boot from the current
env scheme to another env scheme is going to go quite a ways to showing
if the proposed idea is going to be workable enough or not.

> > 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.
> > 
> > > > 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.
> 
> At the moment there are conditionals for dependencies and defaults [1].
> It doesn't seem like too much of a stretch to allow for arbitrary
> arithmetic. In particular, we could really get 80% of the functionality
> with just + (and perhaps & or |).
> 
> https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-dependencies

Yeah, the addition of +- I think really would cover everything that's
not "this doesn't belong in CONFIG space really" I think.  The only
maybe-hangups are that we say for example on TI platforms:
#define CONFIG_SPL_MAX_SIZE (SRAM_SCRATCH_SPACE_ADDR - CONFIG_SPL_TEXT_BASE)

where SRAM_SCRATCH_SPACE_ADDR isn't a CONFIG symbol, on purpose.  But in
turn, maybe that means we just want to re-think the symbol and have a
choice instead.  Some platforms end up being "automatic" size like the
above.  Other platforms like imx* might be "fixed" size and then define
0x10000 or whatever.

It's all the kind of details that come up when picking a symbol and
digging in.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]