Hi Jan,
On 07/05/23 17:41, Jan Kiszka wrote:
On 04.05.23 08:13, Neha Malcom Francis wrote:
Hi Jan
On 04/05/23 10:13, Neha Malcom Francis wrote:
Hi Jan,
On 03/05/23 22:04, Jan Kiszka wrote:
On 03.05.23 14:56, Neha Malcom Francis wrote:
Hi Jan,
On 03/05/23 12:57, Neha Malcom Francis wrote:
Hi Tom
On 27/04/23 04:07, Tom Rini wrote:
On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote:
This series aims to eliminate the use of additional custom
repositories
such as k3-image-gen (K3 Image Generation) repo and
core-secdev-k3 (K3
Security Development Tools) that was plumbed into the U-Boot
build flow
to generate boot images for TI K3 platform devices. And instead, we
move
towards using binman that aligns better with the community standard
build
flow.
This series uses binman for all K3 platforms supported on U-Boot
currently;
both HS (High Security, both SE and FS) and GP (General Purpose)
devices.
Background on using k3-image-gen:
* TI K3 devices require a SYSFW (System Firmware) image
consisting
of a signed system firmware image and board configuration
binaries,
this is needed to bring up system firmware during U-Boot R5 SPL
startup.
* Board configuration data contain board-specific information
such as resource management, power management and security.
Background on using core-secdev-k3:
* Contains resources to sign x509 certificates for HS devices
Series intends to use binman to take over the packaging and
signing for
the R5 bootloader images tiboot3.bin (and sysfw.itb, for
non-combined
boot flow) instead of k3-image-gen.
Series also packages the A72/A53 bootloader images (tispl.bin and
u-boot.img) using ATF, OPTEE and DM (Device Manager)
So, next up is fixing this in CI. After taking Andrew's patch to
fix the
typedef issue, and after my patches to ensure we can get
pyyaml/jsonschema for python, there's problems still:
Thanks for checking this! Couple things:
Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966:
binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in
input
path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts)
(cwd='/tmp/.bm-work/j721s2_hs_evm_a72')
1. This is dependent on the patch merging J721S2 HS and GP configs
[1]. However it has been reverted on -next, seen in the same thread.
And then:
https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328
Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error
I've fixed this, minor but serious change.
2. Regarding iot2050, build fails since it uses
arch/arm/mach-k3/config.mk which is now entirely binman based. Will
try moving iot2050 to binman as well.
I'll need some help with this, might need to know the bootloader
flow to
make a clean migration.
Where do I have to look at? Is there a git repo with that experiment
somewhere?
Jan
There's no experiment yet, I will send one today; but I do not have
complete understanding of the booting; whether the tispl.bin (which I
assume is the only boot component that is affecting iot2050 boot since
k3_fit_atf.sh is no longer there) has any concept of signing? Is
core-secdev-k3 ever used?
I have a tree posted here [2] that builds flash.bin with no error for
me. Please confirm whether your build flow does the same and also let me
know if the binary actually boots.
[2]
https://github.com/nehamalcom/u-boot/tree/migration-to-binman-cicd-iot2050
I've tested the latest version in that branch in the meantime. It
compiles but it does not work. This is missing from the original script:
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index e17ffd7481f..9d83898d33f 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -92,6 +92,15 @@
};
};
};
+
+ configurations {
+ default = "spl";
+ spl {
+ fdt = "fdt-0";
+ firmware = "atf";
+ loadables = "tee", "dm", "spl";
+ };
+ };
};
fit@0x380000 {
Thanks for this! I'll make sure to add this, so we are booting fine on
non-secure with this patch applied as well right?
I didn't test secure booting yet, though. We are currently still signing
via tools/iot2050-sign-fw.sh, partly due to missing features in binman
(there were a lot of proposals on the list recently, may that is solved
now), but partly also due to some remaining breakages.
Got it. To confirm, this is not modifying anything in the secure flow is
it? flash.bin is just signed manually using tools/iot2050-sign-fw.sh
correct?
Jan
--
Thanking You
Neha Malcom Francis
