From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web10.3522.1588237289943931654 for ; Thu, 30 Apr 2020 02:01:30 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 625881063; Thu, 30 Apr 2020 02:01:29 -0700 (PDT) Received: from [192.168.1.81] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E4DC3F68F; Thu, 30 Apr 2020 02:01:28 -0700 (PDT) Subject: Re: [edk2-platforms][PATCH 1/1] Platform/RPi3: allow overriding TF-A binaries during build To: Andrei Warkentin , devel@edk2.groups.io Cc: leif@nuviainc.com, pete@akeo.ie, philmd@redhat.com References: <20200430084939.51592-1-andrey.warkentin@gmail.com> From: "Ard Biesheuvel" Message-ID: Date: Thu, 30 Apr 2020 11:01:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200430084939.51592-1-andrey.warkentin@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 4/30/20 10:49 AM, Andrei Warkentin wrote: > 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. > > This is like the Pi 4 patch that went in a month ago or so. > > Signed-off-by: Andrei Warkentin Reviewed-by: Ard Biesheuvel Pushed as ee999c857d283acb83d27d2b6edc8519badbfd29 Is it my fault that we are using bl1+fip on RPi3? I don't remember, but I suppose we could easily switch to BL31 only like we have on RPI4 > --- > Platform/RaspberryPi/RPi3/RPi3.dsc | 16 ++++++++++++++++ > Platform/RaspberryPi/RPi3/RPi3.fdf | 4 ++-- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc b/Platform/RaspberryPi/RPi3/RPi3.dsc > index 54ebfdfb..bb5e9b99 100644 > --- a/Platform/RaspberryPi/RPi3/RPi3.dsc > +++ b/Platform/RaspberryPi/RPi3/RPi3.dsc > @@ -33,6 +33,22 @@ > DEFINE INCLUDE_TFTP_COMMAND = FALSE > DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x8000004F > > +!ifndef TFA_BUILD_ARTIFACTS > + # > + # Default TF-A binaries checked into edk2-non-osi. > + # > + DEFINE TFA_BUILD_BL1 = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl1.bin > + DEFINE TFA_BUILD_FIP = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/fip.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_BL1 = $(TFA_BUILD_ARTIFACTS)/bl1.bin > + DEFINE TFA_BUILD_FIP = $(TFA_BUILD_ARTIFACTS)/fip.bin > +!endif > + > ################################################################################ > # > # Library Class section - list of all Library Classes needed by this Platform. > diff --git a/Platform/RaspberryPi/RPi3/RPi3.fdf b/Platform/RaspberryPi/RPi3/RPi3.fdf > index e467b5cd..11e3f5a2 100644 > --- a/Platform/RaspberryPi/RPi3/RPi3.fdf > +++ b/Platform/RaspberryPi/RPi3/RPi3.fdf > @@ -51,7 +51,7 @@ NumBlocks = 0x200 > # ATF primary boot image > # > 0x00000000|0x00010000 > -FILE = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl1.bin > +FILE = $(TFA_BUILD_BL1) > > # > # DTB. > @@ -63,7 +63,7 @@ DATA = { 0x00 } > # ATF secondary boot image in FIP format (BL2 + BL31) > # > 0x00020000|0x00010000 > -FILE = Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/fip.bin > +FILE = $(TFA_BUILD_FIP) > > # > # UEFI image >