Jump to content

[397] - maintain/fix DTS entries for some devices such I2C/SPI/W1


Recommended Posts

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


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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 ..."

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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>;
            };
        };
    };
};

 

Link to comment
Share on other sites

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.

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?

 

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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"; ?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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 ?

Link to comment
Share on other sites

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 ... :angry:

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

Link to comment
Share on other sites

@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?

Link to comment
Share on other sites

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";
	};
};
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines