All Activity

https://paste.next.armbian.com/yogopozufa

Hi, if you compile your kernel with "CONFIG_SUN55I_PCK600" set, you'll have the second ethernet port. But you'll loose the wifi adapter, just like in the trunk.129.

@Hqnicolas thanks for your feedback! It's appreciated!

@Berserker this is because you are using the out-of-tree https://github.com/jefflessard/tm16xx-display/tree/main which back port support to 6.6. Since you are using a recent kernel (6.16), you should use the in-tree patches that were submitted for upstreaming: https://github.com/torvalds/linux/compare/master...jefflessard:linux:tm16xx.patch The problem is that export namespace names changed from unquoted to quoted between these two kernel versions.

Hi @GmP, thanks for your detailed feedback. I think your previous permission denied issue was because you were using an older version of the driver with the current version of the display-service. Since you have reviewed the DT, I understand that you are now using the current driver version and that display-service is now working properly. Latest driver version now use line-display library (expected upstreaming requirements), therefore there is no more sysfs value attribute. This has been replaced with the line-display message attribute.

thank you for your work. i have the x96q pro picture attached. i have built the x96q lpddr3 and the w96q lpddr3 v1.3 . both are booting . the problem is with wifi sometimes is not recognised and it needs rebooting few times to work. also i noticed with lpddr3 build the cpu cores are always near 100% but with lpddr3 v1.3 only one core get 100% and not too often.

zero2 != 2w moved to staging

Alright so I am trying to use this OLED display: https://www.amazon.com/AITRIP-Display-SSD1306-3-3V-5V-Arduino/dp/B08JPYJ35Y?th=1 with Armbian(minimal) on my orange pi zero 2w, but I just cant get the i2c1 bus to detect it. Here's some more details: uname -r returns: 6.12.23-current-sunxi64 cat /boot/armbianEnv.txt returns: verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun50i-h616 rootdev=UUID=adb61282-df86-4116-9688-e94c56913687 rootfstype=ext4 overlays=i2c0-pi i2c1-pi param_i2c1_pin_sda=3 param_i2c1_pin_scl=5 user_overlays= usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u sudo i2cdetect -l returns: i2c-0 i2c DesignWare HDMI I2C adapter i2c-1 i2c mv64xxx_i2c adapter I2C adapter i2c-2 i2c mv64xxx_i2c adapter I2C adapter i2c-3 i2c mv64xxx_i2c adapter I2C adapter i2c-4 i2c mv64xxx_i2c adapter I2C adapter sudo i2cdetect -y 1 returns: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Here's a picture of the display: Here's a picture of the pin layout: VCC is going to 3.3v, GND to GND, SDA to pin 3, and SCK to pin 5 Thanks! Feel free to ask for more details!

Hello, idk if this the right place to ask, but, I'm really struggling to get a working driver for the sv6256p, I can't find a repository that compiles on kernel 6.X. My question is, where is the driver source that builds for the rk322x uses? I want to compile it on my installation. I already tried moving the driver files from a rk322x build to my installation, but it didn't work.

I am in the process of installing Armbian on the X88pro13 TV box, which has the RK3528 CPU. https://github.com/joilg/x88pro wifi and ethernet are working

@GmP oook, so now I understand the differences between the two dtso files provided here and in the other thread. Do you spot other differences or peculiarities? Things that are useful are: * the gpio led (do the separate red/blue/green led blinks on both boards?) * wifi reset gpio (do wifi get detected in both boards with base configuration?) * is there a separate PMIC like rk805/rk808 on any of the boards? Things like these go into the dtso for full board support. The PMIC is very important since missing that could cause stability issues.

I followed the "mesa route" without any kind of problem. I cannot following the "libMail route" due to my window manager choice: I installed the Armbian Ubuntu Noble version, but I'm running X Window (not Wayland) in order to get the remote display of the Orange PI Plus running on a local monitor; I tried to do this using Wayland without success. I'im running lightdm and xfce4 now. So the /dev/mail0 is still useful or the mesa-vulkan-drivers are enough ? I read some documentation about the hardware acceleration but in my opinion it is too contradictory. But it is always possible that I'haven't understand anything.....

@jock, sorry for the confusion actually there are two boards (two different TV-BOX) one (here in this post) is an rk3318-H50 as you say T98... using FD650, the other one is rk3318-T9 (only T9) using FD655. All the dtso files posted are correct: for the H50 (T98) in this post you have the versions for the old kernel and the new one. Same in the other post "HELP WANTED" for the other TV BOX. At the end the two latest dtso are valid for the latest kernel. One of the difference between FD650 and FD655 is that the first one has 4 digits but 8 segments (0-7) on the contrary FD655 drives 5 digits and 7 segments (0..6). DTSO files are configured accordingly and fully working. Hope it clarifies.

After wanting to use Debian 13 (Trixie) @Nick A suggested trying to build it myself, and this was my first experience building an Armbian image. I encountered some obstacles, but I got through them. I saw that the model was mentioned branch v20251014. I tried building it (Mate Desktop), which as build smoother than (v20250306) before. I tried booting it with this box (Transpeed 8K618-T) and and found that the wifi was not visible. I followed the troubleshooting methods in the previous thread solved it. I have installed additional IR remote and OpenVFD. Now everything is smooth and happy. The only thing left is the video acceleration, but that would be difficult because it is beyond my ability. Finally, thank you, @Nick A

Even though current is an LTS kernel it probably makes more sense to focus on vendor an edge. vendor because its rockchip bsp and close to being feature-complete. And edge for likely becoming the next LTS kernel which ultimately become current at some point. You can try to see what actually works on current at this time. You can ignore 6.15-6.17 since those patches, if still present, are for archival purposes only and will be remove at some point. In theory it could be re-used but may introduce confusion. If in doubt, copy and rename. Edit: Seems like lots of stuff has been mainlined already. So I suggest shifting your primary focus on edge.

@jock I didn't know the problem could be the watchdog, nor did I know about the existence of the open-source Trust OS. Do you think it's feasible to include the open-source Trust OS in this testing process, or does the open-source Trust OS solve all these problems? My idea wasn't to change it at runtime; my idea is to flash, reboot, test, save the result, repeatedly until all possible combinations are exhausted.

@Gian Luca Please try libMali route: + Flash Armbian 25.8.1 Noble Gnome (Vendor Kernel: 6.1.115) + Disable the Panthor overlay + Install libMali https://github.com/ginkage/libmali-rockchip/releases/download/v1.9-1-04f8711/libmali-valhall-g610-g24p0-wayland-gbm_1.9-1_arm64.deb + Install the WSI https://github.com/ginkage/vulkan-wsi-layer/releases/tag/v1.3.276-1-d48decd (for Wayland, XWayland only) mesa (Panfrost/PanVk) route: + Flash Armbian 25.8.1 Noble Gnome/XFCE (Vendor Kernel: 6.1.115) + Enable the Panthor overlay + Install the "mesa-vulkan-drivers" https://launchpad.net/~ernstp/+archive/ubuntu/mesarc (for both Wayland and X11)

Armbian 25.8.1 Noble XFCE (BSD Kernel: 6.1.115) + PanVk - mesa 25.2.6 (https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + wine-10.17-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.17) + DXVK-sarek-stripped v1.11.0 (https://github.com/pythonlover02/DXVK-Sarek/actions) ~30fps@720p Dark Souls: Remastered

Hi Armbian Community, I'm creating a board configuration for NanoPi Zero2 (RK3528A) and wanted to coordinate with the community before submitting. Great News: Mainline Support Exists! I discovered that Jonas Karlman has already merged NanoPi Zero2 device tree support into mainline Linux kernel: Device tree: rk3528-nanopi-zero2.dts (merged for v6.15-6.18) U-Boot support: Also merged Source: https://github.com/ziyao233/rk3528-mainline Since the hinlink-h28k.csc config already provides RK3528 support, creating a NanoPi Zero2 config should be straightforward. Quick Questions Is anyone already working on this? (Don't want to duplicate!) Kernel branch: Should I target current (6.12) or edge (6.15+) for the DTB? Bootconfig: Can I reuse hinlink_rk3528_defconfig or does Zero2 need its own? My Plan # Copy existing RK3528 config cp hinlink-h28k.csc nanopi-zero2.csc # Update: BOARD_NAME="NanoPi Zero2" BOOT_FDT_FILE="rockchip/rk3528-nanopi-zero2.dtb" KERNEL_TARGET="current,edge" Testing Commitment Hardware: NanoPi Zero2 arriving next week Use case: Production IoT device (headless, Docker, eMMC boot) Will test: Full manufacturing flow, LED control, eMMC boot, network, Docker Will contribute: Tested config + documentation Why This Board? Tiny form factor: 40×40mm Production-ready: Good margins, reliable supply Sufficient specs: 2GB RAM, eMMC, single GbE Mainline support: Thanks to Jonas Karlman's work! Any advice before I proceed? Happy to collaborate or take guidance from maintainers. Thanks! 🙏

That's probably the boot partition in fat32. You can't read linux partitions in Windows without tools. So it's normal you can't read an armbian image in windows since it doesn't use fat partitions. Why it doesn't boot is another case. I would try to build my own image with either legacy or mainline kernel. I don't have the board so no idea what works on it.

It is nog normal desktop images are not available. You can always install a desktop to server images. I use taskset for desktops that need a lot of dependancies. sudo apt install taskset sudo taskset For the xu4 there should be not much difference with the armbian desktop images except for the background image.

@GmP ok, so the leds in the previous dtso are wrongly addressed? Because in the latest dtso I see 7 leds addressed on segment 0, instead the previous dtso declares 4 sparsely addressed leds. edit: note also that your board is T98_RK3318, not T9_RK3318

@jock I have also tested the driver for a rk3318-T9, please see below in case it is useful for the device tree overlay.

Here you are the correct dtso for the latest version of the tm16xx / kernel. Note that this is not the same model of rk3328-t9.dtso found in https://github.com/jefflessard/tm16xx-display however I do think it will work with that model as well. The automatic generated dtso file for the rk3328 from vfd seems to be icorrect as it is addressing segment 7 of fd655. rk3318-t9.dtso

Hi, my feedback with rk3399-kobol-helios64.dtb-6.12.xx-L2-hs400-opp and agressif fancontrol setting like this: # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 FCTEMPS=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=/sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input MINTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=30 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=30 MAXTEMP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=50 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=50 MINSTART=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINSTOP=/sys/devices/platform/p6-fan/hwmon/hwmon6/pwm1=20 /sys/devices/platform/p7-fan/hwmon/hwmon5/pwm1=20 MINPWM=20 is: All it's Okok Without the tunning file DTB and Fancontrol, the nighmare restart. Today, update, original DTB file restore and CRASH when Luks begin to unciffer my DDs Il restore DTB file and my fancontrol setting and: Return to Okok situation. To conclude, i use my helios without problem when this files is installed. My helios64 always crash if i return to original setting after a update.