Re: [Arm.ebbr-discuss] Next steps for EBBR
On 04/04/2018 15:23, Grant Likely wrote: On 04/04/2018 15:12, Mills, William wrote: Grant, None of this is archived at: https://lists.linaro.org/pipermail/boot-architecture/ (even the stuff that explicitly cc'ed the list) Hmmm. I don't know what has happened there. I just got Linaro to reset the admin password of that list, and I've cc'd this message to the list as a test. I'll track down the problem. Seems to be working now. My reply at least shows up in the archive now: https://lists.linaro.org/pipermail/boot-architecture/2018-April/000416.html g. Why did we switch to an @arm.com list? Is there a public archive? Can anyone opt in or is this invite only? We should use open tools for an open standard. boot-architecture was originally cc'd because it has a public archive. I do not intend for any of this discussion to be on a list without an archive. g. Thanks, Bill -Original Message- From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss-boun...@arm.com] On Behalf Of Grant Likely Sent: Thursday, March 29, 2018 5:52 PM To: arm.ebbr-disc...@arm.com; Da Xue Subject: Re: [Arm.ebbr-discuss] Next steps for EBBR On 29/03/2018 22:24, Da Xue wrote: We expect the primary users of EBBR will be embedded & developer Arm boards using U-Boot firmware and Devicetree machine description My concern is around device tree and EFI variable storage for u-boot on flash. The two elephants in the room. How to handle device tree updates? Do we track mainline? How to handle detection and addition of overlays? Certainly issues to discuss while drafting EBBR. We expect a distribution will be able to use the same software (Distro Installer, Grub, Linux UEFI stub, Shim), and the same media (installer images) on both embedded and server platforms Are you referring to SBSA when you say "server platforms"? I don't see why this has to be the case. Yes, I'm talking about SBSA/SBBR compliant platforms. EBBR will require a subset of what SBBR requires; essentially just enough of the UEFI spec to execute a UEFI OS Loader from media or the network. U-Boot implements this today, and a distro would be able to use the exact same OSLoader/Installer on both SBSA/SBBR systems and EBBR systems. That's part of the point of this exercise. What do you mean when you say, "don't see why this has to be the case?" What do you see as the alternative? Linux distributions - Can make EBBR compliance a requirement for support Vendors haven't standardized boot rom sequence. Some SoC boot from SPI first, other eMMC, and others SD card. This is a major pain point that ARM/Linaro should address. I don't see why distributions should force EBBR compliance when a simple u-boot script loading or scanning for a Linux EFI stub suffices unless EBBR is incredibly simple and small. I need to emphasize the simple and small part because it will also allow EBBR to scale up and down. Shouldn't be an issue for EBBR. EBBR is focused on the Firmware->OS interface. It doesn't matter where the SoC boots U-Boot or Tianocore from as long as firmware presents a consistent interface beyond that point. It also doesn't matter how U-Boot implements the boot interface. If the U-Boot developers think a U-Boot script that searches for OS Loaders in the correct order is the best implementation, then that is just fine. What is important is that the OS image must not need to contain anything special in order to boot. ie. It must not require a script to be installed on the media because the UEFI spec already specifies how to find the boot program. End users - EBBR will make it simpler to use embedded Arm boards because each board will not require special setup instructions or image formats Distributions will still need to explicitly have SoC family support in their kernels. Yes, that is a given. It would be a lot of work (that will never get done) for SoC vendors to abstract device classes and functions like Intel has for UEFI. For the boot time environment the abstractions are already there. U-Boot implements the needed abstractions in the form of the U-Boot device drivers. The UEFI APIs are mapped directly onto the U-Boot device model. For runtime services you're right. There is no plan to implement a runtime abstract device driver model. On Thu, Mar 29, 2018 at 6:47 AM, Grant Likely <grant.lik...@arm.com <mailto:grant.lik...@arm.com>> wrote: On 29/03/2018 10:06, Alexander Graf wrote: Does Windows for IoT run in aarch64 mode by now? If not, we might have a problem :). I wouldn't call that a problem. It is up to Microsoft on whether or not they care about an aarch64 port of Windows IoT. They may still find EBBR useful for aarch32, and the whole point of having them involved is they can share what they think would be valuable to have in the spec. Cheers, g. Alex Am 29.03.201
Re: [Arm.ebbr-discuss] Next steps for EBBR
On 04/04/2018 15:12, Mills, William wrote: Grant, None of this is archived at: https://lists.linaro.org/pipermail/boot-architecture/ (even the stuff that explicitly cc'ed the list) Hmmm. I don't know what has happened there. I just got Linaro to reset the admin password of that list, and I've cc'd this message to the list as a test. I'll track down the problem. Why did we switch to an @arm.com list? Is there a public archive? Can anyone opt in or is this invite only? We should use open tools for an open standard. boot-architecture was originally cc'd because it has a public archive. I do not intend for any of this discussion to be on a list without an archive. g. Thanks, Bill -Original Message- From: arm.ebbr-discuss-boun...@arm.com [mailto:arm.ebbr-discuss-boun...@arm.com] On Behalf Of Grant Likely Sent: Thursday, March 29, 2018 5:52 PM To: arm.ebbr-disc...@arm.com; Da Xue Subject: Re: [Arm.ebbr-discuss] Next steps for EBBR On 29/03/2018 22:24, Da Xue wrote: We expect the primary users of EBBR will be embedded & developer Arm boards using U-Boot firmware and Devicetree machine description My concern is around device tree and EFI variable storage for u-boot on flash. The two elephants in the room. How to handle device tree updates? Do we track mainline? How to handle detection and addition of overlays? Certainly issues to discuss while drafting EBBR. We expect a distribution will be able to use the same software (Distro Installer, Grub, Linux UEFI stub, Shim), and the same media (installer images) on both embedded and server platforms Are you referring to SBSA when you say "server platforms"? I don't see why this has to be the case. Yes, I'm talking about SBSA/SBBR compliant platforms. EBBR will require a subset of what SBBR requires; essentially just enough of the UEFI spec to execute a UEFI OS Loader from media or the network. U-Boot implements this today, and a distro would be able to use the exact same OSLoader/Installer on both SBSA/SBBR systems and EBBR systems. That's part of the point of this exercise. What do you mean when you say, "don't see why this has to be the case?" What do you see as the alternative? Linux distributions - Can make EBBR compliance a requirement for support Vendors haven't standardized boot rom sequence. Some SoC boot from SPI first, other eMMC, and others SD card. This is a major pain point that ARM/Linaro should address. I don't see why distributions should force EBBR compliance when a simple u-boot script loading or scanning for a Linux EFI stub suffices unless EBBR is incredibly simple and small. I need to emphasize the simple and small part because it will also allow EBBR to scale up and down. Shouldn't be an issue for EBBR. EBBR is focused on the Firmware->OS interface. It doesn't matter where the SoC boots U-Boot or Tianocore from as long as firmware presents a consistent interface beyond that point. It also doesn't matter how U-Boot implements the boot interface. If the U-Boot developers think a U-Boot script that searches for OS Loaders in the correct order is the best implementation, then that is just fine. What is important is that the OS image must not need to contain anything special in order to boot. ie. It must not require a script to be installed on the media because the UEFI spec already specifies how to find the boot program. End users - EBBR will make it simpler to use embedded Arm boards because each board will not require special setup instructions or image formats Distributions will still need to explicitly have SoC family support in their kernels. Yes, that is a given. It would be a lot of work (that will never get done) for SoC vendors to abstract device classes and functions like Intel has for UEFI. For the boot time environment the abstractions are already there. U-Boot implements the needed abstractions in the form of the U-Boot device drivers. The UEFI APIs are mapped directly onto the U-Boot device model. For runtime services you're right. There is no plan to implement a runtime abstract device driver model. On Thu, Mar 29, 2018 at 6:47 AM, Grant Likely <grant.lik...@arm.com <mailto:grant.lik...@arm.com>> wrote: On 29/03/2018 10:06, Alexander Graf wrote: Does Windows for IoT run in aarch64 mode by now? If not, we might have a problem :). I wouldn't call that a problem. It is up to Microsoft on whether or not they care about an aarch64 port of Windows IoT. They may still find EBBR useful for aarch32, and the whole point of having them involved is they can share what they think would be valuable to have in the spec. Cheers, g. Alex Am 29.03.2018 um 09:34 schrieb Charles Garcia-Tobin <charles.garcia-to...@arm.com <mailto:charles.garcia-to...@arm.com>>: Nice! On 2
