public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: awarkentin@vmware.com
To: "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Subject: [PATCH] Platform/RPi4: allow overriding TF-A binaries during build
Date: Mon, 2 Mar 2020 02:33:56 +0000	[thread overview]
Message-ID: <20200302023315.46048-1-awarkentin@vmware.com> (raw)

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 7c19376725..9af472d3f0 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -40,6 +40,20 @@
   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 52ae1e5b65..5356cfd4b3 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.fdf
+++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
@@ -51,7 +51,7 @@ NumBlocks     = 0x200
 # ATF primary boot image
 #
 0x00000000|0x00020000
-FILE = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl31_pl011.bin
+FILE = $(TFA_BUILD_BL31)
 
 #
 # DTB.
-- 
2.17.1


                 reply	other threads:[~2020-03-02  2:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20200302023315.46048-1-awarkentin@vmware.com \
    --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