10 10
zador.blood.stained

testers wanted Testers wanted: sunxi Device Tree overlays

Recommended Posts

Hi all

Can you suggest some online resource for learning the dts overlay syntax?

I am ok with adding things, I have found something about deleting things, but what if I want to change something? Is it delete and add in the same fragment? One fragment to delete and the next one to add?

Thanks!

Share this post


Link to post
Share on other sites
On 07.12.2017 at 11:24 AM, Menion said:

Can you suggest some online resource for learning the dts overlay syntax?

I'm not sure what (besides the device-tree-compiler source code) should be used as a reference for the advanced functionality (/delete-property/, /delete-node/, etc.).

 

On 07.12.2017 at 11:24 AM, Menion said:

I am ok with adding things, I have found something about deleting things, but what if I want to change something? Is it delete and add in the same fragment? One fragment to delete and the next one to add?

I guess you can do everything in one fragment, overriding and deleting not needed properties to get the end result

Share this post


Link to post
Share on other sites

Thanks. Do you know if it is possible to perform a sort of "dry run" of the dtb+overlay combination in order to check the final results without having to load it on the real target?

Share this post


Link to post
Share on other sites

Hi all

Maybe someone can help

I want to change node: r-gpio-keys

but the syntax:

 

fragment@0 {
                target = <&r-gpio-keys>;

 

prompt a syntax error. The problem are the "-" in the node name. Something like target = <&leds> is accepted.

So how can select such node?

Share this post


Link to post
Share on other sites

Thanks @zador.blood.stained :)

Apparently the dtbo I have made works, I have tested them merging everything with fdtoverlay tool

One question: the overlay under /boot/overlay-user are loaded matching the name with overlay_prefix variable in /boot/armbianEnv.txt, or they are just all loaded?

 

Share this post


Link to post
Share on other sites
20 minutes ago, Menion said:

One question: the overlay under /boot/overlay-user are loaded matching the name with overlay_prefix variable in /boot/armbianEnv.txt, or they are just all loaded?

Overlays in /boot/overlay-user are matched by the full name, overlay_prefix applies only to packaged overlays in /boot/dtb/....

Share this post


Link to post
Share on other sites

So, I need to list somewhere which overlay uboot shall pick up in overlay-user or all of them are loaded?

Also, sorry, but I need another quick help.

I want to set musb to host mode only, so I did this:

 

Quote

/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun50i-h5";
        fragment@0 {

                target-path = "/usb@01c19000";
                __overlay__ {
                        /delete-property/ dr_mode;
                        dr_mode = "host";
                };
        };
};
 

 

In the original dtb, the node is:

 

Quote

                usb@01c19000 {
                        compatible = "allwinner,sun8i-h3-musb";
                        reg = <0x1c19000 0x400>;
                        clocks = <0x6 0x20>;
                        resets = <0x6 0x11>;
                        interrupts = <0x0 0x47 0x4>;
                        interrupt-names = "mc";
                        phys = <0x16 0x0>;
                        phy-names = "usb";
                        extcon = <0x16 0x0>;
                        status = "okay";
                        dr_mode = "otg";
                        linux,phandle = <0x44>;
                        phandle = <0x44>;
                };
 

 

The dts compile fine, but ftdoverlay return error -1 applying the fragment.... Do you know why?

Thanks!

 

Share this post


Link to post
Share on other sites
4 minutes ago, Menion said:

The dts compile fine, but ftdoverlay return error -1 applying the fragment.... Do you know why?

You don't need the "/delete-property/ dr_mode;" line, you should just overwrite dr_mode without deleting the old one (since there can't be 2 properties with the same name old value will be replaced by the new one).

 

7 minutes ago, Menion said:

So, I need to list somewhere which overlay uboot shall pick up in overlay-user or all of them are loaded?

They should be listed in "user_overlays" line in armbianEnv.txt. AFAIK u-boot can't iterate through files in a directory so they need to be listed explicitly.

Share this post


Link to post
Share on other sites

I have also tried to remove the "/delete-property/ dr_mode", same problem

It can be a problem with fdtoverlay, but what happens to the boot process if I put a failing overlay?

Share this post


Link to post
Share on other sites

You are right!

The soc node is very long!

Thanks!!!!

Anyhow, if it may be of any little interest, two overlay I think are usefull for orangepipc2: one set the red led to mmc activity, the other one set the power switch to issue an acpi shutdown event, so you can gracefully shutdown the board without having to log in the console

Bye

Share this post


Link to post
Share on other sites
3 minutes ago, Menion said:

Anyhow, if it may be of any little interest, two overlay I think are usefull for orangepipc2: one set the red led to mmc activity, the other one set the power switch to issue an acpi shutdown event, so you can gracefully shutdown the board without having to log in the console

Packaging them by default may be rather complicated due to variations in buttons/LED names and available triggers, but they can be added to examples.

Share this post


Link to post
Share on other sites

I see also that in the rootfs there is an utility named "armbian-add-overlay" that takes as parameter an overlay dts

Is something that automagically compile, put the dtbo in /boot/overlay-user and add the entry in armbianEnv.txt?

Share this post


Link to post
Share on other sites

Hi @zador.blood.stained

There is something strange with one of the overlay, the red led.

The overlay is:

 

Quote

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun50i-h5";

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

        __overlay__ {

            status {
                linux,default-trigger = "mmc0";
            };
        };
    };
};

 

According to the ftdoverlay output (including all the overlay I use) the parameter seems to be inserted:

 

Quote

    leds {
        compatible = "gpio-leds";

        pwr {
            label = "orangepi:green:pwr";
            gpios = <0x34 0x0 0xa 0x0>;
            default-state = "on";
        };

        status {
            linux,default-trigger = "mmc0";
            label = "orangepi:red:status";
            gpios = <0x15 0x0 0x14 0x0>;
        };
    };

 

parameter added, and nothing is changed compared to the original

But then if I go in /proc/device-tree/leds/status/ I see the attribute:

 

Quote

menion@orangepipc2:/proc/device-tree/leds/status$ ls
gpios  label  linux,default-trigger  name
menion@orangepipc2:/proc/device-tree/leds/status$ 

 

correct value also:

 

Quote

menion@orangepipc2:/proc/device-tree/leds/status$ cat linux,default-trigger 
mmc0menion@orangepipc2:/proc/device-tree/leds/status$ 

 

But the result now is that the green led is blinking!

When I added manually the parameter in the dts it worked. The only thing is that the parameter was added as last in sub-node status

Maybe you have some idea here

Bye

 

 

Share this post


Link to post
Share on other sites

Hello,

 

still not pleased with the accuracy of the builtin rtc of my banana pi, I added a ds3231 module similar to the one described at https://thepihut.com/blogs/raspberry-pi-tutorials/17209332-adding-a-real-time-clock-to-your-raspberry-pi to it. 

 

With that, I noticed two things:

 

- The example I started with at https://github.com/armbian/sunxi-DT-overlays/blob/master/examples/i2c-ds1307.dts contains a typo (a space too much between * and /) at line 11.

 

- It is not completely easy to have an external rtc chip being the default rtc for the board.

 

Anyway, here is the overlay I ended up with:

/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,su
n8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5";

        /* 
         * Aliases can be used to set the external RTC as rtc0
         * Needs supplying the correct path to the I2C controller RTC is connect
ed to,
         * this example is for I2C1 on A20
         */
        fragment@0 {
                target-path = "/aliases";
                __overlay__ {
                        rtc1 = "/soc@01c00000/rtc@01c20d00";
                };
        };
        fragment@1 {
                target-path = "/aliases";
                __overlay__ {
                        rtc0 = "/soc@01c00000/i2c@01c2b400/ds3231@68";
                };
        };

        fragment@2 {
                target = <&i2c2>;
                __overlay__ {
                        #address-cells = <1>;
                        #size-cells = <0>;
                        ds3231@68 {
                                compatible = "maxim,ds3231";
                                reg = <0x68>;
                                status = "okay";
                        };
                };
        };
};

 

Works fine through armbian-add-overlay and is currently in works-for-me state.

 

Added bonus: the chip has a temperature sensor:

# sensors
ds3231-i2c-1-68
Adapter: mv64xxx_i2c adapter
temp1:        +19.8°C  
 

 

Bye,

 

Joerg

 

P.s.: These rtc-board are available also from your Chinese hardware crap dealer of least distrust for less than 1 USD. 

Share this post


Link to post
Share on other sites

Hey,

 

I don't even manage to compile the DTS files.

For example: https://github.com/armbian/sunxi-DT-overlays/blob/master/examples/spi-ads7846.dts

 

$ dtc -I dts -O dtb -o foo.dtbo foo.dts
foo.dtbo: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property
foo.dtbo: Warning (unit_address_vs_reg): Node /fragment@1 has a unit name, but no reg property
foo.dtbo: Warning (gpios_property): Property 'pendown-gpio', cell 2 is not a phandle reference in /fragment@1/__overlay__/ads7846@0
foo.dtbo: Warning (gpios_property): Could not get phandle node for /fragment@1/__overlay__/ads7846@0:pendown-gpio(cell 2)
dtc: livetree.c:521: get_node_by_phandle: Assertion `(phandle != 0) && (phandle != -1)' failed.
Aborted

The warnings don't even seem to be the issue - suppressing (-q) them and forcing compilation even with errors (-f) still results in the assert. Any hint?

Share this post


Link to post
Share on other sites
2 minutes ago, zador.blood.stained said:

- device tree compiler (dtc) should be recent enough - either compile from here or use one from kernel headers

- you need to tell dtc that you are compiling an overlay (add -@ command line parameter)

The missing '-@' wasn't the issue, as I tried with and without. With the dtc from my linux-git clone it worked.

Didn't expect my Debian (testing) version of dtc being the issue here - thanks for pointing me there!

For reference, that's the version which caused me above stated trouble:

 

ii  device-tree-compiler                          1.4.5-3                              amd64        Device Tree Compiler for Flat Device Trees

Share this post


Link to post
Share on other sites

I'm experimenting with nand overlays and it seems to me that rootfs partition has wrong offset (in all overlays):

 

Quote

partition@1000000 {
                               label = "env";
                               reg = <0x0 0x1000000 0x0 0x400000>;
                       };
 

partition@1400000 {
                                                label = "rootfs";
                                                reg = <0x0 0xa00000 0x01 0xff000000>;
                                        };

I think that 0xa00000 should be 0x1400000 ? Am I correct, and should I prepare pull request to fix it?

Share this post


Link to post
Share on other sites

I've notice today, that fixup scripts are failing, if some parameters are passed. For example:

 

if test -n "${param_spinor_spi_bus}"; then
	test "${param_spinor_spi_bus}" = "0" && setenv tmp_spi_path "spi@01c05000"
	test "${param_spinor_spi_bus}" = "1" && setenv tmp_spi_path "spi@01c06000"
	test "${param_spinor_spi_bus}" = "2" && setenv tmp_spi_path "spi@01c17000"
	fdt set /soc@01c00000/${tmp_spi_path} status "okay"
	fdt set /soc@01c00000/${tmp_spi_path}/spiflash status "okay"
	if test -n "${param_spinor_max_freq}"; then
		fdt set /soc@01c00000/${tmp_spi_path}/spiflash spi-max-frequency "<${param_spinor_max_freq}>"
	fi
	if test "${param_spinor_spi_bus}" = "0" && test "${param_spinor_spi_cs}" = "1"; then
		fdt set /soc@01c00000/${tmp_spi_path}/spiflash reg "<1>"
	fi
	env delete tmp_spi_path
fi

I get:

libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

This is caused because u-boot sets paths without leading zero:

=> fdt list /
/ {
	#address-cells = <0x00000001>;
	#size-cells = <0x00000001>;
	interrupt-parent = <0x00000001>;
	model = "Olimex A20-SOM204-EVB-eMMC";
	compatible = "olimex,a20-olimex-som204-evb-emmc", "allwinner,sun7i-a20";
	...
	soc@1c00000 {
	};
	...
};
=> 

As you can see the path is /soc@1c00000 not /soc@01c00000.

 

Does anyone have noticed this?

Share this post


Link to post
Share on other sites
1 minute ago, selfbg said:

Does anyone have noticed this?

Our overlays should be working on kernel 4.14.x, as stated in the README.

Our sunxi-next branch currently points to the kernel 4.14 which still has leading 0s in node names: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts/sun7i-a20.dtsi?h=linux-4.14.y

 

-dev kernel branches (and sunxi-dev in this example) are usually not maintained well, and I definitely did not add overlays to it because they requires exactly this type of maintenance every couple of months.

Share this post


Link to post
Share on other sites

How is this related to kernel version?

 

The fixup script is executed inside u-boot? Both next and dev branches uses the same u-boot.

 

EDIT: Sorry. I've answer my self.

Share this post


Link to post
Share on other sites
1 minute ago, selfbg said:

How is this related to kernel version?

The fixup script code should match the contents of DT files.

 

2 minutes ago, selfbg said:

 

The fixup script is executed inside u-boot?

It is executed by the u-boot from the filesystem, and it is packaged with Device Trees and overlays in the kernel DT package.

Share this post


Link to post
Share on other sites

Hi,

 

I have the Banana Pi M1 and the Banana Pro and just received a I2S to Analogue Module.

I'd love to use these together but unfortunately there is no device tree overlay available.

 

The module is from Adafruit (https://learn.adafruit.com/adafruit-i2s-stereo-decoder-uda1334a) they also mention it is the same chip / driver that is also used by the Hifiberry DAC,

there is support for Raspbian also with an overlay etc.  (see the Raspberry PI kernel tree | https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/hifiberry-dac-overlay.dts).

 

I tried adapting the overlay for usage with the Banana but didn't get it running.

So any help would be greatly appreciated, I will then of course test and report.  Also have a uart to usb cable to access uboot and can build images.

 

This is what I have so far:

/dts-v1/;
/plugin/;

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

    fragment@0 {
		target-path = "/";
		__overlay__ {
			pcm5102a-codec {
				#sound-dai-cells = <0>;
				compatible = "ti,pcm5102a";
				status = "okay";
			};
		};
	};

    fragment@1 {
		target = "/soc@01c00000";
		__overlay__ {
            sound: sound {
    			compatible = "hifiberry,hifiberry-dac";
    			i2s-controller = <&i2s0>;
    			status = "okay";
    		};
		};
	};
};

 

Of course using above overlay and enabled I2S0 Port already with Armbian-Config / armbianEnv.txt and the provided overlay.

 

Naturally there is a driver / codec required to get the Sound Module working, but I think we could use the driver from the Raspbian Kernel Source:

https://github.com/raspberrypi/linux/blob/rpi-4.14.y/sound/soc/codecs/pcm5102a.c

Doesn't seem to rely on anything raspberry specific. 

 

I would integrate, test and the do a PR on github, with this stuff, but need some help getting the overlay working first.

 

Greetings,

Count-Doku

 

 

 

 

Share this post


Link to post
Share on other sites
3 hours ago, count-doku said:

Of course using above overlay and enabled I2S0 Port already

Are you sure ? Did you verified in /proc/device-tree/ using "cat /proc/device-tree/soc@1c00000/i2s@1c22000/status" ?

(because I2C != I2S ...)

From the RPi link you provided you didn't kept those lines here : https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/hifiberry-dac-overlay.dts#L8-L13

Also, in Armbian Mainline config, at least for my Olimex-A20-Micro, I don't find the SND_SOC_PCM5102A enabled to build the driver, you will probably have to end-up building your own image.

 

 

Share this post


Link to post
Share on other sites

Yes I am sure that the I2S0 port is enabled, Armbian provides a overlay for that (https://github.com/armbian/build/blob/18215550b367919c1b270185e110b901e2843edd/patch/kernel/sunxi-next/add-sunxi-overlays.patch#L2246-L2276)
Which I enabled via Armbian-Config / armbianEnv.txt... Also checked that the device is there using /proc/device-tree/

That is also the reason why I didn't keep the I2S -> Okay Lines from the Raspberry PI overlay.

 

That the driver is normally not included is correct, I will add it and then build my own image. But first I would love to get the device tree overlay working.

 

I will conduct some more testing this afternoon or tomorrow and update this reply with my results.

 

EDIT:

So I've got the nodes integrated in the device tree, but not using overlays but decompiling and recompiling it online with dtc. 
I added the following nodes, maybe someone can create a overlay from that? 

// under soc
		sound:sound {
			compatible="hifiberry,hifiberry-dac";
			i2s-controller=<0x99>;  // this is taken from above i2s controller, in the overlay there should be a label I guess
			status="okay";
		};
              
// in the root
	pcm5102a-codec {
		#sound-dai-cells = <0>;
		compatible = "ti,pcm5102a";
		status="okay";
	};              

Testing in /proc revealed the changes had been loaded correctly.

 

Then I tried compiling my own kernel with the PCM5102A driver but the option is not displayed in the kernel configuration.

Any ideas?

 

 

Greetings,

count-doku

 

 

Share this post


Link to post
Share on other sites

Kernel version 4.19.13-sunxi does not accept param_w1_pin=
while 4.14.70-sunxi is working.

 

After every change I rebooted system and checked value for change with command below:

"cat /sys/kernel/debug/gpio"

 

Testing setup:

BananaPi M1 Plus, sensors DS18B20, debian stretch.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
10 10