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.

And yes, localepurge is our friend here :) If I remember correctly the
prebuilt images provided on downloads@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...


br
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@jm0.eu>:

Hi Nikolaus,

I finally got around to testing that 4.17.3+ build of yours and these
are the things I noticed:
fine!

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:

http://download.goldelico.com/letux-kernel/letux-4.18-rc5/binary-armhf/

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, networking,
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 status=0
aid=1)
[  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
present?

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?

Yes.

BR,
Nikolaus