Do make sense an u-boot installer?

Do make sense an u-boot installer?

[Alberto Planas]

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

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!

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nuremberg
Germany

(HRB 36809, AG N?rnberg)
Managing Director: Felix Imend?rffer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210413/214647e7/attachment.sig>

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