Re: eBPF as replacement for UEFi EBC and ACPI AML

[Alexander Graf]

On 13.08.21 13:23, Leif Lindholm wrote:

On Fri, Aug 13, 2021 at 12:58:26 +0200, Alexander Graf wrote:

On 13.08.21 11:54, Leif Lindholm wrote:

On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:

This:

https://linuxfoundation.org/press-release/facebook-google-isovalent-microsoft-and-netflix-launch-ebpf-foundation-as-part-of-the-linux-foundation

Following earlier addition of eBPF in Windows kernel:
https://github.com/microsoft/ebpf-for-windows


Makes me think that the crazy idea I talked about a couple of months ago
(subject of the mail) may not be that crazy….

Not crazy. I have discussed at least the EBC replacement bit with a
few people in the past.

While admittedly the first time it was broached was in jest (I think
credit goes to Peter Jones), it's the best option I can see out there
today.


There are a few reasons you may want to use eBPF:

1) Security
2) Cross-arch compatibility

I don't think you can get either in UEFI's current module model, because you
exchange direct flat memory model objects between entities. So while struct
layouts, function call ABI, etc still matter you still don't get any
additional security because you need to have full access to all memory at
all times.

So let me ask this the other way around: What are you trying to achieve?

Portable option ROMs with a supportable toolchain.



As long as your host ABI is compatible to eBPF, it will also be 
compatible to x86_64, no? That means, you can just as well use x86_64 
instead.


What I'm much more interested in is a path where we move out of the 1980 
misery of flat address spaces and no privilege separation between 
entities. How hard would it be to create wasm bindings for the 99% of 
use cases that Option ROMs have these days? Could we create a shim layer 
between the big UEFI blob and Option ROMs that would make it impossible 
to access stray pointers for example?



Thanks,

Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: eBPF as replacement for UEFi EBC and ACPI AML

[Alexander Graf]

On 13.08.21 11:54, Leif Lindholm wrote:

On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:

This:

https://linuxfoundation.org/press-release/facebook-google-isovalent-microsoft-and-netflix-launch-ebpf-foundation-as-part-of-the-linux-foundation

Following earlier addition of eBPF in Windows kernel:
https://github.com/microsoft/ebpf-for-windows


Makes me think that the crazy idea I talked about a couple of months ago
(subject of the mail) may not be that crazy….

Not crazy. I have discussed at least the EBC replacement bit with a
few people in the past.

While admittedly the first time it was broached was in jest (I think
credit goes to Peter Jones), it's the best option I can see out there
today.



There are a few reasons you may want to use eBPF:

1) Security
2) Cross-arch compatibility

I don't think you can get either in UEFI's current module model, because 
you exchange direct flat memory model objects between entities. So while 
struct layouts, function call ABI, etc still matter you still don't get 
any additional security because you need to have full access to all 
memory at all times.


So let me ask this the other way around: What are you trying to achieve?


Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

[Alexander Graf]

On 20.05.21 18:42, Simon Glass wrote:

Hi,

Re Jeremy's comment:

Using DT to pass platform info at this level is sort of crazy on an ACPI
machine which won't have native DTs. Meaning there is an additional
level of unnecessary indirection that needs to be converted back into a
format which can be utilized by AML and other parts of the ACPI stack.

U-Boot has to generate part of the ACPI tables programmatically, using info
from the DT to do so. In other words, U-Boot supports DT but must also
support generating AML, etc. I don't see a particular problem with that.

I don't think it makes any sense to use ACPI tables to pass data between
boot phases, but if that is being proposed, I'd like to understand the
reason. I also wonder why people are using UEFI on rpi, but that's a
different topic.



Reading the conversation, I believe the main confusion is about what 
"use DT to pass data" means.


There are fundamentally two ways to think of this:

1) Take a standard Linux device tree as input. Use exactly that to pass 
data between stages. Go through the LKML to define pre-Linux bindings. 
Implement a full DT parser to enumerate hardware.


2) Use DT purely as opaque data transfer mechanism and reuse simple 
parts (directories, compatible strings, etc) but leave out the 
complicated ones (recursive #address-cells, interrupt-map, etc). Use it 
to pass data privately between components. Be self-consistent, 
self-documenting and self-backwards-compatible.



Which one of them do you mean Simon? I'd be super happy to see option 2. 
DT as a data container is so much nicer than opaque binary blobs. At the 
same time, I can see how people feel like option 1 would tie them into 
an ecosystem dependency they don't want to be in.



Thanks,

Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Biweekly (Postponed to 14th Dec)

[Alexander Graf]

On 07.12.20 17:56, Heinrich Schuchardt wrote:

On 07.12.20 17:38, Alexander Graf wrote:

On 07.12.20 17:17, Heinrich Schuchardt wrote:

On 07.12.20 16:24, Alexander Graf wrote:

On 07.12.20 16:07, Heinrich Schuchardt wrote:

On 07.12.20 14:43, Grant Likely wrote:

I have a conflict this week and need to cancel. I propose pushing out
to next week (Dec 14th), and cancelling the meeting on the 21st when
many people will be on holiday anyway. Let me know if you want
anything added to the meeting agenda before next week.

A topic that interests me is how much HII support we need in EBBR.

Chapter 2.6.2 of the UEFI spec has "If a platform includes a
configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL,
EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and
EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped
fonts, you must support EFI_HII_FONT_PROTOCOL."

"A configuration infrastructure" in my view should be nothing required
by EBBR.

It has only been the UEFI SCT driving U-Boot to implement some HII
protocol stubs. I wonder if this dependency could be removed from the
SCT.

I think it's only in SCT because it's used in Shell.efi, no? So if we
can somehow remove it from there, it should also remove the dependency
for SCT I hope.

And yes, I agree 100% - HII really shouldn't be necessary for EBBR.


Alex



Alex, you are right it is the shell that is using HII strings and the
HII database extensively. But at least all other HII protocols can be
removed from the list of requirements.


I would love if we could use that chance to get rid of the coupling of
Shell.efi and HII as well :)


Alex


The Unicode strings for the Shell are in the following files. The idea
is to make them all translatable. Currently only English texts exist.



Just a crazy thought: Could Shell.efi provide its own HII implementation 
as a fallback if the system doesn't have one?


Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Biweekly (Postponed to 14th Dec)

[Alexander Graf]

On 07.12.20 17:17, Heinrich Schuchardt wrote:

On 07.12.20 16:24, Alexander Graf wrote:

On 07.12.20 16:07, Heinrich Schuchardt wrote:

On 07.12.20 14:43, Grant Likely wrote:

I have a conflict this week and need to cancel. I propose pushing out
to next week (Dec 14th), and cancelling the meeting on the 21st when
many people will be on holiday anyway. Let me know if you want
anything added to the meeting agenda before next week.

A topic that interests me is how much HII support we need in EBBR.

Chapter 2.6.2 of the UEFI spec has "If a platform includes a
configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL,
EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and
EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped
fonts, you must support EFI_HII_FONT_PROTOCOL."

"A configuration infrastructure" in my view should be nothing required
by EBBR.

It has only been the UEFI SCT driving U-Boot to implement some HII
protocol stubs. I wonder if this dependency could be removed from the
SCT.


I think it's only in SCT because it's used in Shell.efi, no? So if we
can somehow remove it from there, it should also remove the dependency
for SCT I hope.

And yes, I agree 100% - HII really shouldn't be necessary for EBBR.


Alex



Alex, you are right it is the shell that is using HII strings and the
HII database extensively. But at least all other HII protocols can be
removed from the list of requirements.



I would love if we could use that chance to get rid of the coupling of 
Shell.efi and HII as well :)



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Biweekly (Postponed to 14th Dec)

[Alexander Graf]

On 07.12.20 16:07, Heinrich Schuchardt wrote:

On 07.12.20 14:43, Grant Likely wrote:

I have a conflict this week and need to cancel. I propose pushing out to next 
week (Dec 14th), and cancelling the meeting on the 21st when many people will 
be on holiday anyway. Let me know if you want anything added to the meeting 
agenda before next week.

A topic that interests me is how much HII support we need in EBBR.

Chapter 2.6.2 of the UEFI spec has "If a platform includes a
configuration infrastructure, then the EFI_HII_DATABASE_PROTOCOL,
EFI_HII_STRING_PROTOCOL, EFI_HII_CONFIG_ROUTING_PROTOCOL, and
EFI_HII_CONFIG_ACCESS_PROTOCOL are required. If you support bitmapped
fonts, you must support EFI_HII_FONT_PROTOCOL."

"A configuration infrastructure" in my view should be nothing required
by EBBR.

It has only been the UEFI SCT driving U-Boot to implement some HII
protocol stubs. I wonder if this dependency could be removed from the SCT.



I think it's only in SCT because it's used in Shell.efi, no? So if we 
can somehow remove it from there, it should also remove the dependency 
for SCT I hope.


And yes, I agree 100% - HII really shouldn't be necessary for EBBR.


Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: U-Boot/EBBR plugfest at ELC-EU?

[Alexander Graf]

On 28.06.19 12:03, Heinrich Schuchardt wrote:

I would be interested in joining. I hope that for the plugfest no ELC 
conference ticket will be needed.



The easiest option for that would be to submit a talk to ELC-E. IIRC the 
CfP is still open until July 1st. You could easily give one on "Progress 
in UEFI support on U-Boot" or "What it takes to run the edk2 Shell 
outside of edk2" or whatever :). You have plenty content to pull from.


If the talk goes in, that helps visibility and gets you free ticket - 
maybe even travel sponsorship! :)




The problems with booting Linux via U-Boot UEFI I know of are on 32bit ARM 
systems.  It could be helpful to have GRUB developers joining.



Let's make sure Daniel and Leif are on CC then :).

Daniel, Leif, would you be available?

As for myself, I will probably arrive on Monday around noon and will be 
around until Saturday morning, but with KVM Forum happening Wed-Fri I 
won't have much time on my hands there.



Thanks,

Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Securing the boot flow in U-Boot

[Alexander Graf]

> Am 31.05.2019 um 17:18 schrieb Ilias Apalodimas :
> 
> Hi Tom, 
>> On Fri, May 31, 2019 at 11:05:20AM -0400, Tom Rini wrote:
>>> On Fri, May 31, 2019 at 02:40:32PM +0100, Steve McIntyre wrote:
>>> On Tue, May 28, 2019 at 02:04:23PM +0300, Ilias Apalodimas wrote:
>> 
>> The tl;dr purpose of my e-mail was 'Is implementing UEFI Secure Boot for 
>> the 
>> EFI playloads
> 
> I think that you'd better explain why you stick to *UEFI* secure boot.
 
 The main reason is distro support. Since distros use a number of different 
 ways
 of booting up on arm boards, using UEFI is the obvious way to unify that 
 (and
 alrady supported on some) regardless of the bootloader. UEFI secure boot
 provides a common approach to security instead of 'per bootloader' 
 solutions
>>> 
>>> Yup, absolutely (says the Debian EFI team lead) ...
>> 
>> The other things we need to keep in mind is that (based on my own
>> experience implementing UEFI secure boot on an x8664 platform), we are
>> not looking at a case of "make an existing solution function on other
>> architectures" but rather "there's some good concepts here and an
>> implementation waiting to be figured out".
> 
> We agree here. From Grant's proposal's #1 and #2, i'd prefer seeing something
> similar to #2 implemented. 
> I'd prefer having the option to authenticate DTB/initramfs from the 'main
> bootloader', than delegating that to some EFI payload, mostly for 
> fragmentation
> reasons

Why can't a distro generate .efi files from dtb/initrd that just store the 
updated versions into a table? Overriding / loading either would then be a 
matter of executing a normal uefi binary - with all the security benefits that 
brings.

The only big concern I have with this (and similar approaches) is that we would 
allow arbitrary combinations of DTB/kernel/initrd, which may allow an attacker 
to load say a newer kernel with an inconsistent dtb, opening a security hole.

So maybe the real answer is a Linux make step that creates a self-contained 
bundle consisting of all 3 or at least kernel? Distros / distributors 
would then ship a full bundle. With the obvious sizing downsides.


Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EFIBootGuard for CIP and SecureBoot

[Alexander Graf]

On 26.04.19 15:46, Heinrich Schuchardt wrote:
>
> On 4/26/19 1:21 PM, Jan Kiszka wrote:
>> On 26.04.19 12:21, Grant Likely wrote:
>>> On 26/04/2019 10:49, Jan Kiszka wrote:
>>>> On 26.04.19 11:07, Francois Ozog wrote:
>>> [...]
>>>>> Here are the guiding principles of our efforts :
>>>>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>>>>> processor model update solution
>>>>> 1) untrusted world cannot update trusted world
>>>> Conceptually, it can. It's a matter of validating the update by the
>>>> trusted world before using it. A trusted instance can allow an untrusted
>>>> one to write version 2, validate that before switching to it, and stick
>>>> with version 1 if that fails.
>>>>
>>>>> 2) what the UEFI implementation does with the capsule is platform
>>>>> specific
>>>>> 3) the update capsule payload is opaque
>>>>>
>>>>> 1) is a "philosophy" decision. When you have a root of trust down to
>>>>> the operating system. So in theory everything should be fine. But the
>>>>> attack surface is such that we can't rule out hacking (and history
>>>>> prove this is unfortunately a safe assumption). In addition, there may
>>>>> be liability aspects related to the who does the update: the hardware
>>>>> platform administrator may not be the legal entity than the operating
>>>>> system administrator. For instance:
>>>>> -  on Packet.net could, a customer can flash up to the BL33 untrusted
>>>>> firmware but that is all.
>>>>> - A surveillance camera can be operated by city personnel but only law
>>>>> enforcement agency can see raw video (un-blurred faces and licence
>>>>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>>>>> Path but if you allow untrusted world to update the trusted one, city
>>>>> personnel can overcome the legal restriction.
>>>>> With 1) this means that even U-Boot code shall not be able/allowed to
>>>>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>>>>> Secure EL1/0 software (OPTEE and its applications or something else).
>>>>> If possible, allowing the operating system administrator to
>>>>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>>>>> platform dependent. Hence defeats 0)
>>>>>
>>>>> With 2) we do not impose reboot to update. Some platform may impose
>>>>> reboot or some designers will prefer reboot. We say that there is a
>>>>> chain of responsibility for updates.
>>>>> So it is perfectly OK to have a Linux software agent receive an update
>>>>> by any mean (network, USB, serial...). The agent will pack this (or
>>>>> those) into a capsule and push it to UEFI implementation.
>>>>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>>>>> pleases for the update providing it complies with 1) So the UEFI
>>>>> implementation can live update up to BL33 firmware.
>>>>> Should the update be targeted to secure world, then the UEFI
>>>>> implementation can pass it to S-EL3 for update (platform specific)
>>>>> which means the update can also be live. It is a designer decision.
>>>>>
>>>>> With 3) we have flexibility but sometimes too much flexibility is a
>>>>> problem. Alexander Graf suggested we can use a FIT object to pass
>>>>> diverse objects. It is "half" opaque but I really like the idea.
>>>>> The contents of individual FIT components can be blocks to be placed
>>>>> at a fix location in a NOR flash or a file, no importance.
>>>>>
>>>>> What do everyone think about those design principles ?
>>>>>
>>>> UEFI and capsules can be fine for those platform that support it (and
>>>> it's still a rare feature) and for stuff like boot and peripheral
>>>> firmware. I don't think it's a wise, future-proof idea to use it for
>>>> more.
>>>>
>>>> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical
>>>> it will evolve towards that (looking at that as both a user as well as
>>>> an OEM). It's not even present in quite a few of our use cases. In some
>>>> it will never be - think of safety-critical system: 

Re: StandaloneMM discussion

[Alexander Graf]

On 26.04.19 15:01, Francois Ozog wrote:
> On Fri, 26 Apr 2019 at 14:45, Bryan O'Donoghue 
> wrote:
>
>>
>> On 26/04/2019 12:01, Francois Ozog wrote:
>>>
>>> On Fri, 26 Apr 2019 at 12:36, Bryan O'Donoghue
>>> mailto:bryan.odonog...@linaro.org>> wrote:
>>>
>>>
>>>
>>> On 26/04/2019 10:29, Ilias Apalodimas wrote:
>>>  >> I’d rather see Secure Boot image authentication implemented
>>> generically for all u-boot platforms, even when secure world
>>> variable updates are not available.
>>>  > Akashi and Sughosh already have code on that. It's not 100%
>>> complete or tested
>>>  > yet, but the basic concept works.
>>>
>>> Is that to say that u-boot will provide, Runtime services for EFI
>>> capsule update ?
>>>
>>> That shall be one of the few runtime services supported as well as
>>> get/set variables.
>>> Is that the current POR ?
>>>
>>> Yes
>> Well - implementing the RunTime service in u-boot or TEE doesn't make
>> much difference from the use-case I'm looking at.
>>
>> It's a positive that the model we are looking at is a runtime updating -
>> as opposed to a reset based model, which was a bit of a concern for me -
>> thinking about how long a Capsule would need to persist in memory
>> BootROM -> ATF/OPTEE -> uboot and then finally a jump to program the flash.
>>
>> Of course as Udit pointed out, the reason x86 does a reset is because it
>> has to. SPI flash is locked before the DXE phase.
>>
>>> Maybe its a stupid question but, on x86 the way this works is you
>>> submit
>>> a capsule to the EFI runtime service, reboot and the EFI firmware
>> does
>>> your update.
>>>
>>> On Arm then the flow is
>>>
>>> #1
>>> Linux capsule update -> reboot -> BootROM -> [BL31],[BL32 TEE] ->
>> u-boot
>>> and u-boot performs the update ? The bracketed items [] being
>> optional ?
>>> only for the untrusted parts. S-EL3 shall update or validate the updates.
>> OK.
>>
>> Just to clarify then. For the runtime update model.
>>
>> - u-boot will implement enough in RuntimeServices to enable
>>EFI variables
>>CapsuleUpdate
>>
>> - OP-TEE/TA
>>Will aim to provide a similar set of functionality
>>
>> But, you will be able to everything you need to do from what is being
>> implemented in u-boot.
>>
>> The TA then is extra security sugar on top, giving a more secure version
>> of EFI variables and CapsuleUpdate ?
>>
> The UEFI implementer in U-Boot can implement the whole process of update in
> its context or just pass to OPTEE or use OPTEE for a limited set of things.


If you don't have a storage that's only accessible from secure world,
chances are *very* low you can safely access it from UEFI RTS because
any access may conflict with the OS (clocks, pinctrl, device registers,
window mappings, etc etc). So implementing anything but TA calls as
U-Boot UEFI RTS is a waste of time for CapsuleUpdate IMHO.

For UEFI variables, I'm not 100% convinced we ever got to any other
conclusion that the above. The main difference is that you *can* expose
an in-memory cache of variables which only persist on reset. If you
really have to :).


Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: EBBR Plugfest at ELC and/or ELC-E

[Alexander Graf]

On 23.04.19 17:18, Grant Likely wrote:
> Hi Bill and Peter,
>
> [cc'ing boot-architecture to trawl for additional volunteers]
>
> As discussed during EBBR monthly call today, we should have an EBBR 
> plugfest at ELC and/or ELC-E this year with the goal of working out 
> compatibility issues between platforms+firmware and OS images (distro 
> images, OpenEmbedded, Buildroot, Yocto builds, etc).
>
> My initial thought is to run a full day event that is part hacking 
> sprint and part plugfest. We could ask participants to either bring a 
> platform (SBC with firmware installed) or an OS images and then set up a 
> test matrix for each OS to test on each board. After an initial set of 
> attempts the rest of the day could be a hacking sprint to solve problems 
> and squash bugs.
>
> I'm only going to be at ELC this year (Aug 21-23rd in San Diego). I 
> might be able to get the LF to provide a co-located room Tuesday the 20th.
>
> ELC-E will be in late October. If we do this at both events, then 
> someone will need to take the lead on organizing the European version.


ELC-E is right before and at the same location as KVM Forum, so I'm 99%
sure I'll be there. While I would greatly appreciate if someone else
leads the plugfest there, I can do it if nobody else steps up :)


Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] [PATCH] Simplify SetVariable() language

[Alexander Graf]

On 20.12.18 18:39, Grant Likely wrote:
> Instead of masking out GetVariable() when SetVariable() isn't available
> during runtime services, simplify the requirements without losing the
> ability to read variables by using the RuntimeServicesSupported variable
> from UEFI v2.8.1 (unreleased); Mantis issue 1961.
> 
> Peter Jones's earlier patch also specified a Capsule-on-Disk format for
> updating variables that the OS could store in the ESP. I've not included
> that specification in this patch as it is logically a separate feature.
> It may reappear in a separate patch at a later date, or it may get
> proposed for inclusion in the UEFI spec proper.
> 
> Signed-off-by: Grant Likely 
> Cc: Peter Jones 
> ---
>  source/chapter2-uefi.rst | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
> index 379f0ca..4f74d43 100644
> --- a/source/chapter2-uefi.rst
> +++ b/source/chapter2-uefi.rst
> @@ -201,14 +201,15 @@ variables stored on shared media. [#OPTEESupplicant]_
>  
>  If a platform does not implement modifying non-volatile variables with
>  SetVariable() after ExitBootServices(),
> -then it must not provide any variable operations after ExitBootServices().
> -Firmware shall return EFI_UNSUPPORTED for any call to GetVariable(),
> -GetNextVariableName() and SetVariable().
> -Firmware shall not emulated non-volatile variables using volatile RAM cache.
> +then firmware shall return EFI_UNSUPPORTED for any call to SetVariable(),
> +and must advertise that SetVariable() isn't available during runtime services
> +via the "RuntimeServicesSupported" variable as defined in UEFI version 2.8.1.
> +EFI applications can read RuntimeServicesSupported to determine if calls

UEFI?

> +to SetVariable() need to be performed before calling ExitBootServices().

I think this bit needs a bit more explanation. Something along the lines
"If an OS needs to modify UEFI variables, it can only reliably do so
before ExitBootServices()"?

>  
> -.. note:: The behaviour when SetVariable() is not supported during runtime
> -   services is still under discussion and subject to change.
> -   Do not make any firmware implementation decisions based on this text yet.
> +Even when SetVariable() is not supported during runtime services, firmware
> +should cache variable names and values in EfiRuntimeServicesData memory so
> +that GetVariable() and GetNextVeriableName() can behave as specified.

Please note that this will require work in U-Boot and is currently not
implemented ;).


Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] EBBR Weekly - Agenda 30 Aug 2018

[Alexander Graf]

Hi Grant,

I'm off this week so can't join the call. I've asked the FreeBSD guys to 
prepare something too, that looks promising.

I can also create a simple openSUSe/SLE based demo for at least RPi3, Ultra96 
and anything SBBR and SLE supported (like mcbin).

The main question point is whether we want to demo serial or graphical output 
and how :).


Alex

> Am 30.08.2018 um 16:14 schrieb Grant Likely :
> 
> Hi all,
> 
> I'd like to use today's EBBR meeting to discuss the demo for Linaro connect. 
> It would be great if we can have several distro images and show them booting 
> on multiple boards without fuss. Let's coordinate on which boards are 
> feasable candidates to use and which OS images should be used.
> 
> Talk to you at 16:30BST.
> 
> Cheers,
> g.
> 
> ---
> Every Thursday at 16:30 UTC/BST, 8:30 PST/PDT, 00:30 CST
> (following UTC/BST daylight savings time shifts)
> 
> Online meeting: https://meet.lync.com/armh/grant.likely/YBY93TIK
> Skype Web App: https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1
> Phone +44 2033215213,, 4664465#
> Find a local number:
> https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33
> Conference ID: 4664465
> ___
> Arm.ebbr-discuss mailing list
> arm.ebbr-disc...@arm.com

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] U-boot

[Alexander Graf]

On 07/30/2018 06:02 PM, Rob Herring wrote:

On Mon, Jul 30, 2018 at 8:11 AM Alexander Graf  wrote:

On 07/30/2018 02:39 PM, Alexander Graf wrote:

On 07/30/2018 02:16 PM, David Rusling wrote:

Success.   I now have a u-boot built on Arm64 that works.   Along the
way I learnt various things:

[1] Raspberry Pi's first stage loader generates the device tree.
  Overlays are used to turn various things on (for example sound) at
boot time.

Yes. In order for those to propagate into U-Boot you will want to
enable CONFIG_OF_BOARD. That way the first stage generated DT gets
consumed by U-Boot as well. This allows you to run on CM3 or have the
same U-Boot binary for B and B+ for example.

I forgot to mention that for this to work fully with propagation of that
same device tree to an upstream kernel, you will also want to add the
"upstream" overlay. Just add a line saying "dtoverlay=upstream" to
config.txt. Then plug in any installer or image that is UEFI enabled
(and works with DT) and it should boot.

Yuck. That's a fix-up applied to the RPi downstream dtb, right? I
always just load my own (upstream) dtb. Who is providing the upstream
overlay, and how do you do dtb updates in this case as what is
upstream evolves? I'm just concerned this is very much RPi specific
and how can EBBR define managing dtb updates/storage in a consistent
way.


The downstream DT is actually derived from the upstream one. The 
upstream overlay is officially maintained in the downstream repo to 
bring compatibility back into upstream shape, without losing additional 
references that the downstream DT adds (that don't hurt upstream 
compatibility).


The main reason why I pushed for that model is that this way we can 
reuse the raspberry pi specific overlay mechanism and propagate a 
*single* device tree all the way from early boot to Linux.


EBBR itself isn't concerned with how the device tree gets into Linux, as 
long as firmware provides it one way or another and allows for updates. 
Whether firmware consumes it from yet another layer or not IMHO is out 
of scope of EBBR.



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] U-boot

[Alexander Graf]

On 07/30/2018 02:39 PM, Alexander Graf wrote:

On 07/30/2018 02:16 PM, David Rusling wrote:
Success.   I now have a u-boot built on Arm64 that works.   Along the 
way I learnt various things:


[1] Raspberry Pi's first stage loader generates the device tree.  
 Overlays are used to turn various things on (for example sound) at 
boot time.


Yes. In order for those to propagate into U-Boot you will want to 
enable CONFIG_OF_BOARD. That way the first stage generated DT gets 
consumed by U-Boot as well. This allows you to run on CM3 or have the 
same U-Boot binary for B and B+ for example.


I forgot to mention that for this to work fully with propagation of that 
same device tree to an upstream kernel, you will also want to add the 
"upstream" overlay. Just add a line saying "dtoverlay=upstream" to 
config.txt. Then plug in any installer or image that is UEFI enabled 
(and works with DT) and it should boot.



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] U-boot

[Alexander Graf]

On 07/30/2018 02:16 PM, David Rusling wrote:
Success.   I now have a u-boot built on Arm64 that works.   Along the 
way I learnt various things:


[1] Raspberry Pi's first stage loader generates the device tree.  
 Overlays are used to turn various things on (for example sound) at 
boot time.


Yes. In order for those to propagate into U-Boot you will want to enable 
CONFIG_OF_BOARD. That way the first stage generated DT gets consumed by 
U-Boot as well. This allows you to run on CM3 or have the same U-Boot 
binary for B and B+ for example.


[2] There's a big difference between fdt_addr and fdt_addr_r, 
depending on whether you're running mainstream u-boot or rpi u-boot.


What should "mainstream" U-Boot refer to here? "fdt_addr" is the U-Boot 
internal variable that it stores the location of the device tree to that 
was passed into it from a previous stage. "fdt_addr_r" is what the 
distro boot framework passes into whatever you load from within U-Boot.


There's also another one: "fdtcontroladdr". That's the one that U-Boot 
consumes itself.


[3] RPI3 is not really fully upstream, various bits always need to be 
added.  In other words, RPi, like a lot of Arm boards has its own 
mediated kernel tree, u-boot tree etc


That's not really true. We have a lot of happy customers running SLES 
(and openSUSE) off a fully upstream U-Boot + Linux kernel stack. It only 
gets hairy when you want to use things like the camera interface. Also 
from my experience the vc4 driver is very unstable.



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [PATCH] Update manifesto from comments on mailing list

[Alexander Graf]

On 11.07.18 22:15, Grant Likely wrote:
> On 11/07/2018 21:13, Simon Glass wrote:
>> Hi Grant,
>>
>> On 9 July 2018 at 06:17, Grant Likely  wrote:
>>> Editing in response to comments from Bill Mills, Daniel Thompson, and
>>> Alex Graf. Mostly trivial editorial, but did flush out the discussion of
>>> how future updates to the specification would be handled, and added a
>>> note about DT platform compatibility rules.
>>>
>>> Signed-off-by: Grant Likely 
>>> Cc: Bill Mills 
>>> Cc: Alexander Graf 
>>> Cc: Daniel Thompson 
>>> ---
>>>   source/chapter1-about.rst | 49
>>> ---
>>>   1 file changed, 34 insertions(+), 15 deletions(-)
>>>
>>
>> Reviewed-by: Simon Glass 
> 
> hahaha! You are about 5 minutes too late. I just pushed the patch to
> mainline. :-)
> 
> The mailing list archives are forever...
> 
>>
>>> diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
>>> index cb675d9..a2561d6 100644
>>> --- a/source/chapter1-about.rst
>>> +++ b/source/chapter1-about.rst
>>> @@ -23,7 +23,7 @@ It leverages the prevalent industry standard
>>> firmware specification of [UEFI]_.
>>>
>>>   Comments or change requests can be sent to arm.ebbr-disc...@arm.com.
>>>
>>> -Guiding Principals
>>> +Guiding Principles
>>>   ==
>>>
>>>   EBBR as a specification defines requirements on platforms and
>>> operating systems,
>>> @@ -51,7 +51,7 @@ amount of custom engineering required, make it
>>> possible for OS distributions to
>>>   support embedded platforms, while still preserving the firmware
>>> stack product
>>>   vendors are comfortable with.
>>>   Or in simpler terms, EBBR is designed to solve the embedded boot
>>> mess by
>>> -migrating existing firmware projects (U-Boot) to a defined standard
>>> (UEFI).
>>> +adding a defined standard (UEFI) to the existing firmware projects
>>> (U-Boot).
>>>
>>>   However, EBBR is a specification, not an implementation.
>>>   The goal of EBBR is not to mandate U-Boot and Linux.
>>> @@ -61,24 +61,33 @@ ensure that the EBBR requirements are implemented
>>> by both projects.
>>>   [#EDK2Note]_
>>>
>>>   .. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here
>>> because at the
>>> -   time of writing these are the two most important firmware projects.
>>> +   time of writing these are the two most important firmware
>>> projects that
>>> +   implement UEFI.
>>>  Tianocore/EDK2 is a full featured UEFI implementation and so should
>>> -   automatically be EBBR compliant. U-Boot is the incumbant firmware
>>> project
>>> -   for embedded platforms and has added basic UEFI compliance.
>>> +   automatically be EBBR compliant.
>>> +   U-Boot is the incumbant firmware project for embedded platforms
>>> and has
>>> +   steadily been adding UEFI compliance since 2016.
>>
>> Or 2015? That's when it got payload and app support. But I suspect you
>> are talking about the efi_loader support only?
> 
> Ask Alex, He provided the wording. :-)

Yes, EBBR only cares about the efi_loader parts. I guess you could
stretch the sentence to mean payload support too which really helped a
lot, but then again 1 year left or right won't make a big difference.


Alex
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] [PATCH] Introduction: add a manifesto

[Alexander Graf]

On 06.07.18 18:26, Grant Likely wrote:
> Give some rationale behind EBBR so the reader understands what problem
> the specification is intended to solve.
> 
> Signed-off-by: Bill Mills 
> [glikely: made it more verbose to make the intent clear]
> Signed-off-by: Grant Likely 
> ---
>  source/chapter1-about.rst | 94 
> +++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst
> index b667f1b..cb675d9 100644
> --- a/source/chapter1-about.rst
> +++ b/source/chapter1-about.rst
> @@ -23,6 +23,100 @@ It leverages the prevalent industry standard firmware 
> specification of [UEFI]_.
>  
>  Comments or change requests can be sent to arm.ebbr-disc...@arm.com.
>  
> +Guiding Principals
> +==
> +
> +EBBR as a specification defines requirements on platforms and operating 
> systems,
> +but requirements alone don't provide insight into why the specification is
> +written the way it is, or what problems it is intended to solve.
> +Using the assumption that better understanding of the thought process behind
> +EBBR will result in better implementations, this section is a discussion of 
> the
> +goals and guiding principle that shaped EBBR.

principles?

> +
> +This section should be considered commentary, and not a formal part of the 
> specification.
> +
> +EBBR was written as a response to the lack of boot sequence standardization 
> in the embedded system ecosystem.
> +As embedded systems are becoming more sophisticated and connected,
> +it is becoming increasingly important for embedded systems to run standard OS
> +distributions and software stacks, or to have consistent behaviour across a
> +large deployment of heterogeneous platforms.
> +However, the lack of consistency between platforms often requires 
> per-platform
> +customization to get an OS image to boot on multiple platforms.
> +
> +A large part of this ecosystem is based on U-Boot and Linux.
> +Vendors have heavy investments in both projects and are not interested in 
> large
> +scale changes to their firmware architecture.
> +The challenge for EBBR is to define a set of boot standards that reduce the
> +amount of custom engineering required, make it possible for OS distributions 
> to
> +support embedded platforms, while still preserving the firmware stack product
> +vendors are comfortable with.
> +Or in simpler terms, EBBR is designed to solve the embedded boot mess by
> +migrating existing firmware projects (U-Boot) to a defined standard (UEFI).
> +
> +However, EBBR is a specification, not an implementation.
> +The goal of EBBR is not to mandate U-Boot and Linux.
> +Rather, it is to mandate interfaces that can be implemented by any firmware 
> or
> +OS project, while at the same time work with both Tianocore/EDK2 and U-Boot 
> to
> +ensure that the EBBR requirements are implemented by both projects.
> +[#EDK2Note]_
> +
> +.. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here because at the
> +   time of writing these are the two most important firmware projects.

You probably want to clarify that they are the most important firmware
projects *implementing UEFI*. I'm quite sure that whatever Android does
easily outnumbers us ;).

> +   Tianocore/EDK2 is a full featured UEFI implementation and so should
> +   automatically be EBBR compliant. U-Boot is the incumbant firmware project
> +   for embedded platforms and has added basic UEFI compliance.

This document will love for a while. Maybe better document it as trajectory:

... and has steadily been adding UEFI compliance since 2016.

> +
> +The following guiding principals of the EBBR specification and its

principles again, but I guess you'll just search

> +process:
> +
> +- Be agnostic about ACPI and Devicetree.
> +
> +  EBBR explicitly does not require a specific system description language.
> +  Both Devicetree and ACPI are supported.
> +  While ACPI provides more standardization, Devicetree is preferred in may 
> embedded

many

> +  platforms for its flexibility.
> +  The Linux kernel supports both equally well, and so EBBR doesn't require 
> one
> +  over the other.
> +  However, it does require the system description to be provided by the
> +  platform, and that it conform to the relevant ACPI or DT specifications.

... and adhere to strict compatbility rules.


Alex
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] UEFI requirements section

[Alexander Graf]

On 06.07.18 14:57, Grant Likely wrote:
> Dong,
> 
> Looking at the current state of EBBR, Appendix A contains a big list of
> boot/runtime services and protocols that are required to be implemented.
> However, I don't think this list has been audited, and I'm not sure how
> much of it is actually needed. Some of these things (like the list of
> boot/runtime services) seem to be required by the UEFI spec, so it is
> redundant to list them here.
> 
> I'm also unsure on the list of protocols. Some I'm sure are already
> required by the UEFI spec. e.g., UEFI section 2.6.1 requires
> EFI_LOADED_IMAGE_PROTOCOL, EFI_LOADED_IMAGE_DEVICE_PATH,
> EFI_DEVICE_PATH_PROTOCOL, EFI_DECOMPRESS_PROTOCOL, and
> EFI_DEVICE_PATH_UTILITIES_PROTOCOL, so is it necessary to list them in
> EBBR?
> 
> Looking at the current U-Boot implementation, only the following
> protocols are implemented:
> 
> include/efi_api.h|277| #define LOADED_IMAGE_PROTOCOL_GUID \
> include/efi_api.h|519| #define EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID \
> include/efi_api.h|590| #define EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID \
> include/efi_api.h|603| #define EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID \
> include/efi_api.h|619| #define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \
> include/efi_api.h|853| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \
> include/efi_api.h|882| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \
> include/efi_api.h|933| #define EFI_DRIVER_BINDING_PROTOCOL_GUID \

I think this list is missing a few protocols we do implement. Here's a
list of the current efi-next tree:

$ git grep -e '^const efi_gui' lib/efi_loader | cut -d ' ' -f 3
efi_guid_fdt
efi_guid_driver_binding_protocol
efi_guid_event_group_exit_boot_services
efi_guid_event_group_virtual_address_change
efi_guid_event_group_memory_map_change
efi_guid_event_group_ready_to_boot
efi_guid_event_group_reset_system
efi_guid_text_output_protocol
efi_guid_text_input_protocol
efi_guid_device_path_to_text_protocol
efi_guid_device_path_utilities_protocol
efi_block_io_guid
efi_file_system_info_guid
efi_global_variable_guid
efi_guid_device_path
efi_guid_loaded_image
efi_simple_file_system_protocol_guid
efi_file_info_guid

Alex
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] [RFC PATCH] Fill out the system firmware discussion

[Alexander Graf]

On 08.06.18 21:57, Grant Likely wrote:
> Add some more detail on how to handle system firmware. I'm still
> undecided about this, so this patch is more of an RFC discussion than a
> serious patch. Please comment.
> 
> Cc: Daniel Thompson 
> Signed-off-by: Grant Likely 
> ---
>  source/ebbr.rst | 58 
> -
>  1 file changed, 53 insertions(+), 5 deletions(-)
> 
> diff --git a/source/ebbr.rst b/source/ebbr.rst
> index 3998397..c24cef5 100644
> --- a/source/ebbr.rst
> +++ b/source/ebbr.rst
> @@ -200,16 +200,64 @@ System Volume Format
>  The system firmware must support all partitioning standards required
>  by the UEFI specification.
>  
> -On systems where the system firmware binaries reside on the System Volume 
> then
> -the System Volume must be pre-configured with a partition table and include
> -protective partitions to reduce risk of accidental destruction of the system
> -firmware.
> -
>  All pre-installed partition tables must use GPT partitioning unless
>  some immutable feature of the platform (such as a mask programmed boot ROM)
>  makes this impossible; on such platforms MBR partitioning may be
>  used as an alternative.
>  
> +System Firmware Partitions
> +^^
> +On systems where the system firmware binaries reside on the System Volume 
> then
> +the System Volume must be pre-configured with a partition table and system
> +firmware binaries.
> +
> +When system firmware is located at a fixed offset, It is strongly recommended
> +for the partition table to include protective partitions covering the 
> location
> +of firmware to reduce risk of accidental destruction of the system firmware.
> +
> +System boot ROM should obtain the system firmware partition location
> +by reading the partition table.
> +Using a fixed offset into the storage media is deprecated and should
> +not be used for new SoC designs.
> +Future issues of this specification will disallow the use of fixed offsets.

Why should we bother? The only difference between a fixed offset and a
partition location is that the protected firmware partition is
non-movable. It's probably a good idea to assume it can't be moved in
the first place though, since you may always run into bootrom
limitations (like 2G barriers, etc).

I would much rather like to see a note here saying that fixed offsets
are allowed at offset . If firmware wants to sit at 1MB and
reserve a range up to 16MB and puts a reservation partition there, I
don't see any big difference from an OS point of view over a partition
that just happens to sit at 1MB and is 15MB big.

> +A system firmware partition should not also be used as a EFI System
> +Partition (ESP).
> +Pre-installed system firmware partitions must not use the ESP GUID,
> +and OS installation tools should not install EFI executables in a system
> +firmware partition.
> +
> +.. todo::
> +
> +   I'm not sure if this is a good idea. It might be that EBBR should define a
> +   common GUID for system firmware partitions. It also might be that I'm 
> worrying
> +   too much and it is fine to use the ESP as a system firmware partition.
> +   This TODO note is a bit of a discussion of the options.

I personally don't mind to allow use of the ESP as system firmware
partition. It can be very convenient on MBR based systems, as we're
otherwise running out of primary partitions quite quickly.

> +
> +   Options:
> +
> +   - Require ESP and SFPs to be separate
> + - Should a common SFP GUID be defined so a single image can hold 
> firmware
> +   for multiple platforms?
> +   - Don't have to repartition to add additional platforms.
> + - Yet repartitioning required to add the *first* platform

That's an interesting idea, yeah. I would love to have a single SD image
for all 96boards. That in turn obviously clarifies why fixed offsets are
a bad idea.

So we need to be smarter here. If we allow multiple system firmware
partitions, they will have to follow a scheme that allows for 50
different ones to coexist - potentially even on MBR. So we need to have
a requirement that the bootrom loops through all and has a unique
identifier to find the relevant one.

> +   - Require FAT formatting?

FAT of what? IMHO what I would do is allow either ESP+defined path for
system firmare or separate partition with one partition per target device.

> +   - Probably also requires a vendor/soc/file pathname spec to avoid
> + conflicts.

Yes, that's definitely needed.

> +   - OS can mount the ESP without touching SFPs. This means firmware 
> could
> + perform (mediated) operations on the SPF (ex. to update variables)
> + without unmounting the ESP.

If both are on the same block device that is still tricky, no?


Alex

> +   - Downside: Requries at least two fixed sized partitions to boot the
> + platform: a SFP, and the ESP. A single combined SFP+ESP would be 
> more
> + efficient on space.
> +   

Re: [Arm.ebbr-discuss] [PATCH] Issue#10 Add EBBR compliance test

[Alexander Graf]

On 05/23/2018 12:14 AM, Udit Kumar wrote:

This patch adds a appendix for EBBR compliance test.

Signed-off-by: Udit Kumar 
---
  source/ebbr.rst | 16 
  1 file changed, 16 insertions(+)

diff --git a/source/ebbr.rst b/source/ebbr.rst
index 40f03f1..880f126 100644
--- a/source/ebbr.rst
+++ b/source/ebbr.rst
@@ -557,6 +557,22 @@ ServiceUEFI §
  EFI_ISCSI_INITIATOR_NAME_PROTOCOL  16.2
  == ==
  
+***

+APPENDIX E - EBBR Compliance Tests
+***
+
+UEFI Self Certification Tests (SCT) test the UEFI implementation.
+EBBR is leveraging from UEFI, UEFI SCT test suites  check for compliance
+against the EBBR specification.
+To build UEFI SCT, please refer https://github.com/UEFI/UEFI-SCT


Please reword the above to something that is easier to read (and 
grammatically correct). I also think you may want to structure it from 
big picture to small picture. So you should first mention that EBBR will 
need multiple compliance test pieces to run and only then mention SCT as 
the method to verify UEFI compliance.



+
+EBBR is very flexible and many features are platform dependent.
+Therefore platform owner can decide, to implement and test optional features
+with UEFI SCT.


I think a lot of the requirements that get put into this document can be 
generically verified, so I wouldn't wave it off that quickly as "it's 
flexible, so someone may or may not test things". Instead, I'd rather 
like to see a reference in here that a test kit for EBBR is in 
development and will probably not be finished in time for EBBR 1.0, but 
is expected at a later point.



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [RFC PATCH] driver core: make deferring probe forever optional

[Alexander Graf]

On 05/14/2018 12:01 AM, Linus Walleij wrote:

On Wed, May 9, 2018 at 11:44 AM, Alexander Graf <ag...@suse.de> wrote:

On 05/07/2018 08:31 PM, Bjorn Andersson wrote:

Can you please name platform that has enough support for Alexander to
care about backwards and forwards compatibility but lacks a pinctrl
driver.

ZynqMP is one example that immediately comes to my mind. I'm sure there are
others too.

Why isn't that using drivers/pinctrl/pinctrl-zynq.c?

How is it so very different from (old) Zynq as it is already using
the same GPIO driver?


That one is very simple: ZynqMP is usually an AMP system where Linux 
doesn't have full knowledge of the overall system. IIUC they have a tiny 
microblaze (PMU) that does the actual full system configuration for 
peripherals that may interfere with each other. This architecture also 
allows for safety critical code to run alongside a (less safe) Linux system.


I think we'll see architectures like this pop up more over time. TI 
Sitara has similar issues. I know that Jailhouse ran into exactly that 
problem before. I also know that during Linaro Connect Budapest even the 
OP-TEE people realized the current model is bad, because Linux may 
control pins/clocks/etc of devices that the secure world wants to use.


So I actually believe we will see more SoCs in the future that may even 
start with Linux controllable pinctrl or no pinctrl driver but then will 
move to firmware controlled drivers once it starts being necessary.



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

[Alexander Graf]

On 05/07/2018 08:46 PM, Rob Herring wrote:

On Mon, May 7, 2018 at 12:17 PM, William Mills <wmi...@ti.com> wrote:


On 05/07/2018 11:49 AM, Rob Herring wrote:

On Fri, May 4, 2018 at 1:41 PM, William Mills <wmi...@ti.com> wrote:

On 05/04/2018 01:03 PM, Andreas Färber wrote:

Am 04.05.2018 um 18:50 schrieb Alexander Graf:

On 05/04/2018 06:20 PM, William Mills wrote:

On 05/04/2018 11:45 AM, Alexander Graf wrote:
I am missing something.  If there is only MBR and no GPT then there is
no GUID type for EFI Partition.  So how does the firmware find the "EFI
Partition" and the default /efi/boot/boot*.efi file?  Does it just use
the partition with boot flag?

There is a special partition ID for the ESP (0xEF), but U-Boot currently
just searches on every partition that's marked bootable.

... and falls back to the first partition if none on the device is
marked bootable.


Thanks guys, that makes sense.

So the running summary in my head looks like this:

Case #1: Platforms that have separate storage for firmware and OS

OS storage is simple std GPT with no funny MBR stuff.
One image may work on many boards.

Case #2: Platforms where firmware and OS share single storage

Storage uses either GPT or MBR (but only one) based on board need.
Image is dedicated for one machine type (or closely related set).
If raw mode is needed use MBR with 2MB reserved space
OS should not touch reserved space in MBR
If using GPT, firmware should place needed files in either:
 * Vendor registered dir in EFI partition
 * GUID identified partitions w/ attribute bit 0 set
 (can fallback to using names if GUID not found)

This is for all the other stuff vendors stick in custom partitions if
we're lucky or some fixed offset if we're not, right?


Yes.  Today people seem to be using a GPT partition for each of these
low level objects and seem to be using the partition name to identify
them.  They are using very generic names like "boot".

This means that the disk image will only work with one SOC or perhaps
even one board.

If people are going to use raw GPT partitions I think they should at
least use a GUID GPT partition type to give certainty.  Falling back to
a name is OK and will help the casual user.

Bit 0 of the GPT attributes table is listed as "Platform required".
Do current installers leave these partitions alone?

I'll leave that to one of the OS folks.


I double checked with our YaST people. The "Platform required" bit in 
GPT gets translated to the "hidden" bit in parted. That bit is then 
happily ignored by our installer.


So the installer may consider the partition ok to remove.


Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [RFC PATCH] driver core: make deferring probe forever optional

[Alexander Graf]

On 05/08/2018 12:34 AM, Bjorn Andersson wrote:

On Mon 07 May 12:55 PDT 2018, Rob Herring wrote:


On Mon, May 7, 2018 at 1:31 PM, Bjorn Andersson
 wrote:

On Tue 01 May 14:31 PDT 2018, Rob Herring wrote:


Deferred probe will currently wait forever on dependent devices to probe,
but sometimes a driver will never exist. It's also not always critical for
a driver to exist. Platforms can rely on default configuration from the
bootloader or reset defaults for things such as pinctrl and power domains.

But how do you know if this is the case?

Because the platform worked before adding the dependency in the dts.


I'm worried about how to write dts files and drivers to support all
permutation of forward and backward dependencies. And you most
definitely have the same case with bootloader-enabled clocks,
regulators and interconnects.


This is often the case with initial platform support until various drivers
get enabled.

Can you please name platform that has enough support for Alexander to
care about backwards and forwards compatibility but lacks a pinctrl
driver.

Alex will have to answer that. I do agree pinctrl drivers shouldn't be
that hard because it is all just translating a bunch of pin data into
one-time (mostly) register writes, so it shouldn't take that long to
implement support. OTOH, maybe a pinctrl driver is low priority
because nothing needs it yet. Either a given board works with the
defaults and only some new board needs to change things or you don't
need pinctrl until low power modes are implemented. However, power
domains have the same problem and it can take years for those to get
proper support.

Alex proposed declaring dts files stable and then enforcing
compatibility after that point. If anyone believes that will work,
then please send a patch marking all the platforms in the kernel tree
that are stable.


That might be a reasonable idea, but at least in our corner the current
decision that devicetree should be backwards compatible does make it
quite cumbersome to break this assumption - and in the cases we have had
to do it it's really been necessary.


I'm sure Rob would be happy to get a list of every one of those 
instances so we can see how to solve them going forward.


To give you some background: The whole discussion started with a 
proposal from me to support embedded (maybe dtc aided) overlays. Some 
way to have a single dtb that only enables new features such as pinctrl 
when the kernel indicates support for them.


I think eventually we will have to have a mechanism like that for 
platforms that want to maintain compatibility. But the less we have to 
solve using it the better off everyone is, because it just increases 
complexity.





There's at least 2 scenarios where deferred probe can render
a platform broken. Both involve using a DT which has more devices and
dependencies than the kernel supports. The 1st case is a driver may be
disabled in the kernel config.

I agree that there is a chance that you _might_ get some parts of the
system working by relying on the boot loader configuration, but
misconfiguration issues applies to any other fundamental providers, such
as clocks, regulators, power domains and gpios as well.

If it is only a chance, then perhaps we shouldn't allow things
upstream without proper drivers for all these things. That will only
give users the wrong impression.


It's not as much the drivers that's the problem here as it is the
composition of the drivers. For this particular case it would be
convenient not to ship the partial dtb, or at least not ship it with the
promise that it's stable.


Yes, we of course need a gatekeeping event. Not every DT is in a state 
where you can promise compatibility.


However, if you want to have a stable OS interface so that slow moving 
Linux distribtions work well with the platform and non-Linux OSs jump on 
the platform, you will have to provide some guarantees. And people just 
need to be aware that they either give the guarantees or they don't get 
their benefits :).





The 2nd case is the kernel version may
simply not have the dependent driver. This can happen if using a newer DT
(provided by firmware perhaps) with a stable kernel version.


As above, this is in no way limited to pinctrl drivers.

Yes, I wasn't trying to imply that with this patch. I was just
starting with 1 example. IOMMUs (which essentially is already doing
what this patch does) and power domains are the main other 2.

qcom,iommu-v1 is bool, but depends on e.g. CONFIG_MSM_GCC_8916 which is
tristate. So you would need to s/tristate/bool/ everything in
drivers/clk/qcom/Kconfig as well. Not to mention that there are
interconnects and power domains actually involved here as well...


Clocks is an obvious one too, but from the discussion I referenced
that problem is a bit different as platforms change from dummy
fixed-clocks to a real clock controller driver. That will need a
different solution.

So how are you going 

Re: [RFC PATCH] driver core: make deferring probe forever optional

[Alexander Graf]

On 05/07/2018 08:31 PM, Bjorn Andersson wrote:

On Tue 01 May 14:31 PDT 2018, Rob Herring wrote:


Deferred probe will currently wait forever on dependent devices to probe,
but sometimes a driver will never exist. It's also not always critical for
a driver to exist. Platforms can rely on default configuration from the
bootloader or reset defaults for things such as pinctrl and power domains.

But how do you know if this is the case?


This is often the case with initial platform support until various drivers
get enabled.

Can you please name platform that has enough support for Alexander to
care about backwards and forwards compatibility but lacks a pinctrl
driver.


ZynqMP is one example that immediately comes to my mind. I'm sure there 
are others too.


In general it's very frustrating to debug what goes wrong when you can't 
even get serial to output anything at all just because there are now 
pinctrl bindings that your kernel may not know about yet. I've run into 
that too many times.





There's at least 2 scenarios where deferred probe can render
a platform broken. Both involve using a DT which has more devices and
dependencies than the kernel supports. The 1st case is a driver may be
disabled in the kernel config.

I agree that there is a chance that you _might_ get some parts of the
system working by relying on the boot loader configuration, but
misconfiguration issues applies to any other fundamental providers, such
as clocks, regulators, power domains and gpios as well.


The 2nd case is the kernel version may
simply not have the dependent driver. This can happen if using a newer DT
(provided by firmware perhaps) with a stable kernel version.


As above, this is in no way limited to pinctrl drivers.


Unfortunately, this change breaks with modules as we have no way of
knowing when modules are done loading. One possibility is to make this
opt in or out based on compatible strings rather than at a subsystem level.
Ideally this information could be extracted automatically somehow. OTOH,
maybe the lists are pretty small. There's only a handful of subsystems
that can be optional, and then only so many drivers in those that can be
modules (at least for pinctrl, many drivers are built-in only).


On the Qualcomm platform most drivers are tristate and on most platforms
there are size restrictions in the proprietary boot loader preventing us
from boot the kernel after switching all these frameworks from tristate
to bool (which feels like a more appropriate solution than your hack).


I don't see how setting them to bool contradicts with the hack? The goal 
of this patch is to allow systems to load drivers on firmware provided 
pinctrl setups if there is no matching pinctrl driver in the kernel.





Cc: Alexander Graf <ag...@suse.de>
Signed-off-by: Rob Herring <r...@kernel.org>
---
This patch came out of a discussion on the ARM boot-architecture
list[1] about DT forwards and backwards compatibility issues. There are
issues with newer DTs breaking on older, stable kernels. Some of these
are difficult to solve, but cases of optional devices not having
kernel support should be solvable.


There are two cases here:
1) DT contains compatibles that isn't supported by the kernel. In this
case the associated device will remain in the probe deferral list and
user space won't know about the device.

2) DT contains compatibles known to the kernel but has new optional
properties that makes things functional or works around hardware bugs.


The key point is not to regress. Imagine you have firmware 1.0 which 
works with OS 1.0. Firmware provides the device tree.


When you update to firmware to 1.1 you want to make sure OS 1.0 still 
works. The bug you're referring to that existed before of course still 
exists. But we're not worse off.





I tested this on a RPi3 B with the pinctrl driver forced off. With this
change, the MMC/SD and UART drivers can function without the pinctrl
driver.


Cool, so what about graphics, audio, networking, usb and all the other
things that people actually expect when they _use_ a distro?


Again, it's about regressions. If audio didn't work before, a firmware 
update may not get you working audio with OS 1.0. But it may enable OS 
1.1 to provide audio.



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

[Alexander Graf]

On 08.05.18 18:09, Daniel Thompson wrote:
> On Tue, May 08, 2018 at 05:43:51PM +0200, Alexander Graf wrote:
>>
>>
>> On 08.05.18 16:38, Daniel Thompson wrote:
>>> On Fri, May 04, 2018 at 02:41:56PM -0400, William Mills wrote:
>>>>
>>>> On 05/04/2018 01:03 PM, Andreas Färber wrote:
>>>>> Am 04.05.2018 um 18:50 schrieb Alexander Graf:
>>>>>> On 05/04/2018 06:20 PM, William Mills wrote:
>>>>>>> On 05/04/2018 11:45 AM, Alexander Graf wrote:
>>>>>>> I am missing something.  If there is only MBR and no GPT then there is
>>>>>>> no GUID type for EFI Partition.  So how does the firmware find the "EFI
>>>>>>> Partition" and the default /efi/boot/boot*.efi file?  Does it just use
>>>>>>> the partition with boot flag?
>>>>>>
>>>>>> There is a special partition ID for the ESP (0xEF), but U-Boot currently
>>>>>> just searches on every partition that's marked bootable.
>>>>>
>>>>> ... and falls back to the first partition if none on the device is
>>>>> marked bootable.
>>>>>
>>>>
>>>> Thanks guys, that makes sense.
>>>>
>>>> So the running summary in my head looks like this:
>>>>
>>>> Case #1: Platforms that have separate storage for firmware and OS
>>>>
>>>> OS storage is simple std GPT with no funny MBR stuff.
>>>> One image may work on many boards.
>>
>> GPT or MBR. The UEFI spec allows for either of them and so should we.
>>
>>>>
>>>> Case #2: Platforms where firmware and OS share single storage
>>>>
>>>> Storage uses either GPT or MBR (but only one) based on board need.
>>>
>>> As in you want to require a pure protective MBR and prohibit any form of
>>> hybriding?
>>>
>>> I'm OK with this... much simpler than requiring distros never to touch
>>> the MBR of a GPT system!
>>
>> Yes :). Case 1 and 2 are bascially identical.
>>
>>>
>>>
>>>> Image is dedicated for one machine type (or closely related set).
>>>> If raw mode is needed use MBR with 2MB reserved space
>>>> OS should not touch reserved space in MBR
>>>
>>> I'd still prefer that EBBR compliant firmware (where firmware is loaded
>>> from shared media) have a protective partition describing the first
>>> 2MB at the point the firmware is installed to the shared media.
>>
>> The problem with a protective partition is that getting changes into
>> partitioning tools is really hard - and there are many of those out
>> there :).
> 
> Sorry, don't follow.
> 
> Why does requiring an EBBR compliant firmware to provide a protective
> partition describing the first N megabytes imply updating all
> partitioning tools? It is not the OS that has to create it; it is the
> firmware author and they can choose a working tool for this (possibly 
> in expert mode to create the non-aligned partition).

A lot of OSs have installers which end up repartitioning existing disk
targets. I wouldn't vouch for them to not nuke non-ESP partitions :).

>> Also, I think we should only declare 1MB as reserved. If someone needs
>> more space, they should really go the dedicated / separate partition
>> route and use something like SPL to read from one of the options below.
>>
>> The reason 1MB is so convenient is that basically all partitioning tools
>> today already give you a natural 1MB alignment. So there are no OS
>> changes needed.
> 
> Again, don't entirely follow.
> 
> "they should really go the dedicated / separate partition route" implies 
> that implies that an installer should try to recognise it as a protective
> partition and not nuke it (unless the user really, really insists).
> 
> That also implies it can leave a pre-existing protective partition
> covering the first N megabytes alone doesn't it?

If we conclude that reusing the ESP is good enough then we don't need to
manually cover anything. We can simply declare 0.2MB (end of GPT) - 1MB
(start of first partition) of the target disk as reserved for firmware
purposes. If we make it as easy as shoving all additional resources into
the ESP, everything will "just work".

> 
> 
>>>> If using GPT, firmware should place needed files in either:
>>>>* Vendor registered dir in EFI partition
>>>>* GUID identified partitions w/ attribute bit 0 set
>>>>(can fallback to using names if GUID 

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

[Alexander Graf]

On 08.05.18 16:38, Daniel Thompson wrote:
> On Fri, May 04, 2018 at 02:41:56PM -0400, William Mills wrote:
>>
>> On 05/04/2018 01:03 PM, Andreas Färber wrote:
>>> Am 04.05.2018 um 18:50 schrieb Alexander Graf:
>>>> On 05/04/2018 06:20 PM, William Mills wrote:
>>>>> On 05/04/2018 11:45 AM, Alexander Graf wrote:
>>>>> I am missing something.  If there is only MBR and no GPT then there is
>>>>> no GUID type for EFI Partition.  So how does the firmware find the "EFI
>>>>> Partition" and the default /efi/boot/boot*.efi file?  Does it just use
>>>>> the partition with boot flag?
>>>>
>>>> There is a special partition ID for the ESP (0xEF), but U-Boot currently
>>>> just searches on every partition that's marked bootable.
>>>
>>> ... and falls back to the first partition if none on the device is
>>> marked bootable.
>>>
>>
>> Thanks guys, that makes sense.
>>
>> So the running summary in my head looks like this:
>>
>> Case #1: Platforms that have separate storage for firmware and OS
>>
>> OS storage is simple std GPT with no funny MBR stuff.
>> One image may work on many boards.

GPT or MBR. The UEFI spec allows for either of them and so should we.

>>
>> Case #2: Platforms where firmware and OS share single storage
>>
>> Storage uses either GPT or MBR (but only one) based on board need.
> 
> As in you want to require a pure protective MBR and prohibit any form of
> hybriding?
> 
> I'm OK with this... much simpler than requiring distros never to touch
> the MBR of a GPT system!

Yes :). Case 1 and 2 are bascially identical.

> 
> 
>> Image is dedicated for one machine type (or closely related set).
>> If raw mode is needed use MBR with 2MB reserved space
>> OS should not touch reserved space in MBR
> 
> I'd still prefer that EBBR compliant firmware (where firmware is loaded
> from shared media) have a protective partition describing the first
> 2MB at the point the firmware is installed to the shared media.

The problem with a protective partition is that getting changes into
partitioning tools is really hard - and there are many of those out
there :).

Also, I think we should only declare 1MB as reserved. If someone needs
more space, they should really go the dedicated / separate partition
route and use something like SPL to read from one of the options below.

The reason 1MB is so convenient is that basically all partitioning tools
today already give you a natural 1MB alignment. So there are no OS
changes needed.

> 
> 
>> If using GPT, firmware should place needed files in either:
>>  * Vendor registered dir in EFI partition
>>  * GUID identified partitions w/ attribute bit 0 set
>>  (can fallback to using names if GUID not found)

No need to couple these to GPT. You can always have a vendor registered
directory in the ESP with MBR as well.

For GUID partitions a GPT is obviously necessary.

>>
>> Should we consider a future case #3?
>> Case #3: New Platforms where firmware and OS share storage
>>
>> Storage uses std GPT with no exceptions.
>> Image may work with N preknown boards that are unrelated.
>> Firmware files are all in a vendor specified dir in the EFI partition
> 
> Not sure about this.
> 
> For eMMC we'd prefer the boot ROM just load the firmware from the boot 
> partition,
> then the OS can do whatever it wants with the main media (which could ship
> completely unpartitioned and leave it to the OS).
> 
> For UFS, the case is similar, although with multi-layer partitioning the
> terminology is hard. Either way we should rely on flash partitioning so
> that the firmware can be entirely separated by hardware partition. Again
> the flash partition to OS will be installed has not particular need to
> be partitioned in any way at all.
> 
> When booting from media without any hardware partitioning the case #3
> scheme looks good although even there I'm not sure about the need to
> have an image work on unrelated boards though. To be useful it implies 
> that EBBR implementations from different vendors can be combined in
> one disk image (i.e. that vendors will make EBBR implementations
> available with a license to redistribute them). We probably don't want
> to go there... even by implication!

Well, with a fully U-Boot stack for example this should be easily
achievable. I don't think it's a bad idea to suggest. Imagine a world
where you could download a single image that just happens to run on all
96boards!


Alex
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] Booting from eMMC without the boot protocol

[Alexander Graf]

On 05/04/2018 06:20 PM, William Mills wrote:

[explicitly cc'ing boot-arch to see if this solves the TI auth problems]

On 05/04/2018 11:45 AM, Alexander Graf wrote:

On 05/04/2018 04:56 PM, Grant Likely wrote:

On 04/05/2018 15:46, Grant Likely wrote:

On 03/05/2018 09:43, Daniel Thompson wrote:

On Wed, May 02, 2018 at 06:09:15PM -0400, Tom Rini wrote:

On Wed, May 02, 2018 at 10:48:11PM +0100, Grant Likely wrote:

On 02/05/2018 22:24, Tom Rini wrote:

On Wed, May 02, 2018 at 08:40:42PM +0100, Daniel Thompson wrote:

In terms of the restrictions that come from EBBR mandating GPT:

Can we step back, why is EBBR mandating GPT?

I think EBBR should recommend GPT, but allow MBR if the SoC boot
masked
rom conflicts with GPT.

In the early days of GPT there was also a hybrid GPT+MBR scheme that
could list the boot partition in the MBR, but still have a full
GPT. It
isn't pretty, but there is precidence.

How about recommends GPT but allows MBR, no qualifiers.  As you note
there's a lot of ways to fiddle around and make it work, probably, on
all of the existing SoCs that do magic offsets.  But it's a lot easier
to just allow MBR (what the SoCs were designed to have to live
with) and
guide line that in this case nothing before the first 2MiB be used by
the OS.  With a few more spec words around all of that so it's nice
and
formal :)

I'm OK to allow MBR.

I'd be inclined to require that protective partitions be used to defend
the first 2MB though. They are more flexible and are a useful hint to
anyone trying to manually partition.


In a different mail Tom wrote:

And I agree with the high level idea of needing to do something to
protect systems with a magic in-use spot.

There are a couple of extra details.

1. We can't allocate a GUID to discourage an automatic partitioner
     from harming a protected partition. We only have the 8-bit
     partition type.
     Some potential candidates could be 0xA2 (which Altera appear use
     for a similar purpose), 0xE7 (wikipedia does not report existing
     uses) or 0xF0 (PA-RISC Linux boot loader).

2. Boot ROMs that have built-in support for FAT could be hard coded to
     require a specific partition type. >
I think we don't need to worry about #2 to much: systems with built-in
MBR/FAT parsing can use hybrid MBR/GPT to communicate to distros
which partitions are protected because (presumably) they allow
flexibility in placing the first sector of the FAT partition.

Can we start a list of SoCs that have special requirements on the
boot eMMC/SD/USB? It would be useful to see the cross-section of
requirements.

I've created a wiki page to start capturing data. From their we can
decide what scenarios the spec needs to cover.

https://github.com/glikely/ebbr-for-discussion/wiki/Boot-Media-Behaviour

One more thought, are there many new SoCs still using hard coded
offsets instead of an MBR or GPT? It may be that there aren't enough
left for us to care about for EBBR level 0. In which case EBBR Level 0
should support both MBR and GPT (non-hybrid), and then narrow to GPT
only in a future revision.

I don't think we'll be able to move away from MBR anytime soon. For a
quick glimpse on what SoCs need to have blobs installed where, take a
look at our image creation script:

https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM:Live/JeOS/uboot-image-install.in?expand=1


There you can see that we force to MBR (for various reasons) on:

   * RPi (reads MBR)
   * i.MX 5x/6 (SPL at sector 2)
   * Exynos 4/5 (SPL is in sector 1, not sure about newer ones)
   * AM905 (SPL in sector 1)
   * Kirkwood (SPL in sector 1)
   * Zynq(MP) (convenient to store boot.bin on FAT partition in MBR)

I think we should simply dictate that EBBR compliant OSs do not start
any partitions before a sane boundary (1MB? 2MB?). IIRC most
partitioning tools these days won't start partitions before 1MB anyway,
so if we declare 1MB a safe bound we essentially have no work to do.



I did skim (not study) the script.  Looks like a good resource of
current board info.  I see you are using raw mode for many boards.


Yes, we usually prefer raw mode over anything else, as it's then more 
consistent across the different platforms. Special "firmware partitions" 
just become maintenance headaches because then suddenly our partitioner 
needs adoption and awareness.



I am missing something.  If there is only MBR and no GPT then there is
no GUID type for EFI Partition.  So how does the firmware find the "EFI
Partition" and the default /efi/boot/boot*.efi file?  Does it just use
the partition with boot flag?



There is a special partition ID for the ESP (0xEF), but U-Boot currently 
just searches on every partition that's marked bootable.



Alex


___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: DT handling, [Ref Linux-Efi]

[Alexander Graf]

On 03.05.18 18:11, Rob Herring wrote:
> On Thu, May 3, 2018 at 9:29 AM, Alexander Graf <ag...@suse.de> wrote:
>> On 04/30/2018 08:36 PM, Rob Herring wrote:
>>>
>>> On Fri, Apr 27, 2018 at 4:39 PM, Alexander Graf <ag...@suse.de> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> On 27.04.18 18:40, Rob Herring wrote:
>>>>>
>>>>> On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf <ag...@suse.de> wrote:
>>>>>>
>>>>>>
>>>>>> On 27.04.18 08:24, Udit Kumar wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>> There is bit of discussion on linux-efi too , to handle DT update
>>>>>>>
>>>>>>> I guess some members of this forum are active there too.
>>>>>>>
>>>>>>> https://www.spinics.net/lists/linux-efi/msg13700.html
>>>>>>>
>>>>>>> To summaries
>>>>>>> 1/ Ownership of DTB
>>>>>>> IMO should be firmware and we should retain this
>>>>>>> ownership in EBBR as well, Any objections/thoughts ?
>>>>>>
>>>>>> I fully agree. On top of that we need to make clear that backward and
>>>>>> forward compatibility are not optional.
>>>>>>
>>>>>> For that I think we may need to actually give people workable solutions
>>>>>> to create device trees that are compatible with multiple levels of
>>>>>> kernel support. The main areas I'm aware of that keep breaking are:
>>>>>>
>>>>>>* fine grained interrupt controller support
>>>>>
>>>>> Do you have an example of that? The only thing I can think of is
>>>>> people switching interrupts from the GIC to an always-on, low-power
>>>>> mode custom interrupt controller.
>>>>
>>>> The last time I've seen that breakage was:
>>>>
>>>>
>>>>
>>>> https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/bcm270x.dtsi#L158
>>>>
>>>> which indeed does switch interrupts from the GIC to an interrupt muxer
>>>> behind the GIC.
>>>>
>>>> The problem is that once support for that lands upstream, you will have
>>>> very little option but to break backwards compatibility today.
>>>
>>> This one is unfortunate. It could have been handled better. An
>>> interrupt-map property in the aux ctrlr could have mapped the
>>> interrupts to GIC without any aux driver. Then when the aux driver
>>> lands, it just needs to remove the interrupt-map (on boot).
>>
>>
>> To do that you would've needed to know that you need the change in the first
>> place ;).
> 
> Actually, I think we can still solve this. Add the interrupt-map now.
> Then when the aux driver lands it has to fixup the interrupt-map> I think I 
> actually hit the problem when testing my deferred probe
> patch. I saw a 30 sec delay in the console output when the pl011
> driver probed and using the pl011 as the console (they really made a
> mess of the serial console on RPi 3).
> 
>>> Alternatively, I skimmed thru some discussions of the issue, but I'm
>>> not clear why the devices behind the aux controller can't all just
>>> treat their interrupts as shared. But that would be a simple change to
>>> the drivers' irq handlers, so I'm probably missing something. If that
>>> worked, then the DT would never need to change.
>>>
>>> I guess whether this could have been handled better depends if folks
>>> knowingly ignored the issue or this was found after upstreaming
>>> support. The latter case may be unavoidable, but maybe we can make it
>>
>>
>> I think most of these cases are the latter.
>>
>>> rare enough we only need overlays in some exceptions. Whether we try
>>> to be stricter and do better up front or have some overlay based
>>> solution, either one is going to require folks be aware of the issues
>>> and effort to avoid them.
>>
>>
>> Yes, but with the overlay approach we can temper it up after the fact :).
> 
> I was assuming you did not want to be the one to find all the issues
> and fix them. You do want upstream to do a better job and avoid some
> of the issues to begin with, right?

Oh I don't want to be the one, but I don't believe in humans finding
100% of all errors. So I want to also have an answer for the 10% that
fall through

Re: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi]

[Alexander Graf]

> Am 03.05.2018 um 16:31 schrieb Daniel Thompson <daniel.thomp...@linaro.org>:
> 
>> On Thu, May 03, 2018 at 09:02:40AM -0500, Rob Herring wrote:
>> On Thu, May 3, 2018 at 5:13 AM, Daniel Thompson
>> <daniel.thomp...@linaro.org> wrote:
>>> On Wed, May 02, 2018 at 05:39:02PM -0400, Tom Rini wrote:
>>>> On Wed, May 02, 2018 at 05:12:03AM +, Chang, Abner (HPS SW/FW 
>>>> Technologist) wrote:
>>>> 
>>>>>> -Original Message-
>>>>>> From: Udit Kumar [mailto:udit.ku...@nxp.com]
>>>>>> Sent: Wednesday, May 02, 2018 12:26 PM
>>>>>> To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>;
>>>>>> Alexander Graf <ag...@suse.de>; William Mills <wmi...@ti.com>
>>>>>> Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris
>>>>>> <rod.dor...@nxp.com>; arm.ebbr-disc...@arm.com
>>>>>> Subject: RE: DT handling, [Ref Linux-Efi]
>>>>>> 
>>>>>>> We probably don't need to provide a genetic DT driver in UEFI U-Boot,
>>>>>>> instead, we will have to mention how SoC/platform vendors publish
>>>>>>> DTB/DTBO in EBBR spec.
>>>>>>> For example,
>>>>>>> The EFI_CONFIGURATION_TABLE in EFI System table could be used to
>>>>>>> publish the pointer to DTB and DTBO. Declare two GUIDs in EBBR, one
>>>>>>> for DTB another for DTBO. OS boot loader is responsible to merge
>>>>>>> DTB/DTBO according DTB/DTBO discovered in EFI Configuration Table. To
>>>>>>> read DT from EFI variable into memory, memory map to DT in EEPROM or
>>>>>>> other mechanisms is platform implementation. No matter which approach,
>>>>>>> DT producer has to create configuration table in EFI system table
>>>>>>> follow the data structure defined in EBBR.
>>>>>>> Another way instead of using GUID in configuration table is to publish
>>>>>>> DTB/DTBO in EFI device path, this way is more UEFI oriented IMO.
>>>>>>> However, we have to defined corresponding device path node in UEFI
>>>>>>> spec for DT. Similar to using system configuration table. DT producer
>>>>>>> has to install EFI device path for either DTB or DTBO. Then OS boot
>>>>>>> loaders locate those EFI device paths of DTB and DTBO and merge it.
>>>>>> 
>>>>>> We are adding a requirement on OS boot loaders to merge it.
>>>>>> IMO, merging should be done by firmware itself.
>>>>>> In case, we want to host multiple distribution at same time, then this 
>>>>>> is likely
>>>>>> to go with OS boot loaders
>>>>> 
>>>>> That is fine to merge DT by firmware, we still can standardize how
>>>>> UBoot merges DT in EBBR. For example, SoC and other platform UBoot
>>>>> drivers produce their DT or DTO in their own drivers. UBoot provides a
>>>>> centralized EFI DT driver to collect DT/DTO from either EFI system
>>>>> configuration table or EFI device path. Then this centralized EFI DT
>>>>> driver produces the pointer to point to final DT in EFI system
>>>>> configuration table. OS boot loader cab just check EFI system
>>>>> configuration table to retrieve DT, something like this.
>>>> 
>>>> I think I need to step in here to clarify something.  U-Boot drivers
>>>> don't produce a DT and while it's possible, it's generally[1] not done,
>>>> that U-Boot uses _the_ device tree that we pass along to the next stage
>>>> (we've likely filtered things out for space and added a few specific
>>>> things of our own).
>>>> 
>>>> IMHO, what EBBR should cover is saying that firmware may apply overlays
>>>> because we know there's N valid use cases of taking a base and fixing it
>>>> up in both big and small ways.  Then firmware will pass along to the
>>>> next stage (EFI application such as GRUB or *BSD loader or a Linux
>>>> Kernel or ...).
>>> 
>>> Which bits of this discussion target level 0 and which target a later
>>> level 1?
>>> 
>>> Personally I'm not sure there is enough prior art w.r.t. device tree
>>> overlay for anything much related to overlays to target level 0.
>>> 
>>> In fact if we take the view that EBBR def

Re: DT handling, [Ref Linux-Efi]

[Alexander Graf]

On 04/30/2018 08:36 PM, Rob Herring wrote:

On Fri, Apr 27, 2018 at 4:39 PM, Alexander Graf <ag...@suse.de> wrote:

Hi Rob,

On 27.04.18 18:40, Rob Herring wrote:

On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf <ag...@suse.de> wrote:


On 27.04.18 08:24, Udit Kumar wrote:

Hi
There is bit of discussion on linux-efi too , to handle DT update

I guess some members of this forum are active there too.

https://www.spinics.net/lists/linux-efi/msg13700.html

To summaries
1/ Ownership of DTB
IMO should be firmware and we should retain this
ownership in EBBR as well, Any objections/thoughts ?

I fully agree. On top of that we need to make clear that backward and
forward compatibility are not optional.

For that I think we may need to actually give people workable solutions
to create device trees that are compatible with multiple levels of
kernel support. The main areas I'm aware of that keep breaking are:

   * fine grained interrupt controller support

Do you have an example of that? The only thing I can think of is
people switching interrupts from the GIC to an always-on, low-power
mode custom interrupt controller.

The last time I've seen that breakage was:


https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/bcm270x.dtsi#L158

which indeed does switch interrupts from the GIC to an interrupt muxer
behind the GIC.

The problem is that once support for that lands upstream, you will have
very little option but to break backwards compatibility today.

This one is unfortunate. It could have been handled better. An
interrupt-map property in the aux ctrlr could have mapped the
interrupts to GIC without any aux driver. Then when the aux driver
lands, it just needs to remove the interrupt-map (on boot).


To do that you would've needed to know that you need the change in the 
first place ;).



Alternatively, I skimmed thru some discussions of the issue, but I'm
not clear why the devices behind the aux controller can't all just
treat their interrupts as shared. But that would be a simple change to
the drivers' irq handlers, so I'm probably missing something. If that
worked, then the DT would never need to change.

I guess whether this could have been handled better depends if folks
knowingly ignored the issue or this was found after upstreaming
support. The latter case may be unavoidable, but maybe we can make it


I think most of these cases are the latter.


rare enough we only need overlays in some exceptions. Whether we try
to be stricter and do better up front or have some overlay based
solution, either one is going to require folks be aware of the issues
and effort to avoid them.


Yes, but with the overlay approach we can temper it up after the fact :).

I personally think what we need to do is have a flag day event. I think 
ideally that would be a move of the dts file out of the Linux tree into 
a common git repository. Once it's there, we'd need scripts that ensure 
backward compatibility all the way back to whatever was current at the 
flag day.


Projects like U-Boot (or maybe even other OSs) could then have a git 
submodule on that repo and be sure that they can rely on these device 
trees to be stable.





   * clock support

Are there cases other than going from fixed, fake clocks to a real
clock controller node. I'm inclined to stop allowing people to do
that. A better way this could be done is just provide a clock
controller driver with a bunch of fixed clocks. Then the switch from
the dumb driver to the real driver is just a kernel change.

Going from fixed to in-kernel clock driver is one case I'm aware of, yes.

The other one I can think of right now is going from one clock interface
to another. For example if you configure clocks using a firmware
interface and that firmware interface moves to a newer, more shiny
interface (say proprietary to SCMI). That switch may also regress users
of the device tree.

If not only the clocks but the whole firmware interface changes, then
I don't see how a stable DT matters at that point.


Firmware could expose both interfaces, but if the DT only mentions the 
"new" one, OSs that used to work will cease to work.





I think Andre had other examples of where DT compatibility broke, so
I'll let him chime in as well.


   * power domain support

Example?

https://github.com/Xilinx/linux-xlnx/blob/master/arch/arm64/boot/dts/xilinx/zynqmp.dtsi#L110

Booting with the power-domains properties included in the device tree
fails for me, because the driver framework considers them critical to
load a device and just errors out with -EDEFER.


   * pinctrl support

This would be the firmware initially does all the pin setup, then you
move it to DT and drop the setup from the firmware? Otherwise I don't
understand the problem in this case. We'd start with no pinctrl and
then add it to the DT. Why wouldn't the kernel just ignore it?

Because it doesn't. The linux driver framework as it works today looks
at the pinctrl parent

Re: [Arm.ebbr-discuss] DT handling, [Ref Linux-Efi]

[Alexander Graf]

On 05/03/2018 12:13 PM, Daniel Thompson wrote:

On Wed, May 02, 2018 at 05:39:02PM -0400, Tom Rini wrote:

On Wed, May 02, 2018 at 05:12:03AM +, Chang, Abner (HPS SW/FW Technologist) 
wrote:


-Original Message-
From: Udit Kumar [mailto:udit.ku...@nxp.com]
Sent: Wednesday, May 02, 2018 12:26 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>;
Alexander Graf <ag...@suse.de>; William Mills <wmi...@ti.com>
Cc: boot-architecture@lists.linaro.org; n...@arm.com; Rod Dorris
<rod.dor...@nxp.com>; arm.ebbr-disc...@arm.com
Subject: RE: DT handling, [Ref Linux-Efi]


We probably don't need to provide a genetic DT driver in UEFI U-Boot,
instead, we will have to mention how SoC/platform vendors publish
DTB/DTBO in EBBR spec.
For example,
The EFI_CONFIGURATION_TABLE in EFI System table could be used to
publish the pointer to DTB and DTBO. Declare two GUIDs in EBBR, one
for DTB another for DTBO. OS boot loader is responsible to merge
DTB/DTBO according DTB/DTBO discovered in EFI Configuration Table. To
read DT from EFI variable into memory, memory map to DT in EEPROM or
other mechanisms is platform implementation. No matter which approach,
DT producer has to create configuration table in EFI system table
follow the data structure defined in EBBR.
Another way instead of using GUID in configuration table is to publish
DTB/DTBO in EFI device path, this way is more UEFI oriented IMO.
However, we have to defined corresponding device path node in UEFI
spec for DT. Similar to using system configuration table. DT producer
has to install EFI device path for either DTB or DTBO. Then OS boot
loaders locate those EFI device paths of DTB and DTBO and merge it.

We are adding a requirement on OS boot loaders to merge it.
IMO, merging should be done by firmware itself.
In case, we want to host multiple distribution at same time, then this is likely
to go with OS boot loaders

That is fine to merge DT by firmware, we still can standardize how
UBoot merges DT in EBBR. For example, SoC and other platform UBoot
drivers produce their DT or DTO in their own drivers. UBoot provides a
centralized EFI DT driver to collect DT/DTO from either EFI system
configuration table or EFI device path. Then this centralized EFI DT
driver produces the pointer to point to final DT in EFI system
configuration table. OS boot loader cab just check EFI system
configuration table to retrieve DT, something like this.

I think I need to step in here to clarify something.  U-Boot drivers
don't produce a DT and while it's possible, it's generally[1] not done,
that U-Boot uses _the_ device tree that we pass along to the next stage
(we've likely filtered things out for space and added a few specific
things of our own).

IMHO, what EBBR should cover is saying that firmware may apply overlays
because we know there's N valid use cases of taking a base and fixing it
up in both big and small ways.  Then firmware will pass along to the
next stage (EFI application such as GRUB or *BSD loader or a Linux
Kernel or ...).

Which bits of this discussion target level 0 and which target a later
level 1?

Personally I'm not sure there is enough prior art w.r.t. device tree
overlay for anything much related to overlays to target level 0.

In fact if we take the view that EBBR defines a contract between the
system firmware and the OS then arguably DT update is also out of scope
unless we are defining runtime services by which the OS can update the
DT. Again not something I think is ready for level 0.


Well, things like hat devices that give boot loaders hints on what OS 
provided overlays would be useful to load are basically part of the 
contract.


But I agree that it can easily be an EBBR Level 1 topic.


Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [RFC PATCH] driver core: make deferring probe forever optional

[Alexander Graf]

On 05/01/2018 11:31 PM, Rob Herring wrote:

Deferred probe will currently wait forever on dependent devices to probe,
but sometimes a driver will never exist. It's also not always critical for
a driver to exist. Platforms can rely on default configuration from the
bootloader or reset defaults for things such as pinctrl and power domains.
This is often the case with initial platform support until various drivers
get enabled. There's at least 2 scenarios where deferred probe can render
a platform broken. Both involve using a DT which has more devices and
dependencies than the kernel supports. The 1st case is a driver may be
disabled in the kernel config. The 2nd case is the kernel version may
simply not have the dependent driver. This can happen if using a newer DT
(provided by firmware perhaps) with a stable kernel version.

Unfortunately, this change breaks with modules as we have no way of
knowing when modules are done loading. One possibility is to make this
opt in or out based on compatible strings rather than at a subsystem level.
Ideally this information could be extracted automatically somehow. OTOH,
maybe the lists are pretty small. There's only a handful of subsystems
that can be optional, and then only so many drivers in those that can be
modules (at least for pinctrl, many drivers are built-in only).

Cc: Alexander Graf <ag...@suse.de>
Signed-off-by: Rob Herring <r...@kernel.org>
---
This patch came out of a discussion on the ARM boot-architecture
list[1] about DT forwards and backwards compatibility issues. There are
issues with newer DTs breaking on older, stable kernels. Some of these
are difficult to solve, but cases of optional devices not having
kernel support should be solvable.


I think this is a reasonable approach. Maybe this should be a CONFIG 
option that disallows pinctrl drivers (and power domain later) to be =m? 
Then by default we could force those drivers to be compiled in, but if 
you really wanted to do kernel modules for pinctrl/pd you'd consciously 
potentially lose forward compatibility.



Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: DT handling, [Ref Linux-Efi]

[Alexander Graf]

Hi Rob,

On 27.04.18 18:40, Rob Herring wrote:
> On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf <ag...@suse.de> wrote:
>>
>>
>> On 27.04.18 08:24, Udit Kumar wrote:
>>> Hi
>>> There is bit of discussion on linux-efi too , to handle DT update
>>>
>>> I guess some members of this forum are active there too.
>>>
>>> https://www.spinics.net/lists/linux-efi/msg13700.html
>>>
>>> To summaries
>>> 1/ Ownership of DTB
>>> IMO should be firmware and we should retain this
>>> ownership in EBBR as well, Any objections/thoughts ?
>>
>> I fully agree. On top of that we need to make clear that backward and
>> forward compatibility are not optional.
>>
>> For that I think we may need to actually give people workable solutions
>> to create device trees that are compatible with multiple levels of
>> kernel support. The main areas I'm aware of that keep breaking are:
>>
>>   * fine grained interrupt controller support
> 
> Do you have an example of that? The only thing I can think of is
> people switching interrupts from the GIC to an always-on, low-power
> mode custom interrupt controller.

The last time I've seen that breakage was:


https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/bcm270x.dtsi#L158

which indeed does switch interrupts from the GIC to an interrupt muxer
behind the GIC.

The problem is that once support for that lands upstream, you will have
very little option but to break backwards compatibility today.

> 
>>   * clock support
> 
> Are there cases other than going from fixed, fake clocks to a real
> clock controller node. I'm inclined to stop allowing people to do
> that. A better way this could be done is just provide a clock
> controller driver with a bunch of fixed clocks. Then the switch from
> the dumb driver to the real driver is just a kernel change.

Going from fixed to in-kernel clock driver is one case I'm aware of, yes.

The other one I can think of right now is going from one clock interface
to another. For example if you configure clocks using a firmware
interface and that firmware interface moves to a newer, more shiny
interface (say proprietary to SCMI). That switch may also regress users
of the device tree.

I think Andre had other examples of where DT compatibility broke, so
I'll let him chime in as well.

> 
>>   * power domain support
> 
> Example?

https://github.com/Xilinx/linux-xlnx/blob/master/arch/arm64/boot/dts/xilinx/zynqmp.dtsi#L110

Booting with the power-domains properties included in the device tree
fails for me, because the driver framework considers them critical to
load a device and just errors out with -EDEFER.

> 
>>   * pinctrl support
> 
> This would be the firmware initially does all the pin setup, then you
> move it to DT and drop the setup from the firmware? Otherwise I don't
> understand the problem in this case. We'd start with no pinctrl and
> then add it to the DT. Why wouldn't the kernel just ignore it?

Because it doesn't. The linux driver framework as it works today looks
at the pinctrl parent for a specific device and if it can't find it
loaded, throws -EDEFER for the driver getting loaded. I suppose the
rationale behind that is that pinctrl drivers could be modules that get
loaded after the driver you want to load.

> 
>> Every time a device tree changes in any of the above, that usually ends
>> up in backwards incompatibility.
> 
> TBC, you're talking about new dtb with old kernels. We've mainly cared

Yes. Both really.

> about old dtbs and new kernels. So first we should agree the former is
> important too. I do, because simply you wouldn't want a BIOS update to
> make your PC stop booting your already installed OS.

Yes.

> I'd like to solve this with policy and good practice before we try to
> apply technical solutions on top of a mess.

I'm not holding my hopes up, but we can try ;). Another full dimension
of messiness are downstream, unapproved bindings that some times can't
live in the same device tree as their upstream counterparts once
upstream chose a different route.

For pinctrl and power domain, I suppose we could have a compatible
whitelist in the kernel and instead of -EDEFER just consider the targets
immutable if we hit none of the whitelisted strings.

> 
>> My idea to solve that would be to basically create a device tree that
>> has self-contained overlays that only trigger when certain feature
>> strings are available. That way the base device tree could for example
>> contain fixed clocks, but an overlay can get applied when the clock
>> driver is enabled in the kernel configuration. That overlay would then
>> enable the kernel to drive clocks.
> 
> The number of combinations

Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

[Alexander Graf]

On 26.04.18 18:52, William Mills wrote:
> 
> 
> On 04/26/2018 08:43 AM, Alexander Graf wrote:
>> On 04/26/2018 10:51 AM, Grant Likely wrote:
>>> On 25/04/2018 19:34, Alexander Graf wrote:
>>>>
>>>>
>>>> On 25.04.18 19:54, Leif Lindholm wrote:
>>>>> I took an action last week to provide a block of text for how
>>>>> platforms without persistent variable storage should behave. Here's my
>>>>> opening play:
>>>>
>>>> Thanks a lot for getting this started!
>>>>
>>>>>
>>>>> Boot manager behaviour without persistent variable store
>>>>> ===
>>>>>
>>>>> Platforms that do not implement  persistent variable storage must
>>>>> support the Removable Media Boot Behaviour as described by UEFI.
>>>>>
>>>>> Such platforms can additionally implement support for additional
>>>>> statically[1] defined images to be processed as SysPrep,
>>>>
>>>> What we have right now in U-Boot is partial support for dynamic variable
>>>> storage. The way it works is that during boot time, variable store
>>>> exists and is mutable and fully mapped to U-Boot environment variables
>>>> which may well be stored on the ESP.
>>>>
>>>> We're missing logic to actually persist the variables on exit boot
>>>> services today.
>>>>
>>>> So yes, statically defining them (via U-Boot enironment variables, but
>>>> that's an implementation detail) sounds like a great first approximation
>>>> to me.
>>>>
>>>>> Driver and Boot### global variable entries. If present, these
>>>>> entries will be processed in the order specified by corresponding
>>>>> statically defined SysPrepOrder, DriverOrder and BootOrder global
>>>>> variables.
>>>>
>>>> Currently the "bootefi bootmgr" command only implements "BootOrder".
> 
> Can u-boot (or an EFI app) load a driver and have it persist?

Depends on what your definition of persist is :). U-Boot can run an EFI
application that can register protocols. These protocols do not
disappear after the application closed.

> If yes, Can it persist just until ExitBootServices or can it persit to
> runtime time as well?

An application can register memory as runtime memory and install
something there. I'm not sure what the best way would be to actually
make it callable though.

> 
>>>>
>>>>>
>>>>> Any images referred to by such variables must reside in a
>>>>> vendor-specific subdirectory on the EFI System Partition, as recorded
>>>>> in http://uefi.org/registry. /BOOT must not be used except where
>>>>> explicitly permitted by UEFI.
>>>>>
>>>>> Where an executable is present in the prescribed Removable Media
>>>>> location, boot of that must be attempted, and only after this fails
>>>>> should any of the Boot entries be processed.
> 
> This is the "priority" statement I think it problematic as discussed on
> todays call.  I think Boot### should be followed if present but boot
> firmware writers should be cautioned not to hard code stupid stuff into
> them.  (The tricky bit will, of course, be comming up with a definition
> of stupid stuff.  A list of bad examples may be the best way to do this.)
> 
>>>>>
>>>>> Statically configured BootNext, OsRecovery or PlatformRecovery
>>>>> entries must not be used.
>>>>
>>>> We should also mention that all variable accesses during runtime must
>>>> return DEVICE_ERROR and that this is the way an OS can determine that
>>>> persistent variable store is not available.
>>>
>>> That's a pretty big hammer to tell the OS that SetVariable() is not
>>> available. That prevents using variables to communicate any information
>>> to the OS. Could we instead define a capability variable to pass that
>>> information so that the boot configuration can still be passed through
>>> for the OS to query?
>>
>> I guess that's possible (and not a bad idea), would render all our
>> current distributions unable to cope with such a system though :).
>>
>> Alex
> 
> So on the call today I heard that an EBBR.0 OS (after ExitBootServices)
> should be prepared for:
> 1) A system that returns ERROR for Gets and Sets
> 2) A system that returns E

Re: DT handling, [Ref Linux-Efi]

[Alexander Graf]

On 27.04.18 08:24, Udit Kumar wrote:
> Hi 
> There is bit of discussion on linux-efi too , to handle DT update 
> 
> I guess some members of this forum are active there too. 
> 
> https://www.spinics.net/lists/linux-efi/msg13700.html 
> 
> To summaries 
> 1/ Ownership of DTB 
> IMO should be firmware and we should retain this 
> ownership in EBBR as well, Any objections/thoughts ? 

I fully agree. On top of that we need to make clear that backward and
forward compatibility are not optional.

For that I think we may need to actually give people workable solutions
to create device trees that are compatible with multiple levels of
kernel support. The main areas I'm aware of that keep breaking are:

  * fine grained interrupt controller support
  * clock support
  * power domain support
  * pinctrl support

Every time a device tree changes in any of the above, that usually ends
up in backwards incompatibility.

My idea to solve that would be to basically create a device tree that
has self-contained overlays that only trigger when certain feature
strings are available. That way the base device tree could for example
contain fixed clocks, but an overlay can get applied when the clock
driver is enabled in the kernel configuration. That overlay would then
enable the kernel to drive clocks.

Further down, we could even extend dtc with annotations that indicate
"this property should only be exposed when feature string X is
available" to not force people to write overlays inside the device tree.

> 
> Update
> 1/ Updating whole device tree from OS 
> [Capsule update can be used ] 

I think the device tree should be part of firmware. If you need to
update it, update your firmware (or a firmware specific method, not
specified by EBBR).

> 2/ Just modifying the device tree DTBO 

Yes, dtbo support in the boot chain definitely makes sense.

> My preferred way to handle DTBO in firmware will be 
> https://source.android.com/devices/architecture/dto/multiple 
> See picture Runtime DTO implementation for multiple DTs 
> 
> To store this information in partition, options we have 
> 1/ Run time variables 

You mean EFI variables? We could certainly have a driver in firmware
that reads certain EFI variables to apply dtbos from.

> 2/ Some driver in Linux writing to DTBO partition 

What is a DTBO partition?

> 3/ Some other way ?? 

In a lot of cases I think we will end up with enumerable extensions to
systems that will want to have a dtbo applied by their respective
driver. As outlined in the notes from last week, that driver could
expose availability of such an extension to the OS (grub) which could
then apply an OS provided dtbo.

> I am not sure, if distro are updating device tree which is default shipped 
> with board ?? 

I would prefer they didn't :). Right now we leave people little chance,
because device trees keep changing incompatibly. If we get rid of that
problem, there will be very little incentive by distros to ship device
trees.


Alex
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

[Alexander Graf]

On 04/26/2018 10:51 AM, Grant Likely wrote:

On 25/04/2018 19:34, Alexander Graf wrote:



On 25.04.18 19:54, Leif Lindholm wrote:

I took an action last week to provide a block of text for how
platforms without persistent variable storage should behave. Here's my
opening play:


Thanks a lot for getting this started!



Boot manager behaviour without persistent variable store
===

Platforms that do not implement  persistent variable storage must
support the Removable Media Boot Behaviour as described by UEFI.

Such platforms can additionally implement support for additional
statically[1] defined images to be processed as SysPrep,


What we have right now in U-Boot is partial support for dynamic variable
storage. The way it works is that during boot time, variable store
exists and is mutable and fully mapped to U-Boot environment variables
which may well be stored on the ESP.

We're missing logic to actually persist the variables on exit boot
services today.

So yes, statically defining them (via U-Boot enironment variables, but
that's an implementation detail) sounds like a great first approximation
to me.


Driver and Boot### global variable entries. If present, these
entries will be processed in the order specified by corresponding
statically defined SysPrepOrder, DriverOrder and BootOrder global
variables.


Currently the "bootefi bootmgr" command only implements "BootOrder".



Any images referred to by such variables must reside in a
vendor-specific subdirectory on the EFI System Partition, as recorded
in http://uefi.org/registry. /BOOT must not be used except where
explicitly permitted by UEFI.

Where an executable is present in the prescribed Removable Media
location, boot of that must be attempted, and only after this fails
should any of the Boot entries be processed.

Statically configured BootNext, OsRecovery or PlatformRecovery
entries must not be used.


We should also mention that all variable accesses during runtime must
return DEVICE_ERROR and that this is the way an OS can determine that
persistent variable store is not available.


That's a pretty big hammer to tell the OS that SetVariable() is not
available. That prevents using variables to communicate any information
to the OS. Could we instead define a capability variable to pass that
information so that the boot configuration can still be passed through
for the OS to query?


I guess that's possible (and not a bad idea), would render all our 
current distributions unable to cope with such a system though :).


Alex

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables

[Alexander Graf]

On 25.04.18 19:54, Leif Lindholm wrote:
> I took an action last week to provide a block of text for how
> platforms without persistent variable storage should behave. Here's my
> opening play:

Thanks a lot for getting this started!

> 
> Boot manager behaviour without persistent variable store
> ===
> 
> Platforms that do not implement  persistent variable storage must
> support the Removable Media Boot Behaviour as described by UEFI.
> 
> Such platforms can additionally implement support for additional
> statically[1] defined images to be processed as SysPrep,

What we have right now in U-Boot is partial support for dynamic variable
storage. The way it works is that during boot time, variable store
exists and is mutable and fully mapped to U-Boot environment variables
which may well be stored on the ESP.

We're missing logic to actually persist the variables on exit boot
services today.

So yes, statically defining them (via U-Boot enironment variables, but
that's an implementation detail) sounds like a great first approximation
to me.

> Driver and Boot### global variable entries. If present, these
> entries will be processed in the order specified by corresponding
> statically defined SysPrepOrder, DriverOrder and BootOrder global
> variables.

Currently the "bootefi bootmgr" command only implements "BootOrder".

> 
> Any images referred to by such variables must reside in a
> vendor-specific subdirectory on the EFI System Partition, as recorded
> in http://uefi.org/registry. /BOOT must not be used except where
> explicitly permitted by UEFI.
> 
> Where an executable is present in the prescribed Removable Media
> location, boot of that must be attempted, and only after this fails
> should any of the Boot entries be processed.
> 
> Statically configured BootNext, OsRecovery or PlatformRecovery
> entries must not be used.

We should also mention that all variable accesses during runtime must
return DEVICE_ERROR and that this is the way an OS can determine that
persistent variable store is not available.


Alex

> 
> 
> 
> 
> 
> [1] This is worth discussing, but if we were to support dynamic
> creation of these, we need _very_ strict rules around it.
> ___
> Arm.ebbr-discuss mailing list
> arm.ebbr-disc...@arm.com
> 
___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: [Arm.ebbr-discuss] EBBR weekly meeting in 1/2 hour

[Alexander Graf]

Hi Udit,

> Am 23.04.2018 um 07:15 schrieb Udit Kumar :
> 
> Hi Alex, 
> 
> I was reading your notes for DT management 
> 
>> Alex: Have logic in firmware that can enumerate "Hat"s and create EFI object 
>> for them. These objects could then be backed by DTBOs - either by grabbing 
>> them from the device (EEPROM) or by a stored blob in firmware. >Grub for 
>> example could then also be taught about these objects and DTBO support, so 
>> an OS could store its own overlays. EDK2 has the hat logic support today and 
>> already does create objects.
> 
> I am not sure, where you want to store DTBO in EEPROM or on some other 
> partition/media.  
> If this is EEPROM then I hope firmware is stored on this as well. Then we 
> shouldn't expose EEPROM to OS. 

There are hats that provide device tree overlays as part of their self 
description, such as the beagle ones. That‘s what I was referring to.

Of course the actual hat driver again can override or self define a dtbo as 
well.


Alex

> 
> Regards
> Udit 
> 
>> -Original Message-
>> From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss-
>> boun...@arm.com] On Behalf Of Grant Likely
>> Sent: Thursday, April 19, 2018 8:29 PM
>> To: arm.ebbr-discuss ; boot-
>> architect...@lists.linaro.org; n...@arm.com
>> Subject: [Arm.ebbr-discuss] EBBR weekly meeting in 1/2 hour
>> 
>> Hi folks,
>> 
>> Weekly EBBR meeting starts in about 1/2 hour. Dial in details below.
>> Once again the agenda is very short, but I'll open it up to other topics 
>> after
>> action item review. I think there was some interest in talking about DT 
>> overlay
>> handling.
>> 
>> Notes are being captured in the following Google doc. I would greatly
>> appreciate help with taking meeting minutes.
>> 
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.g
>> oogle.com%2Fdocument%2Fd%2F1RdlFp5SIrvjcVOGoGEFVYDsqTqFBJHugbBMV
>> 5MuXUhw%2Fedit%3Fusp%3Dsharing=02%7C01%7Cudit.kumar%40nxp.co
>> m%7C3eb61599b18a412b892508d5a6062f3f%7C686ea1d3bc2b4c6fa92cd99c5c
>> 301635%7C0%7C0%7C636597467908843944=WXyC196CqdpvkQYGtG6Ir
>> P0uHPDNTyPA65LM4jfvJXc%3D=0
>> 
>> Agenda:
>> 1) Action item review
>> 2) Any other business
>> 
>> Cheers,
>> g.
>> 
>> 
>> Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST) Join by Phone
>> +44 2033215213,, 4664465#
>> 
>> ---
>> 
>> Join online meeting
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmeet.l
>> ync.com%2Farmh%2Fgrant.likely%2FYBY93TIK=02%7C01%7Cudit.kumar%
>> 40nxp.com%7C3eb61599b18a412b892508d5a6062f3f%7C686ea1d3bc2b4c6fa9
>> 2cd99c5c301635%7C0%7C0%7C636597467908843944=aFRlW1xGKXR2V
>> hnYEZO%2FFClBt6x8TDd3LVJohERHbmw%3D=0
>> 
>> Trouble Joining? Try Skype Web App
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmeet.l
>> ync.com%2Farmh%2Fgrant.likely%2FYBY93TIK%3Fsl%3D1=02%7C01%7Cu
>> dit.kumar%40nxp.com%7C3eb61599b18a412b892508d5a6062f3f%7C686ea1d3
>> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636597467908843944=fSofD
>> UE97VolIL9%2BwcyE00mV4Av07Muc96GKHGawRC0%3D=0
>> 
>> Join by Phone +44 2033215213,, 4664465#
>> 
>> Find a local number
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdialin.l
>> ync.com%2F7bdb65cd-97d0-44fe-bc03-
>> bf8072eadc33=02%7C01%7Cudit.kumar%40nxp.com%7C3eb61599b18a4
>> 12b892508d5a6062f3f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
>> C636597467908843944=wQoMC8nocRjcsJrKxZBlXQoJZJRJAZJr40AB%2Fy
>> x8Hec%3D=0
>> Conference ID: 4664465
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended 
>> recipient,
>> please notify the sender immediately and do not disclose the contents to any
>> other person, use it for any purpose, or store or copy the information in any
>> medium. Thank you.
>> ___
>> Arm.ebbr-discuss mailing list
>> arm.ebbr-disc...@arm.com

___
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture