Re: Board revision dependent settings in device tree/override tree?

yes, the devicetree was designed in the first place (this is ca 2000) to be
all about static initialization.

On Tue, Apr 2, 2024 at 8:53 AM Martin Roth <[email protected]> wrote:

> Hi all,We actually use Kconfig options and macros in the register settings
> now, though not widely:
>   `register "usb2_ports[CONFIG_CCD_PORT]"       = "USB2_PORT_MID(OC_SKIP)"`
>
> We've also discussed running the devicetrees through the C preprocessor,
> or introducing another method to allow for more configurability, though
> that's only for updating the generation of the data structures, not
> anything configurable at runtime.
>
> Another thing that has been discussed, though probably not as much is
> having multiple devicetrees, or even parts of devicetrees and selecting
> between them at runtime. This could be useful to make board variants that
> all work with a single firmware image.
> Adding any sort of runtime configuration to devicetree would be
> significantly more difficult. The devicetree structure is just data, with
> no way to have it run any code. It's used in all of the various stages,
> some of which can be XIP, so it's not like it could even just contain a
> pointer to a function.
>
> Typically, if there's something based on the devicetree that might need to
> be updated at runtime, we just use a flag for an "auto" or "default"
> setting that gets the value from somewhere else when we're running code
> based on the devicetree. I think that's probably what we want to continue
> for any sort of runtime configuration.
> Martin
> Apr 2, 2024, 09:12 by [email protected]:
>
> > I'll probably regret mentioning this, but recall that the register code
> is, by design, C. So if you look at that CL, you see this
> > .vnn_supported_voltage_bitmap = FIVR_VOLTAGE_MIN_ACTIVE,
> > that could also be a macro.
> >
> > As Matt mentions, it's not something you can know at build time, so it's
> hard to see a way to use it.
> >
> > On Tue, Apr 2, 2024 at 5:39 AM Matt DeVillier <>
> [email protected]> > wrote:
> >
> >> hi Paul,
> >>
> >> I think the patch does it the right way, we want to minimize the amount
> of conditionals in the devicetree, it's supposed to be a static
> representation of the board hardware. These are just FSP UPDs that are
> being set anyway.
> >>
> >> In this case, the board ID is read from an EEPROM (CBI) by the EC, so
> I'm not sure that would be available early enough to conditionally set the
> devicetree params anyway.
> >>
> >> regards,
> >> Matt
> >>
> >> On Tue, Apr 2, 2024 at 4:38 AM Paul Menzel <>> [email protected]>>
> > wrote:
> >>
> >>> Dear coreboot folks,
> >>>
> >>>
> >>>  Change-set *mb/google/nissa/var/craaskov: Disable external fivr* [1]
> >>>  moves the settings for the external fully integrated voltage
> regulator
> >>>  (FIVR) out of device tree/override tree to only apply it to board
> >>>  revision with an external FIVR.
> >>>
> >>>  Is there a way to support conditions in device tree?
> >>>
> >>>
> >>>  Kind regards,
> >>>
> >>>  Paul
> >>>
> >>>
> >>>  [1]: >>> https://review.coreboot.org/c/coreboot/+/81607
> >>>  _______________________________________________
> >>>  coreboot mailing list -- >>> [email protected]
> >>>  To unsubscribe send an email to >>> [email protected]
> >>>
> >> _______________________________________________
> >>  coreboot mailing list -- >> [email protected]
> >>  To unsubscribe send an email to >> [email protected]
> >>
>
>

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]