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? 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@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:

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
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.