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... Best regards, Krzysztof
