How get to the temp with 4.17 kernel and Ubuntu 18.04?


Recommended Posts

Donate and support the project!

just for reference, I've based on 4.17.0.rc7 and this seems to work:

 

		ths: ths@1c25000 {
			#thermal-sensor-cells = <0>;
			compatible = "allwinner,sun8i-h3-ths";
			reg = <0x01c25000 0x400>,
			      <0x01c14234 0x4>;
			reg-names = "ths", "calibration";
			interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
			resets = <&ccu RST_BUS_THS>;
			reset-names = "ahb";
			clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
			clock-names = "ahb", "ths";
		};

 

Link to post
Share on other sites

wouldn't it make sense to check and/or rework this one: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/safe-need-more-inspection/23-sun4i-gpadc-iio-add-H3-thermal-sensor-DT.patch#L15-L22

 

which is basically what you do. The patch:

+	iio-hwmon {
+		compatible = "iio-hwmon";
+		io-channels = <&ths>;
+	};
+
+	soc {
+		ths: thermal-sensor@1c25000 {
+			compatible = "allwinner,sun8i-h3-ths";
+			reg = <0x01c25000 0x100>;
+			clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
+			clock-names = "bus", "mod";
+			resets = <&ccu RST_BUS_THS>;
+			#thermal-sensor-cells = <0>;
+			#io-channel-cells = <0>;
+		};
+	};
+

but despite having thermals working for your build, armbians dev branch would be a step closer in case we switch to >4.14 for next? ;) 

Link to post
Share on other sites

@raschid temp does work fine, but OTG doesn't work with the Armbian DTB. I'm working on getting the OTG port to work with the Armbian DTB since it does work with the FriendlyElec DTB, but breaks temp. NanoPi Duo v1.1 supports OTG (you power off VIN instead of the single USB port). This allows you to attach USB devices without the NanoPi shield.

Link to post
Share on other sites

The FriendlyElec dtb has:

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

Armbian dtb:

		usb@1c19000 {
			compatible = "allwinner,sun8i-h3-musb";
			reg = <0x1c19000 0x400>;
			clocks = <0x3 0x20>;
			resets = <0x3 0x11>;
			interrupts = <0x0 0x47 0x4>;
			interrupt-names = "mc";
			phys = <0x11 0x0>;
			phy-names = "usb";
			extcon = <0x11 0x0>;
			status = "okay";
			dr_mode = "peripheral";
			phandle = <0x3a>;
		};

 

Some of the addresses are different like phys, extcon and phandle and dr_mode is set to "otg" of course. I think when I was playing around with it I just tried the FriendlyElec section and it still doesn't work. There may be other sections of the device tree that need to be changed as well. It's a monster to diff.

sun8i-h2-plus-nanopi-duo.friendlyelec.dts

sun8i-h2-plus-nanopi-duo.dts

Link to post
Share on other sites
1 hour ago, sgjava said:

I just tried the FriendlyElec section and it still doesn't work.

See phandle section here: https://elinux.org/Device_Tree_Mysteries#Phandle

'mixing DT' will most likely end in a mess..  

If you  look into the devicetree documentation for the sun8i-h3-musb: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/allwinner%2Csun4i-a10-musb.txt

It looks like a change to:

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

'should' work. I've neither a otg device nor the board to test it and neither am I a DT expert to be sure it works... :P As soon as you patch a DT (and for sunxi, there are a bunch of DT patches) addresses can change fast (I compared once two decompiled dtb files for the tinker board, once from RKs Linaro once from Armbian even when the 'big picture' looked 'more or less' the same - diff would show ~80% difference ).

I think the reason armbian uses "peripheral" mode is due to g_serial: 

https://github.com/armbian/build/blob/ebd89c9b73a73bada602d7905a5072f5334e8428/config/boards/nanopiduo.conf#L6

https://github.com/armbian/build/commit/446295ee282c4ff064c78ef5ff31be963222c82c

so g_serial might not work anymore when you change to otg mode. 

Link to post
Share on other sites

That's basically just changing only the dr_mode to otg which was the first thing I did. I'll run the FriendlyElec dtb for now since I need the OTG more than temp. I have to force compile to generate a dtb:

sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /soc/pinctrl@1c20800/wifi_wake@0 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@240000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@480000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@648000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@816000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@912000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@960000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1008000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1104000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1200000000 has a unit name, but no reg property
sun8i-h2-plus-nanopi-duo.dtb: Warning (unit_address_vs_reg): Node /opp_table/opp@1296000000 has a unit name, but no reg property

 

Link to post
Share on other sites
Guest
This topic is now closed to further replies.