[U-Boot] [RFC PATCH 17/22] dm: Expand and improve the device lifecycle docs

[Simon Glass]

+U-Boot list again

Hi Jon,

On 30 May 2014 09:55, Jon Loeliger <loeliger at gmail.com> wrote:
>> > Why is the scan only on the "top level"?  My GPIO nodes are, for example,
>> > under an SOC node.
>>
>> Why? Do you have an SOC driver?
>
> Hi Simon,
>
> This gets to my earlier issue:  I want to use the *exact* same DTS file
> for both U-Boot and Linux.  We definitely shouldn't have to copy them
> into both the Kernel and U-Boot source repositories, and we shouldn't
> have to have two in-memory (or flash) DTB blobs either.

Here's something I wrote while fiddling with Beaglebone which may help.

First a note that may to help avoid confusion. U-Boot and Linux both
use device tree. They may use the same device tree source, but it is
seldom useful for them to use the exact same binary from the same
place. More typically, U-Boot has its device tree packaged wtih it,
and the kernel's device tree is packaged with the kernel. In
particular this is important with verified boot, since U-Boot's device
tree must be immutable. If it can be changed then the public keys can
be changed and verified boot is useless. An attacker can simply
generate a new key and put his public key into U-Boot so that
everything verifies. On the other hand the kernel's device tree
typically changes when the kernel changes, so it is useful to package
an updated device tree with the kernel binary. U-Boot supports the
latter with its flexible FIT format (Flat Image Tree).


Re the two source repositories, you can set up any sort of repo that
you like for your .dts files, but they are in the U-Boot and kernel
repos at present.


>
> And yes, all the GPIO nodes are under an SoC bus node.
>
> For example, here is the versatile express DTS from the kernel repository
> with the same device (pl061) I am needing:
>
> $ less versatile-pb.dts
> #include <versatile-ab.dts>
>
> / {
>         model = "ARM Versatile PB";
>         compatible = "arm,versatile-pb";
>
>         amba {
>                 gpio2: gpio at 101e6000 {
>                         compatible = "arm,pl061", "arm,primecell";
>                         reg = <0x101e6000 0x1000>;
>                         interrupts = <8>;
>                         gpio-controller;
>                         #gpio-cells = <2>;
>                         interrupt-controller;
>                         #interrupt-cells = <2>;
>                 };
>
>                 gpio3: gpio at 101e7000 {
>                         compatible = "arm,pl061", "arm,primecell";
>                         reg = <0x101e7000 0x1000>;
>                         interrupts = <9>;
>                         gpio-controller;
>                         #gpio-cells = <2>;
>                         interrupt-controller;
>                         #interrupt-cells = <2>;
>                 };
>
>                 fpga {
>                         uart at 9000 {
>                                 compatible = "arm,pl011", "arm,primecell";
>                                 reg = <0x9000 0x1000>;
>                                 interrupt-parent = <&sic>;
>                                 interrupts = <6>;
>                         };
>                         sci at a000 {
>                                 compatible = "arm,primecell";
>                                 reg = <0xa000 0x1000>;
>                                 interrupt-parent = <&sic>;
>                                 interrupts = <5>;
>                         };
>                         mmc at b000 {
>                                 compatible = "arm,primecell";
>                                 reg = <0xb000 0x1000>;
>                                 interrupts-extended = <&vic 23 &sic 2>;
>                         };
>                 };
>         };
> };
>
> #include <testcases.dtsi>
>
> So yes,  I think we need more iterative structure in the DTS parsing for U-Boot.

Here I expect you would have a driver for the amba bus, and then that
driver would do the scan. The devices should have the amba bus as
their parent.

One reason for this is that the bus may have its own access mechanism
which needs to be provided to devices in that bus (e.g. I2C, SPI, PCI,
SCSI, etc.)

I'm not saying we don't want to scan the tree more deeply, but until
we have a use case for it we should hold off.

Regards,
Simon