IBV

Correction to original post, I have  typo and did not put in "plug" for plughw.
aplay /usr/share/sounds/alsa/Side_Right.wav -D plughw:CARD=Audio,DEV=2  

Most likely P2P wireless, not necessarily functional. This is automatically present by a (wireless) kernel driver. Use the device that works and ignore the other. If bogus device gets to your nerves, dig into the code, find a way how to disable it and sent a patch.

In a groundbreaking development, the Armbian team has officially announced the Armbian Unified Kernel Initiative (AUKI), a revolutionary step towards simplifying Linux on ARM single-board computers. Starting with Armbian kernel v6.14, all previous kernel variants will be merged into a single, all-encompassing kernel that supports every single board and hardware feature out of the box.
One Kernel to Rule Them All
Gone are the days of fragmented kernel versions, custom patches, and hardware-specific quirks. With the new AUKI framework, users no longer have to worry about selecting the right kernel for their device—it just works. Whether you’re running an old Allwinner-based board or a cutting-edge Rockchip or NXP system, the same kernel will seamlessly handle all drivers, features, and optimizations.
UEFI Standardization for All Boards
The traditional ARM boot process has been one of the biggest pain points for Linux users, requiring board-specific U-Boot implementations and patches. Armbian’s new boot method fully adopts UEFI standards, making it possible to boot any supported board just like an x86 PC. This means:
Unified bootloader across all platforms
Secure Boot & TPM support on compatible hardware
Multi-boot from USB, NVMe, and SD cards with no extra configuration
Real-Time Kernel Switching
Armbian kernel v6.14 also introduces instant real-time kernel switching. Whether you need a standard kernel for everyday tasks or a real-time kernel for low-latency applications, you can now toggle between the two by simply adding a kernel command-line switch—no recompiling, no reinstallation. Users can also switch modes effortlessly via armbian-config.
AI & Video Acceleration—Out of the Box
For the first time ever, hardware-accelerated AI inference and video decoding will be universally available on all supported ARM platforms. Whether you’re using Mali, Vivante, or Adreno GPUs, your web browser will automatically leverage full acceleration for machine learning and video tasks—without the need for extra drivers or proprietary blobs.
Unmatched Performance: Instant Boot, 50% Speed Boost
Thanks to deep optimizations and contributions from over 1,000 developers, Armbian kernel v6.14 delivers:
Boot times under 2 seconds on most SBCs
50% overall performance improvement across the board
Enhanced power efficiency, extending battery life on mobile setups
Powered by the Bates Foundation

These remarkable advancements were made possible by the Bates Foundation, a nonprofit organization dedicated to funding open-source initiatives where traditional businesses and governments fall short. Their generous support has enabled a global team of 1,000+ engineers to bring this vision to life.

What’s Next?
The new kernel will roll out in Armbian’s next major release, with preview builds available starting today. Existing users will be automatically migrated via armbian-config. The future of Armbian—and ARM Linux as a whole—has never looked brighter.
The post Armbian Unified Kernel Initiative (AUKI): One Kernel to Power Them All first appeared on Armbian.
View the full article

Yes you could. I gave the UUID example out of habit, I do this on VM's where the disks are /dev/sdX and I want to make sure I get exactly the partition I want on boot in case the kernel/udev is messing the device ordering. In your case /dev/nmve0n1p1 should be fine for example.
You are right, you will need to move anyway the old /var contents to the new partition. In case you are able to mount the SD card on a Linux PC/VM, you could do that too before first boot. But maybe better to follow the procedure I describe later.
Probably the easiest would be to use a Linux VM (eg. VirtualBox). You can then use a usb SD card reader and pass it through to the VM.
My distribution does it (Ubuntu). 
Yes.
After flash the Armbian image, boot it. Allow it to reboot and expand the filesystem. Then:
- disable ram log (by editing the /etc/default/armbian-ramlog and setting ENABLED=false) then reboot
- make sure you have the root password (you can set one with "sudo passwd" if you don't have it)
- reboot in rescue mode (use the root password when prompted)
sudo init 1 - mount the NVME partition you want to use as /var in /mnt. FYI: This step is to move the existing /var data to the new location. You need rescue mode so no services run and write stuff in /var when you do the move. Examples below assume that the partition you want to use is /dev/nvme0n1p1.
mount /dev/nvme0n1p1 /mnt - move the data
mv /var/* /mnt/ - edit /etc/fstab and add a line with the /var mount. 
/dev/nvme0n1p1 /var ext4 defaults 0 2 If you want to use UUID's you can run "blkid" command and you will get the UUID's of all disks/partitions. You can then take the one of the nvme0n1p1 and use it with UUID=<your uuid> like I showed you in the first answer.
- Reboot
 

Hi,
 
theoretically if you knew the UUID of the partition on the NVME disk that you want to use as /var partition, you could do the following:
- after flashing the SD card with the Armbian image, put it in a reader (or a usb card reader) connected to  a Linux PC.
- the / partition on the SD card should be auto mounted
- you can go and then edit the etc/fstab file on the SD card and add a line like this:
UUID=<your UUID goes here> /var ext4 defaults 0 2 put the UUID of the partition you want to use as /var in the above line.
- boot your SD card
 
I am not sure how this will work with the ram logging, you should try it yourself.
 
If it does not work I can show you how to move the /var partition on the NVME disk after Armbian boots the first time (I have done this myself and it works). This involves
- ram log disabling
- reboot in rescue mode
- identify the UUID of your NVME partition for new /var
- move the contents of the /var/ to the new /var
- modify the /etc/fstab to mount the new /var on boot.

Hi,
 
your patch fails because the file rk3399-orangepi-4-lts.dts does not exist in the mainline kernel(s) you tried to build.
Maybe previously you appplied it against the vendor kernel?

For the dts, I would take the
patch/kernel/archive/rockchip64-6.12/dt/rk3399-orangepi-4-lts.dts
, modify it according to your needs and put it in the user patches directory (using the recommended way to replace a patch).

Indeed you are trying to patch a file that is created by an armbian patch. I suppose you can overwrite the armbian patch that creates the rk3399-orangepi-4-lts.dts with a patch that creates the dts with your modifications. 

Awesome!  Thank you for the help.  I was able to use the picomon to figure out that I needed to be wired to the uart0 to see the gps data coming in.
 
 
Rob

Hi,
 
check the status of serial-getty@ttyS2.service  and disable it.
systemctl status serial-getty@ttyS2.service systemctl disable serial-getty@ttyS2.service Also can you please post your kernel command line again to check the console= param:
cat /proc/cmdline According to the doc (https://0pointer.de/blog/projects/serial-console.html) systemd will spawn a serial getty for the console specified in the kernel command line.

Thanks! That was the issue. 


alsamixer > F4: Volume was low/off and Capture was not enabled (SPACEBar). Hitting the spacebar with the channel selected put the red text "CAPTURE".