Hi, On Sat, Mar 16, 2024 at 9:51 AM Conor Dooley <conor@xxxxxxxxxx> wrote: > > On Sat, Mar 16, 2024 at 04:20:03PM +0000, Conor Dooley wrote: > > On Thu, Mar 14, 2024 at 02:20:38PM +0000, Caleb Connolly wrote: > > > On 14/03/2024 12:11, Amrit Anand wrote: > > > 2. A top level board-id property that isn't namespaced implies that it > > > isn't vendor specific, but the proposed implementation doesn't even > > > pretend to be vendor agnostic. > > > > I pointed out previously that the Chromebook guys had some similar > > issues with dtb selection when the OEM varies parts but there does not > > seem to be any of them on CC here. > > That's maybe a bit harsh of me actually, I see that there's a > chrome-platform address on CC, but I don't know if that's gonna reach > the guys that work on these devices (Chen-Yu Tsai and Doug Anderson in > particular). Thanks for the CC. Yeah, I don't watch the "chrome-platform" list myself, though maybe I should... The Chromebook boot flow and how we've handled this so far is documented in the kernel [1]. This method is what we've been using (with slight modifications over the years) since the earlier ARM Chromebooks and is, I believe, supported in both the depthcharge loader (used in Chromebooks) and also in U-Boot, though it's possible (?) that the U-Boot rules might vary ever so slightly. I haven't tried using U-Boot to boot a Chromebook in years. The current way things work for Chromebooks involves a heavy amount of duplication. We bundle an entire "DTB" for every relevant board/rev/sku combination even though many of those DTBs are 99% the same as the other ones. The DTBs have been relatively small and we compress them so this hasn't been a massive deal, but it's always been on the TODO list to come up with a scheme to use DT overlays. We've also talked about bundling a device tree that has the superset of components and then using an in-kernel driver to set the status of some components to okay and there is some overlap there in the possible way to represent board variants. I think Chen-Yu is going to talk about a few of these topics next month at EOSS [2]. In terms of looking at your specific proposal, it's definitely trying to factor in a lot more things than the current one that Chromebooks use. The Chromebook model was "simple" enough that we could just leverage the compatible string, though the way we leverage it has ended up controversial over the years. Yours is definitely too complicated to work the same way. It seems like device tree overlays would be a better fit? I'm not an expert so maybe this is already solved somewhere, but I'd imagine the hard part is getting everyone to agree on how to specify stuff in the DT overlay that allows the bootloader to know whether to overlay it or not... [1] https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html [2] https://eoss24.sched.com/event/1aBGe/second-source-component-probing-on-device-tree-platforms-chen-yu-tsai-google-llc
