All Activity

Mmmh, the easiest thing you can do you can build an armbian image taking rk322x_tee_os.bin from this branch in my repo and overwrite rk322x_tee.bin in the same path of your armbian copy, then build a regular image which will have an opensource TEE and should have no issues anymore. Actually you could even reinstall u-boot without reinstalling the whole system, but it is just a tiny bit more involved. If you can restart from scratch, rebuilding the image with opensource TEE is easier.

sorry for my confusion @jock im kinda new to this. yeah it switched from a 1mim watchdog to a 30mim watchdog crash. Is there a armbian distro that will work, what should i do here?

Hi - thank you for the nice driver. Here is my contrbute: Device under test : T9_RK3318 (T9 Sunwell 3318 version 4+32 GB) Running: v25.11 rolling for RK3318 Box running Armbian Linux 6.12.55-current-rockchip64 Packages: Debian stable (trixie) Support: for advanced users (rolling release) Some info: RK3318:~# lsmod | grep tm tm16xx 28672 0 stmmac_platform 20480 1 dwmac_rk stmmac 241664 3 stmmac_platform,dwmac_rk pcs_xpcs 28672 1 stmmac lsmod | grep i2c i2c_gpio 16384 0 i2c_algo_bit 12288 1 i2c_gpio ls /sys/bus/i2c/devices/ 5-0024 i2c-4 i2c-5 ls /sys/class/leds/display brightness device digits map_seg7 max_brightness num_digits num_segments power segments subsystem trigger uevent value ls -l /sys/class/leds/ total 0 lrwxrwxrwx 1 root root 0 Oct 26 11:53 display -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display lrwxrwxrwx 1 root root 0 Oct 26 11:53 display::alarm -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display::alarm lrwxrwxrwx 1 root root 0 Oct 26 11:53 display::colon -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display::colon lrwxrwxrwx 1 root root 0 Oct 26 11:53 display::lan -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display::lan lrwxrwxrwx 1 root root 0 Oct 26 11:53 display::pause -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display::pause lrwxrwxrwx 1 root root 0 Oct 26 11:53 display::play -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display::play lrwxrwxrwx 1 root root 0 Oct 26 11:53 display::usb -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display::usb lrwxrwxrwx 1 root root 0 Oct 26 11:53 display::wlan -> ../../devices/platform/i2c-display/i2c-5/5-0024/leds/display::wlan lrwxrwxrwx 1 root root 0 Jan 1 1970 input3::capslock -> ../../devices/platform/ff600000.usb/xhci-hcd.0.auto/usb2/2-1/2-1:1.1/0003:248A:8208.0002/input/input3/input3::capslock lrwxrwxrwx 1 root root 0 Jan 1 1970 input3::compose -> ../../devices/platform/ff600000.usb/xhci-hcd.0.auto/usb2/2-1/2-1:1.1/0003:248A:8208.0002/input/input3/input3::compose lrwxrwxrwx 1 root root 0 Jan 1 1970 input3::kana -> ../../devices/platform/ff600000.usb/xhci-hcd.0.auto/usb2/2-1/2-1:1.1/0003:248A:8208.0002/input/input3/input3::kana lrwxrwxrwx 1 root root 0 Jan 1 1970 input3::numlock -> ../../devices/platform/ff600000.usb/xhci-hcd.0.auto/usb2/2-1/2-1:1.1/0003:248A:8208.0002/input/input3/input3::numlock lrwxrwxrwx 1 root root 0 Jan 1 1970 input3::scrolllock -> ../../devices/platform/ff600000.usb/xhci-hcd.0.auto/usb2/2-1/2-1:1.1/0003:248A:8208.0002/input/input3/input3::scrolllock lrwxrwxrwx 1 root root 0 Jan 1 1970 working -> ../../devices/platform/gpio-leds/leds/working Testing... echo "1234" > /sys/class/leds/display/value echo 1 > /sys/class/leds/display\:\:lan/brightness echo 1 > /sys/class/leds/display\:\:usb/brightness All the 7 functions and 4 digits are working and correctly associated. Also trigges are working. I still have this small bug which is stopping rolling messages: display-service -c [INFO] all digits and leds on /usr/sbin/display-service: 116: cannot create /sys/class/leds/display/message: Permission denied All the function leds reacts well (all on) but the four clock digits do not switch, most likey because of the message permission denied. However they do work writing directly in the "value" as above and in the picture. Attached the working dtso file. rk3318-t9.dtso

Multitool uses the proprietary miniloader blob for booting and it does not work with opensource OPTEE unfortunately. I guess the issue is related with this patch that allows mainline opensource u-boot to support proprietary Trust OS, but that's just an ineducated guess.

@jock do you have this OPTEE already builded for sharing? The one in your multitool git did not work for me, also it shows the last change was 2 years ago hahahha.

Hello @Victor Picinin yes the problem is exactly a watchdog in the proprietary trust os. Some people have issues after 60 seconds, others after 30 seconds and others after 30 minutes. Being the proprietary Trust OS closed source, we can't know what is happening. I suspect it is a sort of automatic "suspend" feature of some sort, but can't be sure because digging into practically is diffucult. What is sure is that if we use OPTEE Trust OS compiled from open sources (OPTEE is the base for the proprietary Trust OS too), there are no issues of sort, but we lose some features like DDR3 memory scaling and "virtual power off" (a suspend mode that can awaken the board via IR-control; there is a driver and a device tree overlay for that to work in armbian)

@Victor Picinin Hello Victor thank you for your work. Also @jock and @ilmich managed to obtain free source trust and not the proprietary One but i rembember there were issues ( DMC scaling on DDR3 ??? ) Sure jock or ilmich can answer better

This was a watchdog and trust os issue. For anyone having this issue, i fixed by building a new multitool from OP github: https://github.com/paolosabatino/multitool/tree/master Changing the RK322x TRUST_OS to: rk322x_tee_1.0.1-72-gf230aa2.bin And them building a new armbian build replacing the armbian TRUST_OS with this same one. "rk322x_tee_1.0.1-72-gf230aa2.bin" if anyone needs the builded files "multitool and armbian" feel free to email me at vitorpicinin@gmail.com

I wasn't talking about dmesg logs.

Yes. I check the dmesg logs and they aren't loading which is probably why it doesn't work, but I have tried a variety of methods to try and get them to load, however nothing worked.

Did you make sure they're actually loaded? Like by checking uboot boot logs via serial console?

Would you mind sharing the steps you took to enable csi camera support? I'm trying to enabled the CSI port on the Radxa Zero 3W for the TC358743, but I have been unable to make progress. I'm currently using a Geekom X1301 HAT for the CSI to HDMI adapter which uses the TC358743, but it never shows up. What I have tried so far is extracting the .dtbo files from the official radxa image. Adding them to /boot/overlay-user and enabling the two tc358743 overlays radxa-zero3-tc358743.dtbo radxa-zero3-tc358743-audio.dtbo and finally enabling them in armbianEnv.txt with this line user_overlays=radxa-zero3-tc358743,radxa-zero3-tc358743-audio Is there anything that I missed? The CSI port still doesn't seem to be receiving any power, as the X1301's power LED has been off the whole time.

@Mateus Lima It Is not the first neither will be the last time that china manufacturers fake soc printing. Have a look on allwinner forum

It appears that the system control was not configured properly. In the default DTS the binding is "sun8i-a83t-system-controller" which appears to have been deprecated in favor of the suffix "system-control" from what I could find. So tested with "sun8i-a83t-system-control" and "sun8-h3-system-control" as a fall back option. This time we no complaints from Cedrus: ryzer@cubietruckplus:~$ sudo dmesg | grep cedrus [ 10.624985] sunxi_cedrus: module is from the staging directory, the quality is unknown, you have been warned. [ 10.652836] cedrus 1c0e000.video-codec: Device registered as /dev/video0 Second test was to ensure that the video-engine clocks are set correctly, which can be done by temporarily disabling driver suspension. ryzer@cubietruckplus:/sys/kernel$ sudo cat debug/clk/bus-ve/clk_enable_count 1 ryzer@cubietruckplus:/sys/kernel$ sudo cat debug/clk/ve/clk_enable_count 1 ryzer@cubietruckplus:/sys/kernel$ sudo cat debug/clk/dram-ve/clk_enable_count 1 Next test trying to get working which should be using the version of ffmpeg as detailed here: This is the current output of ffmpeg: ffmpeg version 5.1.7-0+deb12u1 Copyright (c) 2000-2025 the FFmpeg developers built with gcc 12 (Debian 12.2.0-14) configuration: --prefix=/usr --extra-version=0+deb12u1 --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --arch=arm --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librist --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libv4l2 --enable-v4l2-request --enable-v4l2-m2m --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libudev --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --disable-sndio --enable-libjxl --enable-pocketsphinx --enable-librsvg --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-libplacebo --enable-librav1e --enable-shared libavutil 57. 28.100 / 57. 28.100 libavcodec 59. 37.100 / 59. 37.100 libavformat 59. 27.100 / 59. 27.100 libavdevice 59. 7.100 / 59. 7.100 libavfilter 8. 44.100 / 8. 44.100 libswscale 6. 7.100 / 6. 7.100 libswresample 4. 7.100 / 4. 7.100 libpostproc 56. 6.100 / 56. 6.100 Hardware acceleration methods: vdpau vaapi drm opencl vulkan It is also worth mention that as there is no support for the SGX544 GPU, we are limited to a CLI only interface for which MPV can only be launched full-screen. MPV fails to use hardware decoding and falls back to using software. MPV version is reported as 0.35.1 [ 3.639][v][vo/gpu-next/opengl] Initializing GPU context 'drm' [ 3.643][e][vo/gpu-next] Can't handle VT release - signal already used [ 3.647][w][vo/gpu-next/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [ 3.651][v][vo/gpu-next/opengl] Initializing KMS [ 3.657][v][vo/gpu-next/opengl] Picked DRM card 0, primary node /dev/dri/card0 as the default. [ 3.662][v][vo/gpu-next/opengl] Driver: sun4i-drm 1.0.0 (0) [ 3.666][v][vo/gpu-next/opengl/kms] Connector 63 currently connected to encoder 62 [ 3.670][v][vo/gpu-next/opengl/kms] Selected Encoder 62 with CRTC 61 [ 3.675][v][vo/gpu-next/opengl/kms] Selected mode: 1920x1200 (1920x1200@60.00Hz) [ 3.679][v][vo/gpu-next/opengl] DRM Atomic support found [ 3.684][v][vo/gpu-next/opengl/kms] Using overlay plane 51 as draw plane [ 3.689][v][vo/gpu-next/opengl/kms] Using primary plane 57 as drmprime plane [ 3.693][v][vo/gpu-next] GBM_FORMAT_ARGB8888 not supported by draw plane: Falling back to GBM_FORMAT_XRGB8888. [ 3.697][v][vo/gpu-next] Supported modifier: 0x0 [ 3.702][v][vo/gpu-next] Creating GBM device [ 4.915][v][vo/gpu-next] Initializing GBM surface (1920 x 1200) [ 4.920][e][vo/gpu-next] Failed to create GBM surface. [ 4.924][e][vo/gpu-next] Failed to setup GBM. [ 5.397][v][vd] Container reported FPS: 30.000000 [ 5.405][v][vd] Codec list: [ 5.409][v][vd] h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [ 5.414][v][vd] h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper [ 5.418][v][vd] Opening decoder h264 [ 5.424][v][vd] Looking at hwdec h264-drm... [ 5.428][v][vd] Could not create device. [ 5.433][v][vd] No hardware decoding available for this codec. [ 5.437][v][vd] Using software decoding. [ 5.445][v][vd] Detected 8 logical cores.

Well, it seems that I have a very strange device, as I can boot armbian for devices using Allwinner H3, even tho the SoC shows It self as a RK322BA. I don't know what's happening with my device, and unfortunately, there's no much information about it, just some users trying random armbian builds from devices with the same soc, which works, but features like wi-fi doesn't, probably something that can be fixed making a dtb for this device, which I don't know how to unfortunately.

@Mateus Lima I am not very sure this Is a rockchip board.. i see h3q ...may be an allwinner h3 ?????? Can you check removing the heatsink ? Or check with USB ttl adapter ?

That's my device, I don't if showing it's board will be helpful.

It seems the Ethernet dirver is already in mainline, and oss wifi driver are available: https://github.com/lynxlikenation/aic8800

What is this method about? Hold the button while it is booting with the sdcard inserted? I also tried to boot using a usb drive flashed with multitool flashed, but it still boots into android. As for the bootloader, I'm booting it into bootloader mode, and it gets recognised, but "fastboot oem unlock" just prints three dots "..." and doesn't do nothing. In the guide there's a bootloader file I think, but it's not available anymore.

First of all, I would like to thank you for continuing to maintain this project. I use an RK3228 MXQ running raspotify (another great project) playing music. However, I can't equalize the sound? Is there a way to use a sound equalizer? I tried for ALSA and lost a few days in several things but nothing worked.

Do you try also toothpick (there is a recovery button behind headphone port) methode and SD-Card ? or USB boot , there are some box with lock bootloader

I'm trying to boot multitool, but my device is booting directly into android. I've flashed my sdcard using dd and balena, both works fine apparently, the box recognizes the sdcard (it shows on android file manager), but every time I reboot it, it only boots android... Does anyone have any clue of what should I do?

Those are images from BigTreeTech, not Armbian. Official Armbian images for CB1 are here: https://www.armbian.com/bigtreetech-cb1/ If you want to use vendor images, you should report your issue to BigTreeTech then.

https://www.cnx-software.com/2025/10/25/35-orange-pi-4-pro-an-allwinner-a733-edge-ai-sbc-with-up-to-16gb-lpddr5-wifi-6/ https://www.cnx-software.com/2025/07/07/allwinner-a527-t527-and-a733-datasheets-user-manuals-and-linux-sdk-released/ http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-4-Pro.html Another Allwinner board dropped figuring out the wifi chip is always hard, seem to be https://www.taobao.com/list/item/931793873067.htm https://pine64.sfo3.cdn.digitaloceanspaces.com/doc/datasheet/oz64/AIC8800DC Datasheet v1.0.pdf as usual, it is uncertain if drivers and firmware is after all available. Ethernet according to CNX seemed to be YT8531CA Ethernet seemed to be same as that in OrangePi Zero 3 https://www.cnx-software.com/2023/07/03/orange-pi-zero-3-allwinner-h618-sbc-ships-with-up-to-4gb-ram/ WiFi is 'more critical' these days, if it is closed sourced and no firmware, then it is good as just a door stop. Then that thare are other stuff the figure out especially the : - DRAM controller, - and various DRAM timing and configuration aspects - many other low level specific stuff to even have u-boot to boot it up to the linux prompt. - then the other devices e.g. uart etc. - then HDMI - then gpu acceleration (or at least display video, not playing media yet) - then media - and finally NPU, don't seemed documented yet - many more known or unknown unknowns, audio etc

Hi all, I’m trying to get KlipperScreen running directly on the framebuffer on a BigTreeTech CB1 that’s using an Allwinner H616B chip. It’s running Armbian Bookworm (kernel 6.6.66-vendor-sunxi64, Dec 2024 build) on a Manta M8P V2.0 board with a TFT35-SPI display that shows up as fb_st7796s. The goal is to have KlipperScreen render directly to /dev/fb0 without needing a desktop or HDMI. The framebuffer itself seems fine as the screen shows the BigTreeTech logo on boot, and I can write to it manually, so the driver appears to be working correctly. KlipperScreen installs fine, the Python environment and dependencies are all in place, but when I launch it, I always get “Gtk couldn’t be initialized.” If I try running it under Xorg, it throws “xf86OpenConsole: Switching VT failed,” which seems to mean the kernel isn’t allowing virtual terminal switching. I’ve tried both framebuffer and Xorg modes, set SDL_VIDEODRIVER=fbcon and FBDEV=/dev/fb0, and even forced it to use SDL directly, but GTK still won’t start. Everything else works normally, it just refuses to render the GUI. Here’s the kicker: this exact setup worked perfectly on Armbian V2.3.4. KlipperScreen ran out of the box with no special tweaks, so something clearly changed in V3.0 and later builds that broke framebuffer support or GTK initialization. It feels like either framebuffer rendering got dropped, VT switching was removed, or GTK was built without fbdev support. So my main questions are: was framebuffer (fbdev) support intentionally removed from newer Armbian builds for the CB1? Is VT switching disabled by design in the H616 kernel? And is there any known way to run GTK or SDL apps directly on /dev/fb0 under the current Bookworm build? If it’s just a matter of rebuilding GTK or enabling a missing kernel flag, I’m happy to do that I just need to know where the problem actually lies.