[Letux-kernel] New Letux Kernel releases
H. Nikolaus Schaller
hns at goldelico.com
Fri Jul 20 09:58:33 CEST 2018
> Am 19.07.2018 um 16:47 schrieb Josua Mayer <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? 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.
> 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:
How do you come to such big kernel images by using letux_defconfig?
> 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.
> 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?
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.
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>:
>>> 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
Maybe I should split it up into even more small packages (/root, networking,
udev rules, fstab, tty, ssh, X11, systemd, network/interfaces, ...) and
But for a first step this should be good enough and can be generated
>>> 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 status=0
>>> [ 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 levels?
>>> 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 batteries.
> 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 user-space...
>>> 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 battery
>> fuel level like the formula in the script. But they differ for two reasons:
>> 1. there is noise on the ADC signals so they may measure different voltage
>> 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