Hi, On Mon, Jul 25, 2022 at 10:14 AM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > On 25/07/2022 19:09, Doug Anderson wrote: > > Hi, > > > > On Mon, Jul 25, 2022 at 10:08 AM Krzysztof Kozlowski > > <krzysztof.kozlowski@xxxxxxxxxx> wrote: > >> > >> On 25/07/2022 18:54, Doug Anderson wrote: > >>> Hi, > >>> > >>> On Mon, Jul 25, 2022 at 9:41 AM Krzysztof Kozlowski > >>> <krzysztof.kozlowski@xxxxxxxxxx> wrote: > >>>> > >>>> On 25/07/2022 18:25, Doug Anderson wrote: > >>>>> Let's look specifically at the device tree file for the LTE board. One > >>>>> way to look at it is that the dts for the LTE board should have > >>>>> compatibles: > >>>>> compatible = "lte", "wifi-only" > >>>>> > >>>>> The above matches the normal device tree mentality. It says: "hey, if > >>>>> you've got a lte driver for this board then use it; otherwise use the > >>>>> wifi-only driver". > >>>>> > >>>>> However, the above is actually broken for the bootloader use case. The > >>>>> bootloader is trying to pick a device tree and, to the bootloader, the > >>>>> above says "you can use this dts for either an lte board or a > >>>>> wifi-only board". That's bad. If the bootloader picks this device tree > >>>>> for a wifi-only board then the OS will try to initialize lte and > >>>>> things will crash. To go further, if you think about it things > >>>>> actually work fine if the wifi-only device tree says it's compatible > >>>>> with the LTE board. This is why I say it's opposite... ;-) > >>>> > >>>> This is not specific to "bootloaders" but your specific implementation > >>>> of entire chain. How you described it, you have dependent pieces - > >>>> user-space must use the same DTB as bootloader chosen, but bootloader > >>>> makes different choices than user-space. It's perfectly fine to make > >>>> these choices different, but then user-space should not depend on > >>>> something which was/was not initialized in bootloader. > >>> > >>> I think there's a misunderstanding here. > >>> > >>> Currently the ChromeOS bootloader doesn't use the device tree to > >>> control its flow at all. ...but the ChromeOS bootloader is in charge > >>> of picking the device tree to give to the kernel. > >>> > >>> Specifically I'm not aware of any mechanism in the kernel where you > >>> can give it a pile of device tree files and have it pick the right > >>> one. I believe that the official ABI says that it's up to the > >>> bootloader to provide the device tree to the kernel. This is right out > >>> of `Documentation/arm64/booting.rst` > >>> > >>> A FIT image is, as far as I'm aware, a standard way to bundle a kernel > >>> together with many device trees. The idea here is that the bootloader > >>> should grab the kernel out and whichever device tree it decides is the > >>> right one. It should then boot the kernel and give it the correct > >>> device tree. > >> > >> So that's the same case if you had a device called "Foo" (google,foo) > >> with a Qualcomm sdm845 processor (qcom,sdm845) and have a DTS like: > >> "other-company,bar", "qcom,sdm845" > >> > >> Bootloader on Foo sees "bar", ignores it. Then it sees "qcom,sdm845" > >> compatible and is all happy! It loads the DTS and passes to the kernel... > >> > >> You cannot do that... > > > > The bootloader never falls back to just the SoC name. > > There is no "SoC" part of compatible list. Only by convenience we put it > that way, but DT spec does not define first compatible to be for > platform because they all are[1], therefore following your earlier > description - bootloader should load BAR DTS on FOO device just because > qcom,sdm845 matches. As documented in "Documentation/arm/google/chromebook-boot-flow.rst", the bootloader creates a match list to pick a device tree file. It never creates a match list that has just the SoC. It always picks based on the board name and never falls back to just the SoC name. -Doug
