Jump to content

Recommended Posts

Posted

I just got a working version of the mcp251x.dts overlay running an the Allwinner H3, and ran into a few issues along the way.

I'd like to save someone the pain and maybe find the right place for a bug report for the old version of dtc in the image.

 

Compiling the overlay with armbian-add-overlay fails on the target system because the following throws:

dtc -@ -I dts -O dtb -o mcp251x.dtbo mcp251x.dts 
...
dtc: livetree.c:521: get_node_by_phandle: Assertion `(phandle != 0) && (phandle != -1)' failed.
aborted

 

The best reference I can find for this symptom is:

https://patchwork.kernel.org/patch/10015389/

Following them, commenting out the line for "interrupt-parent" allows compilation to finish, but the resulting interrupt request ends up on the wrong interrupt-controller. (gic instead of pio)

 

This is a bug in dtc running overlay mode, and it was patched years ago:

https://www.spinics.net/lists/devicetree/msg199958.html

 

My Armbian compiler build cache does not have this bug.

From the local git repo log: dtc and livetree.c in both mainline and u-boot are very much alive, maintained, and up-to-date.

 

This works:

./armbian/build/cache/sources/linux-mainline/orange-pi-5.4/scripts/dtc/dtc -@ -I dts -O dtb -o mcp251x.dtbo mcp251x.dts

and emits a mcp251x.dtbo that behaves nicely, and lets me send and receive packets.

 

Props to the Armbian team for an amazing toolchain, build from scratch and making a custom overlay was almost easy.

 

Where does the dtc in the image come from, and where should I send a bug report?

 

---

For completeness,

I still can't find documentation for the pin/port numbering for 3-cell interrupt fields in the H3 flavour of .dts.

The third field is the interrupt mode with the definitions in "include/dt-bindings/interrupt-controller/irq.h"

The second field is the pin number on a given port (0-31 inclusive)

The first number is where I got stuck for a bit, I'm pretty sure it's the port number A=0, G=6.

Not all ports have interrupts, The H3 has them on A,G, and L.
The built-in dts in the nanopiduo2 has a wake on lan on PG10 with "interrupts = <6 10 8>"

 

The whole mcp251x.dts went:

/dts-v1/;
/plugin/;

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

	fragment@0 {
		target-path = "/clocks";
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <1>;
			can0_osc_fixed: can0_osc_fixed {
				compatible = "fixed-clock";
				#clock-cells = <0>;
				clock-frequency  = <8000000>;
			};
		};
	};

	fragment@1 {
		target = <&pio>;
		__overlay__ {
			can0_pin_irq: can0_pin_irq {
				pins = "PG11";
				function = "irq";
				bias-pull-up;
			};
		};
	};

	fragment@2 {
		target = <&spi1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			mcp2515 {
				reg = <0>;
				compatible = "microchip,mcp2515";
				pinctrl-names = "default";
				pinctrl-0 = <&can0_pin_irq>;
				spi-max-frequency = <10000000>;
				interrupt-parent = <&pio>;
				interrupts = <6 11 2>; 
				clocks = <&can0_osc_fixed>;
				status = "okay";
			};
		};
	};
};

 

 

 

 

Posted

More traps for new players,

DTC as available in the Ubuntu 18.04 repo also has the get_node_by_phandle assert bug.

 

I've run into the mcp251x interrupt race issue at high bus loads.

The only references to the problem are very old indeed, and the modules I'm running seem to feature all of the changes mentioned.

https://github.com/raspberrypi/linux/issues/2263

https://www.raspberrypi.org/forums/viewtopic.php?t=7027&start=150#p233122

https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=19489

 

I'm very much stuck on this one.

For the time being, I'm throwing a canable in native socketcan mode into the application

https://canable.io/

 

If anyone has any suggestions for patches, I'd love to try them.

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

Important Information

Terms of Use - Privacy Policy - Guidelines