@lex

Yes, I guess this is a confirmation SPI is not working yet. I used the -v to see some output (the spidev_test did not return anything). I had some hope that TX would be the data sent and RX would be the receiving data which is the same.

@jernej FYI, i just did a simple test on /dev/spidev.0.0 with a loop, not sure what should be the result, but here it is: ./spidev_test -v -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................| RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................|

That seems to be the case here. Unfortunately, I have to wait for this support. Thanks anyway.

Sure, but sorry, no progress yet to test your code, I got stuck with the error below and i could not figure out where the mistake is. The message is obvious, but the same setup works with others sbc with 4.18, 4.19 and 4.20. [ 3.455164] sun50i-h6-pinctrl 300b000.pinctrl: pin PC5 already requested by 5010000.spi; cannot claim for 300b000.pinctrl:69 [ 3.444948] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 3.454515] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 3.454940] fbtft_of_value: buswidth = 8 [ 3.454947] fbtft_of_value: debug = 0 [ 3.454950] fbtft_of_value: rotate = 90 [ 3.454953] fbtft_of_value: fps = 60 [ 3.454955] fbtft_of_value: txbuflen = 16384 [ 3.476347] fb_ili9341 spi0.0: gpio_request_one('cs-gpios'=69) failed with -22 [ 3.483740] fb_ili9341: probe of spi0.0 failed with error -22 [ 4.091824] sun4i-drm display-engine: fb0: DRM emulated frame buffer device dma: dma-controller@3002000 { compatible = "allwinner,sun50i-h6-dma"; reg = <0x03002000 0x1000>; interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_DMA>, <&ccu CLK_MBUS_DMA>; clock-names = "bus", "mbus"; dma-channels = <16>; dma-requests = <46>; resets = <&ccu RST_BUS_DMA>; #dma-cells = <1>; }; pio: pinctrl@300b000 { . . spi0_pins: spi0 { pins = "PC0", "PC2", "PC3", "PC5"; function = "spi0"; }; }; spi0: spi@5010000 { compatible = "allwinner,sun8i-h3-spi"; reg = <0x05010000 0x1000>; interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>; clock-names = "ahb", "mod"; dmas = <&dma 23>, <&dma 23>; dma-names = "rx", "tx"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; resets = <&ccu RST_BUS_SPI0>; status = "disabled"; num-cs = <1>; #address-cells = <1>; #size-cells = <0>; }; &pio { spi0_cs_pins: spi0_cs_pins { pins = "PC5", "PH3"; function = "gpio_out"; }; }; &spi0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-0 = <&spi0_pins &spi0_cs_pins>; cs-gpios = <&pio 2 5 GPIO_ACTIVE_HIGH>, <&pio 7 3 GPIO_ACTIVE_HIGH>; num-cs = <2>; pitft: pitft@0{ compatible = "ilitek,ili9341"; reg = <0>; status = "okay"; spi-max-frequency = <50000000>; rotate = <90>; fps = <60>; bgr = <1>; buswidth = <8>; txbuflen = <16384>; dc-gpios = <&pio 2 9 GPIO_ACTIVE_HIGH>; /* PC9 */ reset-gpios = <&pio 2 8 GPIO_ACTIVE_HIGH>; /* PC8 */ led-gpios = <&pio 2 7 GPIO_ACTIVE_LOW>; /* PC7 */ cs-gpios = <&pio 2 5 GPIO_ACTIVE_HIGH>; /* PC5 */ <== kernel complain debug = <0x0>; }; };

Okay, I promise i will try to learn that. Anyway, Your dma code seems to work for the SPI0 although the device is not connected yet and need some tests. [ 3.983705] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 3.990224] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 3.990921] fbtft_of_value: buswidth = 8 [ 3.990929] fbtft_of_value: debug = 0 [ 3.990932] fbtft_of_value: rotate = 90 [ 3.990934] fbtft_of_value: fps = 60 [ 3.990936] fbtft_of_value: txbuflen = 16384 [ 4.273841] graphics fb0: fb_ili9341 frame buffer, 320x240, 150 KiB video memory, 16 KiB buffer memory, fps=62, spi0.0 at 50 MHz [ 4.276796] sun4i-drm display-engine: fb1: DRM emulated frame buffer device

Err... Just don't know how to do that... In a proper way I mean.

The opi3-h6.dts i pointed to already have all the nodes. HDMI works like a charm. Those who will try need to compile the kernel with Wifi and BT enabled. I synced the regulators with H64 but that does not fix the reboot issue. I just noticed the power ON/OFF button works, maybe the H64 does not have this button? Do you have any suggestion about i2c? I will use your dma code and see if i get SPI0 to work.

Nice. BTW Do you have mali working on your kernel?

These are the changes from H64 and OpiOne+ @@ -161,6 +155,7 @@ regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-name = "vcc-ac200"; + regulator-enable-ramp-delay = <100000>; }; reg_aldo3: aldo3 { @@ -219,7 +214,7 @@ reg_dcdca: dcdca { regulator-always-on; regulator-min-microvolt = <810000>; - regulator-max-microvolt = <1160000>; + regulator-max-microvolt = <1080000>; regulator-name = "vdd-cpu"; };

Forgot to print the dma used: dma: dma-controller@3002000 { compatible = "allwinner,sun50i-a64-dma"; reg = <0x03002000 0x1000>; interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_DMA>; dma-channels = <8>; dma-requests = <27>; resets = <&ccu RST_BUS_DMA>; #dma-cells = <1>; };

Possible, do you mean u-boot? I am using old u-boot with old values, will re-check and see if it changes something. Thanks for the tip.

The printed info above (i2cdetect -y 0/1) is from the stock kernel, as soon as i added the i2c entries i2c gets lazy and do not detect the device i attach on PH6 and PH5 (Orange Pi One Plus). I added: &i2c0_pins { bias-pull-up; }; just in case. No success. SPI seems to be in the right direction, i tried to drive ili9341 display but kernel complains PC5 is already in use, so i gave up for now.

I have watched this thread and decided to check the status of the mainline kernel 5.0 for the H6 with the @Icenowy 's work on top of it. I can say it works really nice (tested on Orange Pi 3 H6): * HDMI * DVFS * Gbps / ethernet I have prepared a blindly DT that should work on Opi 3 H6: https://github.com/avafinger/orangepi-h6-ubuntu-base-minimal/tree/master/dts @Igor , Basically fetch the mainline kernel 5, apply your patch set on top and add/modify my DT. I have tried to add i2c and spi but it did not work as i expected. I had something like this: For the i2c i2c0: i2c@5002000 { compatible = "allwinner,sun6i-a31-i2c"; reg = <0x05002000 0x400>; interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_I2C0>; resets = <&ccu RST_BUS_I2C0>; status = "disabled"; #address-cells = <1>; #size-cells = <0>; }; i2c1: i2c@5002400 { compatible = "allwinner,sun6i-a31-i2c"; reg = <0x05002400 0x400>; interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_I2C1>; resets = <&ccu RST_BUS_I2C1>; status = "disabled"; #address-cells = <1>; #size-cells = <0>; }; i2c0_pins: i2c0_pins { pins = "PH5", "PH6"; function = "i2c0"; }; i2c1_pins: i2c1_pins { pins = "PD25", "PD26"; function = "i2c1"; }; Default i2c in use (PMIC and possibly HDMI): ls /dev/i2c-* /dev/i2c-0 /dev/i2c-1 i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- For the SPI0: spi0: spi@5010000 { compatible = "allwinner,sun8i-h3-spi"; reg = <0x05010000 0x1000>; interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>; clock-names = "ahb", "mod"; dmas = <&dma 23>, <&dma 23>; dma-names = "rx", "tx"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pins>; resets = <&ccu RST_BUS_SPI0>; status = "disabled"; num-cs = <1>; #address-cells = <1>; #size-cells = <0>; }; spi0_pins: spi0 { pins = "PC0", "PC2", "PC3", "PC5"; function = "spi0"; }; One thing i noticed was some instability on SD card but resorting to 4.19-rc6 clk values fixed it. Regarding the reboot command, i applied the latest ATF power fix (as suggested by @jernej but reboot works exactly as shutdown -h now

Type in the console terminal and ssh terminal: echo $LANG You should see UTF-8 on both terminals, that will fix the problem. It is just configuration.

htop was built without support for ncursessw (shared libraries for terminal handling (wide character support)). I realized that is not the problem, i found out if you run htop from ssh terminal and from a console terminal you get ASCII on one and UTF-8 on the other (or vice-versa) and both have UTF-8 support. Can you please check if you have the same behavior?

Type in the shell: printf "This is ASCII representation:\n|\n\`\n\`-\nThis is UTF-8 representation:\n\xe2\x94\x82\n\xe2\x94\x9c\n\xe2\x94\x94\xe2\x94\x80\n" You should see this: This is ASCII representation: | ` `- This is UTF-8 representation: │ ├ └─ If you don't see the above representation, you should set UTF-8 for your language in Terminal.

Yes, it does have the same issue. This harmless annoying warning message just halted my NanoPi M4 in a matter of 24 hrs in idle mode. Flooded 5 GB of data and kernel was stalled on next day. That's why i thought this info could help. I would not waste time on this issue, make sure you disable wlan completely and watch for the message, it should not appears, clean up your SD card and run domoticz. If this fix your crash then you should hunt for the fix.

Not sure it is related to your Domoticz crash but if i recall correctly the "warning" message is related to Wifi and should be harmless. There was a patch to fix that and i think the message is due to the missing password or wrong password to connect to wifi. BUT if you were connected to wifi before the crash you could try running without wifi configured and see what happens. Hope this helps.

I hope you mean "mainline kernel"... Please, try that on Pine64+ too.

My last update on this issue in case someone is working to get sound on A64 (>= 4.20). I tried every patch out there, triple checked the code , same situation, no sound. I must have missed something or overlooked something. I finally tried Vasily's kernel and for my surprise no sound. Last hope, i tried Vasily ARCH img, no luck, no sound even on Pine64. Maybe it works on Pinebook,....

Here is what i found so far, there are three patches floating around about audio on A64. for dai compatible string: "allwinner,sun50i-a64-codec-i2s", "allwinner,sun50i-a64-acodec-i2s", "allwinner,sun50i-a64-i2s", I tried to match the code with the compatible string, but i still have issues, no one claims the sun50i-a64-audio and i get this errors:

@Myy, Any chance you will be working on RK3399 5.0.rcX ? (GPU / VPU). I have been looking at your work for NanoPi-T4 but the label ** NOT TESTED ** was a bit discouraging. I can try to help testing or to provide some feedback.

FYI 5.0-rc1 works on NanoPi M4 with this DT, Bluetooth works with this instruction: The missing bits are Wifi and I think for GPU/VPU a new mali userspace is needed. ops, no mali or VPU ready on linux-next, sorry. ERROR: The DDK is not compatible with any of the Mali GPUs on the system. The DDK was built for 0x860 r2p0 status range [0..15], but none of the GPUs matched:

big.LITTLE has a policy for each cluster so I pushed some changes to display CPU Temp, CPU Freq, and CPU V-core for each cluster instead of CPU Freq for each CPU. Added a branch: rk3399 so it does not break things, you may need to review the boot script if one would like to know CPU temp for big and for LITTLE cores.

If you get the xserver on Ubuntu (deb packages), please make a patch. Seems everyone else is using the Debian version which is older than Ubuntu. jock's solution sounds good to implement, maybe it works only on mainline. Glmark2-es2 23 FPS scores look more rendered by software than by mali. On Mali, it should be 55 / 56 FPS (1920x1080). * When i say fbdev i mean everything is rendered directly on /dev/fb0 and not having a Desktop and going CTRL+ALT+F1 to get into console ( framebuffer )