From: Lars Schmidt <l.schmidt@pengutronix.de>
To: Alexander Dahl <ada@thorsis.com>, distrokit@pengutronix.de
Subject: Re: [DistroKit] [PATCH v2 0/4] platform: v8a: barebox: Untangle firmware inject files
Date: Mon, 26 May 2025 11:57:22 +0200 [thread overview]
Message-ID: <b2931878-34fa-49d5-822d-50b3e4f48112@pengutronix.de> (raw)
In-Reply-To: <20250523135815.2998753-1-ada@thorsis.com>
Hi Alex,
it's a good idea to separate these changes from the rest
of my patch series and get all the firmware dependencies between
barebox and tf-a sorted out in one shot. I would change my patches
accordingly once yours got merged.
You solved select in the BAREBOX_DEPENDENCIES to select the
corresponding Firmware packages more elegantly.
Referring to your previous message
20250523-oxidation-impatient-e4414c0099c8@thorsis.com
in my patches:
I think the question where the injection of the firmware blobs go
is just two different ways to approach the problem.
In my opinion, the firmware blobs (which are getting injected
into barebox) belong to their corresponding firmware packages and
inject files into barebox.
If in the future anything with those firmware packages changes,
like the blobs getting renamed, moved or disappear,
it is easier to figure out what else needs to be changed.
So think it would be better that these injections are connected to
their corresponding firmware and not to barebox, and thus get named
named firmwarename.barebox.*
I think this could make future maintenance easier.
In the end it's just two different approaches and both have their valid
reason. So I'd be fine with your solution, too.
Greetings
Lars
On 23.05.25 15:58, Alexander Dahl wrote:
> Hello Lars, everyone,
>
> this is a one year later series with previously dropped patches from
> another series, and basically a follow-up to those mails:
>
> - <20240425-unlivable-approval-c55177db2d5c@thorsis.com>
> - <20250523081049.1693633-6-l.schmidt@pengutronix.de>
>
> Picking this up now, because this was almost ready last year already,
> but I did not manage to rework it for resubmission. Not meant to be
> rude, but maybe suitable for discussing the right approach of firmware
> injection into different bootloader packages.
>
> When having another look, I think it was correct to drop v1, I did not
> go far enough with the first shot. This is done now by patch 3/4 which
> separates the imx-firmware injects from the tf-a injects into separate
> fixup packages for barebox. Patch 4/4 picks up an idea by Lars, please
> let me know when this should be attributed differently.
>
> Note, this is in conflict with the series "[PATCH 00/12] Add beagleplay
> support to DistroKit" sent earlier this week.
>
> Build tested twice on vanilla DistroKit _and_ in a custom BSP using
> DistroKit as a base layer and disabling most DistroKit boards. Upper
> layer builds U-Boot for three different i.MX8/9 based boards, depending
> on both firmware-imx and tf-a.
>
> v2:
> - 6 out of 9 patches from original series applied, series renamed
> - rebased remaining patches to master
> - reworked patch 3/4 to also break out tf-a, not only firmware-imx
> - added new patch 4/4 to not inject all tf-a artifacts unconditionally
>
> v1:
> - Link: https://lore.distrokit.org/distrokit/20240425080303.171897-1-ada@thorsis.com/
>
> Greets
> Alex
>
> Alexander Dahl (4):
> platform: v8a: firmware-rockchip: Move barebox injects to separate
> package
> platform: v8a: barebox: Remove extra host prog
> platform: v8a: firmware-imx: Break out barebox injects to separate
> packages
> platform: v8a: barebox: Inject tf-a binaries conditionally
>
> configs/platform-v8a/platformconfig | 3 ++
> configs/platform-v8a/platforms/barebox.imx.in | 12 ++++++++
> .../platforms/barebox.rockchip.in | 14 +++++++++
> .../platform-v8a/platforms/barebox.tf-a.in | 11 +++++++
> .../platform-v8a/platforms/firmware-imx.in | 6 ----
> .../platforms/firmware-rockchip.in | 5 ----
> configs/platform-v8a/rules/barebox.imx.make | 22 ++++++++++++++
> .../platform-v8a/rules/barebox.rockchip.make | 21 ++++++++++++--
> configs/platform-v8a/rules/barebox.tf-a.make | 29 +++++++++++++++++++
> configs/platform-v8a/rules/firmware-imx.make | 21 --------------
> .../platform-v8a/rules/firmware-rockchip.make | 10 -------
> 11 files changed, 110 insertions(+), 44 deletions(-)
> create mode 100644 configs/platform-v8a/platforms/barebox.imx.in
> create mode 100644 configs/platform-v8a/platforms/barebox.rockchip.in
> create mode 100644 configs/platform-v8a/platforms/barebox.tf-a.in
> create mode 100644 configs/platform-v8a/rules/barebox.imx.make
> create mode 100644 configs/platform-v8a/rules/barebox.tf-a.make
>
>
> base-commit: 89e05d18da5c3a064013b7ae7cdaa3f44ab307c1
prev parent reply other threads:[~2025-05-26 9:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-23 13:58 Alexander Dahl
2025-05-23 13:58 ` [DistroKit] [PATCH v2 1/4] platform: v8a: firmware-rockchip: Move barebox injects to separate package Alexander Dahl
2025-05-23 13:58 ` [DistroKit] [PATCH v2 2/4] platform: v8a: barebox: Remove extra host prog Alexander Dahl
2025-05-23 13:58 ` [DistroKit] [PATCH v2 3/4] platform: v8a: firmware-imx: Break out barebox injects to separate packages Alexander Dahl
2025-05-23 13:58 ` [DistroKit] [PATCH v2 4/4] platform: v8a: barebox: Inject tf-a binaries conditionally Alexander Dahl
2025-05-26 9:57 ` Lars Schmidt [this message]
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=b2931878-34fa-49d5-822d-50b3e4f48112@pengutronix.de \
--to=l.schmidt@pengutronix.de \
--cc=ada@thorsis.com \
--cc=distrokit@pengutronix.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