Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux