linux-aarch64-orangepi5-git: Migration from linux-aarch64-orangepi5 is recommended

[7Ji]

Ever since I created linux-aarch64-orangepi5 on Feb 17th, 2023, it was the main kernel used in my orangepi5-archlinuxarm project. The kernel package was always a pseudo versioned package, as it tracks the revision orangepi uses internal in their build system, which I convert manually to the commit id used when the build system is updated.

However, just recently, orangepi updated their build system and changed which branch to build kernel from their linux-orangepi repo, without touching the internal revision. They introduced OrangePi 5 Pro support in the update and bumped the kernel for OPi5/5B/5Plus all together, so their kernel was bumped together to 5.10.160, but their revision did not change at all.

This leaves me a hard situation to work against: If I bump linux-aarch64-orangepi5 to point to a new commit, what should that commit be? The versioning in their build system still hints OPi5 is at 1.1.8, that could point to both the old commit in -rk3588 tree I was using in 5.10.110-6, or the latest commit in -rk35xx tree.

Thus, I decided to create a new -git package to track their VCS revisions directly, which is linux-aarch64-orangepi5-git, tracking both the kernel and the build system, currently at 5.10.160.r1080192.695850f9bde2.ced0156-1

---

To prepare for migration, simply install linux-aarch64-orangepi5-git from the repo, it does not conflict with the old non-git package. All my kernel packages don't conflict with each other.

sudo pacman -Syu linux-aarch64-orangepi5-git

Update your /boot/extlinux/extlinux.conf to contain both kernels like the following:

MENU TITLE Select a kernel to boot
DEFAULT linux-aarch64-orangepi5
LABEL   linux-aarch64-orangepi5
        LINUX   /vmlinuz-linux-aarch64-orangepi5
        INITRD  /initramfs-linux-aarch64-orangepi5-fallback.img
        FDT     /dtbs/linux-aarch64-orangepi5/rockchip/rk3588s-orangepi-5.dtb
        FDTOVERLAYS     /dtbs/linux-aarch64-orangepi5/rockchip/overlay/rk3588-ssd-sata0.dtbo
        APPEND  root=UUID=61c8756a-f424-4f05-99e9-0318ad48afa8 rw
LABEL   linux-aarch64-orangepi5-git
        LINUX   /vmlinuz-linux-aarch64-orangepi5-git
        INITRD  /initramfs-linux-aarch64-orangepi5-git-fallback.img
        FDT     /dtbs/linux-aarch64-orangepi5-git/rockchip/rk3588s-orangepi-5.dtb
        FDTOVERLAYS     /dtbs/linux-aarch64-orangepi5-git/rockchip/overlay/rk3588-ssd-sata0.dtbo
        APPEND  root=UUID=61c8756a-f424-4f05-99e9-0318ad48afa8 rw

To switch the version, simply modify the DEFAULT line and point it to a different LABEL.

If you want to be able to change the booting target interactively during the boot process, you can add a line like TIMEOUT 30 after the DEFAULT line, which means to wait for 3 seconds to let you make the choice. Personally I feel this a waste of time because I use them as headless servers.

If you have no issue using the new -git kernel, you can safely remove the old kernel and its booting configuration.

sudo pacman  -Rcns linux-aarch64-orangepi5

Your new configuration without the old kernel should look like the following:

LABEL   linux-aarch64-orangepi5-git
LINUX   /vmlinuz-linux-aarch64-orangepi5-git
INITRD  /initramfs-linux-aarch64-orangepi5-git-fallback.img
FDT     /dtbs/linux-aarch64-orangepi5-git/rockchip/rk3588s-orangepi-5.dtb
FDTOVERLAYS     /dtbs/linux-aarch64-orangepi5-git/rockchip/overlay/rk3588-ssd-sata0.dtbo
APPEND  root=UUID=61c8756a-f424-4f05-99e9-0318ad48afa8 rw

---

WARNING: The migration does not introduce conflict if and only if you're using packages built from my source. Some downstream copied and modified my PKGBUILD and used a same folder instead of dedicated folders for DTBs of a kernel, those are not supported by myself and would most likely break

[7Ji]

@kyak @Integral-Tech. FYI

[7Ji]

The old non-git kernel would still ne updated, but that could only come after OPi setting a new meaningful revision in their build system. So 5.10.160 for non-git is not coming soon. I think that would be shipped together with the OPi5 Pro release.

Also, the newest kernel supports OPi5 Pro but I can't confirm it. I only have OPi5 and OPi5 Plus and I don't have any relationship with OPi (All my projects run without sponsorship because I don't like the feeling of being pushed by sponsors) so don't expect me to get sample of OPi5 Pro.

[kyak]

@7Ji i think i inherited /boot/extlinux/extlinux.conf from Orange Pi's original distribution. I'm trying to align it with what you have. What I have:

LABEL Orange Pi
LINUX /vmlinuz-linux-aarch64-orangepi5
FDT /dtbs/linux-aarch64-orangepi5/rockchip/rk3588-orangepi-5-plus.dtb
FDTOVERLAYS /dtbs/linux-aarch64-orangepi5/rockchip/overlay/rk3588-opi5plus-disable-leds.dtbo
APPEND initrd=/initramfs-linux-aarch64-orangepi5.img console=ttyS2,1500000 root=PARTUUID=4fb0eef0-d9f7-4abf-aa09-cbb5c21b4152 rw rootwait audit=0 splash plymouth.ignore-serial-consoles loglevel=2 cma=128M

It's mostly the same apart from cma-128M. Do you know what does it mean?

P.S. It struck me when you suggested to do pacman -Syu linux-aarch64-orangepi5-git. I completely forgot that you're maintaining prebuilt packages in your repo. I used to use pikaur to keep up to date, but it's not an option anymore due to AUR policies. I've just happily switched to using your repo -- thanks a lot for providing that!

[kyak]

And another one. Why do you use rk3588-ssd-sata0.dtbo overlay? I'm also booting from ssd (/dev/nvme0n1) and i don't have/don't need it.

[7Ji]

That example was dumped from the opi5 sata image. I choose that because it is the only one that has an initial overlay line, useful to demonstrating the whole format.

I'm also booting from ssd (/dev/nvme0n1) and i don't have/don't need it

You'll only need that overlay if you remux the m.2 to sata. I don't use that, just for demo.

[7Ji]

@kyak

cma-128M. Do you know what does it mean?

https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html

        cma=nn[MG]@[start[MG][-end[MG]]]
                        [KNL,CMA]
                        Sets the size of kernel global memory area for
                        contiguous memory allocations and optionally the
                        placement constraint by the physical address range of
                        memory allocations. A value of 0 disables CMA
                        altogether. For more information, see
                        kernel/dma/contiguous.c

[kyak]

@kyak

cma-128M. Do you know what does it mean?

https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html

        cma=nn[MG]@[start[MG][-end[MG]]]
                        [KNL,CMA]
                        Sets the size of kernel global memory area for
                        contiguous memory allocations and optionally the
                        placement constraint by the physical address range of
                        memory allocations. A value of 0 disables CMA
                        altogether. For more information, see
                        kernel/dma/contiguous.c

Yeah, but.. Do we need it? I wonder why orange pi sets this.

[7Ji]

No, I don't use that for my boards.

My OPi5:

LABEL   Arch Linux
LINUX   /vmlinuz-linux-aarch64-orangepi5-git
INITRD  /initramfs-linux-aarch64-orangepi5-git.img
FDT     /dtbs/linux-aarch64-orangepi5-git/rockchip/rk3588s-orangepi-5.dtb
APPEND  root=UUID=69defeb4-a1bf-4065-8088-d8bed4793e5e rw console=ttyFIQ00,1500000n8 console=tty1

My OPi 5 Plus:

LABEL   Arch Linux
LINUX   /vmlinuz-linux-aarch64-orangepi5-git
INITRD  /initramfs-linux-aarch64-orangepi5-git.img
FDT     /dtbs/linux-aarch64-orangepi5-git/rockchip/rk3588-orangepi-5-plus.dtb
APPEND  root=/dev/disk/by-path/platform-fe2e0000.mmc-part2 rootflags=subvol=@root rw console=ttyFIQ00,1500000 console=tty1

[7Ji]

@kyak

I dug a little bit into cma.

Depending on your use case you might want to add cma= arg to the cmdline. The Continuous Memory Allocation reserved memory pool is mostly useful for graphic-related stuffs. It's at least for displaying, but I don't know in detail if it's also reserved for decoding.

Without setting, opi's rk vendor kernel uses 8MiB, raising that to 128MiB could help with some workload, but I haven't found any issue using just the default 8M, both headless and on DE.

I've currently set them to 0 on both my OPi5Plus and OPi5, since they run 7x24 as build servers.

[kyak]

@kyak

I dug a little bit into cma.

Depending on your use case you might want to add cma= arg to the cmdline. The Continuous Memory Allocation reserved memory pool is mostly useful for graphic-related stuffs. It's at least for displaying, but I don't know in detail if it's also reserved for decoding.

Without setting, opi's rk vendor kernel uses 8MiB, raising that to 128MiB could help with some workload, but I haven't found any issue using just the default 8M, both headless and on DE.

I've currently set them to 0 on both my OPi5Plus and OPi5, since they run 7x24 as build servers.

Nice, thanks for the info! I removed this parameter for now, no problems so far.