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? 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:
http://download.goldelico.com/letux-kernel/letux-4.17.3/
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:
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:
- there is noise on the ADC signals so they may measure different voltage
- 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