From: Alberto Planas <aplanas@suse.de>
To: u-boot@lists.denx.de
Subject: Do make sense an u-boot installer?
Date: Tue, 13 Apr 2021 19:09:54 +0200 [thread overview]
Message-ID: <3697258.0lk6uhLjKl@lena> (raw)
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>
next reply other threads:[~2021-04-13 17:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 17:09 Alberto Planas [this message]
2021-04-15 18:34 ` Do make sense an u-boot installer? Sean Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3697258.0lk6uhLjKl@lena \
--to=aplanas@suse.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox