[PATCH 4/5] qemu: Drop ARCH_SUPPORT_TFABOOT

[Tom Rini <trini@konsulko.com>]

On Tue, Sep 29, 2020 at 06:13:09PM +0100, Andr? Przywara wrote:
> On 29/09/2020 14:23, Tom Rini wrote:
> 
> Hi Tom,
> 
> > On Thu, Sep 24, 2020 at 01:17:14AM +0100, Andre Przywara wrote:
> > 
> >> CONFIG_ARCH_SUPPORT_TFABOOT seems to be a guard option to enable various
> >> platform specific hacks, when U-Boot is run under TF-A.
> >> Now that the QEMU port does not need to differentiate between secure
> >> vs. non-secure anymore (this is taken care of by the DTB), there is
> >> no need for a build-time option anymore, so remove it.
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > 
> > I don't quite like calling the changes under TFABOOT hacks in that
> 
> Yeah, hack sounds too harsh, apologies for that. I will reword the
> commit message. On a first glance the code guarded by that symbol seemed
> to be only very loosely connected to TF-A.
> 
> > ARCH_SUPPORT_TFABOOT is used to guard TFABOOT and on other platforms
> > that's used to enable/disable various non-hacky build time things.
> > Maybe we need to tweak the help text on TFABOOT to be clear that only
> > may be required on a given platform?
> 
> Well, looking more closely now it looks like on STM32 and FSL this makes
> the difference between: Does U-Boot handle the secure side (errata
> handling, provide PSCI services) or is this done by other firmware (TF-A).
> This seems like a legitimate option(*), but this may indeed be better
> explained. I can make a patch for that if this seems useful.

Yes please, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200929/e8df1a24/attachment.sig>