* [Buildroot] [RFC] package/rpi-firmware: Allow to deploy multiple firmware files
@ 2021-02-08 13:13 Stefan Agner
2021-02-13 17:05 ` Peter Seiderer
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Agner @ 2021-02-08 13:13 UTC (permalink / raw)
To: buildroot
Add a new config option to allow a specific list of firmware files to be
deployed. This is useful if the system needs to decide at runtime which
firmware to use.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
We need this in Home Assistant OS since depending on configuration users want to
use a different firmware. Would something like this be acceptable upstream?
package/rpi-firmware/Config.in | 10 ++++++++++
package/rpi-firmware/rpi-firmware.mk | 19 +++++++++++++++++--
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/package/rpi-firmware/Config.in b/package/rpi-firmware/Config.in
index f5a25c5680..ce31ad46de 100644
--- a/package/rpi-firmware/Config.in
+++ b/package/rpi-firmware/Config.in
@@ -58,8 +58,18 @@ config BR2_PACKAGE_RPI_FIRMWARE_CD
The cut-down firmware, for emergency situations, with only
features required to boot a Linux kernel.
+config BR2_PACKAGE_RPI_FIRMWARE_CUSTOM_LIST
+ bool "deploy firmware files from list"
+ help
+ Deploy firmware files as listed.
+
endchoice
+config BR2_PACKAGE_RPI_FIRMWARE_LIST
+ string
+ default "start.elf start_x.elf start_cd.elf fixup.dat fixup_x.dat fixup_cd.dat" if BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI
+ default "start4.elf start4x.elf start4cd.elf fixup4.dat fixup4x.dat fixup4cd.dat" if BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI4
+
config BR2_PACKAGE_RPI_FIRMWARE_BOOT
string
default "" if BR2_PACKAGE_RPI_FIRMWARE_DEFAULT && BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI
diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
index fe7a099407..d7d432d866 100644
--- a/package/rpi-firmware/rpi-firmware.mk
+++ b/package/rpi-firmware/rpi-firmware.mk
@@ -48,11 +48,26 @@ define RPI_FIRMWARE_INSTALL_BOOTCODE_BIN
endef
endif
+ifeq ($(BR2_PACKAGE_RPI_FIRMWARE_CUSTOM_LIST),y)
+define RPI_FIRMWARE_INSTALL_FIRMWARE
+ $(foreach firmware,$(call qstrip,$(BR2_PACKAGE_RPI_FIRMWARE_LIST)), \
+ $(INSTALL) -D -m 0644 $(@D)/boot/$(firmware) $(BINARIES_DIR)/rpi-firmware/$(firmware)
+ )
+ $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/gaga
+endef
+else
+define RPI_FIRMWARE_INSTALL_FIRMWARE
+ $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/start.elf
+ $(INSTALL) -D -m 0644 $(@D)/boot/fixup$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).dat $(BINARIES_DIR)/rpi-firmware/fixup.dat
+ $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/gugus
+endef
+endif
+
+
define RPI_FIRMWARE_INSTALL_IMAGES_CMDS
$(INSTALL) -D -m 0644 package/rpi-firmware/config.txt $(BINARIES_DIR)/rpi-firmware/config.txt
$(INSTALL) -D -m 0644 package/rpi-firmware/cmdline.txt $(BINARIES_DIR)/rpi-firmware/cmdline.txt
- $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/start.elf
- $(INSTALL) -D -m 0644 $(@D)/boot/fixup$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).dat $(BINARIES_DIR)/rpi-firmware/fixup.dat
+ $(RPI_FIRMWARE_INSTALL_FIRMWARE)
$(RPI_FIRMWARE_INSTALL_BOOTCODE_BIN)
$(RPI_FIRMWARE_INSTALL_DTB)
$(RPI_FIRMWARE_INSTALL_DTB_OVERLAYS)
--
2.30.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* [Buildroot] [RFC] package/rpi-firmware: Allow to deploy multiple firmware files
2021-02-08 13:13 [Buildroot] [RFC] package/rpi-firmware: Allow to deploy multiple firmware files Stefan Agner
@ 2021-02-13 17:05 ` Peter Seiderer
2021-02-13 17:34 ` Yann E. MORIN
0 siblings, 1 reply; 4+ messages in thread
From: Peter Seiderer @ 2021-02-13 17:05 UTC (permalink / raw)
To: buildroot
Hello Stefan,
On Mon, 8 Feb 2021 14:13:49 +0100, Stefan Agner <stefan@agner.ch> wrote:
> Add a new config option to allow a specific list of firmware files to be
> deployed. This is useful if the system needs to decide at runtime which
> firmware to use.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> We need this in Home Assistant OS since depending on configuration users want to
> use a different firmware. Would something like this be acceptable upstream?
>
> package/rpi-firmware/Config.in | 10 ++++++++++
> package/rpi-firmware/rpi-firmware.mk | 19 +++++++++++++++++--
> 2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/package/rpi-firmware/Config.in b/package/rpi-firmware/Config.in
> index f5a25c5680..ce31ad46de 100644
> --- a/package/rpi-firmware/Config.in
> +++ b/package/rpi-firmware/Config.in
> @@ -58,8 +58,18 @@ config BR2_PACKAGE_RPI_FIRMWARE_CD
> The cut-down firmware, for emergency situations, with only
> features required to boot a Linux kernel.
>
> +config BR2_PACKAGE_RPI_FIRMWARE_CUSTOM_LIST
> + bool "deploy firmware files from list"
> + help
> + Deploy firmware files as listed.
> +
> endchoice
>
> +config BR2_PACKAGE_RPI_FIRMWARE_LIST
> + string
> + default "start.elf start_x.elf start_cd.elf fixup.dat fixup_x.dat fixup_cd.dat" if BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI
> + default "start4.elf start4x.elf start4cd.elf fixup4.dat fixup4x.dat fixup4cd.dat" if BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI4
> +
> config BR2_PACKAGE_RPI_FIRMWARE_BOOT
> string
> default "" if BR2_PACKAGE_RPI_FIRMWARE_DEFAULT && BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI
> diff --git a/package/rpi-firmware/rpi-firmware.mk b/package/rpi-firmware/rpi-firmware.mk
> index fe7a099407..d7d432d866 100644
> --- a/package/rpi-firmware/rpi-firmware.mk
> +++ b/package/rpi-firmware/rpi-firmware.mk
> @@ -48,11 +48,26 @@ define RPI_FIRMWARE_INSTALL_BOOTCODE_BIN
> endef
> endif
>
> +ifeq ($(BR2_PACKAGE_RPI_FIRMWARE_CUSTOM_LIST),y)
> +define RPI_FIRMWARE_INSTALL_FIRMWARE
> + $(foreach firmware,$(call qstrip,$(BR2_PACKAGE_RPI_FIRMWARE_LIST)), \
> + $(INSTALL) -D -m 0644 $(@D)/boot/$(firmware) $(BINARIES_DIR)/rpi-firmware/$(firmware)
> + )
> + $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/gaga
> +endef
> +else
> +define RPI_FIRMWARE_INSTALL_FIRMWARE
> + $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/start.elf
> + $(INSTALL) -D -m 0644 $(@D)/boot/fixup$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).dat $(BINARIES_DIR)/rpi-firmware/fixup.dat
> + $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/gugus
> +endef
> +endif
> +
> +
> define RPI_FIRMWARE_INSTALL_IMAGES_CMDS
> $(INSTALL) -D -m 0644 package/rpi-firmware/config.txt $(BINARIES_DIR)/rpi-firmware/config.txt
> $(INSTALL) -D -m 0644 package/rpi-firmware/cmdline.txt $(BINARIES_DIR)/rpi-firmware/cmdline.txt
> - $(INSTALL) -D -m 0644 $(@D)/boot/start$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).elf $(BINARIES_DIR)/rpi-firmware/start.elf
> - $(INSTALL) -D -m 0644 $(@D)/boot/fixup$(BR2_PACKAGE_RPI_FIRMWARE_BOOT).dat $(BINARIES_DIR)/rpi-firmware/fixup.dat
> + $(RPI_FIRMWARE_INSTALL_FIRMWARE)
> $(RPI_FIRMWARE_INSTALL_BOOTCODE_BIN)
> $(RPI_FIRMWARE_INSTALL_DTB)
> $(RPI_FIRMWARE_INSTALL_DTB_OVERLAYS)
Seems the rpi-firmware package tries to be too smart here and to workaround
the smart logic is getting more and more complicated (and your patch is
something orthogonal to the latest changes applied, see [1] for resulting
commit and [2] ff. for discussion) and the package logic is to much focused
to do the right thing for exactly one determined target platform...,
neglecting the multi-target enabled SD card use case (or other custom
use cases)...
Maybe the best would be to reduce the rpi-firmware package to a selectable
list of (verbatim) installed firmware files and an editable/customized
config.txt (as already via the post-image.sh script) or go another step
further and provide customized config.txt files per raspberry pi defconfig
(as most buildroot/rpi user will need a customized version anyway e.g.
to enable custom dtoverlays as vc4-kms-v3d-pi4) and drop the post-image.sh
script?
Regards,
Peter
[1] https://git.buildroot.net/buildroot/commit/?id=1bdc0334ff6273761b2e7fda730cdcc7e1f46862
[2] http://lists.busybox.net/pipermail/buildroot/2020-June/285566.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Buildroot] [RFC] package/rpi-firmware: Allow to deploy multiple firmware files
2021-02-13 17:05 ` Peter Seiderer
@ 2021-02-13 17:34 ` Yann E. MORIN
2021-02-13 17:58 ` Peter Seiderer
0 siblings, 1 reply; 4+ messages in thread
From: Yann E. MORIN @ 2021-02-13 17:34 UTC (permalink / raw)
To: buildroot
Peter, Stefan, All,
On 2021-02-13 18:05 +0100, Peter Seiderer spake thusly:
> On Mon, 8 Feb 2021 14:13:49 +0100, Stefan Agner <stefan@agner.ch> wrote:
> > Add a new config option to allow a specific list of firmware files to be
> > deployed. This is useful if the system needs to decide at runtime which
> > firmware to use.
[--SNIP--]
> Seems the rpi-firmware package tries to be too smart here and to workaround
> the smart logic is getting more and more complicated
Agreed.
> (and your patch is
> something orthogonal to the latest changes applied, see [1] for resulting
> commit and [2] ff. for discussion) and the package logic is to much focused
> to do the right thing for exactly one determined target platform...,
> neglecting the multi-target enabled SD card use case (or other custom
> use cases)...
Well, that is what Buildroot is mostly: build a rootfs for one specific
hardware which "global purpose" does not change over the course of the
life of that hardware, and for the rpi case, that meant the GPU firmware
would not change.
So that's how the rpi-firmware came to be, and how I (amongst others)
tried to steer it so far.
And indeed that does not account for devices where the purpose may
change without re-flashing a new version.
> Maybe the best would be to reduce the rpi-firmware package to a selectable
> list of (verbatim) installed firmware files and an editable/customized
> config.txt (as already via the post-image.sh script) or go another step
> further and provide customized config.txt files per raspberry pi defconfig
> (as most buildroot/rpi user will need a customized version anyway e.g.
> to enable custom dtoverlays as vc4-kms-v3d-pi4) and drop the post-image.sh
> script?
I think that we should just simply copy over all the firmware files for
the selected variant (0/1/2/3 vs. 4), and just have a static config.txt
that just boots the default firmware. Then, for people who want to use
another firmware will have to provide their own post-image script
(either as a replacement for the bundeld one, or as an additional one)
to further tweak config.txt to boot the firmware they need and/or remove
those firmwares they do not want.
This makes the rpi-firmware more in-line with the basic mantra of
Buildroot, which is basically also the mantra of Buildroot: provide a
basic bootable setup that just brings up the board to a shell (and
optionally a very few other stuff) and let the user customise that.
So in the end, although this would probably go against my initial
thinking (to provide one-purpose setup), I will welcome such a
simplification.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Buildroot] [RFC] package/rpi-firmware: Allow to deploy multiple firmware files
2021-02-13 17:34 ` Yann E. MORIN
@ 2021-02-13 17:58 ` Peter Seiderer
0 siblings, 0 replies; 4+ messages in thread
From: Peter Seiderer @ 2021-02-13 17:58 UTC (permalink / raw)
To: buildroot
Hello Yann,
On Sat, 13 Feb 2021 18:34:26 +0100, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> Peter, Stefan, All,
>
> On 2021-02-13 18:05 +0100, Peter Seiderer spake thusly:
> > On Mon, 8 Feb 2021 14:13:49 +0100, Stefan Agner <stefan@agner.ch> wrote:
> > > Add a new config option to allow a specific list of firmware files to be
> > > deployed. This is useful if the system needs to decide at runtime which
> > > firmware to use.
> [--SNIP--]
> > Seems the rpi-firmware package tries to be too smart here and to workaround
> > the smart logic is getting more and more complicated
>
> Agreed.
>
> > (and your patch is
> > something orthogonal to the latest changes applied, see [1] for resulting
> > commit and [2] ff. for discussion) and the package logic is to much focused
> > to do the right thing for exactly one determined target platform...,
> > neglecting the multi-target enabled SD card use case (or other custom
> > use cases)...
>
> Well, that is what Buildroot is mostly: build a rootfs for one specific
> hardware which "global purpose" does not change over the course of the
> life of that hardware, and for the rpi case, that meant the GPU firmware
> would not change.
It is not about the 'change over the course of the live of that hardware'
but about the ability to create/provide a SD card image which fits more
than one fixed/limited target..., I believe a valid use case...
>
> So that's how the rpi-firmware came to be, and how I (amongst others)
> tried to steer it so far.
>
> And indeed that does not account for devices where the purpose may
> change without re-flashing a new version.
>
> > Maybe the best would be to reduce the rpi-firmware package to a selectable
> > list of (verbatim) installed firmware files and an editable/customized
> > config.txt (as already via the post-image.sh script) or go another step
> > further and provide customized config.txt files per raspberry pi defconfig
> > (as most buildroot/rpi user will need a customized version anyway e.g.
> > to enable custom dtoverlays as vc4-kms-v3d-pi4) and drop the post-image.sh
> > script?
>
> I think that we should just simply copy over all the firmware files for
> the selected variant (0/1/2/3 vs. 4), and just have a static config.txt
> that just boots the default firmware. Then, for people who want to use
> another firmware will have to provide their own post-image script
> (either as a replacement for the bundeld one, or as an additional one)
> to further tweak config.txt to boot the firmware they need and/or remove
> those firmwares they do not want.
The 'a static config.txt' will not work, see the post-image.sh quirks
for miniuart-bt-overlay (to enable the serial console on RPi3/RPi4)
and the aarch64 one for the 64-bit builds, instead at least a per
defconfig/board one is needed (some can share a common one)...
>
> This makes the rpi-firmware more in-line with the basic mantra of
> Buildroot, which is basically also the mantra of Buildroot: provide a
> basic bootable setup that just brings up the board to a shell (and
> optionally a very few other stuff) and let the user customise that.
Count a enabled serial console to the basic stuff (see above)...
>
> So in the end, although this would probably go against my initial
> thinking (to provide one-purpose setup), I will welcome such a
> simplification.
Will eventually try to provide a patch the next days....
Regards,
Peter
>
> Regards,
> Yann E. MORIN.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-02-13 17:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-08 13:13 [Buildroot] [RFC] package/rpi-firmware: Allow to deploy multiple firmware files Stefan Agner
2021-02-13 17:05 ` Peter Seiderer
2021-02-13 17:34 ` Yann E. MORIN
2021-02-13 17:58 ` Peter Seiderer
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.