From: "François Ozog" <francois.ozog@linaro.org> To: Mark Kettenis <mark.kettenis@xs4all.nl> Cc: albert.u.boot@aribaud.net, bill.mills@linaro.org, bmeng.cn@gmail.com, ilias.apalodimas@linaro.org, marex@denx.de, morpheus.ibis@gmail.com, qemu-devel@nongnu.org, sjg@chromium.org, trini@konsulko.com, u-boot@lists.denx.de, vanbaren@cideas.com, xypron.glpk@gmx.de, yamada.masahiro@socionext.com Subject: Re: [PATCH 00/31] passage: Define a standard for firmware data flow Date: Mon, 1 Nov 2021 21:45:19 +0100 [thread overview] Message-ID: <CAHFG_=WNHyhHj+RCJOMz89wEW50grYv_veKTfnGTRG0ZEKQ4oA@mail.gmail.com> (raw) In-Reply-To: <d3caa60fcbd1a482@bloch.sibelius.xs4all.nl> 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
WARNING: multiple messages have this Message-ID (diff)
From: "François Ozog" <francois.ozog@linaro.org> To: Mark Kettenis <mark.kettenis@xs4all.nl> Cc: marex@denx.de, albert.u.boot@aribaud.net, trini@konsulko.com, yamada.masahiro@socionext.com, xypron.glpk@gmx.de, bill.mills@linaro.org, ilias.apalodimas@linaro.org, qemu-devel@nongnu.org, u-boot@lists.denx.de, vanbaren@cideas.com, sjg@chromium.org, bmeng.cn@gmail.com, morpheus.ibis@gmail.com Subject: Re: [PATCH 00/31] passage: Define a standard for firmware data flow Date: Mon, 1 Nov 2021 21:45:19 +0100 [thread overview] Message-ID: <CAHFG_=WNHyhHj+RCJOMz89wEW50grYv_veKTfnGTRG0ZEKQ4oA@mail.gmail.com> (raw) In-Reply-To: <d3caa60fcbd1a482@bloch.sibelius.xs4all.nl> [-- Attachment #1: Type: text/plain, Size: 3075 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 6347 bytes --]
next prev parent reply other threads:[~2021-11-01 20:45 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-01 1:17 [PATCH 00/31] passage: Define a standard for firmware data flow Simon Glass 2021-11-01 1:17 ` Simon Glass 2021-11-01 1:17 ` [PATCH 01/31] Makefile: Correct TPL rule for OF_REAL Simon Glass 2021-11-01 6:54 ` Ilias Apalodimas 2021-11-14 0:34 ` Simon Glass 2021-11-01 1:17 ` [PATCH 02/31] kconfig: Add support for conditional values Simon Glass 2021-11-01 7:05 ` Ilias Apalodimas 2022-01-12 21:28 ` Simon Glass 2022-01-12 21:56 ` Tom Rini 2022-01-12 22:22 ` Simon Glass 2022-01-12 23:04 ` Tom Rini 2022-01-13 7:56 ` Rasmus Villemoes 2022-01-13 12:52 ` Tom Rini 2022-01-13 13:56 ` Simon Glass 2022-01-13 15:01 ` Rasmus Villemoes 2022-01-13 15:29 ` Tom Rini 2021-11-01 1:17 ` [PATCH 03/31] dm: core: Allow getting some basic stats Simon Glass 2021-11-01 7:07 ` Ilias Apalodimas 2021-11-01 1:17 ` [PATCH 04/31] stddef: Avoid warning with clang with offsetof() Simon Glass 2022-01-13 8:08 ` Rasmus Villemoes 2022-01-13 13:07 ` Tom Rini 2022-01-13 13:37 ` Simon Glass 2022-01-13 13:41 ` Tom Rini 2022-01-13 13:50 ` Simon Glass 2021-11-01 1:17 ` [PATCH 05/31] fdt: Drop SPL_BUILD macro Simon Glass 2021-11-01 7:42 ` Ilias Apalodimas 2021-11-01 1:17 ` [PATCH 06/31] bloblist: Put the magic number first Simon Glass 2021-11-01 1:17 ` [PATCH 07/31] bloblist: Rename the SPL tag Simon Glass 2021-11-01 1:17 ` [PATCH 08/31] bloblist: Drop unused tags Simon Glass 2021-11-01 1:17 ` [PATCH 09/31] bloblist: Use explicit numbering for the tags Simon Glass 2021-11-01 1:17 ` [PATCH 10/31] bloblist: Support allocating the bloblist Simon Glass 2021-11-01 1:17 ` [PATCH 11/31] bloblist: Use LOG_CATEGORY to simply logging Simon Glass 2021-11-01 1:17 ` [PATCH 12/31] bloblist: Use 'phase' consistently for bloblists Simon Glass 2021-11-01 1:17 ` [PATCH 13/31] bloblist: Refactor Kconfig to support alloc or fixed Simon Glass 2021-11-01 1:17 ` [PATCH 14/31] arm: qemu: Add an SPL build Simon Glass 2021-11-01 1:17 ` Simon Glass 2021-11-01 1:17 ` [PATCH 15/31] bloblist: Add functions to obtain base address and size Simon Glass 2021-11-01 1:17 ` [PATCH 16/31] passage: Support an incoming passage Simon Glass 2021-11-01 1:17 ` [PATCH 17/31] passage: Support a control devicetree Simon Glass 2021-11-01 1:17 ` [PATCH 18/31] passage: arm: Accept a passage from the previous phase Simon Glass 2021-11-01 1:17 ` [PATCH 19/31] passage: spl: Support adding the dtb to the passage bloblist Simon Glass 2021-11-01 1:17 ` [PATCH 20/31] passage: spl: Support passing the passage to U-Boot Simon Glass 2021-11-01 1:17 ` [PATCH 21/31] passage: Record where the devicetree came from Simon Glass 2021-11-01 1:17 ` [PATCH 22/31] passage: Report the devicetree source Simon Glass 2021-11-01 1:17 ` [PATCH 23/31] passage: Add a qemu test for ARM Simon Glass 2021-11-01 1:17 ` [PATCH 24/31] bloblist: doc: Bring in the API documentation Simon Glass 2021-11-01 1:17 ` [PATCH 25/31] bloblist: Relicense to allow BSD-3-Clause Simon Glass 2021-11-01 1:17 ` [PATCH 26/31] sandbox: Add a way of checking structs for standard passage Simon Glass 2021-11-01 1:17 ` [PATCH 27/31] passage: Add documentation Simon Glass 2021-11-01 1:17 ` [PATCH 28/31] passage: Add docs for spl_handoff Simon Glass 2021-11-01 1:17 ` [PATCH 29/31] x86: Move Intel GNVS file into the common include directory Simon Glass 2021-11-01 1:17 ` [PATCH 30/31] passage: Add checks for pre-existing blobs Simon Glass 2021-11-01 1:17 ` [PATCH 31/31] WIP: RFC: Add a gitlab test Simon Glass 2021-11-01 8:53 ` [PATCH 00/31] passage: Define a standard for firmware data flow François Ozog 2021-11-01 8:53 ` François Ozog 2021-11-01 18:19 ` Mark Kettenis 2021-11-01 18:19 ` Mark Kettenis 2021-11-01 20:45 ` François Ozog [this message] 2021-11-01 20:45 ` François Ozog 2021-11-02 14:58 ` Simon Glass 2021-11-02 14:58 ` Simon Glass 2021-11-02 16:03 ` François Ozog 2021-11-02 16:03 ` François Ozog 2021-11-05 2:02 ` Simon Glass 2021-11-05 2:02 ` Simon Glass 2021-11-05 8:26 ` François Ozog 2021-11-05 8:26 ` François Ozog 2021-11-05 16:12 ` Simon Glass 2021-11-05 16:12 ` Simon Glass 2021-11-05 16:31 ` François Ozog 2021-11-05 16:31 ` François Ozog 2021-11-05 17:16 ` Simon Glass 2021-11-05 17:16 ` Simon Glass 2021-11-08 16:20 ` François Ozog 2021-11-08 16:20 ` François Ozog 2021-11-10 19:37 ` Simon Glass 2021-11-10 19:37 ` Simon Glass
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHFG_=WNHyhHj+RCJOMz89wEW50grYv_veKTfnGTRG0ZEKQ4oA@mail.gmail.com' \ --to=francois.ozog@linaro.org \ --cc=albert.u.boot@aribaud.net \ --cc=bill.mills@linaro.org \ --cc=bmeng.cn@gmail.com \ --cc=ilias.apalodimas@linaro.org \ --cc=marex@denx.de \ --cc=mark.kettenis@xs4all.nl \ --cc=morpheus.ibis@gmail.com \ --cc=qemu-devel@nongnu.org \ --cc=sjg@chromium.org \ --cc=trini@konsulko.com \ --cc=u-boot@lists.denx.de \ --cc=vanbaren@cideas.com \ --cc=xypron.glpk@gmx.de \ --cc=yamada.masahiro@socionext.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.