From bill-auger at peers.community  Sat May 21 20:13:18 2022
From: bill-auger at peers.community (bill-auger)
Date: Sat, 21 May 2022 16:13:18 -0400
Subject: [Trisquel-devel] trisquel ARM install tarball
Message-ID: <20220521161318.1a709a0b@parabola.localdomain>

i was able to get trisquel running on the 'freedombox' (aka:
olimex lime2 revG) using the trisquel-base_10.0_armhf.tar.bz2
system - not OOTB though - it needed some work - most
importantly, it does not include the device-tree blobs, which
are necessary to boot most SBCs; and AFAICT, no trisquel package
ships them

to get it working, i started with the olimex debian-11 release -
no one else would need to do that; but for experimentation, i
knew that it would include everything needed to boot that board

booting the olimex kernel into the trisquel rootfs, worked as
expected - the next step was to boot the trisquel kernel; but
again, i first needed the DT blobs for the trisquel kernel - i
compiled them from an x86_64 trisquel system like so:

$ sudo apt source linux-image-generic
$ sudo apt build-dep linux-image-generic
$ sudo apt install gcc-arm-linux-gnueabihf

$ cd linux-* ; chown -R $(id -u):$(id -g) . ;
$ make mrproper
$ make ARCH=arm sunxi_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs

that generated the needed .dtb files for all olimex A20 baords -
for this experiment, i only needed sun7i-a20-olinuxino-lime2.dtb

i copied those and the trisquel kernel to the SD-card, adapted
the kernel.its config, referencing the trisquel kernel, initrd,
and .dtb files, then regenerated the kernel.itb blob - FYI
kernel.itb is what uboot actually boots - it wraps the kernel,
initrd, and device-tree files into a single binary

that almost worked - it loaded the .itb, but failed with this
message:

> image too large increase CONFIG_SYS_BOOTM_LEN

looking at the u-boot source, i found that the default size is
32M for these sunxi-based boards

$ grep CONFIG_SYS_BOOTM_LEN u-boot/include/configs/sunxi-common.h
#define CONFIG_SYS_BOOTM_LEN		(32 << 20)

there is a bit of a mystery here; but here are some numbers -
maybe some else can shed some more light on it - the kernel in
the trisquel tarball is 11M and the initrd is 43M - that
produced a 53M .itb - the olimex kernel is 6.3M and it's initrd
is 8,9M, producing a 16M .itb - naively, that would explain the
error message - however, after i rebuilt the trisquel kernel in
the compressed zImage format, the resulting .itb was 47M; and it
did boot successfully - im not certain why - perhaps the
pre-installed freedombox u-boot has CONFIG_SYS_BOOTM_LEN at 48M

FYI, the build command i used was:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage dtbs

in any case the trisquel kernel and ramdisk are significantly
larger than the olimex system - even with the compressed
trisquel kernel, the result was 3x larger than the olimex boot
binary, which is not compressed

$ ls -1sh {initrd*,*.itb*,vmlinuz*,zImage}
8.9M  initrd.img-5.10.105-olimex
43M   initrd.img-5.4.0-96-generic
47M   kernel.itb
16M   kernel.itb-olimex
53M   kernel.itb-trisquel
6.3M  vmlinuz-5.10.105-olimex
11M   vmlinuz-5.4.0-96-generic
4.1M  zImage

just to be pedantic:

un-compressed olimex kernel:
    6.3M  vmlinuz-5.10.105-olimex
  + 8.9M  initrd.img-5.10.105-olimex
  ----------------------------------
    16M   kernel.itb-olimex

un-compressed trisquel kernel:
    11M   vmlinuz-5.4.0-96-generic
  + 43M   initrd.img-5.4.0-96-generic
  -----------------------------------
    53M   kernel.itb-trisquel

compressed trisquel kernel:
    4.1M  zImage
  + 43M   initrd.img-5.4.0-96-generic
  -----------------------------------
    47M   kernel.itb

my guess is that, either they need to lose some weight (or be
compressed); or trisquel's u-boot will need to be compiled with
all boards configured to load <=64M images, _and_ the trisquel
install guide will need to insist upon installing trisquel's
u-boot onto the boot media for some boards

$ grep -rE '#define CONFIG_SYS_BOOTM_LEN.*32.*' u-boot/ | wc -l
19
$ grep -rE '#define CONFIG_SYS_BOOTM_LEN.*64.*' u-boot/ | wc -l
94
$ grep -rE '#define CONFIG_SYS_BOOTM_LEN.*128.*' u-boot/ | wc -l
6
$ grep -rE '#define CONFIG_SYS_BOOTM_LEN.*256.*' u-boot | wc -l
6

there are other ways around this limit also - parabola is
preferring to use uboot4extlinux, where u-boot boots a syslinux
binary, which can be re-configured easily via a extlinux.conf
file, to boot any number of kernels, without re-compiling -
there is also uboot4grub - AFAICT, trisquel has neither of those
packaged though - initially, i wanted to offer the simplest
solution that would work today, given the tools that trisquel
already has available - for now, the kernel build would only need
to adapted to compress the kernel, and to produce those DT blobs
- unless i was mistaken - i could not find them

there is still some support missing for other olimex boards -
olimex includes a few more blobs than what the trisquel kernel
produced:

/usr/lib/linux-image-5.10.105-olimex/sun7i-a20-olinuxino-lime-emmc.dtb
/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi0.dtbo
/usr/lib/olinuxino-overlays/sun7i-a20/spi0-spiflash.dtbo

the first one means that the some of the original lime models
may not work (the ones with EMMC - not all models have it) -
the others are probably built from olimex custom sources - they
apparently are needed for olimex boards with SPI flash (though
again, not all models have SPI flash)

as a final note, the freedombox project has a tool for building
ARM install tarballs from debian repos, named 'freedom-maker' -
it is in the trisquel repos - i would suggest adapting that for
trisquel - it is likely that the package in the trisquel repos
is not FSDG-fit, and should be treated or deleted anyways - it
probably makes short work of producing install tarballs which
support all of the boards that freedom does - i may experiment
with that next