On Thu, 19 Dec 2019 at 17:56, Steve McIntyre <steve.mcintyre@xxxxxxxxxx> wrote: > > Hi Francois, > > On Thu, Dec 19, 2019 at 01:52:29PM +0100, Francois Ozog wrote: > > > > 5. TS: How are we getting on with the separate DT repo? > > a. Hoping to convince people still, hoping the prototype will help > > b. Qualcomm are managing DTs separately with Android, and it's been > > working OK for them for over a year now. > > c. We're keen to make sure we don't annoy Linux people, > > particularly the non-DT users! > > > > > >We'll certainly talk about this in the context of DTE-8. > >As of now, U-Boot 19.10 embedded DTBs generates kernel 5.3 warnings for binding > >obsolescence on some platforms. > > That sounds worrying - do you have examples you could share, please? > We've been talking about DT stability, which doesn't sounds like this! > I need to rebuild the setup for that and will copy/paste the messages. > > >So, if we think of the DTB provided to Linux as a separate entity, we can split > >the world in two: > >- System Device Tree specs and unified repo agreed upon by platform people. > >- DTB for Linux to be considered as a separate entity in U-Boot (specific > >lifecycle in the specs). > >By doing this split we give time to Linux community to understand and see the > >value of the proposed DTB lifecycle. > > So there's two sides of this, and I *think* I understand which one > you're coming from: > > 1. General-purpose devices designed to be run by end-users with a > range of kernels/systems added/installed/upgraded later. The > platform comes with firmware that (hopefully?) includes working DT > data. > > 2. Special-purpose devices where the combination of > firmware/kernel/system are more tightly managed together by the > platform vendor. > Well. LEDGE is about making a hybrid between 1 and 2 for edge/fog compute nodes. As standard as possible so that a single kernel and userland rootfs can be used on as many as SoC possible. We want a strong "contract" between firmware and OS based on UEFI and only consider UEFI SecureBooting for production systems. The firmware/kernel/system will be tightly controlled from a versioning perspective but yet the kernel/userland *can* be the same on all boards. We have running example of devices updated to the latest equivalent of U-Boot 2019.10 (with some EFI bug fixes we introduced and extended UEFI support) that can run the same image (kernel+userland) on many 64 and 32 bits platforms (well 1 64 bits image and 1 32 bit image). > > I'm worried about case 1 here with DTB updates applied later, in that > there's potential for incompatibilities/breakage between the DTB and > the (user-installed) system running on it. How do we get to a good > general-purpose solution here? Difficult to be very assertive. Yet I'll share my humble views... Booting with kernel provided DTB is, for me, the same as a french man in an english car sitting on the front left hand side of the car saying "I provide the DTB (steering wheel on the left) so the hardware (the english car) need to comply to my description". Nobody thinks of a need for ACPI sources for each board to be present in Linux... I understand that it was just the way to go when everything was not cooked. We are getting closer to a mature situation so let's do things the "right way" ;-) I sense that SoC vendors shall update the firmware DTs much more frequently and in a better coordination with the Linux requirements in terms bindings. Then platform builders can prune/extend the DTB based on their design choices. This organization seem compatible and helpful for 1), 2) and LEDGE one. My 2cts. > > >There is still the question of signed DTB in a UEFI Secure Boot environment: > >shall we embed two DTBs in U-Boot or find a way to sign DTBs? > >And then we will be able to properly address the cases where OPTEE is doing > >live adjustments to a signed DTB. > > Cheers, > -- > Steve McIntyre steve.mcintyre@xxxxxxxxxx > <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs > -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@xxxxxxxxxx | Skype: ffozog
