Re: DT handling, [Ref Linux-Efi]
Hi Rob, On 27.04.18 18:40, Rob Herring wrote: > On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf 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 that would create makes me run away. Then > we're going to combine that with all the other ways people want to use > overlays. I'm happy to see better alternatives, but the current state is just plain painful. >> Further down, we could even extend dtc with annotations that indicate >> "this property should only be exposed when feature string X is >> avail
Re: DT handling, [Ref Linux-Efi]
On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf 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. > * 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. > * power domain support Example? > * 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? > 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 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. I'd like to solve this with policy and good practice before we try to apply technical solutions on top of a mess. > 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 that would create makes me run away. Then we're going to combine that with all the other ways people want to use overlays. > 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. How would that work with clocks where you are changing: clocks = <&fake_fixed_clk>; to: clocks = <&soc_clock_ctrlr 123>; > >> >> 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 The Android way of handling overlays is very much rooted in how the Android ecosystem works. We should probably have wider discussion and decision on to what extent does EBBR address/care about/work with Android? On the one hand, I don't think Android requires anything that's specifically incompatible with EBBR if some wants to follow EBBR and use Android. OTOH, we can't define any requirements for Android in EBBR. Google will define things to the extent they want and vendors will follow that only to the extent they have to. >> 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? The Android way. Everything can be solved with another partition. :) Rob ___ 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
On Fri, Apr 27, 2018 at 11:22:27AM +0100, Grant Likely wrote: > On 26/04/2018 17: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? > > If yes, Can it persist just until ExitBootServices or can it persit to > > runtime time as well? > > > > > > > > > > > > > > > > > > > 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 ERROR for Sets but Gets works > > 3) A system where Sets and Gets work and are persisten > > I've had a bit more of a think about this, and I would like to propose a > different list. First, I think we should require that GetVariable() > always works, and it should match whatever was in the UEFI variables > during boot services. This should not be onerous to implement for anyone > as it only requires the variables to be preserved in a UEFI memory > region. > > I also think I too quickly discounted systems where SetVariable() never > works. HiKey for instance falls into that category. Maybe we still need > to support that for EBBR.0 That sounds rather close to circular logic. Boards that don't implement working SetVariable()
Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables
On Fri, Apr 27, 2018 at 09:58:07AM +0100, Leif Lindholm wrote: > > 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.) > > Yes. This statement was based on my incorrect assumption that we were > permitting systems without any persistent variable storage in the first > revision of the spec. (As opposed to only systems that did not provide > persistent variable storage at runtime.) To be honest, I'm not sure there was 100% argeement either way on yesterday's call but we're definitely zooming in a bit. If only because there were too many "let's leave aside level 0/1 for the time being" to be sure where this all fits. However it seems to be me to be *really* beguiling to combine: 1. A LoaderEntryOneShot set variable implementation that survives a warm boot 2. Support persistent variable storage from UEFI applications 3. (Almost) normal handling of boot variables (assume we still want fallback to removeable media mode if the other boot options fail?). Seems like that would make it relatively easy (or at the least possible) to add special EBBR equivalents of efibootmgr/efivar and allow distro install flows to work like (almost) normal. However, as I said above, I'm not sure if we are talking level 0 or level 1 here? Daniel. ___ 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
On 26/04/2018 17: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? If yes, Can it persist just until ExitBootServices or can it persit to runtime time as well? 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 ERROR for Sets but Gets works 3) A system where Sets and Gets work and are persisten I've had a bit more of a think about this, and I would like to propose a different list. First, I think we should require that GetVariable() always works, and it should match whatever was in the UEFI variables during boot services. This should not be onerous to implement for anyone as it only requires the variables to be preserved in a UEFI memory region. I also think I too quickly discounted systems where SetVariable() never works. HiKey for instance falls into that category. Maybe we still need to support that for EBBR.0 New list of systems to be prepared for: 1) SetVariable() never works (return EFI_WRITE_PROTECTED?) 2) SetVariable() only works at boot time (return EFI_WRITE_PROTECTED at runtime?) 3) SetVariable() works at both boot and runtime Support for a platform that does not ERROR Sets but does not do non-volatile persistence will be discussed for EBBR.1 if we still think it has value and platforms that will need it are common enough I think that's fair. non-persistant SetVariable() pulls in a lot of questions about what the reboot behaviour needs to be, so I'd like to punt it out to the EBBR.1 (liking the EBBR.# terminology BTW) I also heard that all platforms "can persist variables before exit boot services". Is this true today for u-boot based systems that have an env storage defined? What about u-boot based system that do not define any env storage and always rely on uEnv.txt etc? I think this fits into the new list described above. If firmware uses uEnv.txt, then SetVari
Re: Question about EBBR
Hi Abner, Answers below... On 27/04/2018 07:06, Chang, Abner (HPS SW/FW Technologist) wrote: Not sure if this mail list works or not. Hi Grant, GiIbert (from HPE, I think he is also in the mail list) and I are new to this discussion thread . Here are couple questions for you, your answer can give us the clear plan of EBBR spec. 1. I see EBBR spec on ARM web site, however seems it was released in last Sep. Any newer version of this spec? As Dong said, there is no newer version of the spec. The copy on the Arm website is only a draft release. The feedback we received on it was we need a more open process for this spec; hence this group. 2. The purpose of EBBR is to standardize embedded system firmware on different processor archs and also intends abstract platform-specific implementations? The purpose of EBBR is to standardize the firmware interface for different platforms of the same architecture so that OS distributions can support multiple boards. For example, the SUSE AArch64 image should be able to boot on any EBBR compliant AArch64 platform (providing the SoC is supported in the SUSE kernel). Originally EBBR was only intended to address Arm platforms, but after receiving interest from other architectures we've expanded the scope. EBBR builds on existing specs, so it doesn't define a new firmware interface. Rather, it starts with the UEFI spec and adds additional requirements that are relevant for the embedded market. 3. EBBR aligns embedded SWF with UEFI spec (minimum requirements) and leverage EDK2 implementation on uBoot? 3-1 That is to use uBoot to initialize and boot system, but uBoot mimics UEFI protocols and EFI system table then boot to UEFI OS boot loader? 3-2 Or, Uboot could be one of EDK2 packages, wrap the necessary Uboot drivers into UEFI protocols (like the UEFI binding on top of uBoot) and build it using EDK2 build process then generate EDK2 format system firmware? 3-2 makes more sense to me but not sure which one is EBBR intention. I may have more question if the intention of EBBR is 3-2. :) 3-1 is the intent. EBBR specifies UEFI, but doesn't say anything about implementation. U-Boot implements a subset of the UEFI spec which is completely independed from EDK2/Tianocore. A vendor can produce an EBBR compliant system using either U-Boot or EDK2/Tianocore. The first release of EBBR (level 0) will specify a subset of UEFI compliance. The intent is to reflect what is currently implemented in the U-Boot project. Therefore, a vendor who is currently using U-Boot firmware has an easy migration path to become EBBR compliant. UEFI support in U-Boot is rapidly evolving, so I expect future revisions of EBBR (level 1 and onwards) to require a larger subset of UEFI, with the ultimate goal of being 100% compliant to the UEFI spec. As you'll have gathered from the meeting, handling of persistent variables is an important topic right now. The UEFI spec requires the GetVariable()/SetVariable() runtime services to work, but U-Boot does not yet have the ability to set variables at runtime. Similarly, Tianocore/EDK2 on the 96Boards HiKey doesn't support setting variable at all. Therefore, EBBR needs to define the behaviour of firmware when SetVariable() does not work. Cheers, g. 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. ___ 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
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 ERROR for Sets but Gets works In this case you also want to have an indication to the OS that while variables exist, writes do not work. > 3) A system where Sets and Gets work and are persistent > > Support for a platform that does not ERROR Sets but does not do > non-volatile persistence will be discussed for EBBR.1 if we still think > it has value and platforms that will need it are common enough. > > I also heard that all platforms "can persist variables before exit boot > services". Is this true today for u-boot based systems that have an env > storage defined? What about u-boot based system that do not define any > env storage and always rely on uEnv.txt etc? U-Boot supports storing its environment in a file on a partition. And since the UEFI environment is part of the U-Boot environment, persistence works the same way. Keep in mind that the persisting code path does not exist yet today though. U-Boot
Re: [Arm.ebbr-discuss] ebbr: boot behaviour without persistent variables
On Thu, Apr 26, 2018 at 12:52:04PM -0400, William Mills wrote: > 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? > If yes, Can it persist just until ExitBootServices or can it persit to > runtime time as well? > > 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.) Yes. This statement was based on my incorrect assumption that we were permitting systems without any persistent variable storage in the first revision of the spec. (As opposed to only systems that did not provide persistent variable storage at runtime.) > 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 ERROR for Sets but Gets works > 3) A system where Sets and Gets work and are persistent > > Support for a platform that does not ERROR Sets but does not do > non-volatile persistence will be discussed for EBBR.1 if we still think > it has value and platforms that will need it are common enough. Well, I was arguing for supporting that in EBBR.0 (since that matches the behaviour of some EDK2 ports), but I don't think that is something we would like to _add_ to EBBR.1 if it is not supported by EBBR.0. > I also heard that all platforms "can persist variables before exit boot > services". Is this true today for u-boot based systems that have an env > storage defined? What about u-boot based system that do not define any > env storage and always rely on uEnv.txt etc? Yes, this was the reason for my last request for clarification. And the view was that such systems will not be compliant with any version of the spec. / Leif ___ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
Re: DT handling, [Ref Linux-Efi]
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
