martinayotte - Canada - maintain/fix DTS entries for some devices such I2C/SPI/W1 - ASAP

Task from thread http://forum.armbian.com/index.php/topic/1325-claim-a-task-set-due-date-and-start-doing-it/?p=11253

 

@martinayotte I know you already have a lot of dialog for this task on the forum and Github.  If you can consolidate to here that would be fantastic.  If it's too much work I understand.  Please at least provide a status here as you progress.

 

If possible please reference merge requests to this GitHub Issue

I posted 2 days ago some progress on Dynamic Device Tree Overlays, but I think I should report here too.

 

http://forum.armbian.com/index.php/topic/1633-dynamic-device-tree-overlays/#entry12696

 

 

I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.

 

During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.

I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".

 

So, I will probably prepare a patch soon and submit it thru a PR.

PR is now sent : https://github.com/igorpecovnik/lib/pull/421

 

I've faced some issues because of switch from 4.6.2 to 4.6.4 as well as u-boot from v2016-05 to v2106-07, but I get thru those ...

Today, I've also added the SPI pins and SoC, tested quickly with a loopback wire and famous spidev_test.c.

Unfortunately, I don't see much comments about my recent works ...

 

I wish to get some feedback if some of you tried it out, although, of course, most of you don't have yet my sample overlays, such i2c-enable.dtbo/spi-enable.dtbo/w1-enable.dtbo.

 

This bring me again the question : where should those samples should be located in standard images ?

(On beaglebone, they provide some in /lib/firmware)

@martinayotte you're definitely due some recognition. nice work on some hairy stuff that i barely understand. in the context of device tree what is an overlay? a patch to extend an existing dts definition?

 

Tapatalk thinks its important to tell you im using tapatalk from a phone.

@lanefu, DT overlays are small pieces of DT definitions that can be loaded in the kernel DT at any time from user-space and kernel will notify drivers accordingly.

So, with my current samples, I could, for example, make the I2C buses appearing and disappearing from the following shell command :

mkdir /sys/kernel/config/device-tree/overlays/mydtbo
cat i2c-enable.dtbo > /sys/kernel/config/device-tree/overlays/mydtbo/dtbo
echo "overlay loaded ..."
echo "doing here more stuff ..."
rmdir /sys/kernel/config/device-tree/overlays/mydtbo
echo "overlay unloaded ..."

That's pretty cool.....  Can it be used to initialize things that u-boot's DTS does not?

Such as ?

.....like a NIC or something?

 

Tapatalk thinks its important to tell you im using tapatalk from a phone.

I'm not sure to following you ...

Do you means a NIC that wasn't defined in the top level DTB ?

This scenario are pretty rare, but you it should be doable if top level expose everything needed.

But I don't see the advantages, especially if this NIC needs to be present all the time.

Overlays are best suit for things that require to be loaded/unloaded dynamically.

Currently, I have I2C, SPI and W1 sample overlays.

yeah my thinking wasn't making sense....  However your thinking does and I think I get it now.  thank you

For those who are interested, here are some DT Overlay samples.

 

i2c-enable.dts :

 

 

// Enable the i2c interface
/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
    target-path = "/aliases";
    __overlay__ {
            /* Path to the i2c2 controller node */
            i2c0 = "/soc@01c00000/i2c@01c2ac00";
            i2c1 = "/soc@01c00000/i2c@01c2b000";
            i2c2 = "/soc@01c00000/i2c@01c2b400";
        };
    };
    fragment@1 {
        target = <&i2c0>;
        __overlay__ {
            status = "okay";
        };
    };
    fragment@2 {
        target = <&i2c1>;
        __overlay__ {
            clock-frequency = <400000>;
//            clock-frequency = <100000>;
            status = "okay";
        };
    };
    fragment@3 {
        target = <&i2c2>;
        __overlay__ {
            status = "okay";
        };
    };
};

 

 

spidev-enable.dts :

 

 

// Enable the spidev interface
/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun8i-h3";

    fragment@0 {
    target-path = "/aliases";
    __overlay__ {
            /* Path to the SPI controller nodes */
            spi0 = "/soc@01c00000/spi@01c68000";
            spi1 = "/soc@01c00000/spi@01c69000";
        };
    };
    fragment@1 {
        target = <&spi0>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&spi0_pins_a>, <&spi0_cs0_pins_a>;
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;
            spidev@0 {
                compatible = "spidev";
                reg = <0x0>;
                spi-max-frequency = <1000000>;
            };
        };
    };
    fragment@2 {
        target = <&spi1>;

        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&spi1_pins_a>,
                    <&spi1_cs0_pins_a>;
            status = "okay";
            #address-cells = <1>;
            #size-cells = <0>;

            spidev@1{
                compatible = "spidev";
                reg = <0>;
                spi-max-frequency = <1000000>;
            };
        };
    };
};

 

<sup>Hey guys, I am having some trouble with Device Tree Overlays and in need of some guidance.

In a current project I want to connect an ilitek ili9341 2.2" screen to an Olimex Lime 2 and/or NanoPi NEO computer.</sup>

^{My current setup is a Olimex Lime 2 eMMC board running Linux lime2 4.7.3-sunxi and jesse.}

^{I have found a .dts file and modified it to match my need on an Olimex Lime 2}

/*
 * Device Tree overlay for 2.2" SPI TFT from Elecfreaks
 *
 */

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun7i-a20";

    fragment@0 {
        target = <&spi0>;
        __overlay__ {
            status = "okay";

            spidev@0{
                status = "disabled";
            };

            spidev@1{
                status = "disabled";
            };
        };
    };

    fragment@1 {
        target = <&gpio>;
        __overlay__ {
            rpi_display_pins: rpi_display_pins {
                allwinner,pins = <66 129 128>;
                allwinner,function = <1 1 1>; /* out out out in */
            };
        };
    };

    fragment@2 {
        target = <&spi0>;
        __overlay__ {
            /* needed to avoid dtc warning */
            #address-cells = <1>;
            #size-cells = <0>;

            rpidisplay: rpi-display@0{
                compatible = "ilitek,ili9341";
                reg = <0>;
                pinctrl-names = "default";
                pinctrl-0 = <&rpi_display_pins>;

                spi-max-frequency = <32000000>;
                rotate = <0>;
                bgr;
                fps = <30>;
                buswidth = <8>;
                reset-gpios = <&gpio 129 0>;
                dc-gpios = <&gpio 128 0>;
                led-gpios = <&gpio 66 1>;
                debug = <0>;
            };
        };
    };
    __overrides__ {
        speed =   <&rpidisplay>,"spi-max-frequency:0";
        rotate =  <&rpidisplay>,"rotate:0";
        fps =     <&rpidisplay>,"fps:0";
        debug =   <&rpidisplay>,"debug:0";
    };
};

Furthemore I have compiled it using dts (a newer version than the one built in to the Armbian mainline kernel image I am using) to a .dtb file and cat-ed it into a folder similar to `/sys/kernel/config/device-tree/overlays/mydtbo/dtbo`. Afterwards dmesg gives me the following errors:

[  395.429019] __of_adjust_tree_phandle_references: Illegal property (size) 'fixup' @/__local_fixups__
[  395.429058] of_resolve_phandles: __of_adjust_tree_phandle_references failed !
[  395.429071] create_overlay: Failed to resolve tree

Am I forgetting to do something or is my modified .dts file simply wrong?

 

Also which version of the dtc compiler are you using to compile the i2s_enable.dts and spi.. source code?

I trying but have error:

 

# dtc -I dts -O dtb i2c-enable.dts

Error: i2c-enable.dts:2.2-8 syntax error

FATAL ERROR: Unable to parse input tree

root@nanopineo:/boot/dtb# 

 

# dtc -v

Version: DTC 1.4.0

 

 

 

Linux nanopineo 4.9.0-sun8i #4 SMP Mon Oct 31 04:12:20 CST 2016 armv7l armv7l armv7l GNU/Linux

Trying from toolchain. deleted /plugin/; line and close tags but still have error. Sorry for bothering.. I novice in dtc 

Which what I should start? I need switch on i2c/SPI/UART

 

# dtc -f -I dts -O dtb -o i2c-enable.dtb i2c-enable.dts

ERROR (phandle_references): Reference to non-existent node or label "i2c0"

 

ERROR (phandle_references): Reference to non-existent node or label "i2c1"

 

ERROR (phandle_references): Reference to non-existent node or label "i2c2"

 

Warning: Input tree has errors, output forced

 

---------------------------------------------------------------------------

 

 

Found section in sun8i-h3-nanopi-neo :

 

                i2c@01c2ac00 {

                        compatible = "allwinner,sun6i-a31-i2c";

                        reg = <0x1c2ac00 0x400>;

                        interrupts = <0x0 0x6 0x4>;

                        clocks = <0x5 0x3b>;

                        resets = <0x5 0x2e>;

                        pinctrl-names = "default";

                        pinctrl-0 = <0xd>;

                        status = "okay";

                        #address-cells = <0x1>;

                        #size-cells = <0x0>;

                        linux,phandle = <0x31>;

                        phandle = <0x31>;

                };

 

Is it enough set status = "okay"; ?

Yes, if you do the change directly into the main DTS, only "okay" should be required.

 

For overlay, your issue is probably that you didn't use "-@" option of DTC, the command line should be :

 

dtc -@ -I dts -O dtb -o i2c-enable.dtb i2c-enable.dts

Yes, if you do the change directly into the main DTS, only "okay" should be required.

 

For overlay, your issue is probably that you didn't use "-@" option of DTC, the command line should be :

 

dtc -@ -I dts -O dtb -o i2c-enable.dtb i2c-enable.dts

Many thanks!

 

I try it on $ dtc --version

Version: DTC 1.4.0

 

Have some error

 

$ dtc -@ -I dts -O dtb -o i2c-enable.dtb i2c-enable.dts

dtc: invalid option -- '@'

Usage: dtc [options] <input file>

 

 

In my case change directly into the main DTS status to 'okay' is enough. Although, overlay approach look very interesting in any case.

 

 Thanks!

 

dtc: invalid option -- '@'

This means that you have the stock version of DTC which is unaware of overlays, not the one which understand overlays.

You can get the good one, version DTC 1.4.1-g47216cdb, from :

 https://github.com/pantoniou/dtc.git

and choose the proper branch :

dt-overlays5

I've sent the following email to Pantelis Antoniou :

 

 

Hi Pantelis Antoniou,

First, Thanks for all your good works about Dynamic DT Overlays !

In past months, I've integrated your works into Armbian. I'm loving this !
I hope I didn't missed any things during this task ...

My first question is : seeing that your patches were not been  merged
into Mainline, do you have plans to re-submit them in a way that they
will finally been merged ?

My second question is : while doing some tests with an overlay with
clock define for sc16is7xx driver, I've faced that devm_clk_get()
failed to find the new clock.

Looking at https://www.raspberrypi.org/documentation/configuration/device-tree.md,
I've found this quote :

"Adding clocks under the /clocks node at run-time doesn't cause a new
clock provider to be registered, so devm_clk_get will fail for a clock
created in an overlay."

Is there some patches available to fix such issues ?

My third question : I think there is similar issue with creating new
aliases using overlays, although I didn't debug/investigate much
further. Is there any fix for that either ?

Regards,
Martin Ayotte.

 

This is because I feel that new development needs to occur to fill some current gaps :

 

- new clocks not registered dynamically properly.

- new alias not registered dynamically properly.

 

My current use-case is adding new UARTs using sc16is7xx, I got it working, but only by defining new clocks in the main DTB, it wasn't working if defined into the DT Overlay.

@martinayotte

 

Please update the configfs patch for the sunxi-dev kernel.

@zador.blood.stained

 

Due to switch to 4.10 ? Ok ! I will take a look ...

 

EDIT : Oh ! I'm seeing some error in build process :

[ o.k. ] Checking git sources [ u-boot v2016.11 ]
error: Unknown subcommand: get-url
...
[ o.k. ] Checking git sources [ linux-sun8i-mainline orange-pi-4.9 ]
error: Unknown subcommand: get-url
...
[ o.k. ] Checking git sources [ sunxi-tools master ]
error: Unknown subcommand: get-url

EDIT2 : Ok ! this was on my other workstation where git was older. No worries ...

 

EDIT3 : Zador ? I've started new build sunxi-dev/pine64 and don't see errors : ... [[[32ml[[0m][[[32mc[[0m] add_configfs_overlay_for_v4.7.x.patch [[[0;33m succeeded [[0m]

On which target did you faced issues ?

About email sent to Pantelis Antoniou , unfortunately, I've never got answer ...

I've re-send him email 2 days ago, but I doubt this guys will ever reply ...

I guest I will have to try getting answers from his co-Signed-Off, at least to know what is the state of those patches ...

@martinayotte

Recently, I upgraded Armbian on my Orange Pi Plus to the nightly dev build. I quickly found out that the 1-wire gpio doesn't work. The http://linux-sunxi.org/1-Wire gave me some hints where to look for. I decompiled the DTB to check if the device definition is there. It was not, so I added the pieces from the manual (adjusting them a bit - changing port, replacing constants with raw values) and recompiled back to /boot/dtb/sun8i-h3-orangepi-plus.dtb. It works great.

 

I fought, I could contribute to Armbian by preparing patch, so I've modified arch/arm/boot/dts/sun8i-h3.dtsi and made a diff. Looking for the place to post it I found this topic and I started to wonder if the DDT Overlays wouldn't be a better way to start 1-wire. It's not a functionality that everyone needs and enabling it on demand would be a better approach.

 

What do you suggest? How to implement it with Overlays? Does Armbian building tools have functionality to build dtbo's?

I've already done a DT overlay several months ago, so here it is :

// Definitions for w1-gpio module (without external pullup)
/dts-v1/;
/plugin/;

/ {
	compatible = "allwinner,sun8i-h3";

	fragment@0 {
		target-path = "/";
		__overlay__ {

			w1: onewire@0 {
				compatible = "w1-gpio";
				pinctrl-names = "default";
				pinctrl-0 = <&w1_pins>;
				gpios = <&pio 3 14 0>; // PD14 
				status = "okay";
			};
		};
	};

	fragment@1 {
		target = <&pio>;
		__overlay__ {
			w1_pins: w1_pins {
				allwinner,pins = "PD14";
				allwinner,function = "gpio_in"; // in (initially)
				allwinner,pull = <0>; // off
			};
		};
	};

	__overrides__ {
		gpiopin =       <&w1>,"gpios:4",
				<&w1_pins>,"allwinner,pins:0";
	};
};

I've just found the following update on this subject: http://www.spinics.net/lists/devicetree/msg169771.html

 

It's already merged into mainline, but with something still missing. 

10 hours ago, ZupoLlask said:

I've just found the following update on this subject: http://www.spinics.net/lists/devicetree/msg169771.html

 

From Armbian perspective this is the main update on this subject: 

 

10 hours ago, ZupoLlask said:

It's already merged into mainline, but with something still missing. 

We are using some patches on top of mainline. Currently DT overlays are supported for H3 mainline (sun8i-dev) and A10, A20 mainline (sunxi-next) targets, but this has not reached the stable images yet.

I have tried to get a grip on device trees.......it is so chucking complicated.

 

I wish we had a standardized BIOS for all ARM Hardware. ! ? ...