[Letux-kernel] LetuxOS: Kernel: m-stable 6.19 success [iMac.local]

[H. Nikolaus Schaller]

> Am 13.02.2026 um 18:38 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Mon,  9 Feb 2026 17:26:45 +0100 (CET)
> kernel-build-bot at letux.org wrote:
> 
>> KVERSION: v6.19 - http://www.kernel.org
>> CONFIGS:  arch/arm/configs/letux_defconfig arch/arm/configs/letux_lpae_defconfig arch/arm64/configs/letux_defconfig arch/riscv/configs/letux_defconfig arch/mips/configs/letux_defconfig arch/x86/configs/letux_defconfig
>> 
>> Infos
>> =====
>> Project Home: http://projects.goldelico.com/p/gta04-kernel/
>> Issues: http://projects.goldelico.com/p/gta04-kernel/issues/
>> Original: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=v6.19
>> Elixir: https://elixir.bootlin.com/linux/v6.19/source
>> 
>> Downloads
>> =========
>> git: http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=letux-6.19
>> Buildhost: iMac.local
>> ARM: http://download.goldelico.com/letux-kernel/letux-6.19
> 
> hmm, how is this supposed to fit into a 0x5c0000 sized nand area?

Well, it is likely not at all supposed but simply happened and remained untested.

You know we are lacking people testing this every now and then on *all* devices in all modes.
I don't even remember when I had last time tried to flash a kernel into NAND.

> 0x5c00000...0x600000 is reserved for the devicetree (256K)

As you mention this, I start to vaguely remember that there was some 6MB limit
for the Image in the past and it has grown and grown...

http://download.goldelico.com/letux-kernel/letux-6.1/ has just 5.8 MB
http://download.goldelico.com/letux-kernel/letux-6.1.3/ has 5.9
http://download.goldelico.com/letux-kernel/letux-6.1.51/ has 6.0
http://download.goldelico.com/letux-kernel/letux-6.1.162/ still at 6.0
http://download.goldelico.com/letux-kernel/letux-6.6/ started at 6.1

So it is likely because upstream adds more and more code code with default CONFIG=y...
And we might have enabled more features for boards without NAND and µSD boot doesn't complain.

Unless U-Boot can't decompress (there is also some built-in limit AFAIR).

> 
> CONFIG_KERNEL_LZMA=y
> 
> can be set to reduce that at the cost of decompression time.

Another approach is to compile less into the kernel and have more modules.

> 
> We were just talking about sizes on LKML...

More about time/speed than size...

> I personally am happy with having a working bootloader there and
> avoid touching it. There were some partition type differences in the
> past.

Indeed...

I'll have an eye on it.

BR and thanks for the note,
Nikolaus