On 08.05.23 07:05, Neha Malcom Francis wrote: > 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?
Right, at least on the PG1 variants of our boards (only tested one so far). But I would be fairly optimistic for PG2 and M.2 as well. > >> 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? That would be my expectation, at least until we resolve the blockers for signing with binman. But I'd still like to verify this the next days. Jan -- Siemens AG, Technology Competence Center Embedded Linux