Active threads

Hi, I would like to share my recent work: a cheap USB Audio Class 1.0 (UAC) input to UAC 2.0 output converter. For folks that may not understand why I have this crazy idea, here is the background: For some shitty reasons, PS5 does not support outputting audio through certain USB sound card, and that is because PS5 only supports very old USB sound card (UAC 1.0), and usually high end speakers or sound cards would use newer, better UAC 2.0 protocol. So, this shitty thing happens to me, when I thought my EDIFIER S880 speaker would be a plus for my gaming experience. EDIFIER S880 has a UAC 2.0 in input source, so my PS5 does not support that. So, what I can do is to use another 3.5 jack to connect the speaker to my PS5. Unfortunately, there is a staticky buzz sound throughout this channel. What's even worse is that EDIFIER S880 has 6 input source selection, but I can only switch to the next source, wait for 2 seconds, and repeat this process 5 times every time I want to switch the audio from my computer to the PS5. After lots of trials and flashing my custom kernel, I finally did it! The idea is to use a board that has 1 USB otg port to act as a UAC 1.0 sound card, and has another 1 USB host port to connect to the UAC 2.0 speakers, then run programs on that board to redirect sound from USB otg port to USB host port. It is even a plus that the board consumes less power, so we do not need an extra or special power supply for it; this becomes crucial, especially when sharing the same USB connection with the USB otg port (SBC boards are more power-hungry these days!). The standard USB 2.0 protocol only allows 5V 0.5A to the device connected. I actually built one with an Orange Pi One board, but it turns out that the CPU is not fast enough, and there are sound glitches sometimes. With some research, I found this board that perfectly fits my needs: Radxa zero 3W. Here is the advantage: - It is cheap, and the one I used is the nearly minimum SKU (1 GB ram with 8 GB onboard eMMC, they also have no onboard eMMC SKU). - The otg port could handle USB PD protocol, meaning no special hacks are needed, you could get at most 30W of power, if needed (and turns out the normal USB 2.0 port on my PS5 works perfectly, so I guess it consumes less than 5V 1A = 5W) - It is tiny. However, things don't work right out of the box. At the beginning, I flashed the official, latest Radxa OS, modprobe the g_audio. It is running as a UAC 2.0 device, so it is not the one I want. As a result, I grabbed their kernel source, changed the config to UAC 1.0 gadget, and flashed onto the board, but there seems to be some issues in their kernel fork for UAC 1.0 driver: there was no /dev/snd/controlC0, so the g_audio failed to run. As a result, I turned to use the Armbian build. This time, the /dev/snd/pcmC0D0c is missing, so g_audio failed to run again. I then compiled my own kernel, flashed it onto the board. The Armbian build is with kernel 6.1, and the kernel I built is kernel 6.12, then the board failed to boot to the kernel due to U-Boot thought there were some errors. Luckily, I found that building the whole Armbian image with kernel 6.12 can boot without issues, so I built a custom kernel 6.12 with UAC 1.0 enabled image, modeprobe the g_audio module, and it finally worked! After that, I crafted a simple golang SystemV daemon for bootstrapping and terminating the alsaloop program for redirecting the sound, and used a udev rule to notify that daemon of the attachment/detachment of the USB speaker out event. The converter is finally working! Here is the pre-built image for folks who want a quick test. It is based on the commit b27c86e620dcd9f55daadf52ccc85643dba2a381 from the armbian build repo with the following config modification: diff --git a/config/kernel/linux-rockchip64-current.config b/config/kernel/linux-rockchip64-current.config index d053d0997..6e360bba7 100644 --- a/config/kernel/linux-rockchip64-current.config +++ b/config/kernel/linux-rockchip64-current.config @@ -3507,3 +3507,8 @@ CONFIG_RATIONAL_KUNIT_TEST=m CONFIG_MEMCPY_KUNIT_TEST=m CONFIG_TEST_MEMCAT_P=m CONFIG_MEMTEST=y + +CONFIG_USB_CONFIGFS_F_UAC1=y +CONFIG_USB_CONFIGFS_F_UAC2=n +CONFIG_USB_F_UAC2=n +CONFIG_GADGET_UAC1=y Currently, the "current" build does not detect the Wi-Fi interface, but as it does not affect the audio converting feature, I may not put too much effort into this.

I realize that OZPI v3 is supported by the community, but I would like to ask if anyone has information whether u-boot for OZPI v3 will be in version 2025.04 and is the estimated date known? Will armbian-config be fixed for OZPI v3 etc. problem using overlay-prefix in device tree? https://github.com/armbian/configng/issues/592

Please someone help I can't start X11... I installed: sudo apt install xserver-xorg-video-fbdev openbox x11-xserver-utils xinit xserver-xorg-input-evdev Created this /etc/X11/xorg.conf.d/99-fbdev.conf file And tried sudo startx, then the LCD got a black screen for a fraction of a second, and I got (in my ssh session) The error message is FBIOPUT_VSCREENINFO: Invalid argument I also see that xorg wants to use 24 bit color, but my LCD is 18 bit color. I will try to get X11 working again with the linux 6.13 build folders that worked for me in april

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 Update: I found that I can just use both CS0 and CS1 in opiz3 normally as expected in a DTS for a SPI ili948x LCD and touch screen, as seen in my ili9488 thread. (PH9=CS0, PC10=CS1) I was having so much trouble before, but now I finally got it

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?

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