Am 20.07.2018 um 12:36 schrieb Josua Mayer <josua.mayer@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@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.

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.

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/

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.

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.