[Letux-kernel] New Letux Kernel releases
josua.mayer at jm0.eu
Fri Jul 20 12:36:27 CEST 2018
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 :(
> 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 ...
> How do you come to such big kernel images by using letux_defconfig?
so what is happening? Is the compiler version at fault? Or did I
accidentally not switch branches (turns out I did ...)?
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
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
> 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
> And yes, localepurge is our friend here :) If I remember correctly the
> prebuilt images provided on downloads at goldelico have it installed.
>> However half of the used space is apt index (~110MB uncompressed).
> Yes, it is growing and growing. Lenny or Squeeze were really small :)
>> I have a feeling if we ever install debian in nand again, maybe apt
>> index should be in a compressed tmpfs and not persistent.
> Good idea!
> What I do in the flash-nand script is to apt-clean and remove some
> of the cache files... Unfortunately, a jessie+LXDE is ca. 10% too big...
>> Josua Mayer
>> Am 19.07.2018 um 07:32 schrieb H. Nikolaus Schaller:
>>> Hi Josua,
>>> sorry for the delayed answer.
>>>> Am 16.07.2018 um 20:19 schrieb Josua Mayer <josua.mayer at jm0.eu
>>>> <mailto:josua.mayer at jm0.eu>>:
>>>> Hi Nikolaus,
>>>> I finally got around to testing that 4.17.3+ build of yours and these
>>>> are the things I noticed:
>>>> modules.tgz has many files outside of /lib/modules
>>> yes. We have some /etc and /root files in the kernel tree
>>> which regularily need an update to exactly match the specific
>>> kernel variant. Therefore the easiest thing was to pack them
>>> with the modules which have the same constraint.
>>> But we could think about splitting into modules.tgz and root.tgz
>> Yes that would be nice. I really dislike that it overrides the nodm
>> configuration file after I had explicitly disabled nodm before.
>> Also afaik dpkg complains about a file already installed by a system
>> package (can't remember which) so that could use cleaning.
> I have separated this now into three packages:
> linux-kernel(uImage + dtbs + kernel modules)
> linux-headers(header files)
> linux-rootfs(/etc /root ...)
> So if you don't install linux-rootfs.deb there is no conflicting
> config for nodm
> and others.
> Maybe I should split it up into even more small packages (/root,
> udev rules, fstab, tty, ssh, X11, systemd, network/interfaces, ...) and
> some meta-package.
> But for a first step this should be good enough and can be generated
> 100% automatically.
>>>> linux-image_*.deb has many files outside of /lib/modules and /boot
>>> it is the same.
>>>> linux-image_*.deb does not contain the uImage
>>> Oops. But that should be included... I have to check the build scripts.
> I have found the bug and with 4.18-rc5 it is now included.
>>>> With the previous stable 4.16 as fetched by makesd I had occasional
>>>> unexpected shutdown after leaving the phone lying around idle while
>>>> attached to the charger. And every time the battery was empty
>>>> afterwards :(
>>>> I haven't seen this on 4.17 yet after several hours so I guess that
>>>> is a
>>>> good sign!
>>>> WiFi sometimes fails to authenticate (open network) and requires one
>>>> ifdown-ifup cycle:
>>>> [ 411.405700] wlan0: authenticate with <censored>
>>>> [ 411.418884] wlan0: send auth to <censored> (try 1/3)
>>>> [ 411.555633] wlan0: send auth to <censored> (try 2/3)
>>>> [ 411.705718] wlan0: send auth to <censored> (try 3/3)
>>>> [ 411.815734] wlan0: authentication with <censored> timed out
>>>> then on next ifup after ifdown:
>>>> [ 488.789276] wlan0: authenticate with <censored>
>>>> [ 488.801879] wlan0: send auth to <censored> (try 1/3)
>>>> [ 488.830963] wlan0: authenticated
>>>> [ 488.835693] wlan0: associate with <censored> (try 1/3)
>>>> [ 488.846221] wlan0: RX AssocResp from <censored> (capab=0x421
>>>> [ 488.872192] wlcore: Association completed.
>>>> [ 488.881774] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>>>> [ 488.889678] wlan0: associated
>>>> I also have seen this with 4.16 I believe.
>>> That is something I have no idea about...
>>>> I don't understand the output of the charger script:
>>>> Which battery is which, and why do they all have different charge
>>>> TWL4030 Main Battery
>>> this is the first entry which reads the ADCs for voltage and current
>>> and has a built-in formula in the script
>>>> volt: 3777mV
>>>> current: 918mA
>>>> fuel level: ca. 50%
>>>> temp: 27°C
>>>> type: 1mV <-- Is this a type? Really?
>>> Yes, it is the "battery type" ADC input. Which is not used on the GTA04
>>> design, but other hardware. It could be used to measure a resistor built
>>> into the battery to make the software know about small and big
>> okay. I guess there is no way to disable unused ports in dt.
> Well, it can be disabled in DT but it could also be ignored by
>>>> Battery /sys/class/power_supply/bq27000-battery
>>> this is the fuel gauge (bq27000) inside the battery, i.e. quite precise
>> Okay. So this might be the one that a generic userspace wants to use, if
> Yes. But there is no "generic" thing here. User must choose one of
> the records found in /sys/class/power_supply
>>>> present: 1
>>>> technology: Li-ion
>>>> capacity: 10%
>>>> status: Charging
>>>> Battery /sys/class/power_supply/gta04-battery
>>> this is our generic-adc-battery driver which tries to estimate the
>>> fuel level like the formula in the script. But they differ for two
>>> 1. there is noise on the ADC signals so they may measure different
>>> 2. the formula used by the generic-adc-battery driver is questionable
>> So this would be the fall-back if fuel gauge doesn't work or exist?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Letux-kernel