[PATCH v3 00/19] Migration to using binman for bootloader
Jan Kiszka
jan.kiszka at siemens.com
Tue May 9 10:58:30 CEST 2023
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 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?
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
More information about the U-Boot
mailing list