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!