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
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 mailto: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 mailto: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 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
Hi Josua,
Am 20.07.2018 um 12:36 schrieb Josua Mayer josua.mayer@jm0.eu:
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 mailto: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.
Ah, ok. Yes!
This is one of the changes in Letux OS that have not yet been upstreamed.
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.
Well, as long as we have some omap3-gta04.dtsi upstream we should use (and improve) it...
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/ 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.
Such things can happen... Some time ago I tried to debug some kernel module and wasn't able to get my printk working. It turned out that I had an old version in a different directory so that one was always loaded. After a clean build it magically worked :) But clean builds take quite some time, so I try to avoid them...
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.
Ok.
BR, Nikolaus
-
H. Nikolaus Schaller -
Josua Mayer