From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 19 Sep 2025 12:07:04 +0200 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uzY1A-004oQs-0y for lore@lore.pengutronix.de; Fri, 19 Sep 2025 12:07:04 +0200 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1uzY1A-0007by-3S; Fri, 19 Sep 2025 12:07:04 +0200 Received: from mail.thorsis.com ([2003:a:e28:26e4::10]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1uzY0u-0007ar-QZ for ptxdist@pengutronix.de; Fri, 19 Sep 2025 12:06:49 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 9FACA1488D45 for ; Fri, 19 Sep 2025 12:06:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thorsis.com; s=dkim; t=1758276407; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=SZhHyGansduDQfL13YkO/SClPdfIin+NSqzCEmpMIXI=; b=qLtpiw17B9e8hiU1CIsMzm7IHpm3ScGZzF9sA6DWF3fjGd1wQyuxSz1ti0MghjvEWPQdf1 3W4VxPUbgKqLbcnRsdmdSxrGqDbxqeAGrQ0Vsd+VS5f0tdD1WQArTWT0+wr8mEtpXLENiR ZT62x4ipgPitIpPdILVZXjy/0QQCBRsA9yipKYNyCqgYPMFsvM0iGclfx+kTrEehLNmRWp izZM/l8/UeNDRyX8BdWeMEfMHfce4Vnz2AV02kPQEqJyYk6P9iHKG+tLNasYmzkCPZNEmS ww3bcSvgOoCQjTI1w1oHKLvnv0hi1byz4NALytZC232RNKPg9JvyHxtyjRIjeQ== To: ptxdist@pengutronix.de Date: Fri, 19 Sep 2025 12:06:38 +0200 Message-Id: <20250919100643.199174-1-ada@thorsis.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.whiteo.stw.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Subject: [ptxdist] [PATCH v2 0/5] libubootenv: New package to replace target u-boot-tools X-BeenThere: ptxdist@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: PTXdist Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Alexander Dahl via ptxdist Reply-To: ptxdist@pengutronix.de Cc: Alexander Dahl Sender: "ptxdist" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: ptxdist-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false 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