I've been thinking about how to organize EBBR. It started matching the SBBR document structure with the ACPI & ACPI sections removed, but I've moved things around a bit (for instance, citations are now at the end and use the citation markup so they can be collected from the whole document.) We also want to talk about some device sharing issues that SBBR doesn't need to get into, so we need a place to put that stuff.
For discussion, what do you think of the following Table of Contents? I do expect this to change, but I'd like to come to general agreement on how the document is structured.
1. About this Document 1.1 Introcution 1.2 Scope
2. UEFI 2.1 UEFI Version 2.2 UEFI Compliance 2.3 UEFI System Environment and Configuration 2.4 UEFI Boot Services 2.4.1 Required (Moved from Appendix to here) 2.4.2 Optional (this section may be redundant. If it isn't required, then by default it is optional!!) 2.5 UEFI Runtime Services 2.5.1 Required 2.5.2 Optional
3. System Configuration Data 3.1 Devicetree 3.2 ACPI
4. Privileged Firmware 4.1 PSCI 4.2 Secure Services
5. Hardware Configuration and Access 5.1 Shared Storage Media 5.1.1 Block device partitioning 5.1.2 Protecting firmware partitions/blocks 5.2 Shared access (i2c/SPI) 5.3 RTC
(Everything below is additional guidance material, and doesn't make up part of the spec. I've not decided if I'd rather have it in the documentm, or as a separate guidance note) Appendix A - U-Boot implementation note (How to configure U-Boot to be EBBR compliant) Appendix B - EBBR Compliance Testing 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.
On Mon, May 21, 2018 at 1:59 PM, Grant Likely grant.likely@arm.com wrote:
I've been thinking about how to organize EBBR. It started matching the SBBR document structure with the ACPI & ACPI sections removed, but I've moved things around a bit (for instance, citations are now at the end and use the citation markup so they can be collected from the whole document.) We also want to talk about some device sharing issues that SBBR doesn't need to get into, so we need a place to put that stuff.
For discussion, what do you think of the following Table of Contents? I do expect this to change, but I'd like to come to general agreement on how the document is structured.
Looks fine to me, what about optional bits? I'd like to see options around random seed for ASLR and something around secure boot. Not sure where they sit in the uefi spec so where best they'd fit.
Peter
- About this Document
1.1 Introcution 1.2 Scope
- UEFI
2.1 UEFI Version 2.2 UEFI Compliance 2.3 UEFI System Environment and Configuration 2.4 UEFI Boot Services 2.4.1 Required (Moved from Appendix to here) 2.4.2 Optional (this section may be redundant. If it isn't required, then by default it is optional!!) 2.5 UEFI Runtime Services 2.5.1 Required 2.5.2 Optional
- System Configuration Data
3.1 Devicetree 3.2 ACPI
- Privileged Firmware
4.1 PSCI 4.2 Secure Services
- Hardware Configuration and Access
5.1 Shared Storage Media 5.1.1 Block device partitioning 5.1.2 Protecting firmware partitions/blocks 5.2 Shared access (i2c/SPI) 5.3 RTC
(Everything below is additional guidance material, and doesn't make up part of the spec. I've not decided if I'd rather have it in the documentm, or as a separate guidance note) Appendix A - U-Boot implementation note (How to configure U-Boot to be EBBR compliant) Appendix B - EBBR Compliance Testing _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
See below.
As I have said before, I like a document that has examples. We all have traded example use cases and platforms to make our points about what should and should not be required. That should not be left embedded deep in mail archives. Instead we should give the spec reader the same benefit of understanding.
The examples of course would not be binding as requirements or even recommendations. They are only to give deeper understanding of the motivation.
On 05/21/2018 08:59 AM, Grant Likely wrote:
I've been thinking about how to organize EBBR. It started matching the SBBR document structure with the ACPI & ACPI sections removed, but I've moved things around a bit (for instance, citations are now at the end and use the citation markup so they can be collected from the whole document.) We also want to talk about some device sharing issues that SBBR doesn't need to get into, so we need a place to put that stuff.
For discussion, what do you think of the following Table of Contents? I do expect this to change, but I'd like to come to general agreement on how the document is structured.
- About this Document
1.1 Introcution 1.2 Scope
- UEFI
2.1 UEFI Version 2.2 UEFI Compliance 2.3 UEFI System Environment and Configuration 2.4 UEFI Boot Services 2.4.1 Required (Moved from Appendix to here) 2.4.2 Optional (this section may be redundant. If it isn't required, then by default it is optional!!) 2.5 UEFI Runtime Services 2.5.1 Required 2.5.2 Optional
- System Configuration Data
3.1 Devicetree 3.2 ACPI
- Privileged Firmware
4.1 PSCI 4.2 Secure Services
- Hardware Configuration and Access
5.1 Shared Storage Media 5.1.1 Block device partitioning 5.1.2 Protecting firmware partitions/blocks 5.2 Shared access (i2c/SPI) 5.3 RTC
I like these 5.* sections. A specific section to discuss the various points of a specific concept. This is much better than trying to make some of those points in the UEFI requirements/recommendation sections. This allows the UEFI sections to be fairly dry and crisp.
(Everything below is additional guidance material, and doesn't make up part of the spec. I've not decided if I'd rather have it in the documentm, or as a separate guidance note) Appendix A - U-Boot implementation note (How to configure U-Boot to be EBBR compliant) Appendix B - EBBR Compliance Testing
Appendix C - Example Platforms
Non binding example platforms to illustrate some of the concepts. Pick two or maybe three to best illustrate various situations. Example examples: * Dedicated firmware storage, Embedded OS storage, and removable media (PC like) * Single Embedded storage and no removable storage but network access
Appendix D - Example Use cases
* Daniel's example of OS installer image on removable media or network "iso" that then installs to embedded storage (or a different removable storage)
* EBBR Noob * Platform specific OS image * Platform recovery image (not bound by EBBR)
All, I'm writing a blog on Linaro's reorganisation (sounds fascinating doesn't it?). I'm more talking about directions than teams etc, it's not a list of groups / SIGs etc. One area I'd like to highlight is the importance of EBBR to LEDGE (aka Fog and Networking). Some thoughts / questions:
[1] do others believe that EBBR is key to Fog / Edge? I'm less convinced that Device land will see the push (their is a symbiotic link between gateways and devices, with gateways being the 'point of security' for their 'slave' devices).
[2] EBBR et al is complex, so moving down the reference platform route makes sense (to me at least). I know that reference platforms created a lot of debate in Linaro in LEG, but I think that has settled down now, with everyone understanding what they are and are not and where the value is.
[3] I presume the best way to reference EBBR is via the git repository. Any other information I should reference (email lists etc)?
Many thanks, David
On Tue, May 22, 2018 at 11:40 AM, David Rusling david.rusling@linaro.org wrote:
All, I'm writing a blog on Linaro's reorganisation (sounds fascinating doesn't it?). I'm more talking about directions than teams etc, it's not a list of groups / SIGs etc. One area I'd like to highlight is the importance of EBBR to LEDGE (aka Fog and Networking). Some thoughts / questions:
[1] do others believe that EBBR is key to Fog / Edge? I'm less convinced that Device land will see the push (their is a symbiotic link between gateways and devices, with gateways being the 'point of security' for their 'slave' devices).
I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.
[2] EBBR et al is complex, so moving down the reference platform route makes sense (to me at least). I know that reference platforms created a lot of debate in Linaro in LEG, but I think that has settled down now, with everyone understanding what they are and are not and where the value is.
[3] I presume the best way to reference EBBR is via the git repository. Any other information I should reference (email lists etc)?
Yes, I would reference the githib pages [1], we should add things like details of the mailing list into the README/wiki there so there's one spot to reference for everything.
On Tue, 22 May 2018 at 11:52 Peter Robinson pbrobinson@gmail.com wrote:
On Tue, May 22, 2018 at 11:40 AM, David Rusling david.rusling@linaro.org wrote:
All, I'm writing a blog on Linaro's reorganisation (sounds fascinating
doesn't
it?). I'm more talking about directions than teams etc, it's not a
list of
groups / SIGs etc. One area I'd like to highlight is the importance of
EBBR
to LEDGE (aka Fog and Networking). Some thoughts / questions:
[1] do others believe that EBBR is key to Fog / Edge? I'm less convinced that Device land will see the push (their is a symbiotic link between gateways and devices, with gateways being the 'point of security' for
their
'slave' devices).
I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.
Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
[2] EBBR et al is complex, so moving down the reference platform route
makes
sense (to me at least). I know that reference platforms created a lot of debate in Linaro in LEG, but I think that has settled down now, with everyone understanding what they are and are not and where the value is.
[3] I presume the best way to reference EBBR is via the git repository.
Any
other information I should reference (email lists etc)?
Yes, I would reference the githib pages [1], we should add things like details of the mailing list into the README/wiki there so there's one spot to reference for everything.
Yes, that's the hub for everything...
David
All, thanks. I'm pulling together a set of slides for the Linaro members meeting in July plus I'm looking to ensure that the sessions / meetings around this at YVR18 are correct.
For EBBR, are you all planning equivalent documents to SBBR (that is, EBSA, etc or are you planning to broaden those documents to include embedded)?
David
On Tue, 22 May 2018 at 12:12 David Rusling david.rusling@linaro.org wrote:
On Tue, 22 May 2018 at 11:52 Peter Robinson pbrobinson@gmail.com wrote:
On Tue, May 22, 2018 at 11:40 AM, David Rusling david.rusling@linaro.org wrote:
All, I'm writing a blog on Linaro's reorganisation (sounds fascinating
doesn't
it?). I'm more talking about directions than teams etc, it's not a
list of
groups / SIGs etc. One area I'd like to highlight is the importance of
EBBR
to LEDGE (aka Fog and Networking). Some thoughts / questions:
[1] do others believe that EBBR is key to Fog / Edge? I'm less
convinced
that Device land will see the push (their is a symbiotic link between gateways and devices, with gateways being the 'point of security' for
their
'slave' devices).
I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.
Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
[2] EBBR et al is complex, so moving down the reference platform route
makes
sense (to me at least). I know that reference platforms created a lot
of
debate in Linaro in LEG, but I think that has settled down now, with everyone understanding what they are and are not and where the value is.
[3] I presume the best way to reference EBBR is via the git
repository. Any
other information I should reference (email lists etc)?
Yes, I would reference the githib pages [1], we should add things like details of the mailing list into the README/wiki there so there's one spot to reference for everything.
Yes, that's the hub for everything...
David
-- David A Rusling CTO, Linaro https://linaro.org
EBBR is a separate document from SBBR, and it is open in the git repository. We have no plan for an EBSA. We may include some small hardware requirements in EBBR if needed, but at this time no plan for EBSA.
* DW
From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of David Rusling Sent: Monday, June 11, 2018 4:53 AM To: Peter Robinson pbrobinson@gmail.com Cc: boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device
All, thanks. I'm pulling together a set of slides for the Linaro members meeting in July plus I'm looking to ensure that the sessions / meetings around this at YVR18 are correct.
For EBBR, are you all planning equivalent documents to SBBR (that is, EBSA, etc or are you planning to broaden those documents to include embedded)?
David On Tue, 22 May 2018 at 12:12 David Rusling <david.rusling@linaro.orgmailto:david.rusling@linaro.org> wrote: On Tue, 22 May 2018 at 11:52 Peter Robinson <pbrobinson@gmail.commailto:pbrobinson@gmail.com> wrote: On Tue, May 22, 2018 at 11:40 AM, David Rusling <david.rusling@linaro.orgmailto:david.rusling@linaro.org> wrote:
All, I'm writing a blog on Linaro's reorganisation (sounds fascinating doesn't it?). I'm more talking about directions than teams etc, it's not a list of groups / SIGs etc. One area I'd like to highlight is the importance of EBBR to LEDGE (aka Fog and Networking). Some thoughts / questions:
[1] do others believe that EBBR is key to Fog / Edge? I'm less convinced that Device land will see the push (their is a symbiotic link between gateways and devices, with gateways being the 'point of security' for their 'slave' devices).
I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.
Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
[2] EBBR et al is complex, so moving down the reference platform route makes sense (to me at least). I know that reference platforms created a lot of debate in Linaro in LEG, but I think that has settled down now, with everyone understanding what they are and are not and where the value is.
[3] I presume the best way to reference EBBR is via the git repository. Any other information I should reference (email lists etc)?
Yes, I would reference the githib pages [1], we should add things like details of the mailing list into the README/wiki there so there's one spot to reference for everything.
[1] https://github.com/ARM-software/ebbr
Yes, that's the hub for everything...
David
-- David A Rusling CTO, Linaro https://linaro.org -- David A Rusling CTO, Linaro https://linaro.org 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.
Dong, thanks - good plan - keep it in the EBBR and, if it gets bulky, move it out... David
On Mon, 11 Jun 2018 at 16:47 Dong Wei Dong.Wei@arm.com wrote:
EBBR is a separate document from SBBR, and it is open in the git repository. We have no plan for an EBSA. We may include some small hardware requirements in EBBR if needed, but at this time no plan for EBSA.
- DW
*From:* arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com *On Behalf Of *David Rusling *Sent:* Monday, June 11, 2018 4:53 AM *To:* Peter Robinson pbrobinson@gmail.com *Cc:* boot-architecture@lists.linaro.org; arm.ebbr-discuss < arm.ebbr-discuss@arm.com> *Subject:* Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device
All,
thanks. I'm pulling together a set of slides for the Linaro members meeting in July plus I'm looking to ensure that the sessions / meetings around this at YVR18 are correct.
For EBBR, are you all planning equivalent documents to SBBR (that is, EBSA, etc or are you planning to broaden those documents to include embedded)?
David
On Tue, 22 May 2018 at 12:12 David Rusling david.rusling@linaro.org wrote:
On Tue, 22 May 2018 at 11:52 Peter Robinson pbrobinson@gmail.com wrote:
On Tue, May 22, 2018 at 11:40 AM, David Rusling david.rusling@linaro.org wrote:
All, I'm writing a blog on Linaro's reorganisation (sounds fascinating
doesn't
it?). I'm more talking about directions than teams etc, it's not a
list of
groups / SIGs etc. One area I'd like to highlight is the importance of
EBBR
to LEDGE (aka Fog and Networking). Some thoughts / questions:
[1] do others believe that EBBR is key to Fog / Edge? I'm less convinced that Device land will see the push (their is a symbiotic link between gateways and devices, with gateways being the 'point of security' for
their
'slave' devices).
I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.
Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
[2] EBBR et al is complex, so moving down the reference platform route
makes
sense (to me at least). I know that reference platforms created a lot of debate in Linaro in LEG, but I think that has settled down now, with everyone understanding what they are and are not and where the value is.
[3] I presume the best way to reference EBBR is via the git repository.
Any
other information I should reference (email lists etc)?
Yes, I would reference the githib pages [1], we should add things like details of the mailing list into the README/wiki there so there's one spot to reference for everything.
[1] https://github.com/ARM-software/ebbr
Yes, that's the hub for everything...
David
--
David A Rusling
CTO, Linaro
--
David A Rusling
CTO, Linaro
https://linaro.org 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.
David,
On 05/22/2018 07:12 AM, David Rusling wrote:
On Tue, 22 May 2018 at 11:52 Peter Robinson <pbrobinson@gmail.com mailto:pbrobinson@gmail.com> wrote:
On Tue, May 22, 2018 at 11:40 AM, David Rusling <david.rusling@linaro.org <mailto:david.rusling@linaro.org>> wrote: > All, > I'm writing a blog on Linaro's reorganisation (sounds fascinating doesn't > it?). I'm more talking about directions than teams etc, it's not a list of > groups / SIGs etc. One area I'd like to highlight is the importance of EBBR > to LEDGE (aka Fog and Networking). Some thoughts / questions: > > [1] do others believe that EBBR is key to Fog / Edge? I'm less convinced > that Device land will see the push (their is a symbiotic link between > gateways and devices, with gateways being the 'point of security' for their > 'slave' devices). I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
Sure some of these devices will be so server like they should follow the whole SBBR/SBSA. But there will be others that need something lighter. That is where the EBBR should come in. We are trying to make sure it scales down to even $7 boards.
I do think the EBBR is important for this Fog/Edge eco-system but I do not think it will be obvious to everyone that they should pay attention.
The competition for EBBR will be the status quo. Many people see no need to make their HW run multiple OSes. They believe that their custom tweaked OS is the only thing that need ever run.
The same thing is true in the network switch world but the existance of the ONIE project suggests that that world has seen the value of multiple installable OSes.
A robust container eco-system actually decreases the need for EBBR because all the real need for portability is hidden in the containers. A given HW platform just needs the base container host and everything is good.
Luckily there is such a diversity for container hosts systems, the need for EBBR re-emerges so the HW vendor does not need to lock into just one.
> [2] EBBR et al is complex, so moving down the reference platform route makes > sense (to me at least). I know that reference platforms created a lot of > debate in Linaro in LEG, but I think that has settled down now, with > everyone understanding what they are and are not and where the value is. >
I don't know if I agree with the complex part. We are trying to make it easy for HW vendors: Use latest upstream U-boot configured this way and your done. Want to add features? Add these things to your HW.
However for the U-boot/EDK/OS authors we do want a test platform and to show it done well.
As already discussed some in the EBBR calls, QEMU should be "the reference platform". We can configure QEMU to be a very HW resource rich system, a very HW resource constrained system, or any thing in between.
We hope and expect that multiple boards will then buy into this system and be able to show it working. But that is really up to each board's owners / landing team whatever. These are not "reference platforms" but examples of EBBR in the wild. The more the merrier; no one is picking just one real HW platform.
Bill
Bill
On Mon, 11 Jun 2018 at 21:01 William Mills wmills@ti.com wrote:
I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
Sure some of these devices will be so server like they should follow the whole SBBR/SBSA. But there will be others that need something lighter. That is where the EBBR should come in. We are trying to make sure it scales down to even $7 boards.
Agreed. So long as the devices are 'tethered' to a gateway, they can use whatever methods they want. We're a long way from standardising all IoT devices so that they can be managed everywhere by anything.
I do think the EBBR is important for this Fog/Edge eco-system but I do not think it will be obvious to everyone that they should pay attention.
Exactly why I'm covering 'The Boot Problem' @ the member's meeting in Paris next month.
The competition for EBBR will be the status quo. Many people see no need to make their HW run multiple OSes. They believe that their custom tweaked OS is the only thing that need ever run.
True
The same thing is true in the network switch world but the existance of the ONIE project suggests that that world has seen the value of multiple installable OSes.
I think that the SoC guys want it that way, they want to sell silicon into multiple places. The device manufacturers care less.
A robust container eco-system actually decreases the need for EBBR because all the real need for portability is hidden in the containers. A given HW platform just needs the base container host and everything is good.
Yes, containers help automate the payload, but they don't reduce the need for a sane set of firmware 'blobs' that interact safely and securely and are OTA updateable.
Luckily there is such a diversity for container hosts systems, the need for EBBR re-emerges so the HW vendor does not need to lock into just one.
Cut down / embedded Kubernetes works for me
> [2] EBBR et al is complex, so moving down the reference platform route makes > sense (to me at least). I know that reference platforms created a lot of > debate in Linaro in LEG, but I think that has settled down now,with
> everyone understanding what they are and are not and where the value is. >I don't know if I agree with the complex part. We are trying to make it easy for HW vendors: Use latest upstream U-boot configured this way and your done. Want to add features? Add these things to your HW.
However for the U-boot/EDK/OS authors we do want a test platform and to show it done well.
As already discussed some in the EBBR calls, QEMU should be "the reference platform". We can configure QEMU to be a very HW resource rich system, a very HW resource constrained system, or any thing in between.
Agreed.
We hope and expect that multiple boards will then buy into this system and be able to show it working. But that is really up to each board's owners / landing team whatever. These are not "reference platforms" but examples of EBBR in the wild. The more the merrier; no one is picking just one real HW platform.
Good strategy but we need to have the reference Platforms discussion again...
David
Bill
There may be a need for making EBBR more aware to the community.
I ran into a case at Computex last week. Ambedded makes storage servers using Marvell SoCs. Even though Marvell provides UEFI code for the SoC, Ambedded chose to do the uboot anyways.
* DW
From: arm.ebbr-discuss-bounces@arm.com arm.ebbr-discuss-bounces@arm.com On Behalf Of David Rusling Sent: Tuesday, June 12, 2018 1:25 AM To: wmills@ti.com Cc: boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device
Bill On Mon, 11 Jun 2018 at 21:01 William Mills <wmills@ti.commailto:wmills@ti.com> wrote:
I think it's likely useful to fog/edge but not critical, it will depend a lot on the size of the device. In the arm space it'll be either EBBR or SBBR/SBSA, either way standardisation will be good.Well, people misuse the term 'gateway' wildly from tiny bridge devices to grown up things. It will be uneven, but the push will come. Weaker than the data center.
Sure some of these devices will be so server like they should follow the whole SBBR/SBSA. But there will be others that need something lighter. That is where the EBBR should come in. We are trying to make sure it scales down to even $7 boards.
Agreed. So long as the devices are 'tethered' to a gateway, they can use whatever methods they want. We're a long way from standardising all IoT devices so that they can be managed everywhere by anything.
I do think the EBBR is important for this Fog/Edge eco-system but I do not think it will be obvious to everyone that they should pay attention.
Exactly why I'm covering 'The Boot Problem' @ the member's meeting in Paris next month.
The competition for EBBR will be the status quo. Many people see no need to make their HW run multiple OSes. They believe that their custom tweaked OS is the only thing that need ever run.
True
The same thing is true in the network switch world but the existance of the ONIE project suggests that that world has seen the value of multiple installable OSes.
I think that the SoC guys want it that way, they want to sell silicon into multiple places. The device manufacturers care less.
A robust container eco-system actually decreases the need for EBBR because all the real need for portability is hidden in the containers. A given HW platform just needs the base container host and everything is good.
Yes, containers help automate the payload, but they don't reduce the need for a sane set of firmware 'blobs' that interact safely and securely and are OTA updateable.
Luckily there is such a diversity for container hosts systems, the need for EBBR re-emerges so the HW vendor does not need to lock into just one.
Cut down / embedded Kubernetes works for me
> [2] EBBR et al is complex, so moving down the reference platform route makes > sense (to me at least). I know that reference platforms created a lot of > debate in Linaro in LEG, but I think that has settled down now, with > everyone understanding what they are and are not and where the value is. >
I don't know if I agree with the complex part. We are trying to make it easy for HW vendors: Use latest upstream U-boot configured this way and your done. Want to add features? Add these things to your HW.
However for the U-boot/EDK/OS authors we do want a test platform and to show it done well.
As already discussed some in the EBBR calls, QEMU should be "the reference platform". We can configure QEMU to be a very HW resource rich system, a very HW resource constrained system, or any thing in between.
Agreed.
We hope and expect that multiple boards will then buy into this system and be able to show it working. But that is really up to each board's owners / landing team whatever. These are not "reference platforms" but examples of EBBR in the wild. The more the merrier; no one is picking just one real HW platform.
Good strategy but we need to have the reference Platforms discussion again...
David
Bill -- David A Rusling CTO, Linaro https://linaro.org 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.
On Tue, Jun 12, 2018 at 10:16 AM, Dong Wei Dong.Wei@arm.com wrote:
There may be a need for making EBBR more aware to the community.
I ran into a case at Computex last week. Ambedded makes storage servers using Marvell SoCs. Even though Marvell provides UEFI code for the SoC, Ambedded chose to do the uboot anyways.
I think a relevant distinction here is that if someone wants to still do u-boot, they should strongly consider using a version new enough to implement EBBR interfaces such as UEFI services. On price-sensitive devices where you want to optimize flash BOM cost, skipping Tianocore *can* have cost impact, but if the interfaces are kept compatible that should be just fine.
As always, if the SoC vendor provides a reference implementation for their platforms such that doing the right thing is also doing the easiest thing when making a derivative product design, everybody wins.
-Olof
Agree
- DW - -----Original Message----- From: Olof Johansson olof@lixom.net Sent: Tuesday, June 12, 2018 10:58 AM To: Dong Wei Dong.Wei@arm.com Cc: David Rusling david.rusling@linaro.org; wmills@ti.com; boot-architecture@lists.linaro.org; arm.ebbr-discuss arm.ebbr-discuss@arm.com Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device
On Tue, Jun 12, 2018 at 10:16 AM, Dong Wei Dong.Wei@arm.com wrote:
There may be a need for making EBBR more aware to the community.
I ran into a case at Computex last week. Ambedded makes storage servers using Marvell SoCs. Even though Marvell provides UEFI code for the SoC, Ambedded chose to do the uboot anyways.
I think a relevant distinction here is that if someone wants to still do u-boot, they should strongly consider using a version new enough to implement EBBR interfaces such as UEFI services. On price-sensitive devices where you want to optimize flash BOM cost, skipping Tianocore *can* have cost impact, but if the interfaces are kept compatible that should be just fine.
As always, if the SoC vendor provides a reference implementation for their platforms such that doing the right thing is also doing the easiest thing when making a derivative product design, everybody wins.
-Olof 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.
This is why reference platforms make sense as the canonical example. There's a clear mission to create / support U-Boot with the EFI extensions defined by EBBR.
David
On Tue, 12 Jun 2018 at 19:55 Dong Wei Dong.Wei@arm.com wrote:
Agree
- DW
-----Original Message----- From: Olof Johansson olof@lixom.net Sent: Tuesday, June 12, 2018 10:58 AM To: Dong Wei Dong.Wei@arm.com Cc: David Rusling david.rusling@linaro.org; wmills@ti.com; boot-architecture@lists.linaro.org; arm.ebbr-discuss < arm.ebbr-discuss@arm.com> Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device
On Tue, Jun 12, 2018 at 10:16 AM, Dong Wei Dong.Wei@arm.com wrote:
There may be a need for making EBBR more aware to the community.
I ran into a case at Computex last week. Ambedded makes storage servers
using Marvell SoCs. Even though Marvell provides UEFI code for the SoC, Ambedded chose to do the uboot anyways.
I think a relevant distinction here is that if someone wants to still do u-boot, they should strongly consider using a version new enough to implement EBBR interfaces such as UEFI services. On price-sensitive devices where you want to optimize flash BOM cost, skipping Tianocore *can* have cost impact, but if the interfaces are kept compatible that should be just fine.
As always, if the SoC vendor provides a reference implementation for their platforms such that doing the right thing is also doing the easiest thing when making a derivative product design, everybody wins.
-Olof 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@lists.linaro.org
-
David Rusling -
Dong Wei -
Grant Likely -
Olof Johansson -
Peter Robinson -
William Mills