Active threads

Here are a few generic tips to consider: - Going to something industrial grade is always good. mean-well would be entry-level here - Phone chargers are not good for powering SBCs. They're designed to handle constant load while SBCs draw is variable depending on load. - Usually SBCs prefer slight overvoltage. So it is usually not an issue to feed them with an PSU that outputs 5.1 or 5.2 volts since this compensates for losses across wires, connectors and the PCB anyway. I personally have a mean well HRP-200-5 which powers all my sbcs but would be way too much for a single one. Official chargers from Raspberry or Orangepi would do too since they already come with slight overvoltage by design.

# dpkg -L linux-u-boot-nanopi-r6c-current | grep platform_install.sh /usr/lib/u-boot/platform_install.sh that script writes the uboot binary

Armbian doesn't support TV Boxes. Read the following to understand the status of Armbian and TV Boxes:

Most SBC backup tools I have seen are based on rsync and they operate then on/with Ext4 filesystem. Is fine when you don't have complex servers and databases running. I am not sure about pihole, but I saw that by default it keeps a 1 year history so a database file of about 1GB. I am not sure what happens to integrity of such a file on the target if during copy/rsync the source file also changes. AFAIK databases have their ways to handle it, when power-loss or so, but not sure. If you want to be sure, use Btrfs as filesystem, then you can make atomic snapshots and use those for source of rsync or use: btrfs send -p <old snapshotnumber> <snapshot number>| ssh <remote_host> btrfs receive <backup folder>. That is the basic manual option. Complete tool is btrbk, it is standard in Debian repo, see https://digint.ch/btrbk/index.html docs of author. You still need some partition and bootloader handling I think. Or assume that a total crash is rare so only backup to NAS or so and reconstruct manually if you need a new SD-card or so or want to copy thing so eMMC of the OPi3.

Thank you, i have verified that now Panfrost is there in kernel but it seems to use it i have to build a mesa with gallium (Panfrost) myself.

Thanks for the info and the PR link. So the fix is in the works but not merged yet — any idea how long it might take to land in nightlies or mainline? Should I keep the thread open until then, or just close it and reopen if needed after testing? Thanks again.

Ver 20250627-edge kernel 6.16-rc3

Armbian doesn't release this old LTS release now, but you can build one from github.com/armbian/build Yes, flatpak version is using ffmpeg in its own sandbox without rkmpp support, if you build the deb locally, it will get linked with ffmpeg on system which has rkmpp support.

I am a new user to Allwinner T527 SOC in OrangePi 4A.... The SBC is great for general purposes but VPU really sucks. On the other hand my RK3566 SOC in OPi3b & Radxa Zero 3E shines when using JellyFin or Chrome

They are in the same pin numbers, but different GPIO

Since this issue is well over a year old, I'm not sure where you stand with this. Are you still looking to get a fix? If so, answering all of the questions asked would be helpful. When you say "broke again" what do you mean by broke? Apparently the box is running and you can update it as you continue to update it per the message above saying you have upgraded to 6.12.32. Have you tried a fresh image installed on a new SD card to see if that works (vs. your upgraded system)?

Any fixes for this? Some rock chip ICs need custom PCie overlay to set pcie speeds, maybe the kernel just has it set to gen 2? 0001:11:00.0 Non-Volatile memory controller: Micron/Crucial Technology Device 5421 (rev 01) (prog-if 02 [NVM Express]) Subsystem: Micron/Crucial Technology Device 5021 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 126 Region 0: Memory at f1200000 (64-bit, non-prefetchable) [size=16K] Capabilities: [80] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 unlimited ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS- LnkCtl2: Target Link Speed: 16GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+ EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: Upstream Port Capabilities: [d0] MSI-X: Enable+ Count=9 Masked- Vector table: BAR=0 offset=00002000 PBA: BAR=0 offset=00003000 Capabilities: [e0] MSI: Enable- Count=1/8 Maskable+ 64bit+ Address: 0000000000000000 Data: 0000 Masking: 00000000 Pending: 00000000 Capabilities: [f8] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100 v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [110 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=10us PortTPowerOnTime=300us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns L1SubCtl2: T_PwrOn=10us Capabilities: [128 v1] Alternative Routing-ID Interpretation (ARI) ARICap: MFVC- ACS-, Next Function: 0 ARICtl: MFVC- ACS-, Function Group: 0 Capabilities: [1e0 v1] Data Link Feature <?> Capabilities: [200 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [300 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [340 v1] Physical Layer 16.0 GT/s <?> Capabilities: [378 v1] Lane Margining at the Receiver <?> Kernel driver in use: nvme

Ok. I've played around with several of the installs on the front page for Rock 5 ITX. It seems that the Rockchip BSP kernels are important, that and configuring pulseaudio correctly, it isn't configured correctly out of the box. It's the "headphone" card entry you need to set as the audio sink for some reason. And you need to turn the volume all the way up. But if you do those things, you get adequate audio. It's not perfect, it spits and pops but it works. Here's the armbianmonitor -u URL for a *working* install - https://paste.armbian.com/lefimociki Again, I'm pretty sure it has something to do with the Rockchip BSP, kernel related patches or blobs.

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.

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

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/

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