On Tue, Mar 19, 2024 at 5:36 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > 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]. That's right. It's the last talk before the closing game on the last day. Elliot is also presenting the board-id proposal at EOSS [3], which is the last talk of day 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... I think qcom,board-id + qcom,oem-id maps to our board name + SKU ID + revision. The difference is probably because we make our device codenames public? We don't actually have integer identifiers for each board family, though I do see the appeal of it. So it looks like this proposal is more about identifying boards without polluting (?) the compatible namespace with all sorts of combinations and hacks like we have. > [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 [3] https://eoss24.sched.com/event/1aBFy/shipping-multiple-devicetrees-how-to-identify-which-dtb-is-for-my-board-elliot-berman-qualcomm
