xPL Proposal

[Simon Glass]

Hi Tom,

On Fri, 21 Feb 2025 at 16:20, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Feb 21, 2025 at 03:54:52PM -0700, Simon Glass wrote:
> > Hi  Tom,
> >
> > On Fri, 21 Feb 2025 at 12:26, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 08:19:40AM -0600, Tom Rini wrote:
> > > > On Thu, Feb 20, 2025 at 06:30:18PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 20 Feb 2025 at 13:40, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 20, 2025 at 11:13:34AM -0700, Simon Glass wrote:
> > > [snip]
> > > > > > I will look at "splg4" once it's somewhere on source.denx.de and I can
> > > > > > look at it, and refrain from otherwise assuming how it solves the
> > > > > > problems I had seen previously.
> > > > >
> > > > > I pushed an updated version to dm/splg-working but it is not very
> > > > > updated. Still needs more work.
> > > >
> > > > Thanks.
> > >
> > > So, after doing the remaining CONFIG_TEXT_BASE -> CONFIG_PPL_TEXT_BASE
> > > changes, here's another example of the problem with your approach. What
> > > stops xilinx_zynqmp_kria from building in splg-working is that
> > > BUTTON was missing from scripts/conf_nospl. Annoyingly, a mrproper (or
> > > since I always use O=, rm -rf) is needed for changes there to be picked
> > > up, but that's maybe just a missing Makefile dependency line. But that
> > > just makes it easier to see the next problem, which I don't see the
> > > answer to. For PPL, we can build drivers/spi/zynqmp_gqspi.o just fine.
> > > For SPL however:
> > >   CC      spl/drivers/spi/zynqmp_gqspi.o
> > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c: In function 'zynqmp_qspi_of_to_plat':
> > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:203:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > >   203 |         plat->regs = (struct zynqmp_qspi_regs *)(dev_read_addr(bus) +
> > >       |                      ^
> > > /home/trini/work/u-boot/u-boot/drivers/spi/zynqmp_gqspi.c:205:26: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > >   205 |         plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
> > >       |                          ^
> > >
> > > And I don't see, really, what's even getting us down this error path.
> >
> > It's the FDT_64BIT in conf_nospl - that symbol needs to be the same
> > across all phases.
> >
> > I pushed a new tree which builds without the warning. Note that
> > SPL_SPI is enabled.
>
> So, the "what" is FDT_64BIT wasn't correct. I think this is showing that
> scripts/conf_nospl is going to be a problem in and of itself, and likely
> as confusing if not more-so than any of the in-the-end visible changes.

Yes, perhaps the key point I've been trying to get across is this confusion.

As you know, at present we have two types of options:
a) those for which each phase has its own value
b) those for which there is a single value shared across all phases

The only way today that you can tell them apart is by looking for uses
of CONFIG_IS_ENABLED() and $(PHASE_) with the option. If you see them,
then the option is a) otherwise it is b). There is no way to tell from
Kconfig. Also, some parts of the code may use CONFIG_IS_ENABLED() for
an option, some may use IS_ENABLED() for that same option. Some may
use $(PHASE_) and some may not. It's a bit of a mess.

Stepping back a bit, perhaps the goal of my series is to identify
options in b) so we can deal with them in a better way. They are all
listed in conf_nospl, in preparation for some future action.

Regards,
Simon