From: Andrei Warkentin <awarkentin@vmware.com>
For PFTF developers working on the firmware, being able to use a
local TF-A build without extra extra copy operations ends up being
very helpful.
This can be accomplished via a TFA_BUILD_ARTIFACTS option passed
to the edk2 build tool.
If/when the Pi 3 and 4 DSC/FDFs become unified, this will be even
more important to trivially perform a full clean upstream build
for either platform, without having to worry about different TF-A
deliverables - Pi 4 uses bl31.bin, while Pi 3 uses fip.bin and bl1.bin.
A similar Pi 3 patch to follow.
The context for this is the community Raspberry Pi 4 firmware
project (https://https://rpi4-uefi.dev, https://github.com/pftf),
which you might have heard already about from Pete Batard, who
upstreamed much of my previous Pi 3 and Pi 4 enablement patches.
Signed-off-by: Andrei Warkentin <awarkentin@vmware.com>
---
Platform/RaspberryPi/RPi4/RPi4.dsc | 14 ++++++++++++++
Platform/RaspberryPi/RPi4/RPi4.fdf | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc b/Platform/RaspberryPi/RPi4/RPi4.dsc
index c039f6df2eb4..1d38f4ab051d 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -40,6 +40,20 @@ [Defines]
DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x8000004F
DEFINE ACPI_BASIC_MODE_ENABLE = FALSE
+!ifndef TFA_BUILD_ARTIFACTS
+ #
+ # Default TF-A binary checked into edk2-non-osi.
+ #
+ DEFINE TFA_BUILD_BL31 = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl31_pl011.bin
+!else
+ #
+ # Usually we use the checked-in binaries, but for developers working
+ # on the firmware, being able to use a local TF-A build without extra copy
+ # operations ends up being very helpful.
+ #
+ DEFINE TFA_BUILD_BL31 = $(TFA_BUILD_ARTIFACTS)/bl31.bin
+!endif
+
################################################################################
#
# Library Class section - list of all Library Classes needed by this Platform.
diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf b/Platform/RaspberryPi/RPi4/RPi4.fdf
index b2a6ac9e6c66..8e2d6fd49a9d 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.fdf
+++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
@@ -51,7 +51,7 @@ [FD.RPI_EFI]
# ATF primary boot image
#
0x00000000|0x00020000
-FILE = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl31_pl011.bin
+FILE = $(TFA_BUILD_BL31)
#
# DTB.
--
2.21.0.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#55213): https://edk2.groups.io/g/devel/message/55213
Mute This Topic: https://groups.io/mt/71676028/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
On Mon, 2 Mar 2020 at 15:42, Pete Batard <pete@akeo.ie> wrote: > > From: Andrei Warkentin <awarkentin@vmware.com> > > For PFTF developers working on the firmware, being able to use a > local TF-A build without extra extra copy operations ends up being > very helpful. > > This can be accomplished via a TFA_BUILD_ARTIFACTS option passed > to the edk2 build tool. > > If/when the Pi 3 and 4 DSC/FDFs become unified, this will be even > more important to trivially perform a full clean upstream build > for either platform, without having to worry about different TF-A > deliverables - Pi 4 uses bl31.bin, while Pi 3 uses fip.bin and bl1.bin. > > A similar Pi 3 patch to follow. > > The context for this is the community Raspberry Pi 4 firmware > project (https://https://rpi4-uefi.dev, https://github.com/pftf), > which you might have heard already about from Pete Batard, who > upstreamed much of my previous Pi 3 and Pi 4 enablement patches. > > Signed-off-by: Andrei Warkentin <awarkentin@vmware.com> Do we really need this patch? For development, you can put anything you want here. For doing releases, I'd expect edk2-platforms to be in sync with edk2-non-osi, given that there are more blobs there than TF-A, right? > --- > Platform/RaspberryPi/RPi4/RPi4.dsc | 14 ++++++++++++++ > Platform/RaspberryPi/RPi4/RPi4.fdf | 2 +- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc b/Platform/RaspberryPi/RPi4/RPi4.dsc > index c039f6df2eb4..1d38f4ab051d 100644 > --- a/Platform/RaspberryPi/RPi4/RPi4.dsc > +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc > @@ -40,6 +40,20 @@ [Defines] > DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x8000004F > DEFINE ACPI_BASIC_MODE_ENABLE = FALSE > > +!ifndef TFA_BUILD_ARTIFACTS > + # > + # Default TF-A binary checked into edk2-non-osi. > + # > + DEFINE TFA_BUILD_BL31 = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl31_pl011.bin > +!else > + # > + # Usually we use the checked-in binaries, but for developers working > + # on the firmware, being able to use a local TF-A build without extra copy > + # operations ends up being very helpful. > + # > + DEFINE TFA_BUILD_BL31 = $(TFA_BUILD_ARTIFACTS)/bl31.bin > +!endif > + > ################################################################################ > # > # Library Class section - list of all Library Classes needed by this Platform. > diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf b/Platform/RaspberryPi/RPi4/RPi4.fdf > index b2a6ac9e6c66..8e2d6fd49a9d 100644 > --- a/Platform/RaspberryPi/RPi4/RPi4.fdf > +++ b/Platform/RaspberryPi/RPi4/RPi4.fdf > @@ -51,7 +51,7 @@ [FD.RPI_EFI] > # ATF primary boot image > # > 0x00000000|0x00020000 > -FILE = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl31_pl011.bin > +FILE = $(TFA_BUILD_BL31) > > # > # DTB. > -- > 2.21.0.windows.1 > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55217): https://edk2.groups.io/g/devel/message/55217 Mute This Topic: https://groups.io/mt/71676028/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Hi Ard, > Do we really need this patch? For development, you can put anything > you want here. For doing releases, I'd expect edk2-platforms to be in > sync with edk2-non-osi, given that there are more blobs there than > TF-A, right? This is a developer productivity improvement that I've found to be useful and it has no impact on others for the default case of building code for release. Sure, you can copy things around and stage/unstage files, but I like automating my work and I tend to track the upstream TF-A (for regressions, rpi4-uefi.dev work), so being able to quickly generate builds both with internal and external TF-A and without extra hoopla has been key. The time I avoid dealing with dirty trees is time I can spend elsewhere else making Pi 4 implementation better. There aren't really any other blobs that matter for Pi 4...The embedded DTB is going to go away as part of fixing the regression seen with https://github.com/pftf/RPi4/issues/17 (on the Pi 4 you can't really boot anyway without passing a DTB in config.txt). A -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55226): https://edk2.groups.io/g/devel/message/55226 Mute This Topic: https://groups.io/mt/71676028/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Mon, 2 Mar 2020 at 18:40, Andrei Warkentin <awarkentin@vmware.com> wrote: > > Hi Ard, > > > Do we really need this patch? For development, you can put anything > > you want here. For doing releases, I'd expect edk2-platforms to be in > > sync with edk2-non-osi, given that there are more blobs there than > > TF-A, right? > > This is a developer productivity improvement that I've found to be useful and it has no impact on others for the default case of building code for release. > > Sure, you can copy things around and stage/unstage files, but I like automating my work and I tend to track the upstream TF-A (for regressions, rpi4-uefi.dev work), > so being able to quickly generate builds both with internal and external TF-A and without extra hoopla has been key. The time I avoid dealing with dirty trees is time I can spend elsewhere else making Pi 4 implementation better. > > There aren't really any other blobs that matter for Pi 4...The embedded DTB is going to go away as part of fixing the regression seen with https://github.com/pftf/RPi4/issues/17 (on the Pi 4 you can't really boot anyway without passing a DTB in config.txt). > Fair enough. I still don't quite see the point, but I don't really mind either. Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Pushed as 30324eefb3a4..07cc442f7212 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55228): https://edk2.groups.io/g/devel/message/55228 Mute This Topic: https://groups.io/mt/71676028/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2026 Red Hat, Inc.