Hello Tom, On Mon, May 06, 2024 at 05:05:25PM -0600, Tom Rini wrote: > On Mon, May 06, 2024 at 01:13:00PM +0200, Francesco Dolcini wrote: > > Hello all, > > > > On Wed, May 01, 2024 at 09:18:01PM +0000, Humphreys, Jonathan wrote: > > > Problem statement: > > > ================== > > > > > > Device trees are in theory a pure description of the hardware, and since > > > the hardware > > > doesn't change, the device tree describing the hardware likewise never > > > changes. > > > With this, a device tree could then be burned into the hardware's ROM to > > > be > > > queried by software for hardware discovery. > > > > I would like to add another use case that I do not see mentioned here. > > > > In case of SoM (System On Module) the system can be designed in such a > > way that the firmware does not really need to know the complete hardware > > description, but only the hardware subset relevant for booting and > > the initial hardware configuration is required. > > > > However the operating system would need the complete hardware > > description, that is made of a SoM plus a carrier/base board, to properly > > work. > > > > From a life cycle point of view the firmware of the SoM is going to be > > available and written to the board before the actual whole hardware is > > even existing and I would not expect to force the SoM user to > > update/customize the firmware. > > FWIW, my expectation and experiences are the opposite. Using the > firmware stack for the SoM unmodified and expecting the OS to get to and > then use the correct device tree isn't likely. I'm sure there will be > cases where it can (and does today) work, but that's not going to be the > case every time.
I am not sure I was able to understand what you mean, or maybe I was not clear on my explanation, let me try to _exemplify_ this. SOM hardware, let's assume this SOM is made of SOC/PMIC/RAM/FLASH, all the available pins/functionality are routed to some connector. The boot firmware can be implemented with only the on-SOM functionality. It does not need anything else. This SOM is then used in a complete system that is for example adding an ADC in some non-discoverable bus (I2C? SPI? ...), implemented in a base/carrier board. Now the OS *needs* to be told about this ADC device, and in this context this means DT. My experience is that the firmware is not going to be modified to handle this need, however in some way we need to provide the DT blob to the OS. The fact that we have DT overlays available as an implementation building block is not solving the issue there, since they need to come from somewhere, and in my example here, it would not be the firmware. IMO this is a very important use case for SOM vendors and I do not know how this would be addressed within the EBBR framework. Francesco _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
