<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Josua,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 20.07.2018 um 12:36 schrieb Josua Mayer <<a href="mailto:josua.mayer@jm0.eu" class="">josua.mayer@jm0.eu</a>>:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Hi Nikolaus,<br class="">
</p>
<br class="">
<div class="moz-cite-prefix">Am 20.07.2018 um 09:58 schrieb H.
Nikolaus Schaller:<br class="">
</div>
<blockquote type="cite" cite="mid:93DBE705-DD46-4EE7-B06F-17685CC09486@goldelico.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
Hi Josua,
<div class=""><br class="">
<blockquote type="cite" class="">Am 19.07.2018 um 16:47 schrieb
Josua Mayer <<a href="mailto:josua.mayer@jm0.eu" class="" moz-do-not-send="true">josua.mayer@jm0.eu</a>>:<br class="">
<br class="">
Hi Nikolaus,<br class="">
<br class="">
Let me add another issue:<br class="">
The zImage is bigger than 4MB. In order to boot from nand
flash on the<br class="">
gta04, zImage with appended DTB and u-boot header has to fit
within 4MB,<br class="">
sadly :(<br class="">
</blockquote>
<div class=""><br class="">
</div>
Hmm.</div>
<div class=""><br class="">
</div>
<div class="">Who is imposing this limitation? <br class="">
</div>
</blockquote>
Hmmm, I just did a cat /proc/mtd to find that value. Lets find out!<br class="">
letux-4.18-rc5: 0x280000 0x600000<br class="">
linux-4.8-rc5: 0x280000 0x400000<br class="">
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.<br class=""></div></div></blockquote><div><br class=""></div>Ah, ok. Yes!</div><div><br class=""></div><div>This is one of the changes in Letux OS that have not yet been upstreamed.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite" cite="mid:93DBE705-DD46-4EE7-B06F-17685CC09486@goldelico.com" class="">
<div class="">The latest GTA04 NAND partition scheme has</div>
<div class="">reserved 6 (or 8?) MB for the kernel for quite a
while because it did grow and</div>
<div class="">grow over the years. So there should be enough room.</div>
</blockquote>
for servicability, this only helps if we can get the new size
upstreamed :/<br class=""></div></div></blockquote></div><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">Or we get to treat DTB like firmware and have it not be part of the
OS.<br class=""></div></div></blockquote><div><br class=""></div><div>Well, as long as we have some omap3-gta04.dtsi upstream we should use</div><div>(and improve) it...</div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:93DBE705-DD46-4EE7-B06F-17685CC09486@goldelico.com" class=""><div class=""><br class="">
<blockquote type="cite" class="">So I experimented with the
first most obvious setting, the kernel<br class="">
compression algorithm, with letux_defconfig on 4.17.3:<br class="">
XZ: -rwxr-xr-x 1 1000 100 4205240 18. Jul 21:47
arch/arm/boot/zImage<br class="">
LZMA: -rwxr-xr-x 1 1000 100 4468392 18. Jul 21:45
arch/arm/boot/zImage<br class="">
GZIP: -rwxr-xr-x 1 1000 100 6055896 18. Jul 21:54
arch/arm/boot/zImage<br class="">
LZO: -rwxr-xr-x 1 1000 100 6684312 18. Jul 21:52
arch/arm/boot/zImage<br class="">
LZ4: -rwxr-xr-x 1 1000 100 7187536 18. Jul 21:51
arch/arm/boot/zImage<br class="">
<br class="">
Currently the letux_defconfig uses the default, gzip. As you
can see,<br class="">
the gzip size is roughly 6MB.<br class="">
</blockquote>
<div class=""><br class="">
</div>
My uImage (4.17.3) is roughly 4.5 MB:</div>
</blockquote>
Oh, right ...<br class="">
<blockquote type="cite" cite="mid:93DBE705-DD46-4EE7-B06F-17685CC09486@goldelico.com" class="">
<div class=""><br class="">
</div>
<div class=""><a href="http://download.goldelico.com/letux-kernel/letux-4.17.3/" class="" moz-do-not-send="true">http://download.goldelico.com/letux-kernel/letux-4.17.3/</a></div>
<div class=""><br class="">
</div>
<div class="">How do you come to such big kernel images by using
letux_defconfig?</div>
</blockquote>
export ARCH=arm
CROSS_COMPILE=/opt/toolchain/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-<br class="">
make letux_defconfig<br class="">
make menuconfig<br class="">
make zImage<br class="">
<br class="">
so what is happening? Is the compiler version at fault? Or did I
accidentally not switch branches (turns out I did ...)?<br class="">
So retrying:<br class="">
GZIP: -rwxr-xr-x 1 1000 100 4726096 20. Jul 12:21
arch/arm/boot/zImage<br class="">
LZMA: -rwxr-xr-x 1 1000 100 3533000 20. Jul 12:27
arch/arm/boot/zImage<br class="">
XZ: -rwxr-xr-x 1 1000 100 3336280 20. Jul 12:24
arch/arm/boot/zImage<br class="">
Oh wow! This is the size we want where space is really precious
(nand).<br class="">
So yes, some of my android experiments backfired in the previous
builds.
</div></div></blockquote><div><br class=""></div>Such things can happen... Some time ago I tried to debug some kernel module</div><div>and wasn't able to get my printk working. It turned out that I had an old version</div><div>in a different directory so that one was always loaded. After a clean build it</div><div>magically worked :) But clean builds take quite some time, so I try to avoid</div><div>them...</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:93DBE705-DD46-4EE7-B06F-17685CC09486@goldelico.com" class="">
<div class=""><br class="">
<blockquote type="cite" class="">So I think we should pick a
different algorithm. From this list xz and<br class="">
lzma are the best,<br class="">
and xz is actually exceptionally close to the goal!<br class="">
So I think xz should become the default.<br class="">
</blockquote>
<div class=""><br class="">
</div>
That would be a special solution for GTA04 NAND... All other
boards</div>
<div class="">supported by Letux OS have no problem with bigger
(and gz) kernels. So</div>
<div class="">we should think twice if we want to change that for
everyone.</div>
</blockquote>
You have a point there. I would think we want an algorithm with fast
decompression.<br class="">
Maybe this is worth benchmarking first, for making a good decision.<br class="">
A different way of reasoning is that smaller size on disk doesn't
hurt anyone, and that the xz decompressor is fast enough.<br class="">
<br class="">
For reference Debian has chosen XZ for linux-image-armmp:<br class="">
-rw-r--r-- 1 1000 100 4080128 22. Jun 11:50 vmlinuz-4.16.0-2-armmp<br class="">
<blockquote type="cite" cite="mid:93DBE705-DD46-4EE7-B06F-17685CC09486@goldelico.com" class="">
<div class=""><br class="">
<blockquote type="cite" class=""><br class="">
Can we do something else to get this kernel smaller? I do not
have an<br class="">
overview of what kernel options affect size and why they may
be useful<br class="">
or not.<br class="">
</blockquote>
<div class=""><br class="">
</div>
Well, all options with "=y" basically affect kernel binary size.
If you want</div>
<div class="">to build a GTA04 only kernel, you could remove
support for OMAP4&5 and i.MX6</div>
<div class="">and AM335x. But that leads to specialized kernel
binaries (and configs) for</div>
<div class="">every device model. Something we wanted to avoid by
having an multiarch kernel.</div>
<div class=""><br class="">
<blockquote type="cite" class=""><br class="">
A debian buster rootfs fits nicely into the 220MB rootfs
partition, and<br class="">
the localepurge package really helps a lot!<br class="">
</blockquote>
<div class=""><br class="">
</div>
Yes, that should nicely fit but is probably without X11 and lxde
or xfce?</div>
</blockquote>
Yes, without everything essentially. I haven't tried fitting xorg
back in yet.<br class=""></div></div></blockquote><div><br class=""></div>Ok.</div><div><br class=""></div><div>BR,</div><div>Nikolaus</div><div><br class=""></div><br class=""></div></body></html>