HI Quentin,
On Mon, 2 Sept 2024 at 10:57, Quentin Schulz <quentin.sch...@cherry.de> wrote:
>
> Hi Simon,
>
> On 8/30/24 3:06 AM, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 27 Aug 2024 at 15:43, Tom Rini <tr...@konsulko.com> wrote:
> >>
> >> On Tue, Aug 27, 2024 at 01:24:59PM -0600, Simon Glass wrote:
> >>> Hi Tom,
> >>>
> >>> On Tue, 27 Aug 2024 at 10:50, Tom Rini <tr...@konsulko.com> wrote:
> >>>>
> >>>> On Sun, Aug 25, 2024 at 07:07:23AM -0600, Simon Glass wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> We have the term 'SPL', which has a dual meaning. It is both a
> >>>>> particular phase of U-Boot (the one that loads U-Boot proper) and a
> >>>>> generic name for any pre-proper phase.
> >>>>>
> >>>>> You can see that in a few areas, but for example CONFIG_SPL_BUILD is
> >>>>> enabled for TPL and VPL builds, not just SPL.
> >>>>>
> >>>>> I propose to rename the generic term from SPL to xPL (meaning any PL
> >>>>> phase), leaving SPL to just refer to the phase before U-Boot proper.
> >>>>>
> >>>>> The symbol would be CONFIG_XPL but in documentation we would talk of
> >>>>> xPL, with a lower-case X, so it is more obvious that it refers to any
> >>>>> phase.
> >>>>>
> >>>>> What do you think?
> >>>>
> >>>> I still worry this is just another part of the long symptom of needing
> >>>> to re-work how we configure / build as we have 1 case of "build things
> >>>> this way" (full U-Boot) and N cases of "build things another way" (SPL,
> >>>> TPL, VPL, UPL?). And really we need a way to short-hand
> >>>> "fooboard_defconfig" means "fooboard_spl_defconfig +
> >>>> fooboard_tpl_defconfig + fooboard_SOMETHING_defconfig".
> >>>
> >>> IMO my XPL series does this, at least for some definition of this. I'd
> >>> really like to get that in as it would make all of this much easier.
> >>
> >> Yeah, what I recall of your XPL series was that it made a lot of changes
> >> I didn't like and highlighted what I thought was that yes, really
> >> Yamada-san was right all along and we need a different way of
> >> configuring + building.
> >>
> >> I had even today thought that we could possibly
> >> get away with some shorthand where if for "fooboard_defconfig" we _also_
> >> had "fooboard_spl_defconfig" we knew to build in ${O}/spl/ the spl
> >> variant. It would be harder for cases where we have "fooboard_defconfig"
> >> and "fooboard_hs_defconfig" that both need "fooboard_spl_defconfig", but
> >> it would cover many cases at least. Anyhow...
> >
> > We should discuss this sometime as it has come up once or twice
> > before. Given the dependencies between XPL and proper and don't think
> > we can sensible split into separate files, let alone separate the
> > Kconfig. In fact I still believe that we need a small Kconfig-language
> > addition to support this sort of thing and avoid duplicating the rules
> > everywhere*. I believe I might have even done a patch for it. We got
>
> I thought about this already, one of the issues being that it is not
> guaranteed that the dependencies for a symbol for xPL will be the same
> for yPL nor for proper, so we still need a way to override those from a
> redefinition of the symbol (or any other mechanism). I may misremember
> but I think one of the most straightforward issue was that most (all)
> proper have DM support while xPL do not necessarily have to (and there
> usually is the xPL loaded by BootROM, limited by SRAM size, that does
> not have DM support).
Indeed, they can have different values in TPL and SPL, for example.
My idea for the Kconfig-language addition was [1]
>
> But this has been a big pain of mine, with proper symbols usually being
> properly configured wrt dependencies and Makefile, but a lot of corner
> cases missed for xPL, especially wrt Make rules.
Yes...well, my series actually simplified all the rules and got rid of
$(SPL_TPL) etc.
>
> FWIW, I've always been confused by CONFIG_SPL_BUILD not being for SPL
> but anything !proper (to the point I always have to check whenever I see
> this symbol).
Yes, it is really not what you would expect.
I added an issue at [2]
Regards,
Simon
[1]
https://patchwork.ozlabs.org/project/uboot/patch/20230219145453.1.Idaaf79c3e768b85750d5a7eb732052576c5e07e5@changeid/
[2] https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/26
