On 08.05.20 17:40, Andrew F. Davis wrote:
On 5/4/20 8:38 AM, Jan Kiszka wrote:
From: Jan Kiszka <jan.kis...@siemens.com>
Build the secured board dtbs (.dtb_HS) as part of the regular dtb build
on CONFIG_TI_SECURE_DEVICE targets. This avoids rebuilding them,
possibly overwriting artifacts that are in use, as it is done so far.
In the same run, fix needless rebuilding of the secured spl dtb.
Fixes: 508369672ca3 ("arm: mach-k3: Add secure device build support")
CC: Andrew F. Davis <a...@ti.com>
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
arch/arm/dts/Makefile | 6 ++++--
arch/arm/mach-k3/config_secure.mk | 19 ++++++++++++++-----
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2c123bd6da..b68e9c0726 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,5 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
+include $(srctree)/arch/arm/mach-k3/config_secure.mk
+
This is hacky, we should not in the top level dts makefile have a
dependency on a specific platform configuration file.
What about mach-omap/config_secure.mk, etc..
They don't need those special signing the k3 need. If they did, they
could be included here as well.
The negative of building dtbs twice for HS is very minor compared to the
extra complexity this patch adds. It will be much more difficult to
clean this up later.
Overwriting a build artifacts that were already completed and may just
be in use while doing so is broken. This must be fixed.
As I wrote, I will add support for injecting public keys into the dtbs,
and that also revealed this issue.
Better suggestions welcome.
Jan
