Active threads

No, I didn't change a thing. Things just break after upgrading. Today I did sudo apt-get update and apt-get full-upgrade after many months of not using the box, and broke agian. The kernel is now 6.12.32 and I can see that /boot/dtb/amlogic got updated to a June 4 date. sudo rfkill list shows nothing.

Thank you - I should have checked w/ df. The reason is that /var/log is mapped to /dev/zram1 which is 47M for my system and auditd.conf requested space_left=75 (MiB, that is). I changed this to space_left=25% and admin_space_left=5%. No it starts to log something at least.

This needs to be enabled: https://github.com/armbian/os/pull/332 As we started with a model without HDMI port, this was simply overlooked. Build with: ./compile.sh ENABLE_EXTENSIONS="v4l2loopback-dkms,mesa-vpu" That I don't know how it works if at all. Wayland is troublesome even on 1st class x86 hardware. Update: will rebuild images later today with mesa extension enabled.

Hi all, I am new to kernel development, and I found an old ASUS tinkerboard. I want to give it a second life with some fun projects. The project I am building is another IP KVM, so I bought an HDMI to CSI module. After tinkering around for a while, I found I supplied the wrong clock for that module: [ 8.469299] tc358743 2-000f: unsupported refclk rate: 50000000 Hz [ 8.483069] kernel BUG at drivers/media/i2c/tc358743.c:593! I have no idea about the clock value to put in the dts file, so I just copied some values from the ASUS kernel source. From the driver code drivers/media/i2c/tc358743.c, it shows that there are only 3 valid clocks: switch (state->pdata.refclk_hz) { case 26000000: case 27000000: case 42000000: ... default: dev_err(dev, "unsupported refclk rate: %u Hz\n", state->pdata.refclk_hz); ... However, the clock values used in the dts file are some pre-defined macros: # dts configuration clocks = <&cru SCLK_VIP_OUT>; # include/dt-bindings/clock/rk3288-cru.h that contains the `SCLK_VIP_OUT` ... #define SCLK_CRYPTO 125 #define SCLK_MIPIDSI_24M 126 #define SCLK_VIP_OUT 127 ... I wonder if some folks have experience with the clock setting and can help me pick the correct value. Thank you.

Technically a DTS is specific to a kernel version. As changes happen to the kernel apis, those need to be reflected in the DTS's. So they DTB and kernel image are always built and shipped together. Now in practice changes that impact the DTS aren't common, so you can usually use DTS's accross kernel versions. However in this case, I'm assuming that when you refer to 6.1 that is a vendor kernel, and 6.10 or greater would be mainline kernel. Now these are two very different code bases. A vendor kernel is whatever the board/cpu vendor hacked together to get a kernel running on their hardware. Often these are more android kernel based. When features finally get rolled into mainline, their implementation is often completely different. Thus one can't share a DTS between a vendor kernel and a mainline kernel. But often you can use the vendor DTS to gather information about what needs to be implemented in the mainline DTS.

Hi @fabiobassa, Until recently, I thought that the TTY serial port and the SSH terminal were the same thing, just the different forms of communication! I learned how to use SSH here, it helped me a lot with remote access, which I didn't know about. A few days ago I was even trying to find out how the serial port works, even though I don't have the TTY USB adapter, I have Arduino boards here, Nano and Uno, could I use them as an adapter? Could you give a brief explanation of how it works? I'll try to do it, because just as SSH was very useful, I believe that this communication via the TTY port is more important for diagnostics! I'm grateful for the dedication of all of you who maintain this forum, thank you very much! P.S.: I'm using the oscilloscope, and I can't find the memory clock pin that enables markrom mode, and I didn't see a signal on the serial port!

@KrzyPac You apply the patch to the kernel source-tree, In this case we will use meson64 as an example. Add the patch to: patch/kernel/archive/meson64-6.12/ Enable in the defconfig: echo "CONFIG_OPENVFD=m" >> config/kernel/linux-meson64-current.config Build a new IMG or KERNEL as one normally would for your unit. general-drv-auxdisplay-Add-openvfd-driver.patch

spi1-cs0-pin and etc are defined in .dtsi file , since they are physical pins of the H616/H618 chip. But they are assigned to different pins of 26-PIN and 40-PIN of Zero3 and zero2w

This might be about PCI-E bifurcation not working or can also be something mixed up with other SERDES ports. ROCK3A just uses 1x PCIe3x2-lanes (for NVME) but the R5C 2x PCIe3x1-lanes. The second lane might not be enabled or the 1st 2.5GbE chip might get 2-lanes allocated. And/or any other mix-up, but less likely I think. If the USB3 ports work and also if you have a working M.2 E-key WiFi, it is likely that bifurcation not working. For my ROCK3A I have to use original Radxa U-Boot and Armbian vendor kernel 6.1.x, otherwise It doesn't do what I want. So you might use other U-Boot and other kernel. Or just the FriendlyElec OpenWrt based image, but that is not easy generic Debian Linux. For my R6C I got Armbian userspace/rootfs working with Armbian mainline based kernel was about 17 months ago. Also with Armbian vendor based kernel. I see in Armbian Bookworm with beta repo: # apt list | grep u-boot-nanopi-r5c linux-u-boot-nanopi-r5c-current/bookworm 25.8.0-trunk.244 arm64 linux-u-boot-nanopi-r5c-edge/bookworm 25.8.0-trunk.244 arm64 You can do similar grep for kernels. Install an alternative and see on which U-Boot it is based. Or maybe first pick an older image from archive. At least you must know what U-Boot and what kernel. For my ROCK3A i tried 3 U-Boot binaries and also 3 kernel flavor, so many combinations possible.

i use ARMBIAN_20.10_Arm-64_buster_current_5.9.0 and i use ARMBIAN_20.10_Arm-64_focal_current_5.9.0 Maybe the dtb file Is not good ?

Hello @alg_42 You have only 1 GB of space in /tmp. This is tmpfs, so it uses your RAM. It is not enough to unpack your backup into. You can increase the size but the Pine64 either has only 512MB or 1GB of RAM, so that is not a good idea. I suggest you temporarily deactivate the /tmp mount instead, reboot, complete your backup and then reactivate the /tmp mount and reboot again. Armbian puts /tmp on tmpfs so that the frequent writes to it do not wear out your flash so it is important you reactivated it later on and don't leave it on your main partition indefinitely. Can you share the output of "grep tmp /etc/fstab" with us?

I'm, using one of those CH340 based usb-uart dongles https://www.aliexpress.com/w/wholesale-usb-uart-ch340.html but that normally most usb-uart dongles would work https://www.aliexpress.com/w/wholesale-usb-uart.html just make sure to check that it has / uses 3.3V io levels. Not 5V io levels as that may damage the processor (cpu / soc) for the pins connection review the user manual http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-Zero-3.html it is the 3 pins labelled Debug TTL UART on their board photo http://www.orangepi.org/img/zero3/0627-zero3 (6).png --- off-topic: for these small boards, I've basically stopped running them with an LCD monitor and keyboard as I find it a hassle as I'm using a desktop PC and trying to share the monitor. I mostly use them 'headless' using the usb-uart port. And in fact, after you setup the network appropriately e.g. set a static IP address or install avahi, the usb-uart console is no longer needed for static (fixed) IP address it is covered in the networking guide https://docs.armbian.com/User-Guide_Networking/ for avahi (MDNS) > apt install avahi-daemon avahi-utils edit /etc/avahi/avahi-daemon.conf [publish] publish-workstation=yes you can find the board on the ethernet over MDNS e.g. https://github.com/hrzlgnm/mdns-browser and you can ssh into the board over the network, e.g. using putty https://www.putty.org/

There is no moonlight-qt packaged in this ppa for noble, you can build from source: https://salsa.debian.org/amazingfate/moonlight-qt

Is there any trick to make use of the integrated fan on Radxa 25W PoE Hat? I'm using 4GB Radxa Rock 5C Lite Armbian_25.5.1_Rock-5c_bookworm_vendor_6.1.115_minimal Some guides mention that one should enable an overlay. I didn't find any relevant overlays in armbian-config. In the Radxa repo I found rock-5a-radxa-25w-poe.dts which specifies that it's also compatible with Rock 5C. I've compiled it and enabled it, but by default the fan is not spinning (on high temps) and I'm not sure how to investigate that. Also, does it matter that I have 5C Lite? As it has another chip: RK3582

Thats the Plan I just wanted to update my fork first in case any problems occured before submitting. Just wanted to check, seeming as I am covering 2 areas (dts patches and drm patches) would you still prefer this to be in a single commit? The original purposing being to add hdmi support for the Pcduino2 and Pcduino3, but evolved due to the drm breakages.

In collaboration with Inria, the French Institute for Research in Computer Science and Automation, Tathagata Roy shares the progress made over the past year on the CoccinelleForRust project, co-sponsored by Collabora View the full article

nope, just checked.

This is an awesome effort from you all! I purchased a v3. 1 2gb ddr3 version off ebay for 25usd and tried out the mate graphical image and it worked like a charm. Just some feedback for you all and others like me that read this forum. 996mb ram I think it is as reported by other users also. Vulkan graphics seem to be working, WiFi and usb ports all working out of the box. Bluetooth appears but I didn't try to connect to any devices yet. I even tried the tiny stories 656k ollama llm to see if that would work and its pretty fast with some bad stories haha even the 1b parameter model loaded but it's barely working. I will try llama.c next to try get some. Kind of acceleration from the gpu. Supertuxkart runs very smoothly. I installed on a 32gb SanDisk tf card with no worries flashing using etcher. It's quite a capable little machine. I even managed to compile a game I'm building at the moment for Linux + dos called deadseas which runs rather well. I havnt tried sound or anything yet as I'm direct into an old monitor via hdmi > dvi. So much better than the stock Android that the x96q comes with. Anyway thanks for your efforts!

Im currently trying to implement gpu support, but ive been stuck on the same error since a few days. Heres my armbianmonitor -u output: https://paste.armbian.com/uforekotuw root@radxa-cubie-a5e:~# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary domain status children performance /device runtime status managed by ------------------------------------------------------------------------------ pd1_gpu off-0 0 pd1_pcie off-0 0 pd1_nand off-0 0 pd1_de off-0 0 pd1_vo1 off-0 0 4510000.ethernet suspended 0 SW pd1_vo0 off-0 0 pd1_vi off-0 0 pd1_ve off-0 0 pd_riscv off-0 0 pd_sram off-0 0 pd_npu off-0 0 pd_dsp off-0 0 dmesg | grep -i "gpu\|mali" [ 1.836128] panfrost 1800000.gpu: clock rate = 432000000 [ 1.848131] panfrost 1800000.gpu: gpu soft reset timed out, attempting hard reset [ 1.858262] panfrost 1800000.gpu: gpu hard reset timed out [ 1.858486] panfrost 1800000.gpu: Fatal error during GPU init [ 1.858674] panfrost 1800000.gpu: probe with driver panfrost failed with error -110

Not yet, i'll try to contact him ! Thank you very muych

Success story: https://forums.raspberrypi.com/viewtopic.php?p=2322591#p2322591 with the 3.5 inch ili9488, graphics (wayland) and touch in raspberry pi 3b I hope this helps with making it work in orange pi zero 3 and 2w (only touch missing)

All good now?

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Added instructions for joining your home lab: https://docs.armbian.com/WifiPerformance/#adding-a-new-device

That should make it. You can always try to see if it works and search online if not.