public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Pete Batard" <pete@akeo.ie>
To: devel@edk2.groups.io
Cc: ard.biesheuvel@linaro.org, leif@nuviainc.com, awarkentin@vmware.com
Subject: [edk2-devel][RESEND][PATCH 1/2] Platform/RPi4: allow overriding TF-A binaries during build
Date: Mon,  2 Mar 2020 14:42:18 +0000	[thread overview]
Message-ID: <20200302144219.10452-2-pete@akeo.ie> (raw)
In-Reply-To: <20200302144219.10452-1-pete@akeo.ie>

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


  reply	other threads:[~2020-03-02 14:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 14:42 [edk2-devel][RESEND][PATCH 0/2] Resend of the 2 previous RPi patches Pete Batard
2020-03-02 14:42 ` Pete Batard [this message]
2020-03-02 14:54   ` [edk2-devel][RESEND][PATCH 1/2] Platform/RPi4: allow overriding TF-A binaries during build Ard Biesheuvel
2020-03-02 17:40     ` Andrei Warkentin
2020-03-02 18:13       ` Ard Biesheuvel
2020-03-02 14:42 ` [edk2-devel][RESEND][PATCH 2/2] Platform/RPi4/Library/PlatformBootManagerLib: remove dead logo code Pete Batard
2020-03-02 14:49   ` Ard Biesheuvel

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-list 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=20200302144219.10452-2-pete@akeo.ie \
    --to=devel@edk2.groups.io \
    /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