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!
>

Reply via email to