All Activity

I am currently trying to add the board support "the official way" by forking the repo and adding the board in the "Community maintained" category. To me it seems that this requires not "normal" .config files, but ".csc" files. This is fine and I created one accordingly. But I dont know where to place it. What would be the best place for that? Additionally, I have created a patch that pulled the latest DTS file for the M1S from the mainline kernel repo. That worked fine as well and after compilation there was a local DTS file created and everything worked so far. But here I have the same problem/question: where to put these patches? Or is it preferable to use the created DTS file and place that somwhere without the patches that pull the mainline DTS? So basically I wish for a little bit support where to put which files to be "Board support Rules" compliant. Greetings!

Good point! I was not aware of that. I will try today and report back.

Lowest price is what makes it popular. But software is the biggest key of the package and there they are among the worst. On this SoC, we will be cooperating with SoC maker's board directly - working with Orangepi is too damaging for us: https://www.cnx-software.com/2025/04/27/muse-pi-pro-feature-packed-credit-card-sized-spacemit-m1-risc-v-sbc/ This will probably be done in a couple of weeks, so you can follow that and adjust accordingly.

Thank you for your quick answer, Jimbolaya. Yes, I did try different cables all with the same result. I wonder if there is another way to access the serial console, J13 perhaps? Albeit with some required soldering, I suppose. Then remains the question of which headers exactly relate to GND, TX and RX.

I don't think that's a relevant issue. I couldn't `modprobe zfs` in my case.

I noticed this problem a long time ago, but now I feel it is important to fix it: I get a slim black bar on the left side, and a portion of the pixels on the right get "cropped" because they don't fit in the LCD display area? Do you get the same in your LCD? Do you know a way to fix it? I am talking about this LCD: RED PCB LCD https://www.aliexpress.us/item/3256802847521952.html?

Hi @Nick A I tried build your fork repository and facing the following error, Can you please help me to fix this error? Source code: https://github.com/NickAlilovic/build/ $ git remote -v origin git@github.com:NickAlilovic/build.git (fetch) origin git@github.com:NickAlilovic/build.git (push) $ git branch main * v20250306 Build command: ./compile.sh build BOARD=x96q-lpddr3-v1-3 BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=yes RELEASE=trixie Error: [🐳|🌱] git: Fetch from remote completed, rev-parsing... [ 'debootstrap-debian-devel' 'master' 'FETCH_HEAD' ] [🐳|🌱] Debootstrap version [ '1.0.142' for /armbian/cache/sources/debootstrap-debian-devel/debootstrap ] [🐳|🌱] Installing base system with 5 packages [ Stage 1/2 ] [🐳|🔨] I: Retrieving InRelease [🐳|🔨] I: Checking Release signature [🐳|🔨] E: Release signed by unknown key (key id 762F67A0B2C39DE4) [🐳|🔨] The specified keyring /usr/share/keyrings/debian-archive-keyring.gpg may be incorrect or out of date. [🐳|🔨] You can find the latest Debian release key at https://ftp-master.debian.org/keys.html [🐳|💥] error! [ Debootstrap first stage failed /armbian/cache/sources/debootstrap-debian-devel/debootstrap trixie yes ] [🐳|💥] Cleaning up [ please wait for cleanups to finish ]

Unfortunately I don't have experience with the onboard flash, but I've never had an issue with the serial port. You've tried different cables i assume?

@jock Tested this and got a 1mim watchdog crash. I dont know if it helps to track this issue but with: "rk322x_tee_1.0.1-72-gf230aa2.bin" it goes to a 30mim. Like i said before, im kinda new to this. so i might have done something wrong when building armbian. If anyone here has a working build that does not trigger this watchdog, please let me know.

In theory, it shouldn't

I received a Helios4 and was finally able to get it to boot. As per instructions, I booted from microSD and flashed the latest Armbian image to sda1 via the nand-sata-install command. This reboots fine now, but only with the microSD-card present and the SW1 dipswitch set to "SD card boot mode". Is anybody here using "SPI NOR Flash" or "SATA1" boot mode to get rid of the microSD card? I am bit handicapped here since my serial port on the microUSB only comes up maybe 1 in 10 times. I wonder if it's worn out or if I am simply doing something wrong. Related Links: 1 2 3

@jock Does it make a diference witch multitool trusted OS i use?

I'm looking for Orange Pi RV2 RISC-V support. This board is gaining popularity due to the Orange Pi manufacturer's good reputation with Arm. I have successfully built both Orange Pi and Raspberry Pi aarch64 builds on Debian from source so I'd like to know how to build Armbian for Orange Pi RV2 riscv64. What would I need to modify in the build process? Thanks!!

Update: It works now, however the power LED doesn't seem to light up, but the video card is detected in /dev

Okay I found out that the previous error was mainly user error, due to an invalid user_overlays=, however I am facing a new issue and it still doesn't seem to work This is the new error Boot script loaded from mmc 1:1 308 bytes read in 2 ms (150.4 KiB/s) 14207910 bytes read in 1182 ms (11.5 MiB/s) 48779776 bytes read in 4043 ms (11.5 MiB/s) 161122 bytes read in 26 ms (5.9 MiB/s) Working FDT set to a100000 3772 bytes read in 4 ms (920.9 KiB/s) Applying user provided DT overlay radxa-zer5028 bytes read in 8 ms (613.3 KiB/s) Applying user provided DT overlay radxa-zero3-tc358743-audio.dtbo Trying kaslrseed command... Info: Unknown command can be safely ignored since ot apply to all boards. Unknown command 'kaslrseed' - try 'help' Moving Image from 0x2080000 to 0x220## Loading init Ramdisk from Legacy Image at 0a200000 ... Imagpe: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 14207846 Bytes = 13.5 MiB Loadoint: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 0a100000 Booting using the fdt blob at 0xa100000 Working FDT set Loading Ramdisk to 7c133000, end 7cebfb66 ... OK I'm not sure why it is saying it is loading radxa-zer5028 when that is clearly not what is listed in armbianEnv.txt This is what is in armbianEnv user_overlays=radxa-zero3-tc358743 radxa-zero3-tc358743-audio

After checking uboot logs, it shows that it fails to load the dtbo files, although I'm not sure what the error is. ** Booting bootflow 'mmc@fe2b0000.bootdev.part_1' with script Boot script loaded from mmc 1:1 308 bytes read in 2 ms (150.4 KiB/s) 14207910 bytes read in 1182 ms (11.5 MiB/s) 48779776 bytes read in 4043 ms (11.5 MiB/s) 161122 bytes read in 26 ms (5.9 MiB/s) Working FDT set to a100000 Failed to load '/overlay-user/radxa-zero3-tc358743,radxa-zero3-tc358743-audio.dtbo' Trying kaslrseed command... Info: Unknown command can be safely ignored sincelrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' Moving Image from 0x20840000 ## Loading init Ramdisk from Legacy Image at 0a200000 ... Image : AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 14207846 Bytes = 13.5 MiB Load Address: 00000int: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 0a100000 Booting using the fdt blob at 0xa100000 Working FDT set to a100000 Loading Ramdisk to 7c133000, end 7cebfb66 ... OK ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0) ERROR: reserving fdt memory region failed (addr=0 size=0 flags=0) Loading Device Tree to 000000007c0a3000, end 000000007c132fff .OK Working FDT set to 7c0a3000

I have managed to successfully install Armbian onto the DELL Wyse3040 As mentioned above, the way to do this is to use a PE environment that works on these devices. I used an old version of Hiren's BootCD and booted from it. Then I used a NTFS formatted flash drive with the unzipped image and used Roadkill's Disk Image to write it to the eMMC And it works, beautifully

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. Edit: I have investigated a little and it seems that I am still using the tm16xx which came with the distribution, as depmod was failng. After a fresh recompile all your module load but nodes under "leds" are not there, it seems that the dtso/dtbo is not read - nothing appears in dmesg. 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