* Re: [PATCH] scripts/make-gpt.sh: make GPT offset configurable
2022-09-28 14:02 [PATCH] scripts/make-gpt.sh: make GPT offset configurable Ivan Nikolaenko
@ 2022-09-29 10:22 ` Alyssa Ross
0 siblings, 0 replies; 2+ messages in thread
From: Alyssa Ross @ 2022-09-29 10:22 UTC (permalink / raw)
To: Ivan Nikolaenko; +Cc: devel, Ville Ilvonen
[-- Attachment #1: Type: text/plain, Size: 5138 bytes --]
Ivan Nikolaenko <ivan.nikolaenko@unikie.com> writes:
> These changes can be used in an external configuration layer as
> follows:
> overlays = [
> (self: super:
> {
> gptOffset = 9437184;
> })
> ];
>
> Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
> ---
>
> This patch is not a solution but just a proposal about how things can be done.
> There is at least one another way of doing this (having our own make-gpt.sh script),
> but I thought that editing of the current one is better way.
>
> Also I don't know should we also consider other images and rootfs be fixed this way.
>
> img/live/Makefile | 3 ++-
> img/live/default.nix | 1 +
> scripts/make-gpt.sh | 22 ++++++++++++++++++++--
> 3 files changed, 23 insertions(+), 3 deletions(-)
Hi Ivan, thanks for the proposal.
I still think this is a cross-distribution problem looking for a
cross-distribution solution, not something specific to Spectrum. Other
distributions providing vendor-neutral ARM images (e.g. Fedora, NixOS)
have exactly the same problem. Solving it as part of Spectrum doesn't
help them solve the same problem, and I think it's critically important
for the long term maintainability of Spectrum that we be wary of
implementing custom solutions for cross-distro problems, even when they
start out pretty small like this one.
So I think the best way forward here would be to have a small program
that lives outside of Spectrum. It would take a firmware image, a
generic ARM OS GPT image, and a configurable offset (or, if more
board-specific knowledge ends up being required, some sort of board
configuration file). It would then create a new GPT image, install the
firmware appropriately, and then copy the partitions from the generic
image, offset appropriately.
[[ To be honest, I'm surprised this program doesn't exist already
considering its limited scope, but I haven't seen anything like it. I
suspect part of the reason is that most distros have still not caught up
with the idea of installing an image, rather than doing a bespoke
imperative installation, but that's definitely the direction things are
moving in — e.g. systemd is doing lots of work to support image-based
installs. [1] ]]
This approach would avoid introducing additional complexity into
Spectrum, _and_ would work for other operating systems too. It could be
_the_ way to produce firmware+OS images for people who need to do that,
reducing the amount of effort required to be spent on this problem
across the ecosystem by users, integrators, and distributors. And the
program should be pretty small and easy to write.
It wouldn't be duplicating Spectrum's make-gpt.sh particularly, because
the two would be focused on different tasks. make-gpt.sh takes some
filesystem images and produces a GPT image from them, whereas this
program would take an existing GPT and add in the platform-specific
firmware. And it wouldn't need to be duplicated for every board
somebody wanted to build images for, because the same program should be
flexible enough to work for all boards that work this way.
Some background here that's important to remember is that this is not
something most end users would be expected to need to do. The ideal way
of installing Spectrum on ARM, for an end user, would be to install a
firmware distribution on separate storage (or if their board comes with
firmware pre-installed that supports standards-based boot, they don't
even have to do that!), and then install Spectrum on main storage. The
firmware and OS could be updated and maintained independently*, and so
Spectrum doesn't have to also be an ARM firmware distribution — we can
leave that to other capable projects. Combined firmware+OS images are
therefore mainly useful to two groups: end users using boards that don't
have separate storage for firmware (or for which there is no firmware
available that supports booting from main storage), or organisations who
want to roll a system out across lots of devices, for whom it's more
convenient to only have a single image on a single type of storage to
worry about.
If there's some reason this wouldn't work, and we absolutely *need*
changes in Spectrum to accomodate firmware in the images we build, I'm
willing to reconsider, but with my current knowledge, it looks to me
like it could be solved distribution-independently, outside of Spectrum,
and that doing so would make things better for everybody trying to
create vendor-neutral ARM OSes.
Previous discussion on this topic:
- https://spectrum-os.org/lists/archives/spectrum-devel/20220828164957.p3743hvijjrkm66b@x220.qyliss.net/
- https://spectrum-os.org/lists/archives/spectrum-devel/0ead7a33-4c9b-6eab-26df-5bbe02fc4649@unikie.com/
[[ As a side note, EBBR recommends using a protective partition rather than
just offseting the GPT, to make the firmware area of the image more
visible. [1] ]]
* I'd really like fwupd support in Spectrum.
[1]: https://arm-software.github.io/ebbr/index.html#gpt-partitioning
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread