Hello Rob,
thanks for the follow up. I still have a couple questions for you
before I see a clear direction forward, see below.
On Wed, 5 Jun 2024 08:45:31 -0600
Rob Herring <robh@xxxxxxxxxx> wrote:
[...]
> > > > + # "base" overlay describing the common components on every add-on that
> > > > + # are required to read the model ID
> > >
> > > This is located on the add-on board, right?
> >
> > Exactly. Each add-on has an EEPROM with the add-on model ID stored
> > along with other data.
> >
> > > Is it really any better to have this as a separate overlay rather than
> > > just making it an include? Better to have just 1 overlay per board
> > > applied atomically than splitting it up.
> >
> > (see below)
> >
> > > > + - |
> > > > + &i2c1 {
> > >
> > > Generally, I think everything on an add-on board should be underneath
> > > the connector node. For starters, that makes controlling probing and
> > > removal of devices easier. For example, you'll want to handle
> > > reset-gpios and powergood-gpios before any devices 'appear'. Otherwise,
> > > you add devices on i2c1, start probing them, and then reset them at some
> > > async time?
> >
> > This is not a problem because the code is asserting reset before
> > loading the first overlay. From patch 5/5:
>
> What if the bootloader happened to load the overlay already? Or you
> kexec into a new kernel?
When an overlay is loaded by the bootloader, IIRC it becomes an
integral part of the live device tree and is not removable anymore.
This does not make sense for a physically removable add-on: as the
add-on can be physically removed, its device tree representation must
be removable as well.
And the main board is able to work autonomously without the add-on, so
I don't see any reason for loading the overlay in the bootloader.
For the kexec case, the main use cases I can think of involves 'kexec
--dtb=...' to loads its own copy of the base DT (without overlays). So
everything will probe again, and the overlays will be loaded again
by the connector driver if/whan the add-on is connected.
And if there are use cases of kexec when the 2nd kernel finds the DT
with the overlays already loaded, this is just as wrong as in the
bootloader case.
> Keeping things underneath a connector node makes managing the
> dependencies easier. It also can allow us to have some control over what
> overlays can and can't modify. It also reflects reality that these
> devices sit behind the connector.
