Hi Tom,

On Wed, 12 Jan 2022 at 14:56, Tom Rini trini@konsulko.com wrote:

On Wed, Jan 12, 2022 at 02:28:21PM -0700, Simon Glass wrote:

...

Hi Ilias,

On Mon, 1 Nov 2021 at 01:05, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:

...

On Mon, 1 Nov 2021 at 03:19, Simon Glass sjg@chromium.org wrote:

...

At present if an optional Kconfig value needs to be used it must be bracketed by #ifdef. For example, with this Kconfig setup:

config WIBBLE bool "Support wibbles, the world needs more wibbles"

config WIBBLE_ADDR hex "Address of the wibble" depends on WIBBLE

then the following code must be used:

#ifdef CONFIG_WIBBLE static void handle_wibble(void) { int val = CONFIG_WIBBLE_ADDR;

    ...

} #endif

The example here might be a bit off and we might need this for int related values. Was this function handle_wibble() supposed to return an int or not? We could shield the linker easier here without adding macros. Something along the lines of static void handle_wibble(void) { #ifdef CONFIG_WIBBLE int val = CONFIG_WIBBLE_ADDR; #endif }

In that case you don't an extra ifdef to call handle_wibble(). Personally I find this easier to read.

But how does that help with the problem here? I am trying to avoid using preprocessor macros in this case.

I'm not sure I see a problem here. A number of the finish-converting-X that I did recently had a guard symbol first because usage wasn't fully converted but really everyone using that area of code needed to set the value, or use the default.

There might be some cases where we do still need a guard symbol because usage is in common code and maybe shouldn't be, but instead moved to other usage-specific files.

I also think I've seen cases where doing: if (CONFIG_EVALUATES_TO_ZERO) { ... }

takes more space in the binary than an #ifdef does.

I'd like to see that.

And finally for the moment, we also have many cases where zero is a valid value. That's what leads to potentially harder to read code or needing a guard, I think.

The specific case where this is (to be) used is here:

https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-14-s...

addr = IF_ENABLED_INT(CONFIG_BLOBLIST_FIXED, CONFIG_BLOBLIST_ADDR);

This is because BLOBLIST_ADDR depends on BLOBLIST_FIXED (it is meaningless to have an address if the bloblits is allocated).

One fix is to always have an address, and set it to 0 by default (and not use it) when BLOBLIST_FIXED is not enabled.

But it does lead to a strange Kconfig since options are present which are not really used.

Another option is to add an accessor to the header file, as is down with global_data (e.g. as is done with gd_of_root()).

Thoughts?

Regards, Simon

On 12/01/2022 22.56, Tom Rini wrote:

On Wed, Jan 12, 2022 at 02:28:21PM -0700, Simon Glass wrote:

...

Hi Ilias,

On Mon, 1 Nov 2021 at 01:05, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:

...

On Mon, 1 Nov 2021 at 03:19, Simon Glass sjg@chromium.org wrote:

...

At present if an optional Kconfig value needs to be used it must be bracketed by #ifdef. For example, with this Kconfig setup:

config WIBBLE bool "Support wibbles, the world needs more wibbles"

config WIBBLE_ADDR hex "Address of the wibble" depends on WIBBLE

then the following code must be used:

#ifdef CONFIG_WIBBLE static void handle_wibble(void) { int val = CONFIG_WIBBLE_ADDR;

    ...

} #endif

The example here might be a bit off and we might need this for int related values. Was this function handle_wibble() supposed to return an int or not? We could shield the linker easier here without adding macros. Something along the lines of static void handle_wibble(void) { #ifdef CONFIG_WIBBLE int val = CONFIG_WIBBLE_ADDR; #endif }

In that case you don't an extra ifdef to call handle_wibble(). Personally I find this easier to read.

But how does that help with the problem here? I am trying to avoid using preprocessor macros in this case.

I'm not sure I see a problem here. A number of the finish-converting-X that I did recently had a guard symbol first because usage wasn't fully converted but really everyone using that area of code needed to set the value, or use the default.

There might be some cases where we do still need a guard symbol because usage is in common code and maybe shouldn't be, but instead moved to other usage-specific files.

I also think I've seen cases where doing: if (CONFIG_EVALUATES_TO_ZERO) { ... }

takes more space in the binary than an #ifdef does.

Please provide a specific example. If CONFIG_EVALUATES_TO_ZERO is any integer-constant-expression evaluating at compile-time to 0, gcc throws away the whole block very early during parsing. If it doesn't, that's a compiler bug, so let's please not make decisions based on not-even-anecdotal data.

And finally for the moment, we also have many cases where zero is a valid value. That's what leads to potentially harder to read code or needing a guard, I think.

I like Simon's idea, but the replacement/fallback should _not_ be a literal 0. We want a guarantee that the code has actually been discarded by the compiler or linker (i.e., that the access is done in code that is otherwise guarded by the "parent" Kconfig symbol), so instead the fallback should be a call to (the nowhere defined of course)

extern long invalid_use_of_IF_ENABLED_INT(void);

Of course, if people don't build with -O2 and -ffunction-sections,-fdata-sections and link with --gc-sections, that may break, but why should we care?

Rasmus

Hi,

On Thu, 13 Jan 2022 at 05:52, Tom Rini trini@konsulko.com wrote:

On Thu, Jan 13, 2022 at 08:56:02AM +0100, Rasmus Villemoes wrote:

...

On 12/01/2022 22.56, Tom Rini wrote:

...

On Wed, Jan 12, 2022 at 02:28:21PM -0700, Simon Glass wrote:

...

Hi Ilias,

On Mon, 1 Nov 2021 at 01:05, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:

...

On Mon, 1 Nov 2021 at 03:19, Simon Glass sjg@chromium.org wrote:

...

At present if an optional Kconfig value needs to be used it must be bracketed by #ifdef. For example, with this Kconfig setup:

config WIBBLE bool "Support wibbles, the world needs more wibbles"

config WIBBLE_ADDR hex "Address of the wibble" depends on WIBBLE

then the following code must be used:

#ifdef CONFIG_WIBBLE static void handle_wibble(void) { int val = CONFIG_WIBBLE_ADDR;

    ...

} #endif

The example here might be a bit off and we might need this for int related values. Was this function handle_wibble() supposed to return an int or not? We could shield the linker easier here without adding macros. Something along the lines of static void handle_wibble(void) { #ifdef CONFIG_WIBBLE int val = CONFIG_WIBBLE_ADDR; #endif }

In that case you don't an extra ifdef to call handle_wibble(). Personally I find this easier to read.

But how does that help with the problem here? I am trying to avoid using preprocessor macros in this case.

I'm not sure I see a problem here. A number of the finish-converting-X that I did recently had a guard symbol first because usage wasn't fully converted but really everyone using that area of code needed to set the value, or use the default.

There might be some cases where we do still need a guard symbol because usage is in common code and maybe shouldn't be, but instead moved to other usage-specific files.

I also think I've seen cases where doing: if (CONFIG_EVALUATES_TO_ZERO) { ... }

takes more space in the binary than an #ifdef does.

Please provide a specific example. If CONFIG_EVALUATES_TO_ZERO is any integer-constant-expression evaluating at compile-time to 0, gcc throws away the whole block very early during parsing. If it doesn't, that's a compiler bug, so let's please not make decisions based on not-even-anecdotal data.

OK. I believe it was commit 7856cd5a6dd6 ("Convert CONFIG_SYS_PCI_64BIT to Kconfig") a few platforms changed size and as best I can tell, the used / evaluated value for CONFIG_SYS_PCI_64BIT didn't change.

...

...

And finally for the moment, we also have many cases where zero is a valid value. That's what leads to potentially harder to read code or needing a guard, I think.

I like Simon's idea, but the replacement/fallback should _not_ be a literal 0. We want a guarantee that the code has actually been discarded by the compiler or linker (i.e., that the access is done in code that is otherwise guarded by the "parent" Kconfig symbol), so instead the fallback should be a call to (the nowhere defined of course)

extern long invalid_use_of_IF_ENABLED_INT(void);

Of course, if people don't build with -O2 and -ffunction-sections,-fdata-sections and link with --gc-sections, that may break, but why should we care?

LTO also gets this correct I assume and yes, I like that better.

Yes it should work fine and it checks there is no effective access, which is nice.

For now I'm going ahead with the bloblist series without this, but I'll send an updated patch on its own.

Regards, Simon

On Thu, Jan 13, 2022 at 04:01:45PM +0100, Rasmus Villemoes wrote:

On 13/01/2022 13.52, Tom Rini wrote:

...

On Thu, Jan 13, 2022 at 08:56:02AM +0100, Rasmus Villemoes wrote:

...

On 12/01/2022 22.56, Tom Rini wrote:

...

I also think I've seen cases where doing: if (CONFIG_EVALUATES_TO_ZERO) { ... }

takes more space in the binary than an #ifdef does.

Please provide a specific example. If CONFIG_EVALUATES_TO_ZERO is any integer-constant-expression evaluating at compile-time to 0, gcc throws away the whole block very early during parsing. If it doesn't, that's a compiler bug, so let's please not make decisions based on not-even-anecdotal data.

OK. I believe it was commit 7856cd5a6dd6 ("Convert CONFIG_SYS_PCI_64BIT to Kconfig") a few platforms changed size

Can you remember which ones? I'd like to see if I can reproduce.

That said, that commit made the Kconfig symbol 'default y if PPC'. Are you really sure all ppc-boards that set CONFIG_PCI also used to set SYS_PCI_64BIT?

And another thing I notice is that a lot of the #define removals remove

#define CONFIG_SYS_PCI_64BIT

and not

#define CONFIG_SYS_PCI_64BIT 1

Now that doesn't matter for the places that test the definedness of CONFIG_SYS_PCI_64BIT, because kconfig either doesn't define it or define it with value 1. But it does matter for (the single) IS_ENABLED() use, because IS_ENABLED(bla) evaluates to 1 if and only if bla expands to 1. Or rather, if and only if __ARG_PLACEHOLDER_ concatenated with the expansion of bla in turn expands to "0, " - which only happens if we hit the __ARG_PLACEHOLDER_1 macro.

So when bla is defined with an empty expansion, for the purpose of IS_ENABLED, it might as well not be defined or expand to 0 or to gobbledygook.

And when one knows what to look for, it's easy to demonstrate:

$ export ARCH=ppc $ export CROSS_COMPILE=powerpc-linux-gnu- $ git checkout 7856cd5a6dd6~1 $ make T1042D4RDB_defconfig $ make drivers/pci/pci-uclass.i $ grep -C3 'beyond the 32-bit boundary' drivers/pci/pci-uclass.i

if (!(0) && type == 0x00000000 && ((u32)(((pci_addr) >> 16) >> 16))) { ({ if (0) printf(" - beyond the 32-bit boundary, ignoring\n"); }); continue; }

$ git checkout 7856cd5a6dd6 $ make T1042D4RDB_defconfig $ make drivers/pci/pci-uclass.i $ grep -C3 'beyond the 32-bit boundary' drivers/pci/pci-uclass.i

if (!(1) && type == 0x00000000 && ((u32)(((pci_addr) >> 16) >> 16))) { ({ if (0) printf(" - beyond the 32-bit boundary, ignoring\n"); }); continue; }

Whether that change makes the generated code smaller or larger I can't say, but it's certainly not a nop semantically. [Of course, the change is for the better, as the generated code now matches the intention; previously 64 bit pci addresses would be ignored for the boards that had an empty definition of CONFIG_SYS_PCI_64BIT.]

But it has nothing whatsoever to do with whether gcc is capable of throwing away a whole "if (0)" block. But I will believe that other Kconfig conversions have been bit by the same issue, making it _seem_ like IS_ENABLED() is somehow at fault and #ifdefs are "better".

Yes, that's what happened there, thanks for digging in and explaining. What I really meant by "better" was "same size when converting" which is important when migrating a ton of machines I can only very partially test.

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 don't see what the benefits are from using Passage instead. It would only fragment things even more.

Hi François,

On Mon, 1 Nov 2021 at 02:53, François Ozog francois.ozog@linaro.org wrote:

Hi Simon,

this seems a great endeavor. I'd like to better understand the scope of it.

Is it to be used as part of what could become a U-Boot entry ABI scheme? By that I mean giving some fixed aspects to U-Boot entry while letting boards to have flexibility (say for instance that the first 5 architecture ABI parameter registers are reserved for U-Boot), and the Passage is about specifying either those reserved registers or one of them?

The goal is to provide a standard entry scheme for all firmware binaries. Whether it achieves that (or can with some mods) is up for discussion.

Re the registers, do you think we need 5?

Thinking entry ABI, here is what I observed on Arm:

Linux has two entry ABIs:

• plain: x0 = dtb; command line = dtb:/chosen/bootargs; initrd = dtb:/chosen/linux,initrd-*
• EFI: x0=handle, x1=systemtable, x30=return address; dtb = EFI_UUID config table; initrd = efi:<loadfile2(INITRD vendor media UUID); command line = efi: image_protocol::load_options

U-Boot (proper) has plenty of schemes:

• dtb is passed as either x0, x1, fixed memory area (Qemu which is bad in itself), or other registers
• additional information passing: board specific register scheme, SMC calls
• U-Boot for RPI boards implement a Linux shaped entry ABI to be launched by Videocore firmware

Based on all the above, I would tend to think that RPI scheme is a good idea but also shall not prevent additional schemes for the boards.

I was not actually considering Linux since I believe/assume its entry scheme is fixed and not up for discussion.

I also did not think about the EFI case. As I understand it we cannot touch it as it is used by UEFI today. Maybe it is even in the standard?

Really I am hoping we can start afresh...?

What about a U-Boot Arm entry ABI like:

• plain: x0=dtb, x1=<Passage defined>, x2-x5 = <reserved>, other registers are per platform, SMC calls allowed too

Hmm we don't actually need the dtb as it is available in the bloblist. But I added an offset to it as a convenience.

• EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is launched as an EFI app) dtb = EFI_UUID config table, + Passage = Passage UUID config table

I don't understand the last line. Where is the passage info / bloblist? Do you mean it goes in the HOB list with a UUID? I suppose that is the most EFI-compatible way.

What do you think about the idea of using an offset into the bloblist for the dtb? Also, can we make the standard passage ABI a build-time option, so it is deterministic?

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'm worried about this becoming a substitute for devicetree. Really my intent is to provide a way to pass simple info, whereas what you talk about there seems like something that should be DT, just that it might need suitable bindings.

As you know I have more expansive views about what should be in DT.

Cheers

PS: as Ilias mentions, this patch set contains bug fixes, non immediately related additional functions (DM stats). It would be great to carve those out to fast path them and keep this one with the very core of your idea.

The DM stats is used in 'passage: Report the devicetree source'. I know it is sideways but I think it is better to make the output line more useful than just reporting the devicetree source.

The first patch is indeed unrelated. I will pick it up so we can drop it for the next rev.

Regards, Simon

On Mon, 1 Nov 2021 at 02:17, Simon Glass sjg@chromium.org wrote:

...

This series adds a standard way of passing information between different firmware phases. This already exists in U-Boot at a very basic level, in the form of a bloblist containing an spl_handoff structure, but the intent here is to define something useful across projects.

The need for this is growing as firmware fragments into multiple binaries each with its own purpose. Without any run-time connection, we must rely on build-time settings which are brittle and painful to keep in sync.

This feature is named 'standard passage' since the name is more unique than many others that could be chosen, it is a passage in the sense that information is flowing from one place to another and it is standard, because that is what we want to create.

The implementation is simply a pointer to a bloblist in a register, with an extra register to point to a devicetree, for more complex data, if one is present in the bloblist. This should cover all cases (small memory footprint as well as complex data flow) and be easy enough to implement on all architectures.

The core bloblist code is relicensed to BSD-3-Clause in case it is useful in non-GPL projects but there is no requirement to use the same code.

This series includes tweaks to the bloblist implementation in U-Boot to make it more suitable for the task, including:

• Allocate tags explicitly in the enum
• Put the magic number first
• Define a process for adding tags

The emphasis is on enabling open communcation between binaries, not enabling passage of secret, undocumented data, although this is possible in a private environment.

This series is built on the OF_BOARD series It is available at u-boot-dm/pass-working or:

https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/073b5c156f222c69...

Simon Glass (31): Makefile: Correct TPL rule for OF_REAL kconfig: Add support for conditional values dm: core: Allow getting some basic stats stddef: Avoid warning with clang with offsetof() fdt: Drop SPL_BUILD macro bloblist: Put the magic number first bloblist: Rename the SPL tag bloblist: Drop unused tags bloblist: Use explicit numbering for the tags bloblist: Support allocating the bloblist bloblist: Use LOG_CATEGORY to simply logging bloblist: Use 'phase' consistently for bloblists bloblist: Refactor Kconfig to support alloc or fixed arm: qemu: Add an SPL build bloblist: Add functions to obtain base address and size passage: Support an incoming passage passage: Support a control devicetree passage: arm: Accept a passage from the previous phase passage: spl: Support adding the dtb to the passage bloblist passage: spl: Support passing the passage to U-Boot passage: Record where the devicetree came from passage: Report the devicetree source passage: Add a qemu test for ARM bloblist: doc: Bring in the API documentation bloblist: Relicense to allow BSD-3-Clause sandbox: Add a way of checking structs for standard passage passage: Add documentation passage: Add docs for spl_handoff x86: Move Intel GNVS file into the common include directory passage: Add checks for pre-existing blobs WIP: RFC: Add a gitlab test

.gitlab-ci.yml | 6 + MAINTAINERS | 10 + Makefile | 2 +- arch/arm/cpu/armv7/start.S | 7 +- arch/arm/dts/qemu-arm-u-boot.dtsi | 22 ++ arch/arm/lib/crt0.S | 4 + arch/arm/mach-qemu/Kconfig | 9 + arch/sandbox/cpu/spl.c | 2 +- arch/x86/cpu/apollolake/acpi.c | 2 +- arch/x86/cpu/broadwell/cpu_from_spl.c | 4 +- arch/x86/cpu/intel_common/acpi.c | 2 +- .../include/asm/arch-apollolake/global_nvs.h | 2 +- arch/x86/lib/spl.c | 2 +- arch/x86/lib/tpl.c | 2 +- board/emulation/qemu-arm/Kconfig | 23 +- board/emulation/qemu-arm/MAINTAINERS | 1 + board/emulation/qemu-arm/Makefile | 1 + board/emulation/qemu-arm/spl.c | 27 ++ board/google/chromebook_coral/coral.c | 2 +- board/sandbox/Makefile | 3 +- board/sandbox/stdpass_check.c | 107 ++++++ cmd/bdinfo.c | 2 + common/Kconfig | 161 ++++++++- common/bloblist.c | 124 +++++-- common/board_f.c | 48 ++- common/board_r.c | 18 + common/spl/spl.c | 74 +++- configs/qemu_arm_spl_defconfig | 78 +++++ doc/board/emulation/qemu-arm.rst | 38 +++ doc/develop/bloblist.rst | 28 +- doc/develop/index.rst | 1 + doc/develop/std_passage.rst | 319 ++++++++++++++++++ drivers/core/device.c | 11 + drivers/core/root.c | 7 + drivers/core/uclass.c | 13 + drivers/serial/serial-uclass.c | 3 +- dts/Kconfig | 12 + include/asm-generic/global_data.h | 35 ++ include/bloblist.h | 175 +++++++--- include/dm/device.h | 11 +- include/dm/root.h | 8 + include/dm/uclass-internal.h | 7 + include/fdtdec.h | 40 ++- include/handoff.h | 8 +- .../x86/include/asm => include}/intel_gnvs.h | 0 include/linux/kconfig.h | 18 + include/linux/stddef.h | 8 +- include/spl.h | 15 + include/stdpass/README | 4 + include/stdpass/tpm2_eventlog.h | 42 +++ include/stdpass/vboot_ctx.h | 267 +++++++++++++++ lib/asm-offsets.c | 5 + lib/fdtdec.c | 65 +++- scripts/config_whitelist.txt | 1 + test/bloblist.c | 21 +- test/dm/core.c | 41 +++ test/py/tests/test_passage.py | 11 + 57 files changed, 1798 insertions(+), 161 deletions(-) create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi create mode 100644 board/emulation/qemu-arm/spl.c create mode 100644 board/sandbox/stdpass_check.c create mode 100644 configs/qemu_arm_spl_defconfig create mode 100644 doc/develop/std_passage.rst rename {arch/x86/include/asm => include}/intel_gnvs.h (100%) create mode 100644 include/stdpass/README create mode 100644 include/stdpass/tpm2_eventlog.h create mode 100644 include/stdpass/vboot_ctx.h create mode 100644 test/py/tests/test_passage.py

-- 2.33.1.1089.g2158813163f-goog

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

Hi François,

On Tue, 2 Nov 2021 at 10:03, François Ozog francois.ozog@linaro.org wrote:

Hi Simon,

On Tue, 2 Nov 2021 at 15:59, Simon Glass sjg@chromium.org wrote:

...

Hi François,

On Mon, 1 Nov 2021 at 02:53, François Ozog francois.ozog@linaro.org wrote:

...

Hi Simon,

this seems a great endeavor. I'd like to better understand the scope of it.

Is it to be used as part of what could become a U-Boot entry ABI scheme? By that I mean giving some fixed aspects to U-Boot entry while letting boards to have flexibility (say for instance that the first 5 architecture ABI parameter registers are reserved for U-Boot), and the Passage is about specifying either those reserved registers or one of them?

The goal is to provide a standard entry scheme for all firmware binaries. Whether it achieves that (or can with some mods) is up for discussion.

If you say a) define a U-Boot entry ABI and providing a firmware-to-firmware information passing facility which would be part of all firmware ABIs (as the projects decide to define their own ABI) it looks good. but If you say

It is an ABI to be adopted by U-Boot but also other firmware. For example, if TF-A calls U-Boot it should use standard passage. If U-Boot calls TF-A or Optee it should use standard passage.

b) define a standard entry scheme (register map, processor state, MMU state, SMMU state, GIC state...) that does not look realistic.

No I don't mean that. This data structure could be used in any state, so long as the two registers are set correctly.

I think you mean a) but just want to be sure.

Yes I think so.

...

Re the registers, do you think we need 5?

I don't :-)

...

...

Thinking entry ABI, here is what I observed on Arm:

Linux has two entry ABIs:

• plain: x0 = dtb; command line = dtb:/chosen/bootargs; initrd = dtb:/chosen/linux,initrd-*
• EFI: x0=handle, x1=systemtable, x30=return address; dtb = EFI_UUID config table; initrd = efi:<loadfile2(INITRD vendor media UUID); command line = efi: image_protocol::load_options

U-Boot (proper) has plenty of schemes:

• dtb is passed as either x0, x1, fixed memory area (Qemu which is bad in itself), or other registers
• additional information passing: board specific register scheme, SMC calls
• U-Boot for RPI boards implement a Linux shaped entry ABI to be launched by Videocore firmware

Based on all the above, I would tend to think that RPI scheme is a good idea but also shall not prevent additional schemes for the boards.

I was not actually considering Linux since I believe/assume its entry scheme is fixed and not up for discussion.

I also did not think about the EFI case. As I understand it we cannot touch it as it is used by UEFI today. Maybe it is even in the standard?

It is in the spec and we are making it evolve, or its understanding evolve (jurisprudence) for instance on initrd standard handling.

Well perhaps we could merge it with standard passage. But EFI is not going to want to use a bloblist, it will want to use a HOB.

...

Really I am hoping we can start afresh...?

...

What about a U-Boot Arm entry ABI like:

• plain: x0=dtb, x1=<Passage defined>, x2-x5 = <reserved>, other registers are per platform, SMC calls allowed too

Hmm we don't actually need the dtb as it is available in the bloblist.

If you don't have x0=dtb, then you will not be able to use U-Boot on RPI4. Unless you want to redo everything the RPI firmware is doing.

That's right, RPI cannot support standard passage. It is not open-source firmware so it isn't really relevant to this discussion. It will just do what it does and have limited functionality, with work-arounds to deal with the pain, as one might expect.

...

But I added an offset to it as a convenience.

...

• EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is launched as an EFI app) dtb = EFI_UUID config table, + Passage = Passage UUID config table

I don't understand the last line. Where is the passage info / bloblist? Do you mean it goes in the HOB list with a UUID? I suppose that is the most EFI-compatible way.

The Passage config table could just contain the "head" of the bloblist/Passage information.

If UEFI wants to deal with standard passage, that is...

...

What do you think about the idea of using an offset into the bloblist for the dtb?

It is possible but as I said, failing to mimic Linux entry ABI would miss the opportunity to just boot without changes on RPI4.

See above. Broadcom could look at open-sourcing their bootloader if they wish.

...

Also, can we make the standard passage ABI a build-time option, so it is deterministic?

Looks good. I would look into stating that for SystemReady we would advise to use that option and make it standard for Trusted Substrate (Linaro recipes that we upstreaming to make SystemReady compliance easy and consistent across platforms).

OK. I mean that if the option is enabled, then standard passage must be provided / emitted or things won't work. If the option is disabled, then standard passage is not used. In other words, we are looking for magic values in registers, etc, just enabling/disabling it at build-time.

...

...

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'm worried about this becoming a substitute for devicetree. Really my intent is to provide a way to pass simple info, whereas what you talk about there seems like something that should be DT, just that it might need suitable bindings.

I see your point and I agree It should not be a substitute. here is an expanded version of what I had in mind when I wrote those lines. cma, initrd and other Linux kernel parameters can be conveyed either through command line or DT. When using the non UEFI Linux entry ABI, you need to use the DT to pass those parameters. When using the UEFI Linux entry ABI, you *can* (not must) use the command line to pass all information, leaving the DT passed to the OS without any /chosen. When introducing Passage, I was wondering if we could pass command line to Linux and, same as UEFI, leave the DT free from /chosen. I am not sure it is a good goal though. I may be too pushing for a DT free from parameters.

We could. Are there benefits to that?

I doubt we would pass the standard passage to Linux as a bloblist. I imagine something like this. The bloblist sits in memory with some things in it, including a devicetree, perhaps an SMBIOS table and a TPM log. But when U-Boot calls Linux it puts the address/size of those individual things in the devicetree. They don't move and are still contiguous in memory, but the bloblist around them is forgotten. Linux doesn't know that the three separate things it is picking up are actually part of a bloblist structure, since it doesn't care about that. Even a console log could work the same way. That way we don't end up trying to teach Linux about bloblist when it already has a perfectly good means to accept these items.

For ACPI I see things a similar way. The ACPI tables can point to things that *happen* to be in a bloblist, but without any knowledge of that needed in Linux, grub, etc.

...

As you know I have more expansive views about what should be in DT.

I think both of us are huge supporters of DT format and self describing capabilities. I am inclined to put rules into what fits into what lands in the DT that is passed to the OS. I am a fan of having DT used more in ad-hoc files.

Me too.

...

...

Cheers

PS: as Ilias mentions, this patch set contains bug fixes, non immediately related additional functions (DM stats). It would be great to carve those out to fast path them and keep this one with the very core of your idea.

The DM stats is used in 'passage: Report the devicetree source'. I know it is sideways but I think it is better to make the output line more useful than just reporting the devicetree source.

I believe the DM stats has merits in its own. You could upstream this independently and then Passage would be yet another "customer" of the feature.

I could, but it would just be a debug feature so people might not think it worth the code space. With the devicetree source it is more compelling.

...

The first patch is indeed unrelated. I will pick it up so we can drop it for the next rev.

[..]

Regards, Simon

Hi François,

On Fri, 5 Nov 2021 at 02:27, François Ozog francois.ozog@linaro.org wrote:

On Fri, 5 Nov 2021 at 03:02, Simon Glass sjg@chromium.org wrote:

...

Hi François,

On Tue, 2 Nov 2021 at 10:03, François Ozog francois.ozog@linaro.org wrote:

...

Hi Simon,

On Tue, 2 Nov 2021 at 15:59, Simon Glass sjg@chromium.org wrote:

...

Hi François,

On Mon, 1 Nov 2021 at 02:53, François Ozog francois.ozog@linaro.org wrote:

...

Hi Simon,

this seems a great endeavor. I'd like to better understand the scope of it.

Is it to be used as part of what could become a U-Boot entry ABI scheme? By that I mean giving some fixed aspects to U-Boot entry while letting boards to have flexibility (say for instance that the first 5 architecture ABI parameter registers are reserved for U-Boot), and the Passage is about specifying either those reserved registers or one of them?

The goal is to provide a standard entry scheme for all firmware binaries. Whether it achieves that (or can with some mods) is up for discussion.

If you say a) define a U-Boot entry ABI and providing a firmware-to-firmware information passing facility which would be part of all firmware ABIs (as the projects decide to define their own ABI) it looks good. but If you say

It is an ABI to be adopted by U-Boot but also other firmware. For example, if TF-A calls U-Boot it should use standard passage. If U-Boot calls TF-A or Optee it should use standard passage.

...

b) define a standard entry scheme (register map, processor state, MMU state, SMMU state, GIC state...) that does not look realistic.

No I don't mean that. This data structure could be used in any state, so long as the two registers are set correctly.

...

I think you mean a) but just want to be sure.

Yes I think so.

...

...

Re the registers, do you think we need 5?

I don't :-)

...

...

...

Thinking entry ABI, here is what I observed on Arm:

Linux has two entry ABIs:

• plain: x0 = dtb; command line = dtb:/chosen/bootargs; initrd = dtb:/chosen/linux,initrd-*
• EFI: x0=handle, x1=systemtable, x30=return address; dtb = EFI_UUID config table; initrd = efi:<loadfile2(INITRD vendor media UUID); command line = efi: image_protocol::load_options

U-Boot (proper) has plenty of schemes:

• dtb is passed as either x0, x1, fixed memory area (Qemu which is bad in itself), or other registers
• additional information passing: board specific register scheme, SMC calls
• U-Boot for RPI boards implement a Linux shaped entry ABI to be launched by Videocore firmware

Based on all the above, I would tend to think that RPI scheme is a good idea but also shall not prevent additional schemes for the boards.

I was not actually considering Linux since I believe/assume its entry scheme is fixed and not up for discussion.

I also did not think about the EFI case. As I understand it we cannot touch it as it is used by UEFI today. Maybe it is even in the standard?

It is in the spec and we are making it evolve, or its understanding evolve (jurisprudence) for instance on initrd standard handling.

Well perhaps we could merge it with standard passage. But EFI is not going to want to use a bloblist, it will want to use a HOB.

...

...

Really I am hoping we can start afresh...?

...

What about a U-Boot Arm entry ABI like:

• plain: x0=dtb, x1=<Passage defined>, x2-x5 = <reserved>, other registers are per platform, SMC calls allowed too

Hmm we don't actually need the dtb as it is available in the bloblist.

If you don't have x0=dtb, then you will not be able to use U-Boot on RPI4. Unless you want to redo everything the RPI firmware is doing.

That's right, RPI cannot support standard passage. It is not open-source firmware so it isn't really relevant to this discussion. It will just do what it does and have limited functionality, with work-arounds to deal with the pain, as one might expect.

So you are seeing two "all-or-nothing" options: <specific>: U-Boot entry is board specific as it is today <purepassage>: A new form where the only parameter is a head of bloblist, one of those blobs contain a DT You propose to mandate a DT for all boards make sense in that environment. For RPI4, you just ignore everything the prior boot loader does because it is not <passage> compliant.

It's not that. It's just that it is closed-source, so not relevant to the discussion here. They could open-source it and then we could consider it, but it has been closed-source for years now, so why would we think that would happen?

This reinforces my opposition to the mandatory DT proposal.

a third option is I think way more attractive: <optpassage>: shaped after the architecture Linux entry (ie. first parameter is dtb) [+ passage head (i.e. second parameter is pointer to passage head)]

This way, you make U-Boot entry clean in RPI4, Apple M1, Qemu, SystemReady contexts and get a well deserved standardized information passing between prior loaders and U-Boot.

The three options are possible though, you could select a U-Boot entry CONFIG option for:

<specific> <optpassage> <purepassage>

But despite it would be technically feasible, I don't think it is goes in the right direction.

OK. Do you think we need a separate devicetree pointer, rather than forcing it to be inside the created bloblist?

I'd like to understand what problem you are solving with this. I am trying to figure out a firmware-to-firmware mini-ABI (just a few register values) that can be used in open-source projects. The ABI is not intended to be used with Linux (I am unsure of the benefit it would give and whether it is feasible to change the current one).

You are talking about the Linux entry mechanism. What relevance does that have for firmware?

I understand that some projects already implement the Linux mechanism, but that is because they expect to jump straight to Linux, not have U-Boot in the path. So IMO standard passage offers no benefit to them.

To address them in turn: - rpi4 - closed source, who cares? - Apple M1 - we could probably expand it to pass a bloblist, but it would be confusing unless we share registers, as you suggest - Qemu - I already tried to update that and got pushback...do you really think those guys are going to want to add a bloblist? So again, who cares? - SystemReady - not sure what this means in practice, but it would be good if SystemReady could use standard passage

So let's say we have an optional standard-passage thing and we use registers such that it is similar to Linux and EFI and just expands on them.

The first problem is that Linux and EFI seem to be completely incompatible. Can that be changed, perhaps on the EFI side? If not, we need two separate protocols.

I'll ignore EFI for now. So we might have:

r0 = 0 r1 = machine number (0?) r2 = dtb pointer r3 = bloblist pointer, 0 if missing r14 = return address

or

x0 = dtb x1 = bloblist pointer, 0 if missing x30 = return address

For EFI, we could add a blob to the bloblist containing the system table and handle, perhaps? Otherwise:

x2 - efi handle x3 - system table

Is that along the lines of what you are thinking?

But still, please respond above so I can understand what problem you are worried about.

Regards, Simon

...

...

...

But I added an offset to it as a convenience.

...

• EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is launched as an EFI app) dtb = EFI_UUID config table, + Passage = Passage UUID config table

I don't understand the last line. Where is the passage info / bloblist? Do you mean it goes in the HOB list with a UUID? I suppose that is the most EFI-compatible way.

The Passage config table could just contain the "head" of the bloblist/Passage information.

If UEFI wants to deal with standard passage, that is...

...

...

What do you think about the idea of using an offset into the bloblist for the dtb?

It is possible but as I said, failing to mimic Linux entry ABI would miss the opportunity to just boot without changes on RPI4.

See above. Broadcom could look at open-sourcing their bootloader if they wish.

...

...

Also, can we make the standard passage ABI a build-time option, so it is deterministic?

Looks good. I would look into stating that for SystemReady we would advise to use that option and make it standard for Trusted Substrate (Linaro recipes that we upstreaming to make SystemReady compliance easy and consistent across platforms).

OK. I mean that if the option is enabled, then standard passage must be provided / emitted or things won't work. If the option is disabled, then standard passage is not used. In other words, we are looking for magic values in registers, etc, just enabling/disabling it at build-time.

...

...

...

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'm worried about this becoming a substitute for devicetree. Really my intent is to provide a way to pass simple info, whereas what you talk about there seems like something that should be DT, just that it might need suitable bindings.

I see your point and I agree It should not be a substitute. here is an expanded version of what I had in mind when I wrote those lines. cma, initrd and other Linux kernel parameters can be conveyed either through command line or DT. When using the non UEFI Linux entry ABI, you need to use the DT to pass those parameters. When using the UEFI Linux entry ABI, you *can* (not must) use the command line to pass all information, leaving the DT passed to the OS without any /chosen. When introducing Passage, I was wondering if we could pass command line to Linux and, same as UEFI, leave the DT free from /chosen. I am not sure it is a good goal though. I may be too pushing for a DT free from parameters.

We could. Are there benefits to that?

I doubt we would pass the standard passage to Linux as a bloblist. I imagine something like this. The bloblist sits in memory with some things in it, including a devicetree, perhaps an SMBIOS table and a TPM log. But when U-Boot calls Linux it puts the address/size of those individual things in the devicetree. They don't move and are still contiguous in memory, but the bloblist around them is forgotten. Linux doesn't know that the three separate things it is picking up are actually part of a bloblist structure, since it doesn't care about that. Even a console log could work the same way. That way we don't end up trying to teach Linux about bloblist when it already has a perfectly good means to accept these items.

For ACPI I see things a similar way. The ACPI tables can point to things that *happen* to be in a bloblist, but without any knowledge of that needed in Linux, grub, etc.

...

...

As you know I have more expansive views about what should be in DT.

I think both of us are huge supporters of DT format and self describing capabilities. I am inclined to put rules into what fits into what lands in the DT that is passed to the OS. I am a fan of having DT used more in ad-hoc files.

Me too.

...

...

...

Cheers

PS: as Ilias mentions, this patch set contains bug fixes, non immediately related additional functions (DM stats). It would be great to carve those out to fast path them and keep this one with the very core of your idea.

The DM stats is used in 'passage: Report the devicetree source'. I know it is sideways but I think it is better to make the output line more useful than just reporting the devicetree source.

I believe the DM stats has merits in its own. You could upstream this independently and then Passage would be yet another "customer" of the feature.

I could, but it would just be a debug feature so people might not think it worth the code space. With the devicetree source it is more compelling.

...

...

The first patch is indeed unrelated. I will pick it up so we can drop it for the next rev.

[..]

Regards, Simon

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

) to signal Hi François,

On Fri, 5 Nov 2021 at 10:31, François Ozog francois.ozog@linaro.org wrote:

Hi Simon,

Le ven. 5 nov. 2021 à 17:12, Simon Glass sjg@chromium.org a écrit :

...

Hi François,

On Fri, 5 Nov 2021 at 02:27, François Ozog francois.ozog@linaro.org wrote:

...

On Fri, 5 Nov 2021 at 03:02, Simon Glass sjg@chromium.org wrote:

...

Hi François,

On Tue, 2 Nov 2021 at 10:03, François Ozog francois.ozog@linaro.org wrote:

...

Hi Simon,

On Tue, 2 Nov 2021 at 15:59, Simon Glass sjg@chromium.org wrote:

...

Hi François,

On Mon, 1 Nov 2021 at 02:53, François Ozog francois.ozog@linaro.org wrote: > > Hi Simon, > > this seems a great endeavor. I'd like to better understand the scope of it. > > Is it to be used as part of what could become a U-Boot entry ABI scheme? By that I mean giving some fixed aspects > to U-Boot entry while letting boards to have flexibility (say for instance that the first 5 architecture ABI > parameter registers are reserved for U-Boot), and the Passage is about specifying either those reserved registers > or one of them?

The goal is to provide a standard entry scheme for all firmware binaries. Whether it achieves that (or can with some mods) is up for discussion.

If you say a) define a U-Boot entry ABI and providing a firmware-to-firmware information passing facility which would be part of all firmware ABIs (as the projects decide to define their own ABI) it looks good. but If you say

It is an ABI to be adopted by U-Boot but also other firmware. For example, if TF-A calls U-Boot it should use standard passage. If U-Boot calls TF-A or Optee it should use standard passage.

...

b) define a standard entry scheme (register map, processor state, MMU state, SMMU state, GIC state...) that does not look realistic.

No I don't mean that. This data structure could be used in any state, so long as the two registers are set correctly.

...

I think you mean a) but just want to be sure.

Yes I think so.

...

...

Re the registers, do you think we need 5?

I don't :-)

...

...

> > Thinking entry ABI, here is what I observed on Arm: > > Linux has two entry ABIs: > - plain: x0 = dtb; > command line = dtb:/chosen/bootargs; initrd = dtb:/chosen/linux,initrd-* > - EFI: x0=handle, x1=systemtable, x30=return address; > dtb = EFI_UUID config table; initrd = efi:<loadfile2(INITRD vendor media UUID); command line = efi: image_protocol::load_options > > U-Boot (proper) has plenty of schemes: > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad in itself), or other registers > - additional information passing: board specific register scheme, SMC calls > - U-Boot for RPI boards implement a Linux shaped entry ABI to be launched by Videocore firmware > > Based on all the above, I would tend to think that RPI scheme is a good idea but also > shall not prevent additional schemes for the boards.

I was not actually considering Linux since I believe/assume its entry scheme is fixed and not up for discussion.

I also did not think about the EFI case. As I understand it we cannot touch it as it is used by UEFI today. Maybe it is even in the standard?

It is in the spec and we are making it evolve, or its understanding evolve (jurisprudence) for instance on initrd standard handling.

Well perhaps we could merge it with standard passage. But EFI is not going to want to use a bloblist, it will want to use a HOB.

...

...

Really I am hoping we can start afresh...?

> > What about a U-Boot Arm entry ABI like: > - plain: x0=dtb, x1=<Passage defined>, x2-x5 = <reserved>, other registers are per platform, SMC calls allowed too

Hmm we don't actually need the dtb as it is available in the bloblist.

If you don't have x0=dtb, then you will not be able to use U-Boot on RPI4. Unless you want to redo everything the RPI firmware is doing.

That's right, RPI cannot support standard passage. It is not open-source firmware so it isn't really relevant to this discussion. It will just do what it does and have limited functionality, with work-arounds to deal with the pain, as one might expect.

So you are seeing two "all-or-nothing" options: <specific>: U-Boot entry is board specific as it is today <purepassage>: A new form where the only parameter is a head of bloblist, one of those blobs contain a DT You propose to mandate a DT for all boards make sense in that environment. For RPI4, you just ignore everything the prior boot loader does because it is not <passage> compliant.

It's not that. It's just that it is closed-source, so not relevant to the discussion here. They could open-source it and then we could consider it, but it has been closed-source for years now, so why would we think that would happen?

...

This reinforces my opposition to the mandatory DT proposal.

a third option is I think way more attractive: <optpassage>: shaped after the architecture Linux entry (ie. first parameter is dtb) [+ passage head (i.e. second parameter is pointer to passage head)]

This way, you make U-Boot entry clean in RPI4, Apple M1, Qemu, SystemReady contexts and get a well deserved standardized information passing between prior loaders and U-Boot.

The three options are possible though, you could select a U-Boot entry CONFIG option for:

<specific> <optpassage> <purepassage>

But despite it would be technically feasible, I don't think it is goes in the right direction.

OK. Do you think we need a separate devicetree pointer, rather than forcing it to be inside the created bloblist?

I'd like to understand what problem you are solving with this. I am trying to figure out a firmware-to-firmware mini-ABI (just a few register values) that can be used in open-source projects. The ABI is not intended to be used with Linux (I am unsure of the benefit it would give and whether it is feasible to change the current one).

You are talking about the Linux entry mechanism. What relevance does that have for firmware?

I understand that some projects already implement the Linux mechanism, but that is because they expect to jump straight to Linux, not have U-Boot in the path. So IMO standard passage offers no benefit to them.

To address them in turn:

• rpi4 - closed source, who cares?
• Apple M1 - we could probably expand it to pass a bloblist, but it

would be confusing unless we share registers, as you suggest

• Qemu - I already tried to update that and got pushback...do you

really think those guys are going to want to add a bloblist? So again, who cares?

• SystemReady - not sure what this means in practice, but it would be

good if SystemReady could use standard passage

So let's say we have an optional standard-passage thing and we use registers such that it is similar to Linux and EFI and just expands on them.

The first problem is that Linux and EFI seem to be completely incompatible. Can that be changed, perhaps on the EFI side? If not, we need two separate protocols.

I'll ignore EFI for now. So we might have:

r0 = 0 r1 = machine number (0?) r2 = dtb pointer r3 = bloblist pointer, 0 if missing r14 = return address

or

x0 = dtb x1 = bloblist pointer, 0 if missing x30 = return address

That’s essentially what I proposed! you do not force the DTB to be found in the bloblist, and shape the U-Boot entry after the Linux entry ABI. Good ! I was saving a few registers for future ABI evolution so that boards can be guaranteed to have their board specific registers properly protected. The 5 registers, leaving 3 undefined was just « why not ». We could also have a cookie in x1: high 48 bits magic low 16 ABI version, x2=bloblist pointer.

Isn't 32 bits enough for a magic value?

Also x3 might be nicer, to match ARM 32-bit, so:

x0 = dtb x1 = ABI indicator bits 63:32 0xb00757a3, bits 31:1 = 0, bit 0 = 1 (version 1) ? We don't need to decide how many bits for the version right now. Perhaps 8 is plenty x2 = 0 x3 = bloblist pointer, 0 if missing x4 = 0 x30 = return address

For ARM:

r0 = 0 r1 = machine number (0xb00757xx to signal standard passage where xx is the ABI version?)* r2 = dtb pointer r3 = bloblist pointer (if r1 is 0xb00757xx), else 0 r4 = 0 r14 = return address

* might be safe, looking at https://elixir.bootlin.com/linux/latest/source/arch/arm/kernel/setup.c#L1094

...

For EFI, we could add a blob to the bloblist containing the system table and handle, perhaps? Otherwise:

x2 - efi handle x3 - system table

Is that along the lines of what you are thinking?

No, efi entry is only x0=efi handle, x1=system table . I was trying to find a way to have passage when U-Boot is loaded as a UEFI app (your other patch set to make U-Boot a more integrated UEFi app). Let’s say that a U-Boot aware DXE driver/protocol actually populate such a table, it could be a communication channel between that driver and U-Boot.

OK, I figured, so how about, for EFI on 64-bit:

x0 = handle x1 = systable x2 = ABI indicator bits 63:32 0xb00757a3, bits 31:1 = 0, bit 0 = 1 (version 1) x3 = bloblist pointer x4 = 0 x30 = return address

EFI 32-bit:

r0 = handle r1 = systable r2 = 0xb00757a3 r3 = bloblist pointer r4 = 0 r14 = return address

Regards, Simon

...

But still, please respond above so I can understand what problem you are worried about.

Regards, Simon

...

...

...

...

But I added an offset to it as a convenience.

> - EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is launched as an EFI app) > dtb = EFI_UUID config table, + Passage = Passage UUID config table

I don't understand the last line. Where is the passage info / bloblist? Do you mean it goes in the HOB list with a UUID? I suppose that is the most EFI-compatible way.

The Passage config table could just contain the "head" of the bloblist/Passage information.

If UEFI wants to deal with standard passage, that is...

...

...

What do you think about the idea of using an offset into the bloblist for the dtb?

It is possible but as I said, failing to mimic Linux entry ABI would miss the opportunity to just boot without changes on RPI4.

See above. Broadcom could look at open-sourcing their bootloader if they wish.

...

...

Also, can we make the standard passage ABI a build-time option, so it is deterministic?

Looks good. I would look into stating that for SystemReady we would advise to use that option and make it standard for Trusted Substrate (Linaro recipes that we upstreaming to make SystemReady compliance easy and consistent across platforms).

OK. I mean that if the option is enabled, then standard passage must be provided / emitted or things won't work. If the option is disabled, then standard passage is not used. In other words, we are looking for magic values in registers, etc, just enabling/disabling it at build-time.

...

...

> > 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'm worried about this becoming a substitute for devicetree. Really my intent is to provide a way to pass simple info, whereas what you talk about there seems like something that should be DT, just that it might need suitable bindings.

I see your point and I agree It should not be a substitute. here is an expanded version of what I had in mind when I wrote those lines. cma, initrd and other Linux kernel parameters can be conveyed either through command line or DT. When using the non UEFI Linux entry ABI, you need to use the DT to pass those parameters. When using the UEFI Linux entry ABI, you *can* (not must) use the command line to pass all information, leaving the DT passed to the OS without any /chosen. When introducing Passage, I was wondering if we could pass command line to Linux and, same as UEFI, leave the DT free from /chosen. I am not sure it is a good goal though. I may be too pushing for a DT free from parameters.

We could. Are there benefits to that?

I doubt we would pass the standard passage to Linux as a bloblist. I imagine something like this. The bloblist sits in memory with some things in it, including a devicetree, perhaps an SMBIOS table and a TPM log. But when U-Boot calls Linux it puts the address/size of those individual things in the devicetree. They don't move and are still contiguous in memory, but the bloblist around them is forgotten. Linux doesn't know that the three separate things it is picking up are actually part of a bloblist structure, since it doesn't care about that. Even a console log could work the same way. That way we don't end up trying to teach Linux about bloblist when it already has a perfectly good means to accept these items.

For ACPI I see things a similar way. The ACPI tables can point to things that *happen* to be in a bloblist, but without any knowledge of that needed in Linux, grub, etc.

...

...

As you know I have more expansive views about what should be in DT.

I think both of us are huge supporters of DT format and self describing capabilities. I am inclined to put rules into what fits into what lands in the DT that is passed to the OS. I am a fan of having DT used more in ad-hoc files.

Me too.

...

...

> > Cheers > > PS: as Ilias mentions, this patch set contains bug fixes, non immediately related additional functions (DM stats). It would be great to carve those out to fast path them and keep this one with the very core of your idea.

The DM stats is used in 'passage: Report the devicetree source'. I know it is sideways but I think it is better to make the output line more useful than just reporting the devicetree source.

I believe the DM stats has merits in its own. You could upstream this independently and then Passage would be yet another "customer" of the feature.

I could, but it would just be a debug feature so people might not think it worth the code space. With the devicetree source it is more compelling.

...

...

The first patch is indeed unrelated. I will pick it up so we can drop it for the next rev.

[..]

Regards, Simon

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

Hi François,

On Mon, 8 Nov 2021 at 09:20, François Ozog francois.ozog@linaro.org wrote:

On Fri, 5 Nov 2021 at 18:17, Simon Glass sjg@chromium.org wrote:

...

) to signal Hi François,

On Fri, 5 Nov 2021 at 10:31, François Ozog francois.ozog@linaro.org wrote:

...

Hi Simon,

Le ven. 5 nov. 2021 à 17:12, Simon Glass sjg@chromium.org a écrit :

...

Hi François,

On Fri, 5 Nov 2021 at 02:27, François Ozog francois.ozog@linaro.org wrote:

...

On Fri, 5 Nov 2021 at 03:02, Simon Glass sjg@chromium.org wrote:

...

Hi François,

On Tue, 2 Nov 2021 at 10:03, François Ozog francois.ozog@linaro.org wrote: > > Hi Simon, > > On Tue, 2 Nov 2021 at 15:59, Simon Glass sjg@chromium.org wrote: >> >> Hi François, >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog francois.ozog@linaro.org wrote: >> > >> > Hi Simon, >> > >> > this seems a great endeavor. I'd like to better understand the scope of it. >> > >> > Is it to be used as part of what could become a U-Boot entry ABI scheme? By that I mean giving some fixed aspects >> > to U-Boot entry while letting boards to have flexibility (say for instance that the first 5 architecture ABI >> > parameter registers are reserved for U-Boot), and the Passage is about specifying either those reserved registers >> > or one of them? >> >> The goal is to provide a standard entry scheme for all firmware >> binaries. Whether it achieves that (or can with some mods) is up for >> discussion. >> > If you say > a) define a U-Boot entry ABI and providing a firmware-to-firmware information passing facility which would be part of all firmware ABIs (as the projects decide to define their own ABI) it looks good. > but If you say

It is an ABI to be adopted by U-Boot but also other firmware. For example, if TF-A calls U-Boot it should use standard passage. If U-Boot calls TF-A or Optee it should use standard passage.

> b) define a standard entry scheme (register map, processor state, MMU state, SMMU state, GIC state...) that does not look realistic.

No I don't mean that. This data structure could be used in any state, so long as the two registers are set correctly.

> I think you mean a) but just want to be sure.

Yes I think so.

>> >> Re the registers, do you think we need 5? >>

I don't :-)

>> > >> > Thinking entry ABI, here is what I observed on Arm: >> > >> > Linux has two entry ABIs: >> > - plain: x0 = dtb; >> > command line = dtb:/chosen/bootargs; initrd = dtb:/chosen/linux,initrd-* >> > - EFI: x0=handle, x1=systemtable, x30=return address; >> > dtb = EFI_UUID config table; initrd = efi:<loadfile2(INITRD vendor media UUID); command line = efi: image_protocol::load_options >> > >> > U-Boot (proper) has plenty of schemes: >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad in itself), or other registers >> > - additional information passing: board specific register scheme, SMC calls >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be launched by Videocore firmware >> > >> > Based on all the above, I would tend to think that RPI scheme is a good idea but also >> > shall not prevent additional schemes for the boards. >> >> I was not actually considering Linux since I believe/assume its entry >> scheme is fixed and not up for discussion. >> >> I also did not think about the EFI case. As I understand it we cannot >> touch it as it is used by UEFI today. Maybe it is even in the >> standard? > > It is in the spec and we are making it evolve, or its understanding evolve (jurisprudence) for instance on initrd standard handling.

Well perhaps we could merge it with standard passage. But EFI is not going to want to use a bloblist, it will want to use a HOB.

>> >> >> Really I am hoping we can start afresh...? >> >> > >> > What about a U-Boot Arm entry ABI like: >> > - plain: x0=dtb, x1=<Passage defined>, x2-x5 = <reserved>, other registers are per platform, SMC calls allowed too >> >> Hmm we don't actually need the dtb as it is available in the bloblist. > > If you don't have x0=dtb, then you will not be able to use U-Boot on RPI4. > Unless you want to redo everything the RPI firmware is doing.

That's right, RPI cannot support standard passage. It is not open-source firmware so it isn't really relevant to this discussion. It will just do what it does and have limited functionality, with work-arounds to deal with the pain, as one might expect.

So you are seeing two "all-or-nothing" options: <specific>: U-Boot entry is board specific as it is today <purepassage>: A new form where the only parameter is a head of bloblist, one of those blobs contain a DT You propose to mandate a DT for all boards make sense in that environment. For RPI4, you just ignore everything the prior boot loader does because it is not <passage> compliant.

It's not that. It's just that it is closed-source, so not relevant to the discussion here. They could open-source it and then we could consider it, but it has been closed-source for years now, so why would we think that would happen?

...

This reinforces my opposition to the mandatory DT proposal.

a third option is I think way more attractive: <optpassage>: shaped after the architecture Linux entry (ie. first parameter is dtb) [+ passage head (i.e. second parameter is pointer to passage head)]

This way, you make U-Boot entry clean in RPI4, Apple M1, Qemu, SystemReady contexts and get a well deserved standardized information passing between prior loaders and U-Boot.

The three options are possible though, you could select a U-Boot entry CONFIG option for:

<specific> <optpassage> <purepassage>

But despite it would be technically feasible, I don't think it is goes in the right direction.

OK. Do you think we need a separate devicetree pointer, rather than forcing it to be inside the created bloblist?

I'd like to understand what problem you are solving with this. I am trying to figure out a firmware-to-firmware mini-ABI (just a few register values) that can be used in open-source projects. The ABI is not intended to be used with Linux (I am unsure of the benefit it would give and whether it is feasible to change the current one).

You are talking about the Linux entry mechanism. What relevance does that have for firmware?

I understand that some projects already implement the Linux mechanism, but that is because they expect to jump straight to Linux, not have U-Boot in the path. So IMO standard passage offers no benefit to them.

To address them in turn:

• rpi4 - closed source, who cares?
• Apple M1 - we could probably expand it to pass a bloblist, but it

would be confusing unless we share registers, as you suggest

• Qemu - I already tried to update that and got pushback...do you

really think those guys are going to want to add a bloblist? So again, who cares?

• SystemReady - not sure what this means in practice, but it would be

good if SystemReady could use standard passage

So let's say we have an optional standard-passage thing and we use registers such that it is similar to Linux and EFI and just expands on them.

The first problem is that Linux and EFI seem to be completely incompatible. Can that be changed, perhaps on the EFI side? If not, we need two separate protocols.

I'll ignore EFI for now. So we might have:

r0 = 0 r1 = machine number (0?) r2 = dtb pointer r3 = bloblist pointer, 0 if missing r14 = return address

or

x0 = dtb x1 = bloblist pointer, 0 if missing x30 = return address

That’s essentially what I proposed! you do not force the DTB to be found in the bloblist, and shape the U-Boot entry after the Linux entry ABI. Good ! I was saving a few registers for future ABI evolution so that boards can be guaranteed to have their board specific registers properly protected. The 5 registers, leaving 3 undefined was just « why not ». We could also have a cookie in x1: high 48 bits magic low 16 ABI version, x2=bloblist pointer.

Isn't 32 bits enough for a magic value?

Also x3 might be nicer, to match ARM 32-bit, so:

x0 = dtb x1 = ABI indicator bits 63:32 0xb00757a3, bits 31:1 = 0, bit 0 = 1 (version 1) ? We don't need to decide how many bits for the version right now. Perhaps 8 is plenty x2 = 0 x3 = bloblist pointer, 0 if missing x4 = 0 x30 = return address

sounds usable. Need more comments on this.

...

For ARM:

r0 = 0 r1 = machine number (0xb00757xx to signal standard passage where xx is the ABI version?)* r2 = dtb pointer r3 = bloblist pointer (if r1 is 0xb00757xx), else 0 r4 = 0 r14 = return address

• might be safe, looking at

https://elixir.bootlin.com/linux/latest/source/arch/arm/kernel/setup.c#L1094

Indeed. Need more comments on this.

...

...

...

For EFI, we could add a blob to the bloblist containing the system table and handle, perhaps? Otherwise:

x2 - efi handle x3 - system table

Is that along the lines of what you are thinking?

No, efi entry is only x0=efi handle, x1=system table . I was trying to find a way to have passage when U-Boot is loaded as a UEFI app (your other patch set to make U-Boot a more integrated UEFi app). Let’s say that a U-Boot aware DXE driver/protocol actually populate such a table, it could be a communication channel between that driver and U-Boot.

OK, I figured, so how about, for EFI on 64-bit:

x0 = handle x1 = systable x2 = ABI indicator bits 63:32 0xb00757a3, bits 31:1 = 0, bit 0 = 1 (version 1) x3 = bloblist pointer x4 = 0 x30 = return address

EFI 32-bit:

r0 = handle r1 = systable r2 = 0xb00757a3 r3 = bloblist pointer r4 = 0 r14 = return address

Let's be clear that this is for an existing UEFI implementation to boot U-Boot. If the implementation cannot be changed to add the information, a UEFI driver or protocol may be used. Could SPL may be tweaked to craft the bloblist based on whatever information I that case?

Yes that is easy enough, but then how does SPL load U-Boot? UEFI requires an efl file and we don't want to put the EFI app into SPL, I think.

(side comment: LinuxBoot has developed techniques to replace most of an EDK2 implementation by Linux. This entry ABI does not apply in this use case as it is defined by EDK2.)

Now on the how.

EFI API has already defined extension mechanism, so that may be difficult to add.

let's put the bloblist pointer in a <configtable>:

typedef struct { 1936 /// 1937 /// The 128-bit GUID value that uniquely identifies the system configuration table. 1938 /// 1939 EFI_GUID VendorGuid; /* set to BLOB_LIST_GUID */ 1940 /// 1941 /// A pointer to the table associated with VendorGuid. 1942 /// 1943 VOID *VendorTable; /* bloblist pointer */ 1944 } EFI_CONFIGURATION_TABLE;

U-Boot or a driver or a protocol can set the VendorTable to bloblist pointer and add this to the list of configuration tables via https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/5_uefi_servic...

The blobs should be already accounted for in the memory map as they were pre-allocated before U-Boot entry. But that may be a topic to be checked.

OK, well in that case I suppose we don't need to define it here? Or are you saying that we should define this as an alternative way to get the bloblist?

Everything we define, we need tests for, so I want to make sure only useful cases are included.

Regards, Simon

...

Regards, Simon

...

...

But still, please respond above so I can understand what problem you are worried about.

Regards, Simon

...

...

>> >> But I added an offset to it as a convenience. >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is launched as an EFI app) >> > dtb = EFI_UUID config table, + Passage = Passage UUID config table >> >> I don't understand the last line. Where is the passage info / >> bloblist? Do you mean it goes in the HOB list with a UUID? I suppose >> that is the most EFI-compatible way. > > The Passage config table could just contain the "head" of the bloblist/Passage information.

If UEFI wants to deal with standard passage, that is...

>> >> >> What do you think about the idea of using an offset into the bloblist >> for the dtb? > > It is possible but as I said, failing to mimic Linux entry ABI would miss the opportunity to just boot without changes on RPI4.

See above. Broadcom could look at open-sourcing their bootloader if they wish.

>> >> Also, can we make the standard passage ABI a build-time >> option, so it is deterministic? >> > Looks good. I would look into stating that for SystemReady we would advise to use that option and make it standard for Trusted Substrate (Linaro recipes that we upstreaming to make SystemReady compliance easy and consistent across platforms).

OK. I mean that if the option is enabled, then standard passage must be provided / emitted or things won't work. If the option is disabled, then standard passage is not used. In other words, we are looking for magic values in registers, etc, just enabling/disabling it at build-time.

>> >> > >> > 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'm worried about this becoming a substitute for devicetree. Really my >> intent is to provide a way to pass simple info, whereas what you talk >> about there seems like something that should be DT, just that it might >> need suitable bindings. >> > I see your point and I agree It should not be a substitute. > here is an expanded version of what I had in mind when I wrote those lines. > cma, initrd and other Linux kernel parameters can be conveyed either through command line or DT. > When using the non UEFI Linux entry ABI, you need to use the DT to pass those parameters. > When using the UEFI Linux entry ABI, you *can* (not must) use the command line to pass all information, leaving the DT passed to the OS without any /chosen. > When introducing Passage, I was wondering if we could pass command line to Linux and, same as UEFI, leave the DT free from /chosen. > I am not sure it is a good goal though. I may be too pushing for a DT free from parameters.

We could. Are there benefits to that?

I doubt we would pass the standard passage to Linux as a bloblist. I imagine something like this. The bloblist sits in memory with some things in it, including a devicetree, perhaps an SMBIOS table and a TPM log. But when U-Boot calls Linux it puts the address/size of those individual things in the devicetree. They don't move and are still contiguous in memory, but the bloblist around them is forgotten. Linux doesn't know that the three separate things it is picking up are actually part of a bloblist structure, since it doesn't care about that. Even a console log could work the same way. That way we don't end up trying to teach Linux about bloblist when it already has a perfectly good means to accept these items.

For ACPI I see things a similar way. The ACPI tables can point to things that *happen* to be in a bloblist, but without any knowledge of that needed in Linux, grub, etc.

>> >> As you know I have more expansive views about what should be in DT. > > I think both of us are huge supporters of DT format and self describing capabilities. > I am inclined to put rules into what fits into what lands in the DT that is passed to the OS. > I am a fan of having DT used more in ad-hoc files.

Me too.

>> >> > >> > Cheers >> > >> > PS: as Ilias mentions, this patch set contains bug fixes, non immediately related additional functions (DM stats). It would be great to carve those out to fast path them and keep this one with the very core of your idea. >> >> The DM stats is used in 'passage: Report the devicetree source'. I >> know it is sideways but I think it is better to make the output line >> more useful than just reporting the devicetree source. >> > I believe the DM stats has merits in its own. You could upstream this independently and then Passage would be yet another "customer" of the feature.

I could, but it would just be a debug feature so people might not think it worth the code space. With the devicetree source it is more compelling.

>> >> The first patch is indeed unrelated. I will pick it up so we can drop >> it for the next rev. >> [..]

Regards, Simon

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog

-- François-Frédéric Ozog | Director Business Development T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog