How Do You Build With The Latest (Relatively) Stable Edge Kernel, Not The Ultra-Latest Bleeding Edge Kernel?

[The Tall Man]

I've downloaded the latest stable Release of the source code:

https://github.com/armbian/build/releases/tag/v25.8.1

 

When doing a Build, when it allows you to select the kernel branch: [vendor, mainline, edge], the only edge available for selection is the bleeding edge (i.e. latest trunk version). I've downloaded the 25.8.1 source code, and that's the edge version I want to compile.

How do you build an image with the latest (relatively) stable edge kernel, as available in Armbian-Config? (i.e. currently v6.16.1-edge at Armbian 25.8.1)?

 

Update #1

When compiling the image with the edge kernel, it downloaded it from the internet and it took roughly an hour to build. When compiling an otherwise identical image with the Vendor kernel, it did not seem to download it from the internet (although I wasn't watching it closely), and it took roughly less than half the time to build the image. The reason I compiled an image with the Vendor kernel is because something broke in the last 24 hours on the internet-supplied edge kernel. It compiled 24 hours ago, a few hours ago it didn't. This wouldn't be an issue if it was compiling the most recent release of v6.16.1-edge (25.8.1), as per my intention, instead of the ultra-latest.

I also made some discoveries about version number inconsistencies (independent of the kernel branch selected). Things are confused.
In Release 25.8.1, the version is 25.11.0.trunk.

In Release 25.5.1, the version is 25.08.0-trunk.

 

 

Edited 4 hours ago by The Tall Man
.

[eselarm]

My experience is that the edge kernel is stable enough, but if you act like a disk-jockey (playing with disks or SD-cards/images nowadays) you destroy your success potentially every time you try some new image. Instead, pick a distro Debian or Ubuntu when Armbian, and make backups and/or do snapshots of what worked and then install packages variants. You can have vendor, current, edge kernels installed at the same time.

 

A lot faster build maybe because the kernel is already build by some person or some computer before, so you get it fetched from a cache. I have added the beta repo in my sources so I can select between various kernels (and U-Boot variants). You need a bootmanager though, so own extlinux.conf script or wipe standard boot.* files and make sure EFI works, with GRUB or so. The latter works fine if you don't need overlays etc, so more use the SBC as PC then as embedded board to control things via GPIO pins or so. You can also re-install a specific kernel every time, but that does not work when the one you wanted to run does not start the board or crashes it.

 

The OPi5plus I would consider as a PC, I do that for similar boards like ROCK5B and NanoPi-R6C at least. I select kernel via GRUB and have a permanent serial console cable connected, so it also works without HDMI connected. It is mainly the choice between vendor and mainline, that is the state of ARM64 nowadays. Some new boards like RPi5 cannot run mainline yet, so then there is little need to have a bootmanager, then you need the disk-jockey methods.

[The Tall Man]

True, it's not critical to compile the ideal kernel into the image as long as I get one that works, I can always update it later from within the image. But I do prefer to do things right the first time, and to be utilizing the version I think I am and intend to be using. Btw, I boot from grub as well.

 

For my Orange PI 5 Plus, The edge kernel is the only one that's actually useful to me because the Vendor kernel has no GPU acceleration at all, the Mainline kernel has no video output to my DVI monitor, and all 3 kernel branches aren't correctly utilizing the ES8388 analog audio, which I need. The audio volume is barely audible even when all volume controls are maxed out. It's been that way in every operating system I've tried (except those with old barebones Vendor Kernels from Orange PI).

 

So ultimately I want to compile the latest (relatively) stable edge kernel myself, so I can modify the source code in an attempt to fix the audio, and of course share the solution when / if I find it.

I've already found that the ES8388 and ES8328 are compatible - hence the es8328 modules used in the kernel for the ES8388. And I've narrowed down where the issue most likely is:

 

Directory: sound/soc/codecs

Files: es8328.h, es8328.c, es8328-i2c.c