Compiling DTS with DTC

[ALIGMSTEN]

Hi, hopefully some kind and more knowledgeable soul could provide some pointers, when trying to compile out of tree dts with dtsi includes on orangepizero2.

 

I realise the included files must be pre-processed before compiled and have tried numerous approaches all which failed miserably by not being able to move beyond the following error.

 

Error: dt-bindings/interrupt-controller/arm-gic.h:6.1-8 syntax error
FATAL ERROR: Unable to parse input tree

 

The relevant lines in arm-gic.h:

 

#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_ARM_GIC_H
#define _DT_BINDINGS_INTERRUPT_CONTROLLER_ARM_GIC_H

#include <dt-bindings/interrupt-controller/irq.h>

 

I’m unsure whether or not this is a cpp or dtc error.

 

The paths seem to be resolved:

 

alistair@orangepizero2:/boot/dtb-5.15.46-sunxi64/allwinner$ ls -l dt-bindings
lrwxrwxrwx 1 root root 58 Jun 18 21:49 dt-bindings -> /usr/src/linux-headers-5.15.43-sunxi64/include/dt-bindings
alistair@orangepizero2:/boot/dtb-5.15.46-sunxi64/allwinner$ ls -l dt-bindings/interrupt-controller/arm-gic.h
-rw-r--r-- 1 root root 536 Jun 17 15:55 dt-bindings/interrupt-controller/arm-gic.h
alistair@orangepizero2:/boot/dtb-5.15.46-sunxi64/allwinner$

 

Perhaps the error is obvious, here one of the failed instructions:

 

alistair@orangepizero2:/boot/dtb-5.15.46-sunxi64/allwinner$ sudo gcc -I /boot/dtb/allwinner/ -E -nostdinc -undef -D__DTS__ -x assembler-with-cpp -o sun-h616-orangepi-zero2-b.dts.tmp sun-h616-orangepi-zero2-b.dts
alistair@orangepizero2:/boot/dtb-5.15.46-sunxi64/allwinner$ 

alistair@orangepizero2:/boot/dtb-5.15.46-sunxi64/allwinner$ sudo dtc -I dts -O dtb -o sun-h616-orangepi-zero2-b.dtb sun-h616-orangepi-zero2-b.dts.tmp
Error: dt-bindings/interrupt-controller/arm-gic.h:6.1-8 syntax error
FATAL ERROR: Unable to parse input tree
alistair@orangepizero2:/boot/dtb-5.15.46-sunxi64/allwinner$

 

Any help would be gratefully appreciated.

 

Best,

Alistair

 

[ALIGMSTEN]

At this point have found it near impossible to compile anything complex with device trees or modules on the board.

 

Best way around, in my humble opinion, is to use the build system, with current kernel, and consider donating to the good armbian people for providing you with the those abilities, should you pursue that route.

 

All the modern kernel are semi functional but missing parts, dts etc which hopefully will find their way into 5.20 judging from comments.

 

Alternatively use the legacy version, there is enough information in all these threads how to resolve issues you may come across for your use case.

 

Best,

Alistair

 

 

[nullzed]

😭so you mean armbian in zero2 have no dts at all?

i thought i download a wrong image.

[ALIGMSTEN]

Its not armbian problem, development with soc is minimal with mainline kernel, have been piecing together 'my own' dts, dtsi files from various sources. While have been able to pre-process to dtb, have been unable to compile to bin to test by swapping out on the board. Just totally stuck, nonetheless still looking into possible reasons. 

[ALIGMSTEN]

 

Andre-ARM authored and jernejsk committed 26 days ago 

1 parent 7dd91a1 commit 5a378f9f2b15a2aa3b7485e46c3d300103ea384b

 

Missed this only updated branch today....... Added support for orangepizero2 mainline.

 

The reboot is applied.

 

 

[ALIGMSTEN]

Hello,

 

I've submitted a PR 'Update arm64-dts-Add-sun50i-h616-orangepi-zero2-device.patch #4051' for the reboot which @Igor has merged, bringing armbian in-line with 5.20-rc1.

 

Progress, nonetheless all is still not well. I've been noticing on the boards I've been using that booting remains problematic and I often have to power cycle before the boards start. The red light is default on for modern kernels and can be changed in user space etc. @gleam2003 has commented here in zero2 forums about the rsb/i2c difference. 

 

 

Quote

@gleam2003

Posted 14 hours ago

I find that rsb is used in place if i2c.

I have an old board and like old orengepi one plus and the new orangepi 3 lts they dosen't boot with rsb.

 

I modify the DTS for use i2c and the board boot.

 

I think that this rsb bus is buggy

 

I think that this is valuable commentary and something that I've been suspecting is problematic.

 

orange-pi from 5.16 sun50i-h616-orangepi-zero2.dts themselves differ here from mainline 5.20-rc1 and use the i2c bus instead of rsb.

 

&r_i2c {
	status = "okay";

	axp305: pmic@36 {
		compatible = "x-powers,axp305", "x-powers,axp805",
			     "x-powers,axp806";
		interrupt-controller;
		#interrupt-cells = <1>;
		reg = <0x36>;

		x-powers,self-working-mode;
		vina-supply = <&reg_vcc5v>;
		vinb-supply = <&reg_vcc5v>;
		vinc-supply = <&reg_vcc5v>;
		vind-supply = <&reg_vcc5v>;
		vine-supply = <&reg_vcc5v>;
		aldoin-supply = <&reg_vcc5v>;
		bldoin-supply = <&reg_vcc5v>;
		cldoin-supply = <&reg_vcc5v>;

 

and secondly have recently enabled blod2 to 1.8v

 

reg_bldo2: bldo2 {
				regulator-always-on;
				regulator-min-microvolt = <1800000>;
				regulator-max-microvolt = <1800000>;
				regulator-name = "vcc1v8";
			};

 

I would have to check the schematics of bldo2 to see functionality.

 

I don't have much time but it might be worth testing! 

Would like to hear @gleam2003 exact experience with this?

 

Best,

Alistair

[ALIGMSTEN]

To elaborate a little more on rsb/i2c - twi legacy

 

The de-compiled legacy dtb uses the two wire interface.

 

twi@0x07081400 {
                        #address-cells = <0x01>;
                        #size-cells = <0x00>;
                        compatible = "allwinner,sun50i-twi";
                        device_type = "twi5";
                        reg = <0x00 0x7081400 0x00 0x400>;
                        interrupts = <0x00 0x69 0x04>;
                        clocks = <0x4a>;
                        clock-frequency = <0x30d40>;
                        pinctrl-names = "default\0sleep";
                        pinctrl-0 = <0x4b>;
                        pinctrl-1 = <0x4c>;
                        status = "okay";
                        no_suspend = <0x01>;
                        linux,phandle = <0x126>;
                        phandle = <0x126>;

                        pmu {
                                compatible = "x-powers,axp1530";
                                reg = <0x36>;
                                wakeup-source;
                                linux,phandle = <0x127>;
                                phandle = <0x127>;

                                standby_param {
                                        vcc-dram = <0x04>;
                                        linux,phandle = <0x128>;
                                        phandle = <0x128>;
                                };

 

Also noted that mainline initially was i2c bus.

 

Subject: [PATCH v2 21/21] arm64: dts: allwinner: Add OrangePi Zero 2 .dts
Date: Fri, 11 Dec 2020 01:19:34 +0000

 

&r_i2c {
+	status = "okay";
+
+	axp305: pmic@36 {
+		compatible = "x-powers,axp305", "x-powers,axp805",
+			     "x-powers,axp806";
+		reg = <0x36>;

 

[ALIGMSTEN]

OK @gleam2003no need to clarify I see Orangepi One Plus Rollback to i2c #3964.

 

Its what had in mind I'll do some quick testing.

[ALIGMSTEN]

Some background for those interested before blindly making changes:

Also suggest reading the relevant datasheets.

 

 

sunxi_ Add support for AXP305 PMIC · fbd37d8d28 - u-boot.pdf[linux-sunxi] [PATCH v2 01_21] sunxi_ Add support for AXP305 PMIC.pdf