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-boun...@arm.com <arm.ebbr-discuss-boun...@arm.com> On Behalf Of David Rusling Sent: Tuesday, June 12, 2018 1:25 AM To: wmi...@ti.com Cc: boot-architecture@lists.linaro.org; arm.ebbr-discuss <arm.ebbr-disc...@arm.com> Subject: Re: [Arm.ebbr-discuss] EBBR - Fog, Edge and Device Bill On Mon, 11 Jun 2018 at 21:01 William Mills <wmi...@ti.com<mailto:wmi...@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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
