+U-Boot list again

Hi Jon,

On 30 May 2014 09:55, Jon Loeliger loeliger@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@101e6000 {
                    compatible = "arm,pl061", "arm,primecell";
                    reg = <0x101e6000 0x1000>;
                    interrupts = <8>;
                    gpio-controller;
                    #gpio-cells = <2>;
                    interrupt-controller;
                    #interrupt-cells = <2>;
            };

            gpio3: gpio@101e7000 {
                    compatible = "arm,pl061", "arm,primecell";
                    reg = <0x101e7000 0x1000>;
                    interrupts = <9>;
                    gpio-controller;
                    #gpio-cells = <2>;
                    interrupt-controller;
                    #interrupt-cells = <2>;
            };

            fpga {
                    uart@9000 {
                            compatible = "arm,pl011", "arm,primecell";
                            reg = <0x9000 0x1000>;
                            interrupt-parent = <&sic>;
                            interrupts = <6>;
                    };
                    sci@a000 {
                            compatible = "arm,primecell";
                            reg = <0xa000 0x1000>;
                            interrupt-parent = <&sic>;
                            interrupts = <5>;
                    };
                    mmc@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