On Tue, May 07, 2024 at 08:17:02PM +0200, Francesco Dolcini wrote:
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:
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.
In EBBR terms there *is* only firmware and OS. One of these is required know something about the baseboard the SoM has been mounted in. Given we want to support generic OSs that are not tied to a specific board then the knowledge of what baseboard is connected *must* be the firmware[1].
However, EBBR does not require the firmware to be monolithic, only that the firmware passes a DT to the OS.
That means that a firmware implementation for a SoM can be designed to allow alternative DTs to be provisioned when different baseboards are connected. For example, it could be configured to load the DT from a small firmware-specific filesystem that can be provisioned by the baseboard designer.
However I'd be inclined to view this as an implementation decision rather than something that needs to be standardized for EBBR. When working with a SoM, I expect the SoM vendor to supply firmware sources so I can tweak the firmware to directly support the new baseboard.
Daniel.
[1]: Even if the generic OS contains mechanisms to augment or load an alternative DT it still requires the firmware to tell it what baseboard is connected somehow (elsewhere in this thread we talk about using the DT root node compatible string for that).