[PATCH v3 00/19] Migration to using binman for bootloader

Neha Malcom Francis n-francis at ti.com
Mon May 8 07:05:45 CEST 2023


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 at 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


More information about the U-Boot mailing list