[Letux-kernel] New Letux Kernel releases

H. Nikolaus Schaller hns at goldelico.com
Fri Jul 20 15:47:10 CEST 2018

Hi Josua,

> Am 20.07.2018 um 12:36 schrieb Josua Mayer <josua.mayer at jm0.eu>:
> Hi Nikolaus,
> Am 20.07.2018 um 09:58 schrieb H. Nikolaus Schaller:
>> Hi Josua,
>>> Am 19.07.2018 um 16:47 schrieb Josua Mayer <josua.mayer at jm0.eu <mailto:josua.mayer at jm0.eu>>:
>>> Hi Nikolaus,
>>> Let me add another issue:
>>> The zImage is bigger than 4MB. In order to boot from nand flash on the
>>> gta04, zImage with appended DTB and u-boot header has to fit within 4MB,
>>> sadly :(
>> Hmm.
>> Who is imposing this limitation? 
> Hmmm, I just did a cat /proc/mtd to find that value. Lets find out!
> letux-4.18-rc5: 0x280000 0x600000
> linux-4.8-rc5: 0x280000 0x400000
> So omap3-gta04.dtsi imposes the limitation. I was hit by this because I used the pure debian I built on my sdcard to then set up a system in nand.

Ah, ok. Yes!

This is one of the changes in Letux OS that have not yet been upstreamed.

>> The latest GTA04 NAND partition scheme has
>> reserved 6 (or 8?) MB for the kernel for quite a while because it did grow and
>> grow over the years. So there should be enough room.
> for servicability, this only helps if we can get the new size upstreamed :/

> Or we get to treat DTB like firmware and have it not be part of the OS.

Well, as long as we have some omap3-gta04.dtsi upstream we should use
(and improve) it...

>>> So I experimented with the first most obvious setting, the kernel
>>> compression algorithm, with letux_defconfig on 4.17.3:
>>> XZ:   -rwxr-xr-x 1 1000 100 4205240 18. Jul 21:47 arch/arm/boot/zImage
>>> LZMA: -rwxr-xr-x 1 1000 100 4468392 18. Jul 21:45 arch/arm/boot/zImage
>>> GZIP: -rwxr-xr-x 1 1000 100 6055896 18. Jul 21:54 arch/arm/boot/zImage
>>> LZO:  -rwxr-xr-x 1 1000 100 6684312 18. Jul 21:52 arch/arm/boot/zImage
>>> LZ4:  -rwxr-xr-x 1 1000 100 7187536 18. Jul 21:51 arch/arm/boot/zImage
>>> Currently the letux_defconfig uses the default, gzip. As you can see,
>>> the gzip size is roughly 6MB.
>> My uImage (4.17.3) is roughly 4.5 MB:
> Oh, right ...
>> http://download.goldelico.com/letux-kernel/letux-4.17.3/ <http://download.goldelico.com/letux-kernel/letux-4.17.3/>
>> How do you come to such big kernel images by using letux_defconfig?
> export ARCH=arm CROSS_COMPILE=/opt/toolchain/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-
> make letux_defconfig
> make menuconfig
> make zImage
> so what is happening? Is the compiler version at fault? Or did I accidentally not switch branches (turns out I did ...)?
> So retrying:
> GZIP:  -rwxr-xr-x 1 1000 100 4726096 20. Jul 12:21 arch/arm/boot/zImage
> LZMA: -rwxr-xr-x 1 1000 100 3533000 20. Jul 12:27 arch/arm/boot/zImage
> XZ:      -rwxr-xr-x 1 1000 100 3336280 20. Jul 12:24 arch/arm/boot/zImage
> Oh wow! This is the size we want where space is really precious (nand).
> So yes, some of my android experiments backfired in the previous builds.

Such things can happen... Some time ago I tried to debug some kernel module
and wasn't able to get my printk working. It turned out that I had an old version
in a different directory so that one was always loaded. After a clean build it
magically worked :) But clean builds take quite some time, so I try to avoid

>>> So I think we should pick a different algorithm. From this list xz and
>>> lzma are the best,
>>> and xz is actually exceptionally close to the goal!
>>> So I think xz should become the default.
>> That would be a special solution for GTA04 NAND... All other boards
>> supported by Letux OS have no problem with bigger (and gz) kernels. So
>> we should think twice if we want to change that for everyone.
> You have a point there. I would think we want an algorithm with fast decompression.
> Maybe this is worth benchmarking first, for making a good decision.
> A different way of reasoning is that smaller size on disk doesn't hurt anyone, and that the xz decompressor is fast enough.
> For reference Debian has chosen XZ for linux-image-armmp:
> -rw-r--r-- 1 1000 100 4080128 22. Jun 11:50 vmlinuz-4.16.0-2-armmp
>>> Can we do something else to get this kernel smaller? I do not have an
>>> overview of what kernel options affect size and why they may be useful
>>> or not.
>> Well, all options with "=y" basically affect kernel binary size. If you want
>> to build a GTA04 only kernel, you could remove support for OMAP4&5 and i.MX6
>> and AM335x. But that leads to specialized kernel binaries (and configs) for
>> every device model. Something we wanted to avoid by having an multiarch kernel.
>>> A debian buster rootfs fits nicely into the 220MB rootfs partition, and
>>> the localepurge package really helps a lot!
>> Yes, that should nicely fit but is probably without X11 and lxde or xfce?
> Yes, without everything essentially. I haven't tried fitting xorg back in yet.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180720/6220ba95/attachment.html>

More information about the Letux-kernel mailing list