[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/31] passage: Define a standard for firmware data flow

From: François Ozog
Subject: Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Date: Mon, 1 Nov 2021 21:45:19 +0100

Hi Mark,

Le lun. 1 nov. 2021 à 19:19, Mark Kettenis <mark.kettenis@xs4all.nl> a écrit :
> From: François Ozog <francois.ozog@linaro.org>
> Date: Mon, 1 Nov 2021 09:53:40 +0100


> We could further leverage Passage to pass Operating Systems parameters that
> could be removed from device tree (migration of /chosen to Passage). Memory
> inventory would still be in DT but allocations for CMA or GPUs would be in
> Passage. This idea is to reach a point where  device tree is a "pristine"
> hardware description.

I wanted to react on something you said in an earlier thread, but this
discussion seems to be appropriate as well:

The notion that device trees only describe the hardware isn't really
correct.  Device trees have always been used to configure firmware
options (through the /options node) and between firmware and the OS
(through the /chosen node) and to describe firmware interfaces
(e.g. OpenFirmware calls, PSCI (on ARM), RTAS (on POWER)).  This was
the case on the original Open Firmware systems, and is still done on
PowerNV systems that use flattened device trees.

I understand and agree with the above. 
Yet, PSCI is different from /options and /chosen: those are platform services made available to the OS when the boot firmware code has been unloaded/neutralized.

What I (not just myself but let’s simplify) am trying to decouple the supply chain: loosely coupled platform provider (ODM), the firmware provider, OS provider, application provider. So it is not to prevent presence of those existing nodes, it is to be able introduce some rationalization in their use:

Platform interfaces such as PSCI: The question is “who” injects them in the DT (build time or runtime). There is no single good answer and you may want the authoritative entity that implements the service to actually inject itself in the DT passed to the OS. I know some platforms are using SMC calls from U-Boot to know what to inject in the DT. I see those as the same nature of DIMM sensing and injection in the DT.

/chosen:  a must have when you do not have UEFI but not necessary with UEFI.

/options: it should be possible for the end customer to make the decision of integration: at build time or at runtime based on a separate flattened device tree file.

This decoupling should result for instance, in the long run, in adjustable memory layouts without headaches. changing the secure dram size is simple from hardware perspective but a massive issue from a firmware perspective: multiple firmware projects sources need to be adjusted, making manual calculations on explicit constants or “hidden” ones. It should even be possible to adjust it at runtime on the field (user selected firmware parameter).

I don't see what the benefits are from using Passage instead.  It
would only fragment things even more.
François-Frédéric Ozog | Director Business Development
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

reply via email to

[Prev in Thread] Current Thread [Next in Thread]