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 { 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. Jan -- Siemens AG, Technology Competence Center Embedded Linux