[RFC PATCH 2/2] board: ti: am65x: Move to using Extension framework

[Simon Glass]

Hi Köry,

On Fri, 6 Oct 2023 at 07:26, Köry Maincent <kory.maincent at bootlin.com> wrote:
>
> On Wed, 4 Oct 2023 15:39:23 +0300
> Roger Quadros <rogerq at kernel.org> wrote:
>
> Hello,
> Thanks for adding me in cc. Also it seems I forgot to add myself to MAINTAINERS
> for the extension_board.c file.
>
> > >>> Before this goes too far I think this should move to using a linker
> > >>> list to declare the driver (or a driver-model driver if you prefer,
> > >>> but that might be overkill).
> >
> > So I've been working on this on the side and got linker list way working
> > with custom script booting but as soon as I move to standard boot flow
> > it no longer works. This is because there is no code in place to
> > apply the overlay and pass it to next stage e.g. EFI.
> >
> > I see the following note at
> > https://elixir.bootlin.com/u-boot/latest/source/boot/bootmeth_efi.c#L304
> >
> > "
> >                 /*
> >                  * TODO: Apply extension overlay
> >                  *
> >                  * Here we need to load and apply the extension overlay. This
> > is
> >                  * not implemented. See do_extension_apply(). The extension
> >                  * stuff needs an implementation in boot/extension.c so it is
> >                  * separate from the command code. Really the extension stuff
> >                  * should use the device tree and a uclass / driver interface
> >                  * rather than implementing its own list
> >                  */
> > "
>
> I agreed that the extension implementation should move in boot/extension.c or
> common for general use. I am wondering what the advantage of creating an uclass
> interface?
> I am not an uclass expert but there is no per driver ops and usage. What do you
> dislike about using its own list?

I looked at this briefly for bootstd and left it alone, partly for this reason.

The operations I know about are:
- scan for extension boards to produce a list: needs to happen at
start of 'bootflow scan' I think)
- applying relevant overlays: needs to happen in the read_bootflow()
method perhaps
- listing available extensions

I think a uclass makes sense, along with separating out the
'extension' command from the actual functionality.

>
> > Another note at
> > https://elixir.bootlin.com/u-boot/latest/source/cmd/extension_board.c#L198
> >
> > "/* extensions should have a uclass - for now we use UCLASS_SIMPLE_BUS uclass
> > */"
> >
> > So are we better off implementing a class driver for extension stuff?
>
> I think the first point should be to move it in common or boot and makes it
> generic for using the extension function everywhere. I will let Simon answer
> about the uclass part.

I believe this relates to boot/

>
> Regards,

Regards,
Simon