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.przyw...@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
signature.asc
Description: PGP signature