All Activity

Hi, not sure if you can run 1-wire, SPI3, and I2C3 together as there may be an overlap in the pins used, but I have just managed to get my I2C1 and I2C3 busses working after having struggled with overlays' installation, that is, after thinking they are not working. My problem came from "overlay_prefix=" in /boot/armbianEnv.txt. It was set to "rk35xx". I edited armbianEnv.txt directly, and after changing this to "rk3568" (for Rock 3a), it allowed me, when running armbian-config (system --> kernel --> manage device tree overlays), to select from overlays inside /boot/dtb/rockchip/. In that folder, all files are indeed prefixed with "rk3568". However, I wanted to try "rockchip-rk3568-hk-i2c0.dtbo" from /boot/dtb/rockchip/overlay/. Prefix here is "rockchip-rk3568"; so I changed "overlay_prefix=", again directly inside /boot/armbianEnv.txt using a text editor, to that, and started again the armbian-config utility. Now, to my delight, I was able to select from the overlays stored inside /boot/dtb/rockchip/overlay/. (Note: In this folder is the SPI overlay that you will want to try.) Note to not include the "-". Note also that overlays rockchip-rk3568-hk-i2c0 and rockchip-rk3568-hk-i2c1 (note I2C0 and I2C1) enabled I2C busses 1 and 3 on the Rock 3a, *not* 0 and 1 as the names might imply! (Bus 0, 5 and 6 were already enabled on my setup before adding these two overlays.) (You will have to try and see which of the two enables I2C3 for you 🙂.) In other words, there may be inconsistencies in numbering schemes. Hope this helps, Teddy

HI David, Probably the easiest way to it. I can confirm by my Pcduino3 that Hdmi at least works although only with current (tested with 6.6.75) for the moment. I found that while the components are correctly enabled in edge (tested with 6.12.9) hdmi fails due to some a fault with the "hdmi-connector" component of the drm driver. all the best Ryzer

Hi Jwalds, It's definitely possible as there is Hardware support for it however the software support does not currently exist within the current Cedrus driver. To the best of my knowledge there is currently no mainline video encoding support for any Allwinner SOC. There are problem some efforts to get it working though, one such is: https://bootlin.com/blog/open-source-linux-kernel-support-for-the-allwinner-v3-v3s-s3-h-264-video-encoder/ while target at the V3 it should set the groundwork for getting encoding supported on other Allwinner SOCs. If there is already some form of decoding support then there should already be the video engine / video codec engine node within the main H616 dts. While I prefer overlays there are certain limits meaning it has to been integrated into the main dts rather than via an overlay. Found this out recently myself when exploring G2D hardware block present in some Allwinner SOCs. Best of luck Ryzer

ok I got it working by modifying my dts file. I am sharing it here for those who face the issue. So you dont have to waste days while pulling your hairs /dts-v1/; /plugin/; / { compatible = "rockchip,rk3568"; /* Update to match your SoC */ fragment@0 { target = <&spi3>; /* Correct SPI3 node */ __overlay__ { #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&spi3m1_pins &spi3m1_cs0>; /* Reference correct pin configuration */ status = "okay"; /* Enable SPI3 */ spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <5000000>; status = "okay"; }; }; }; };

This is the closest I can find https://forum.armbian.com/topic/26551-video-encoder-using-mainline-kernel/ https://gregdavill.com/posts/allwinner-s3-videoencoders/ https://linux-sunxi.org/Cedrus

I have not seen any one of them do it, but I assume they possess that capability since it is mentioned in the datasheet for H616 here: https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf I am looking for a DTS that has the correct parameters for the cedar driver (correct registers, memory etc) for the H618. I am absolutely open to doing a DTS overlay if that would make work easier.

In my case, armbian 25.5.0-trunk.256 still no go same thing happens not able to boot - rock pi 4b

If you had a serial console we can get an android and armbian boot log. Not easy to debug errors without it.

I will order a serial console

Just tried the image, no HDMI output sadly

Thank you all for your ideas,. I’m considering to acquire a cheap hdmi to to video converter and only readjust the resolution to match the 4:3 ratio. It would be enough for me. best regards David

Is the topic still relevant? I'm also trying to connect ST7735S + OPI Z3. But my screen doesn't even light up. I checked the screen on the ESP - it's working. There is no clear description anywhere of what packages need to be installed on the system. I would like to display information about the system on the screen

@Wan Lan Try this image.. if it doesn't work. I'll make a SECURE BOOT version. If they both don't work then you need a serial console. https://github.com/NickAlilovic/build/releases/download/20250306/Armbian-unofficial_25.05.0-trunk_X96q-lpddr3-v1-3_noble_edge_6.12.11_xfce_desktop.img.xz Your power controller is axp1530 aka axp313a pmu { compatible = "x-powers,axp1530"; reg = <0x36>; wakeup-source; linux,phandle = <0x128>; phandle = <0x128>; standby_param { vcc-dram = <0x4>; linux,phandle = <0x129>; phandle = <0x129>; }; regulators { dcdc1 { regulator-name = "axp1530-dcdc1"; I think these are your Dram Settings dram_select_para { device_type = "dram_select_para"; select_mode = <0x1>; select_gpio0 = <0x53 0x8 0xe 0x0 0x1 0xffffffff 0xffffffff>; select_gpio1 = <0x53 0x8 0xf 0x0 0x1 0xffffffff 0xffffffff>; select_gpio2 = <0x53 0x8 0x10 0x0 0x1 0xffffffff 0xffffffff>; select_gpio3; }; dram_para1 { device_type = "dram_para1"; dram_clk = <0x288>; dram_type = <0x7>; dram_dx_odt = <0x6060606>; dram_dx_dri = <0xd0d0d0d>; dram_ca_dri = <0xd0d>; dram_odt_en = <0x1>; dram_para1 = <0x30fa>; dram_para2 = <0x0>; dram_mr0 = <0x0>; dram_mr1 = <0xc3>; dram_mr2 = <0x6>; dram_mr3 = <0x1>; dram_mr4 = <0x0>; dram_mr5 = <0x0>; dram_mr6 = <0x0>; dram_mr11 = <0x0>; dram_mr12 = <0x0>; dram_mr13 = <0x0>; dram_mr14 = <0x0>; dram_mr16 = <0x0>; dram_mr17 = <0x0>; dram_mr22 = <0x0>; dram_tpr0 = <0x0>; dram_tpr1 = <0x0>; dram_tpr2 = <0x0>; dram_tpr3 = <0x0>; dram_tpr6 = <0x2fa88080>; dram_tpr10 = <0x2f3359>; dram_tpr11 = <0xaa889967>; dram_tpr12 = <0xeeee8979>; dram_tpr13 = <0x60>; }; or it could be this one. The dram_type = <0x3>; in this one and dram_type = <0x7>; above. [329]DRAM Type =? (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) dram { compatible = "allwinner,dram"; clocks = <0xd9>; clock-names = "pll_ddr"; dram_clk = <0x288>; dram_type = <0x3>; dram_zq = <0x3f3fdd>; dram_odt_en = <0x1>; dram_para1 = <0x30fb>; dram_para2 = <0x0>; dram_mr0 = <0x840>; dram_mr1 = <0x4>; dram_mr2 = <0x8>; dram_mr3 = <0x0>; dram_tpr0 = <0xc0000007>; dram_tpr1 = <0x0>; dram_tpr2 = <0x100>; dram_tpr3 = <0x0>; dram_tpr4 = <0x0>; dram_tpr5 = <0x0>; dram_tpr6 = <0x33808080>; dram_tpr7 = <0x0>; dram_tpr8 = <0x0>; dram_tpr9 = <0x0>; dram_tpr10 = <0x2f6606>; dram_tpr11 = <0xffffdddd>; dram_tpr12 = <0xfedf7657>; dram_tpr13 = <0x40>; linux,phandle = <0x17c>; phandle = <0x17c>; device_type = "dram"; dram_dx_odt = <0x3030303>; dram_dx_dri = <0xe0e0e0e>; dram_ca_dri = <0x1c16>; dram_mr4 = <0x0>; dram_mr5 = <0x0>; dram_mr6 = <0x0>; dram_mr11 = <0x0>; dram_mr12 = <0x0>; dram_mr13 = <0x0>; dram_mr14 = <0x0>; dram_mr16 = <0x0>; dram_mr17 = <0x0>; dram_mr22 = <0x0>; };

@Nick A Hello, I've extracted the DTS for my device 01_dtbdump.dtb.dts

Hi @Werner I ran the command, it looks like it uploads multiple kernel boot log. so I the most bottom one is the last kernel log I am dealing with. https://paste.armbian.de/fexaxufalu Last night, I played with dts, and I got the SPI3 enumerated at /dev/spi3. but it still not working. I mean when I run a script to use the SPI3, I cannot see any clock gets generated on SPI3.CLK. Here is the dts file: (venv) root@rock-3a:~# cat my-spi3-overlay.dts /dts-v1/; /plugin/; / { compatible = "rockchip,rk3568"; /* Update to match your SoC */ fragment@0 { target = <&spi3>; /* Correct SPI3 node */ __overlay__ { #address-cells = <1>; #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&spi3m1_pins>; /* Reference correct pin configuration */ status = "okay"; /* Enable SPI3 */ spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <5000000>; status = "okay"; }; }; }; fragment@1 { target = <&pinctrl>; /* Ensure this matches your pin controller node */ __overlay__ { spi3m1_pins: spi3m1-pins { rockchip,pins = < 4 18 3 0 /* GPIO4_C2 as SPI3_CLK_M1 */ 4 19 3 0 /* GPIO4_C3 as SPI3_MOSI_M1 */ 4 21 3 0 /* GPIO4_C5 as SPI3_MISO_M1 */ 4 22 3 0 /* GPIO4_C6 as SPI3_CS0_M1 */ >; }; }; }; }; here is the armbianEnv.txt (venv) root@rock-3a:~# cat /boot/armbianEnv.txt verbosity=1 bootlogo=false console=both extraargs=cma=256M overlay_prefix=rk35xx fdtfile=rockchip/rk3568-rock-3a.dtb rootdev=UUID=8a5d56b7-1e1b-49b6-8384-5ef8a0460c96 rootfstype=ext4 #overlays=rockchip-rk3568-hk-spi-spidev user_overlays=rk3568-i2c3m0-enable rk3568-w1-gpio3-a2 my-spi3-overlay param_spidev_spi_bus=1 param_spidev_max_freq=1000000 param_spidev_spi_cs=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Here is the logic analyzer output while the script was running. noted CS pin is alway Low and other pins are always High no matter what I am running the script. I have also attached the script that I am running to test out the SPI3 adc_reader.py

Have you ever seen the OPIZ2w (or OPIZ3) doing HW video encoding in another Linux? Where did you find this cedrus driver? What does the website claim it can do? Where did your OS image come from? What DTS modifications did you mean? Why not just a DTS overlay?

Hi rcr, Sorry to say, but I have not been able to fix the problem. IMHO there are 3 areas where there could be potential problems that explain the hangs... File Descriptors and Log Files: If a kernel driver or a kernel module is writing to a log file (e.g., via printk or a custom logging mechanism), and logrotate moves or deletes that log file, the driver might continue writing to the old file descriptor. This could lead to logs being written to a deleted file or lost until the file descriptor is refreshed (e.g., by restarting the driver or the logging service), but if improperly handled could cause a crash. Resource Deplation: Logrotate, when configured to compress very large log files, consumes significant CPU or I/O resources. It could cause a watchdog to time out. When zram is involved, the load will be higher because zram is faster than disk access Custom kernel driver logging: If a kernel driver uses a custom logging mechanism that interacts with user-space log files (e.g. via a custom device file), improper handling of log rotation could cause issues. For example, if the driver expects the log file to exist and it doesn't, it might fail or behave unexpectedly. I suspect it might be related to a driver in the 6.12.x kernel that comes with these releases. For Rockchip 3588 I have not seen the issue with the vendor drivers (5.10, 6.1).

I have tried to used apt update and upgrade to update latest Mesa driver but keep getting error 'file has unexpected size' so therefore fails as unable to fetch the archive! the file is available after apt update but unable to install. How can i fix this please?

@Александр Соколов Please look at the previous page. There is also a photo without a radiator. I connected it to the router. I accepted the IP address. I tried to connect via the windows command prompt, then through the Putty application. As a result, I scanned the network and found no open ports. I can capture the process on video. Главное шьётся на другие андроиды и на LibreELEC а мультитул никак не реагирует.

This could be a similar problem that I have had with the mks-klipad50 board (also a rockchip64). In case of the bootloop, do the u-boot messages show "efi_free_pool" messages, directly followed by a "Synchronous Abort", like this? (The hex numbers can vary and there are a lot more registers dumped, this is just the start): Starting kernel ... efi_free_pool: illegal free 0x000000003cf21040 "Synchronous Abort" handler, esr 0x96000004 In that case, it is rather caused by the bootloader (u-boot) and the kernel version change had just a very indirect effect which triggered that problem.

moved

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

If its not in https://archive.armbian.com/, then we don't have it anymore.

Thanks for the info but I am not using a rolling release. I f this update/patch can be applied to the version I am using how do I go about that? Failing that, where can I get the latest version of Debian cinnamon with the patch included? The software has been fully updated as of today but still no hdmi audio. Is there a simple fix? Thanks for your help update. I have gone into Armbian-config and changed from stable to rolling updates but still not working!

Please, help me find an old version of firmware for Nanopi Neo Air. I'm looking for Armbian 5.73 Debian based 4.19.20-sunxi . Best regards