Do make sense an u-boot installer?

[Sean Anderson]

On 4/13/21 1:09 PM, Alberto Planas wrote:
 > Hi,
 >
 > lately I am working on a small script that try to unify and help the
 > installation of u-boot (and the different assets) into SD cards.
 >
 > As I am not knowledge about u-boot, I am starting small and with an use case
 > that makes sense for my work. I want to discuss a bit if makes sense the idea,
 > can be extended to cover other use cases and have a chance to be upstreamed
 > inside u-boot/tools.
 >
 > Before sending any patches, the current code is living here:
 >
 > https://github.com/aplanas/u-boot/tree/dubi/tools/dubi

 > # Delay the check, so we can validate all the input
 > [ "$(id -u)" -ne "0" ] && die "Please, run the installer as a root"

Have you considered use fakeroot? E.g. something like

	mkdir $1
	truncate -s ${SIZE}M $1.img
	mkfs.ext4 $1.img
	fuse2fs -o fakeroot $1.img $1
	fakeroot tar -C $1 -xf root.tar
	fusermount -u $1

Some other filesystems also support methods like this (I believe there
are several tools for FAT, and things like sload for F2FS).
Unfortunately, not every filesystem has a native fuse module or
importing tool. Alternatively, you could use guestfish (which uses qemu
to create filesystems (but which also requires /boot/vmlinuz to be
world-readable for whatever reason)) or lkl (which is the most versatile
solution, if a bit sledgehammer-esque).

---

Have you considered integrating with binman?

--Sean

 >
 > and the documentation is:
 >
 > https://github.com/aplanas/u-boot/blob/dubi/tools/dubi/README
 >
 > It is a POSIX Shell script with minimal dependencies, and fully tested via the
 > script `test_dubi` from the same directory.
 >
 > The referred use case is like this:
 >
 > * In the openSUSE project we generate a bunch of images for multiple ARM /
 > RISC-V devices, and all the logic for the installation is in a place that is
 > hard to reuse. There are other teams that needs this installation logic for
 > other projects.
 >
 > * Could be handy a tool that can tool that can do something like:
 >
 >    # List all the devices models that I can install
 >    dubi --list
 >
 >    # Partition, format and install the bootloader in a local image file
 >    dubi --format --wipe -m rpi4 sdcard.img
 >
 >    # ... or in a real device
 >    dubi --format --wipe -m rpi4 /dev/sdc
 >
 > The models are stored in separated directories:
 >
 > /usr/share/u-boot/
 >     rpi4/
 >        dubi.dsc
 >        uboot.bin
 >        boot.scr
 >     rpi3/
 >        ...
 >
 > And a typical description file can be something like this:
 >
 >    # SPDX-License-Identifier: GPL-2.0+
 >
 >    MODEL=sunxi
 >    CPU=a31
 >    DESCRIPTION="Allwinner A31 (sun6i) SoC features a Quad-Core Cortex-A7 ARM
 > Processor SoC, and a Power VR SGX544 (with 8 shader engines) GPU from
 > Imagination Technologies."
 >
 >    EFI=n
 >    LABEL=dos
 >
 >    FILESYSTEM=ext4
 >
 >    register partition size=16MiB type=c
 >    register partition size=500MiB type=swap
 >    register partition type=linux
 >
 >    register bootloader u-boot-sunxi-with-spl.bin dst=8k
 >    register bootscr boot.scr partition=1 path=/
 >
 >
 > ... or something like that.
 >
 > The current script more or less to that (minus some missing calls to mkimage,
 > WIP), and allows you to inject your own code for the different stages of the
 > installation process, in case that the defaults get too short.
 >
 > Is this a path for an installer that makes sense? If so, any thoughts about
 > changes / improvements?
 >
 > Thanks!
 >