mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Alexander Dahl via ptxdist <ptxdist@pengutronix.de>
To: ptxdist@pengutronix.de
Cc: Alexander Dahl <ada@thorsis.com>
Subject: [ptxdist] [PATCH v2 0/5] libubootenv: New package to replace target u-boot-tools
Date: Fri, 19 Sep 2025 12:06:38 +0200	[thread overview]
Message-ID: <20250919100643.199174-1-ada@thorsis.com> (raw)

Hello,

some months ago I sent an RFC series for swupdate which contained a new
libubootenv package as dependency.  No need for swupdate from my side,
but I have two more use cases for libubootenv now.  This is why I took
the two patches from the old series and made a v2 without swupdate.

I just added three new patches now, but if needed those can be squashed
in any way the maintainer thinks would fit better.  For now makes it
better comparable to v1 from March 2025.

I'm not sure how to realize the dependency from the rauc package,
though.  Currently RAUC_U_BOOT selects (target) U_BOOT_TOOLS.  Now we
have two compatible alternatives for the fw_printenv/fw_setenv tools
from two differente packages.  Either of these packages would be
sufficient to provide the dependency for RAUC, but how should this be
expressed in the Kconfig menu?  (This is a runtime dependency only, it
just works by disabling RAUC_U_BOOT and selecting LIBUBOOTENV_TOOLS
here.  As far as I understood, something like this is not possible?

	select LIBUBOOTENV_TOOLS || U_BOOT_TOOLS

Background: when porting a new board using the u-boot bootloader to use
rauc, I noticed the kernel does not allow to write to mmcblockXbootX
devices per default.  When rauc writes to such devices by itself it
disables the readonly mode through sysfs, and enables the write
protection again after writing.  For reading/writing the u-boot
environment however it calls fw_printenv/fw_setenv, which were coming
from u-boot itself and are built in ptxdist by the u-boot-tools package.
Those tools can not write to these mmc boot partitions, but the drop in
replacements from libubootenv can.

The other reason is libubootenv variants of fw_printenv/fw_setenv might
be able to use _one_ fw_env.config for multiple boards, if bootloader
puts same information about u-boot into devicetree's 'chosen' node.
Did not test that yet, though.

v2:
- Reworded some commit messages
- Added three new patches

RFC:
- Link: https://lore.ptxdist.org/ptxdist/mailman.2955.1742547175.466.ptxdist@pengutronix.de/

Alexander Dahl (5):
  libubootenv: Introduce new package
  libubootenv: Add option for installing tools
  libubootenv: Install config file to target
  libubootenv: Import some fixes from master
  libubootenv: Make yaml support optional

 .../0001-Make-libyaml-optional.patch          | 1507 +++++++++++++++++
 ..._config-fix-segfault-on-empty-config.patch |   40 +
 ...-Fix-warning-when-copying-UBI-volume.patch |   35 +
 ...segfault-due-to-uninitialized-pointe.patch |   32 +
 ...nfig.c-Catch-NULL-pointer-for-calloc.patch |   30 +
 patches/libubootenv-0.3.6/series              |    8 +
 rules/libubootenv.in                          |   35 +
 rules/libubootenv.make                        |   67 +
 8 files changed, 1754 insertions(+)
 create mode 100644 patches/libubootenv-0.3.6/0001-Make-libyaml-optional.patch
 create mode 100644 patches/libubootenv-0.3.6/0002-extended_config-fix-segfault-on-empty-config.patch
 create mode 100644 patches/libubootenv-0.3.6/0003-BUG-Fix-warning-when-copying-UBI-volume.patch
 create mode 100644 patches/libubootenv-0.3.6/0004-libubootenv-fix-segfault-due-to-uninitialized-pointe.patch
 create mode 100644 patches/libubootenv-0.3.6/0005-extended_config.c-Catch-NULL-pointer-for-calloc.patch
 create mode 100644 patches/libubootenv-0.3.6/series
 create mode 100644 rules/libubootenv.in
 create mode 100644 rules/libubootenv.make


base-commit: db4766231f67a702335986c510727f76459f53fc
-- 
2.39.5




             reply	other threads:[~2025-09-19 10:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-19 10:06 Alexander Dahl via ptxdist [this message]
2025-09-19 10:06 ` [ptxdist] [PATCH v2 1/5] libubootenv: Introduce new package Alexander Dahl via ptxdist
2025-09-22 11:04   ` [ptxdist] [APPLIED] " Michael Olbrich
2025-09-19 10:06 ` [ptxdist] [PATCH v2 2/5] libubootenv: Add option for installing tools Alexander Dahl via ptxdist
2025-09-22 11:04   ` [ptxdist] [APPLIED] " Michael Olbrich
2025-09-19 10:06 ` [ptxdist] [PATCH v2 3/5] libubootenv: Install config file to target Alexander Dahl via ptxdist
2025-09-22 11:04   ` [ptxdist] [APPLIED] " Michael Olbrich
2025-09-19 10:06 ` [ptxdist] [PATCH v2 4/5] libubootenv: Import some fixes from master Alexander Dahl via ptxdist
2025-09-22 11:04   ` [ptxdist] [APPLIED] " Michael Olbrich
2025-09-19 10:06 ` [ptxdist] [PATCH v2 5/5] libubootenv: Make yaml support optional Alexander Dahl via ptxdist
2025-09-22 11:04   ` [ptxdist] [APPLIED] " Michael Olbrich

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=20250919100643.199174-1-ada@thorsis.com \
    --to=ptxdist@pengutronix.de \
    --cc=ada@thorsis.com \
    /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