Curvy Android

I'm trying to activate the UART9 overlay to enable an additional serial port. According to the Armbian documentation, I should create /boot/armbianEnv.txt and add overlays=uart9 to it. However, after multiple attempts, the serial boot log doesn't show any changes, as if the file isn't being read at all. Here's what I've tried so far: Created /boot/armbianEnv.txt with the following content: overlays=uart9 Tried different overlay_prefix settings (e.g., overlay_prefix=k1). Renamed the file to orangepiEnv.txt after seeing it referenced elsewhere. None of these changes seem to have any effect, the UART9 device doesn't appear in /dev/, and the boot log doesn't reflect the overlay being applied. Could someone point me in the right direction? What am I missing here? Once I get the UART9 overlay working, I'd also like to create a custom overlay to use a GPIO pin for PPS (Pulse Per Second) input. Any guidance on that would be greatly appreciated!

Setting pcie_aspm=off makes the drive work in the top slot albeit one order of magnitude slower than in the bottom slot. If I swap the kernel parameter with pcie_aspm.policy=performance, I've got a working drive and it's operating at normal speed. Thanks a bunch! Seeing that there are differences in behavior between the two M.2 slots, does that mean they're connected differently?

Firstly, thank you for the ongoing support for the RV2. I'm encountering an issue with the top M.2 slot. While I can boot from it, as soon as the prompt appears, an ext4 error is thrown, the root filesystem is mounted read-only, and the system fails to complete the login process. Interestingly, when I move the same disk to the bottom M.2 slot, everything works perfectly. To further investigate, I wiped the NVMe drive, created an empty ext4 partition, and booted from an SD card. Here are the results: Bottom Slot (Works as expected): The disk can be mounted and used without issues. Passes multiple `fio` write and read tests. Top Slot (Fails to mount): Unable to mount the disk: root@orangepirv2:~# mount /dev/nvme0n1p1 /mnt/test mount: /mnt/test: can't read superblock on /dev/nvme0n1p1. dmesg(1) may have more information after failed mount system call. I've checked the dmesg logs, and the only noticeable difference is that when the disk is in the bottom slot (and working), there are more Bluetooth-related lines. Does this indicate that the lines for that slot are used by multiple systems, or am I on the wrong track? Here are the relevant dmesg logs for both scenarios: Booting from SD, NVMe disk in top M.2 slot: Booting from SD, NVMe disk in bottom M.2 slot: Any insights or suggestions would be greatly appreciated.