All Activity

I wonder if a port is possible and/or feasible, if it is, where can I check? I tried searching on documentations for a guide on how to start a port, but couldn't find anything. If I remember correctly, xiaomi-elish hardware is very related to xiaomi-alioth, to the point of some of the code for PMOS being shared, obviously each hardware has it's quirks but, I think it's possible, i do have the device for testing, and I have some knowledge of programming, but I can learn more in the process.

Here, yes. Thank you! No, but we need to test images made for release. There is another last minute change https://github.com/armbian/build/commit/1890d7f6566a65202f73730b469d024c20f863b8 than can, in theory, make unbootable image. OK. Bugs will be present and we won't be fixing them at this stage. Here - if basic things works - that image boots, have connectivity and video output ... its ready to ship. All other things can be fixed with an update. If / when they are fixed.

I tried several Armbian images, but none of them booted successfully, so I ended up compiling a custom kernel for this Orange Pi 4 Pro. The Ubuntu and Debian images hosted on the Orange Pi website were also missing too many features. https://github.com/blippu/orangepi4pro with this new kernel, you can properly use docker, tailscale and samba/ cifs

I don't know if this is known already and if its off topic for this thread. I did a search for moonlight in the allwinner section and nothing came up so I'm sticking it here I got moonlight running on H618 (actually it might be a H616....) box with no issues at all. Streamed a game from my main PC (with sunshine) at 1080p and it ran great. Makes for a cheap Steamlink alternative. I just followed the instructions here, It does mention v4l2 so maybe the v4l2request patch is required for it to work. There is an Embedded version that might work if you don't have v4l2 support.

I download Armbian_26.2.1_Odroidm2_noble_current_6.18.8_gnome_desktop.img.xz and burnt to a new SD card. Tested: Install OK Initial startup to desktop OK shutdown OK boot OK HDMI OK HDMI audio FAILED only dummy sound device Wifi via PCI M-key to E-key adapter Intel Wifi 6 AX200 OK USB-2 OK multiple devices including HUB USB-3 OK thumb drive USB-C FAILED nil buses detected or exposed I have managed to add a user device tree overlay to expose the USB-C port in non OTG mode and get some USB-C devices working. A USB-C thumb drive was consistent. But I only managed to connect my Pixel 8a successfully once at 480m speed.

Armbian 25.11.2 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + Box64 arm64 v0.4.1 652da4fbc (https://ryanfortner.github.io/box64-debs/) + proton-10.0-4-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/download/proton-10.0-4/wine-proton-10.0-4-amd64-wow64.tar.xz) + DXVK-stripped v1.10.3 ~50fps@720p (low settings) box64 environment variables: Injustice Gods Among Us Ultimate Edition

@Kevin su Armbian uses one kernel config for both server and desktop images. You could compile your own server image and enable this option. I can help you with build errors. SBCs often have relatively weak single-core performance compared to x86 servers. Full preemption prevents a single long-running kernel task from causing noticeable "stutter" in network responses or shell interaction.

I am currently on the community Odroid M2 CURRENT (6.18) (not edge 6.19) rolling release. Does this differ significantly enough from the images provided here: https://fi.mirror.armbian.de/incoming/igorpecovnik/ that I should download afresh and re-install before submitting any test results? Reporting! Where? (Every other section 1 - 7 had a necessary link) Much appreciated in advance. Willing to help or donate a M2 board if necessary.

@Nick A I agree with your point — for modern SBCs, the difference is probably not that significant, and it’s more of a psychological feeling. However, it would be even better if the new version could switch to CONFIG_PREEMPT_VOLUNTARY.

@Kevin su I wouldn’t call fully preemptive scheduling “not suitable” for server use, especially on ARM SBCs. On modern kernels, CONFIG_PREEMPT=y has low overhead and is widely used by Armbian even for headless/server images. For a purely headless system under sustained, throughput-focused load, CONFIG_PREEMPT_VOLUNTARY can be a reasonable alternative, but the difference is usually small. It’s more a tuning preference than a correctness issue.

Hello, I have some troubles with this TVBOX: it runs armbian and other distros correctly, using the meson-gxm-t95z-plus.dtb but sometimes wifi goes into kernel panic at boot, and when it does, the whole system becomes unstable (i.e. not rebooting, eth0 hangs...). I have extracted the original .DTB from the only firmware that exists for this box, the ancient 6.0 Marshmellow Android (I guess it's a 3.x kernel...). I attach it to this message hoping someone more expert than me can help in making it work ina more stable manner. I attach a picture of the board also, it reads "M8S". Box has 2GB ram and 16GB eMMC, brcmfmac wifi/bt and ZTE PHY chip. meson1.dtb

UPDATE: Serial Logs and GPT Signature Error on RK3229 (Kingston eMCP) Hi everyone, Following up on my previous post about the "Red LED" issue with my RK3228A (Kingston eMCP) box. I managed to hook up an ESP32-S3 as a USB-to-Serial bridge to see what’s happening under the hood. The box is communicating at 1,500,000 baud. Here is the log I captured when trying to boot the Multitool from the SD card: Secure read PBA: 0xc04 Secure read PBA: 0x1004 Secure read PBA: 0x1404 Secure read PBA: 0x1804 Secure read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x631442f0 signature is wrong recovery gpt... GPT 0x631442f0 signature is wrong recovery gpt fail! LOADER Check OK! 0x2000, 735748 TOS Check OK! 0x4000, 804945 Enter Trust OS INF [0x0] TEE-CORE:init_primary_helper:377: Initializing (1.1.0-333-gc9d95d1 #2 2018年 08月 17日 星期五 03:32:22 UTC arm) INF [0x0] TEE-CORE:init_primary_helper:378: Release version: 2.0 INF [0x0] TEE-CORE:init_primary_helper:379: Next entry point address: 0x61000000 It seems the bootloader initializes the RAM and Trust OS correctly, but then it hits a GPT signature is wrong error and the recovery fails. This happens right before the kernel should start loading. I have already tried two different SD cards (16GB Lexar and 8GB Generic) with the same result. Given these logs, what should be my next steps?

For me, those 57°C is fine without further cooling. Starting cool on my RV2 is: root@orangepirv2:~# uptime;cat $(find /sys -name temp) 18:55:15 up 0 min, 1 user, load average: 0.90, 0.25, 0.08 27000 28000 Now some work, will probably max out at 95° or so root@orangepirv2:~# uptime;cat $(find /sys -name temp) 19:23:11 up 28 min, 3 users, load average: 7.61, 6.79, 3.86 90000 90000 Stop compiling and wait a bit gives this which is fine IMO root@orangepirv2:~# uptime;cat $(find /sys -name temp) 19:35:07 up 40 min, 3 users, load average: 0.00, 0.64, 1.81 56000 58000

Thank you. Looking forward to all these contributions hitting the main branch so I can depend on the standard edge and current builds!

That's not bad honestly. The K1 series runs hot in general. If you add heavy lifting to thee equation it would require a fan. I have the MusePi Pro and BPI-F3 and both run hot.

The patch brought the idle load average drastically down on the R2S from 2.0 to 0.18. However the temp remains at 57-58 deg C. orangepi@orangepir2s:~$ cat /sys/class/thermal/thermal_zone1/temp 56000 orangepi@orangepir2s:~$ htop orangepi@orangepir2s:~$ cat /sys/class/thermal/thermal_zone1/temp 57000

I think the onboard fan is not being controlled correctly. root@rock5b01:~# dmesg | grep -i fan [ 6.577344] pwm-fan pwm-fan: Looking up fan-supply from device tree [ 6.577352] pwm-fan pwm-fan: Looking up fan-supply property in node /pwm-fan failed [ 6.581563] thermal_sys: Failed to bind 'soc-thermal' with 'pwm-fan': -22 [ 6.581571] thermal_sys: Failed to bind 'soc-thermal' with 'pwm-fan': -22 [ 6.581574] thermal_sys: Failed to bind 'soc-thermal' with 'pwm-fan': -22 [ 6.581577] thermal_sys: Failed to bind 'soc-thermal' with 'pwm-fan': -22 Running: Armbian v25.11.2 for Rock 5B running Armbian Linux 6.1.115-vendor-rk35xx

I patched that, am rebuilding and will post the R2S temps after that patch.

@Nick A Thanks for the reply. I don’t have enough Linux knowledge, so should I just wait for your new release? My box isn’t an X96Q — it’s a generic no-name one — but after trying many, many images, I found that the version you compiled happens to work perfectly and runs smoothly. So far I haven’t found any issues (the only thing missing is Wi-Fi, but that’s not a problem with your build: SV6256P). Even other images made for X96Q LPDDR3 by different people have all kinds of problems. Another small issue: your current compilation option is fully preemptive scheduling. This option is not suitable for server use. I suggest changing it to voluntary preemption or non-preemptive, thank you. The option of your images: CONFIG_PREEMPT_BUILD=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_PREEMPT_RT is not set CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPTION=y # CONFIG_PREEMPT_DYNAMIC is not set # CONFIG_SCHED_CORE is not set # CONFIG_SCHED_CLASS_EXT is not set

@maxsub yes and no. That 900*.patch never was meant to be in the Armbian repo, I wounder how this made it in the Armbian repo. Some black git magic... Patch experimentally rolls back an upstream change (...that removes the kthread under discussion and by this prevents the main CPU from communicating to the remote CPU). Upstream (the Fedora folks that emitted the SpacemiT code drops) has removed the kthread to prevent high CPU load b/c they use RV2 for their RISCV compile farm or so. The 900*.patch was an experiment by me to understand the impact on HDMI audio / ADMA). Long blabla. This proposed and committed change solves the issue for my pull RQ on the topic: https://github.com/armbian/build/pull/9299/changes/613737fab5aadc2d0a288a10a98aa0a433db4e76

Hi everyone, I have a Multilaser tablet with the Allwinner A50 chip and I wanted to compile a DTB file for it, so I could boot Armbian, but I haven't found anything on the internet about PIN MAP or anyone who has worked with this chip. Also, it already has an unlocked bootloader. I really wanted to do a project with this tablet, as I'm a student at the Federal Institute and it would be a great project!

Is this specific patch that reverts the busy looping thread? https://github.com/armbian/build/commit/99ad08839eed42d647e716a3ed090ea318d01d2e

What was already tested: UEFI x86 KDE Neon, Gnome, Ubuntu minimal MusePI Pro Xfce Odroid M1 KDE Neon Odroid N2 Xfce https://paste.armbian.com/oqegebaqey Orangepi 5 Nanopi M4V2 Odroid M2 Radxa E54 Rock 5C Orangepi 3LTS

I managed to get some USB-C functionality back by adding a device tree overlay. cat odroid-usbc-fix.dts /dts-v1/; /plugin/; /* 1. Force the USB controller into Host mode */ &{/usb@fc000000} { dr_mode = "host"; status = "okay"; /delete-property/ usb-role-switch; /delete-node/ port; }; /* 2. Target the specific USB3 Type-C regulator by its absolute path */ &{/regulator-5v0-vcc-usb3-typec} { regulator-always-on; regulator-boot-on; status = "okay"; }; /* 3. Target the USB3 Host regulator by its absolute path */ &{/regulator-5v0-vcc-usb3-host} { regulator-always-on; regulator-boot-on; status = "okay"; }; However this disables OTG and devices with strict udev switching timing requirements fail to switch. So my QHY CCD camera is correctly detected as a westbridge device and udev / fxload commences loading the firmware but the power to the device is toggled and the firmware load fails as a result. If I plug the QHY CCD in to the USB-C port via a powered USB-C hub then everything works fine. This works because the HUB is providing constant power. So there appears to be a lot of difference between the Radxa USB-C and Odroid USB-C implementation that will need someone better at kernel stuff than me.

As a followup: we have some help from @c0rnelius who digged out a solution to that kthread=high load issue (see latest commit / patches in my branch on https://github.com/sven-ola/armbian-build/tree/orangepi-rv2). Maybe this helps for the R2S too?