Bill On Mon, 11 Jun 2018 at 21:01 William Mills <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 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
