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. -Doug
