All Activity

wich OS system Windows balenaEtcher, linux "dd" , do you perform checksum

Expected. current had a bare minimum of hdmi support before it became recent LTS kernel. Therefore no fixes will hit there until rollover to next LTS. Needs to be enabled. Either enable panthor overlay (the mainline panthor driver was backported to vendor kernel but is disabled by default) and install more recent mesa packages (depends on userspace). Or install proprietary mali blobs. Having or building an image with mesa-vpu extension enabled handles that for you. There is no automatic method of installing afterwards yet. https://github.com/armbian/apa/issues/20

hello. Do you resolve this issue? I am struggle with CSI camera in orange pi 3b. but it does not work. How to enable CSI and camera. Can you help me? thanks

The board I have has a different Rockchip SoC (rk3588-orangepi-5-plus), but it's been my experience that the edge kernel (6.16) is the only one that's of any real use to me. I get no video with the "current" (6.12) kernel, and no GPU acceleration with the vendor (6.1) kernel. So I would suggest just switching to the edge kernel.

On the OrangePI-5-Plus, using an edge kernel, I've found that the desktop environment's GPU rendering works very smoothly on Wayland, in KDE 6 on Debian Trixie. It renders much more smoothly than gnome with Wayland (it's been my experience that the edge kernel is the only one that works). But I've encountered a major rendering bug. It only appears in Trixie KDE Plasma 6 with Wayland rendering. It does not appear when using x11 or when using either rendering in gnome. Nor does it appear at all in Bookworm. I have tried all kinds of things to "fix" these to no avail, including installing more wayland and mesa packages, then upgrading them to stable backports and then even to unstable testing (forky) versions. I've also tried the Debian unstable edge kernel from testing (6.16.3) as well as the Armbian stable edge kernel (6.16.4) with the same results. I installed Debian Trixie using the Debian .iso installer (w/ EFI boot), then upgraded to their edge/testing kernel (6.16.3) from their testing/forky repository. The bug showed up in pure Debian without a drop of Armbian. Then I installed the Armbian stable edge kernel (6.16.4) to replace the Debian edge/testing kernel in that installation. The bug remained. The rendering bug also showed up in the release version of Armbian Trixie 25.8.1 using the Armbian edge kernel. KDE 6 Wayland Render Bug Symptom: The [ALT-TAB] Task-Switcher's Text Labels (see screenshot #1) The major place this bug shows up is in the task switcher (using ALT-TAB). The window labels, instead of rendering as textual fonts, they render as blocks. I tried several things with the fonts, from changing their type and size, turning on/off anti-aliasing, to changing the desktop themes, and so on. I also tried using different "task switchers" from the list. All I got were the same blocks -they just appeared in different sizes and positions with no other changes. So I'm reasonably sure the rendering issue has nothing to do with fonts, desktop themes, Plasma settings, etc. KDE 6 Wayland Render Bug Symptom: glmark2 (x11) verses glmark2-wayland (see screenshots #2 and #3) Using the command-line utility: glmark2, there's an x11 version and a Wayland version. The each render to an 800x600 window. Normally the only visual difference between them is that the Wayland version has no window borders around it. But with this bug, the Wayland version renders significantly smaller on the screen, and also at a significant performance reduction (>50%). Conclusion I already know it isn't an Armbian issue. I don't believe it's a kernel issue either. I'm reasonably sure it has nothing to do with fonts, themes, or Plasma settings. In my internet searches, I have found no other reports of this specific rendering bug that I think are relevant to whatever is happening now. I did find some vague statements about there still being some "issues" with rendering in the upgrade from KDE 5 (using QT5 libraries) to KDE 6 (using QT6 libraries). I also read that KDE Plasma 6 has a somewhat unique interface or relationship with Wayland and uses its own protocols with it. I think this explains why the bug doesn't show up in gnome, and also helps to isolate, to a degree, where the bug actually is. From what I've read, apparently this issue shows up differently on different systems? It is my impression that these specific symptoms of this bug may be unique to this hardware (Rockchip rk3588 SoC) or GPU (MALI-G610 (built-in)), even though it is a clearly a software bug. P.S. I just ran Fedora's KDE Plasma 6 image. There were about a thousand updates to run on it. Plasma 6.3.4 (think) upgraded to version 6.4. And their mainline kernel (6.14 upgraded to 6.16.7 I think). The rendering bug I mentioned here did not show up either before or after those updates. So it appears the issue isn't with KDE Plasma itself either, that it's apparently on Debian's end. I noticed some of the (Debian) packages are specifically to bridge 5 and 6. I would guess that's where the problem is - apparently they didn't make a clean break. Screenshot #1: [ALT-TAB] task-switcher Screenshot #2: glmark Screenshot #3: glmark-wayland

Hi there, To make it more clear: On PC1: [As administrator] Add a route/hop via 'rocky linux' for packets destined for 10.10.10.0/24 https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/ route ADD 10.10.10.0 MASK 255.255.255.0 192.168.100.101 On 'rocky linux' Raspberry Pi: Enable IPv4 forwarding: sudo sysctl -w net.ipv4.ip_forward=1 Add masquerading for NIC2 (10.10.10.1): sudo iptables -t nat -A POSTROUTING -j MASQUERADE -o enp4s0 Or use the firewall-cmd thing, which you posted: sudo firewall-cmd --zone=public --add-masquerade Then try to ping 'device 1' from PC1 once more. The traceroute should show nexthop to be 'rocky linux' for any IP address in the range 10.10.10.0/24 if you configured the route/hop on PC1 correctly. Groetjes,

Hi there, Ah so PC1 is windows based? You need to set the route to 'rocky linux' on that box. Some googling shows you can add a route on windows: https://www.howtogeek.com/22/adding-a-tcpip-route-to-the-windows-routing-table/. I do not have any Windows PCs around to test this out though. Is your goal to only ping 'device 1' ? I presume that you have other things in mind that just pinging 'device 1' ? Another route you can try is to connect from PC1 to a specific port on 'rocky linux' and then have that port traffic forwarded/NATed to 'device 1'. Have not done that myself ever, but let's see. Groetjes,

Arhhh still no good. PC1 still can NOT ping 10.10.10.2 root@rpi4b:~# ip route show default via 192.168.100.254 dev eth0 proto static metric 101 10.10.10.0/24 dev enp4s0 proto kernel scope link src 10.10.10.1 metric 100 169.254.0.0/16 dev enp4s0 scope link metric 1000 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.101 metric 101 root@rpi4b:~# anything needed for ? net.ipv4.ip_forward=1 ? note: NIC2 and Device 1 have no gateway.. dont think it matters right ?

Hi there, Not sure about the syntax of `firewall-cmd`, but you should only masquerade on the NIC connected to the 10.10.10.0/24 network, as masquerading does have some performance impact to/from that NIC. Seems you need to check which `zones` are defined and create a `zone` to only cover NIC2 on 'rocky linux'. For the `route` command, you can use the "new" `ip route` way: # type on PC1 sudo ip route add 10.10.10.0/24 via 192.168.100.101 This will tell PC1 to throw packets that are destined to reach the 10.10.10.0/24 network towards 'rocky linux''s NIC1. No, masquerading is done on the destination address of the IP packet, it will not change any source/destination port number. Masquerade here uses NAT, port is not translated. Groetjes,

Problem with the multitool I'm trying to burn the multitool into the micro sd, but every time I try the disk go unallocated, can someone help me??

I have also installed firewalld any ports or routing i should allow ? eg : sudo firewall-cmd --zone=public --add-masquerade ?

@Nick A I fixed the wifi issue after warm reboot for x98h with this patch:

root@rpi4b:~# sudo route add -net 10.10.10.0/24 gateway 192.168.100.101 sudo: route: command not found root@rpi4b:~# Do i need to add dev eth0 or enp4s0 ?

Hi there, Ah that diagram changes things a little. You would need to add a route to PC1, so that it knows to send packets for device 1 via 'rocky linux'. sudo route add -net 10.10.10.0/24 gateway 192.168.100.101 That will make sure packets with destination 10.10.10.0/24 will be sent to 'rocky linux'. Then on 'rocky linux' the forwarding should handle forwarding those packages from NIC1 to NIC2. You will have NIC2 masquerade outgoing packets as 10.10.10.1 instead of the real source address 192.168.100.102, so 'device 1' will respond to 10.10.10.1 instead of 192.168.100.102 - as 'device 1' has no default route. Then on 'device 1', packets will arrive from "masqueraded" NIC2 10.10.10.1 and it should respond accordingly. Then on 'rocky linux' responses from 'device 1' will be received on NIC2, conntrack will know where the packet originally came from and send stuff back to 'PC1' This should work, but this is a little messy 🙂 Do ping back here! Groetjes,

Hi all. Thank you all for helping on this. I have created a diagram. - Armbian not rocky. the red box is what I CAN NOT change - no access. I do have access to the Linux box - so I want to be able to ping from PC 1 to Device 1 on 10.10.10.2. Device 1 - do have access to it and configure whatever it needs.

Hi everyone, I need to enable the csi camera and i2c port on my zero3 development board. When I click on the management overlay, an error occurs. Is there any solution?

Hi there, The `net.ipv4.ip_forward=1` will make the packets coming in on NIC1 be routed/sent to NIC2 due to the destination fitting in the network, but the device on NIC2 will not know how to send return packets to 192.168.100.*/24 as it does not have any fitting directly connected networks. Usually you could use default gateway/route to point them back to the Pi, but you said you cannot configure that. Try the following on the Pi: sudo iptables -t nat -A POSTROUTING -j MASQUERADE -o enp4s0 That should enable NAT on NIC2, which will masquerade any packet sent from NIC2 with "source address" 10.10.10.*/24 which it does know how to talk to. Btw, can you confirm the following was indeed the output of `ip route`: 10.10.10.10/24 dev enp4s0 proto kernel scope link src 10.10.10.2 metric 100 One would expect 10.10.10.0/24 as network instead of 10.10.10.10/24. Groetjes,

Dear Armbians, I'm thrilled to announce the launch of this digest for our amazing community. For newcomers, Armbian is a lightweight Linux distribution that breathes life into ARM-based single-board computers, transforming tiny, affordable boards into powerful servers, workstations, and IoT devices. This newsletter is our way of keeping you in the loop, sharing the latest releases, celebrating community contributions, and diving into the technical insights that power your projects. Whether you're a tech enthusiast or just getting started with your first Orange Pi, there's something here for you. Thanks for being part of this incredible journey! Igor Armbian project manager View the full article

moved

Hi all, I’m running Armbian 24.5 (Ubuntu Jammy CLI) on an Orange Pi 3 LTS with kernel 6.6.y, trying to use a CH341A Mini Programmer to flash an SPI EEPROM chip. But I’m stuck, the programmer isn’t detecting the chip at all. Connected the module to the chip using the correct pins (CS, MOSI, MISO, CLK). Powered the chip at 3.3V to match Armbian’s logic level. Used flashrom on Armbian (via terminal) to detect the chip, but it returns “no device” or similar errors. Tried different USB ports, different cables , same result. Do I need to match some specific SPI mode or speed for Armbian or for specific EEPROMs? Is there an issue with voltage levels or pull-up / pull-down resistors that often catches beginners? Any recommended OS commands/logs to check so I can see what’s going wrong (e.g. permissions, USB detection, lsusb output)? Thanks in advance for your help!

tag adjusted

Hi Werner I apologize for radxa zero, as I do not know which tag to choose. I have a board based on OK3568 from Forlinx. Logs https://paste.armbian.com/ohokuhozab

Hi there, the 2 NICs are on my RPi Armbian. ip route output. > modified it abit to match but concept is below. default via 10.10.10.254 dev enp4s0 proto static metric 100 169.254.0.0/16 dev enp4s0 scope link metric 1000 192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.10 metric 101 10.10.10.10/24 dev enp4s0 proto kernel scope link src 10.10.10.2 metric 100 I have only PC1 connected to NIC1 with 192.168.100.101 GW - 192.168.100.254 This PC1 can NOT be changed. Device1 on NIC2 10.10.10.100/24 < this have no Gateway as its only a slave device. I need to reach Device1 on NIC2 from the PC1 on NIC1..how is this achieved? I tried /etc/sysctl.conf net.ipv4.ip_forward=1 still missing something… I failed to mention is that I can only modify settings within the Linux box containing the 2 NICs. I need some sort of interlinking NIC1 on 192.168 to forward packets to 10.10 network…

Can't say I know much about X11, but after playing around with the Cinnamon version I did get a desktop by: created file:/etc/X11/xorg.conf Section "Device" Identifier "Device0" Driver "fbdev" Option "Device" "/dev/dri/card0" EndSection So I figure something in the configuration or driver related ?. And that goes for all Debian flavors I tested. All gave the same error.

Hi there, Not sure if your question is complete, are both NIC1 and NIC2 in the same PC1 ? (NIC being network interface controller/card.) If NIC1 and NIC2 are both in the same computing node, the routes should be there already, if the configuration is plain and not something funky. Can you share the output of `ip a s` and `ip route` ? Also, do you have any firewall enabled? Gr,