jgeisler

Hi, I had the same problem still with ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.14.18-sunxi. But I didn't want to compile the kernel anew. So I did dtc -I dtb -O dts -o sun7i-a20-bananapi.dts sun7i-a20-bananapi.dtb with a copy of the dtb file from "/boot/dtb-4.14.18-sunxi" (maybe with sudo). Then edited the dts like this patch --- sun7i-a20-bananapi.dts 2018-03-05 18:42:30.608935387 +0000 +++ sun7i-a20-bananapi_can.dts 2018-03-05 18:28:21.085552756 +0000 @@ -1099,12 +1099,12 @@ linux,phandle = <0x2b>; phandle = <0x2b>; - can0@0 { + can0_pins_a: can0@0 { pins = "PH20", "PH21"; function = "can"; linux,phandle = <0x74>; phandle = <0x74>; - }; + }; clk_out_a@0 { pins = "PI12"; @@ -1847,10 +1847,12 @@ reg = <0x1c2bc00 0x400>; interrupts = <0x0 0x1a 0x4>; clocks = <0x43 0x4>; - status = "disabled"; linux,phandle = <0xb5>; phandle = <0xb5>; - }; + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&can0_pins_a>; + }; i2c@01c2c000 { compatible = "allwinner,sun7i-a20-i2c", "allwinner,sun4i-a10-i2c"; and recompiled with dtc -I dts -O dtb -o sun7i-a20-bananapi_can.dtb sun7i-a20-bananapi_can.dts copied it back to "/boot/dtb-4.14.18-sunxi", overwriting the original (and making a copy of the original of course). And voila: I have CAN bus working. But beware: the dtc on my bananapi had a lot of error messages and the changed dtb didn't boot. So I had to do the whole procedure on my main machine. Hope this helps anyone to a painless CAN bus activation. And thanks to the previous posters to get me on the right track.

Yay, it works. I get audio. Loading the modules via /etc/modules is a good solution. Now I just wonder, what the overlay does. Looking at this source code sun8i-h3-analog-codec.dts, I don't see anything that might load a driver. I thought that is what overlays do: load and configure drivers. Maybe this overlay is incomplete?

Hi, I have a similar problem on my OPi zero. I have Welcome to ARMBIAN 5.36 user-built Ubuntu 16.04.3 LTS 4.13.16-sunxi overlays=analog-codec is set but nothing happens, not the silghtest hint what might go wrong in dmesg. But when I do sudo modprobe sun8i-codec-analog sudo modprobe sun4i-codec I get jgeisler@orangepizero:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 and jgeisler@orangepizero:~$ dmesg|tail [ 142.801380] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok That looks promising, though I have not yet soldered a jack to the pins to see if the audio actually works. What does that tell me? What is going wrong with the overlay?

Talking of this, did anybody notice that the dts for all the rk3288 boards state that is compatible = "arm,cortex-a12";? Does that make any difference?

Well Ubuntu Vivid is quite dated. The miqi image (and Armbian soon?) gives me accelerated desktop and accelerated video in chromium (1080p on youtube with h264ify). And the box cost me only 36€.

After some more failed attempts and a lot of reading on how the device tree works, I have now a dts file that boots clean with the miqi image on my UT3S. https://pastebin.com/eAWqkf9j https://pastebin.com/ZD4CRbRE (edit: now with phandle links instead of numbers) It should provide wifi and bluetooth but I some how cannot get them to work. Maybe the kernel lacks the drivers? Further it should utilize the fan in the thermal zones for the cpu an gpu. But that does not work either, the fan is not even listed as a cooling device. Turning the fan on via its GPIO works though. Edit: here https://cateee.net/lkddb/web-lkddb/ROCKCHIP_THERMAL.html it says "Rockchip thermal driver provides support for Temperature sensor ADC (TS-ADC) found on Rockchip SoCs. It supports one critical trip point. Cpufreq is used as the cooling device and will throttle CPUs when the Temperature crosses the passive trip point." Can that be? At least the temperature sensor is now enabled an can be read. What is still missing are the IR input, the audio jack, the power button, the power led and the RTC and probably some other stuff too. But at least I know now a bit more about how it all works.

Lazarus! I felt lucky, but I wasn't, then came the serial console and I brought me back. After a bit of research I decided that it should be safe to boot the miqi image with the openelec UT3 device tree. I found out that all the different phandl, pinctrl-0, power-domains, iommus, remote-endpoint, phys, ddc-i2c-bus, rockchip,pins, gpios, sound-dai and dmas etc. - values are just some kind of pointer that can change from one run of dtc from dts to dtb and back so, the rk3288-ugoos-ut3s.dts only has the whole RAM configuration dropped, added wireless configuration, enabled temperature sensors, added debug console FIQ? So, I copied the compiled dtb to the boot file-system and edited extlinux.conf to use it. Reboot. Black screen. No way to reach the device via network. So off to some more learning. I took my ceramic cooktop-scraper, cracked open the box and connected the wrong pins (that suspicious looking 3-header is not the serial port). Fortunately, http://www.bitkistl.com/2015/04/ugoos-ut3s-first-impressions.html has us covered, except he doesn't mention to run the serial at 115200bps. Finally I got this rather nice boot log https://pastebin.com/Bhd7UKKd that leaves me wondering what went wrong. Wanting to go back to the old config, I interrupted u-boot autostart and told it to "ums mmc 1" which let me connect the OTG as a USB stick with the eMMC data of the UT3 on it. Connected this to my other PC, edited extlinux.conf back to use the old dtb, reset, and back I am writing this post on the UT3 (with the lid off and some wires hanging out). I guess, now I have to learn a bit more about device trees, before I start my next adventure.

Getting into uboot probably means to go via the serial interface? I have not yet cracked the box open. So, maybe I'll wait a little longer, or I try to figure out if the miqi image allows booting from sd and try it from there, or I feel luck and just give it a go.

I finally found the dts that omegamoon created for running openelec with a 4.4 kernel on a ugoos ut3(s/+?): https://github.com/omegamoon/linux-rockchip-kernel/blob/release-4.4/arch/arm/boot/dts/rk3288-ugoos-ut3s.dts It look very much like the one that came with the miqi image: https://pastebin.com/apRfExC3 It has a wireless-wlan and a wireless-bluetooth node, Some words in linux,phandle, phandle, [xzy]-supply, pinctrl-0, power-domains, iommus, remote-endpoint, phys, ddc-i2c-bus, rockchip,pins, gpios, sound-dai and dmas are different The serial@ff180000 is configured a bit differently tsadc@ff280000 is status "okay", instead of "disabled" dmc@ff610000 and syscon@ffac0000 are missing ddr-sram@1000 in bus_intmem@ff700000 is missing, Can anyone tell me if it might be safe to try to use this dts with the miqi image on my UT3S? (I boot from eMMC via extlinux, so I could just exchange the dtb in the filesystem). Would I risk not being able to boot anymore or not being able to reset the dtb to the currently working one? BTW: I'm trying to live my normal desktop life with the UT3S w/ miqi image and it works quite well so far. Only Xorg crashes once in a while and sends me to the login screen. No audio from the AV jack and no bluetooth.

I flashed my UT3S now as described here: http://www.bitkistl.com/2016/10/ugoos-ut3-devices-with-firmware-from.html It does work out of the box really well, just as described in the above link. I even got hw accelerated video in Chromium youtube. FWIW, here is the dmesg: https://pastebin.com/0GvM8Rfa What is really interesting is that it boots via extlinux. That means that the dtb is a file in the file-system (/media/your_user_name/1E81-4CCA/). Here is the decompiled dtb, that came with the miqi image: https://pastebin.com/8j6qEgM1

The dts on pastebin is from the ugoos dualboot firmware v3.1 from 2015. On their blog it says that it features a Ubuntu 15.04 but no mention of the kernel version. uname -a says "Linux Ugoos_box 3.10.0 #44 SMP PREEMPT Thu Jul 30 15:21:59 HKT 2015 armv7l armv7l armv7l GNU/Linux". Libreelec was also ported to the UT3 http://www.cnx-software.com/2017/02/23/libreelec-is-now-running-on-ugoos-ut3-rockchip-rk3288-tv-box/. In the build_rk3288_ugoos-ut3s.sh on https://github.com/omegamoon/LibreELEC.tv it says PROJECT=Rockchip_rk3288 ARCH=arm DISTRO=MoonRock DEVICE_TREE=rk3288-ugoos-ut3s make rkimage But in the repo I could nowhere find the rk3288-ugoos-ut3s.dts or dtb.

I'm now looking into the RochChip-way of making an image (http://rockchip.wikidot.com/linux-user-guide). But I can't figure out where to get a _defconfig file for building u-boot. Is that route worth anything?

Sure: https://pastebin.com/apRfExC3

Its seems the pvtm-operating-points table has to be read in triples of KHz uV pvtm margin. Reading it like this gives 1800000kHz@1350000uV. I found this in firefly-rk3288.dts. Although the format there is a bit differen with lots of ampersands in the top level names. Assuming the dts file is usable, how could I combine it with e.g. the Armbian Tinker Board image to run on my UT3S?

In the dual-boot archive you can download from Ugoos, there is a folder "Image" with different .img-files. One of them is "resource.img". It's one of the files I had to flash for the linux-only installation. It's binary, but when opening it with a text editor, there are characters "ENTRrk-kernel.dtb" at offset 512. Don't know if that helps. I wouldn't knwo how to extract the device tree from there.