[PATCH v3 2/9] arm: dts: imx8mp: Add common u-boot dtsi

[Heiko Schocher]

Hi Tim, Simon,

On 13.07.21 22:17, Simon Glass wrote:
> Hi Tim,
> 
> On Mon, 12 Jul 2021 at 14:58, Tim Harvey <tharvey at gateworks.com> wrote:
>>
>> On Mon, Jul 12, 2021 at 12:44 PM Simon Glass <sjg at chromium.org> wrote:
>>>
>>> Hi Tim,
>>>
>>> On Mon, 12 Jul 2021 at 10:42, Tim Harvey <tharvey at gateworks.com> wrote:
>>>>
>>>> On Sat, Jul 10, 2021 at 5:23 AM Heiko Schocher <hs at denx.de> wrote:
>>>>>
>>>>> Hello Tim,
>>>>>
>>>>> On 09.07.21 16:47, Tim Harvey wrote:
>>>>>> On Wed, Jul 7, 2021 at 5:58 AM Teresa Remmet <t.remmet at phytec.de> wrote:
>>>>>>>
>>>>>>> Factor out the common node settings for dm-spl and dm-pre-reloc
>>>>>>> and move them to imx8mp-u-boot.dtsi
>>>>>>>
>>>>>>> Signed-off-by: Teresa Remmet <t.remmet at phytec.de>
>>>>>>> Reviewed-by: Fabio Estevam <festevam at gmail.com>
>>>>>>> Reviewed-by: Heiko Schocher <hs at denx.de>
>>>>>>> ---
>>>>>>> Changes in v3:
>>>>>>> - Moved binman nodes to common imx8mp-u-boot.dtsi
>>>>>>> Changes in v2:
>>>>>>> - none
>>>>>>>
>>>>>>>  arch/arm/dts/imx8mp-evk-u-boot.dtsi           | 143 +----------------
>>>>>>>  .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi    |  39 +----
>>>>>>>  arch/arm/dts/imx8mp-u-boot.dtsi               | 149 ++++++++++++++++++
>>>>>>>  3 files changed, 153 insertions(+), 178 deletions(-)
>>>>>>>  create mode 100644 arch/arm/dts/imx8mp-u-boot.dtsi
>>>>>>>
>>>> <snip>
>>>>>>>
>>>>>>
>>>>>> Teresa,
>>>>>>
>>>>>> I've noticed many of the imx8m boards migrating to using binman for
>>>>>> image packaging.
>>>>>>
>>>>>> Doesn't this change from having a single flash.bin encompasing the SPL
>>>>>> and U-Boot proper to having split files? I noticed that happened with
>>>>>> imx8mm_evk for example when it switched to binman.
>>>>>
>>>>> Yes, but you can easy generate there a single image again.
>>>>>
>>>>>> What are the benefits to using binman?
>>>>>
>>>>> Beside the pros from binmal in general, I see the benefit in special
>>>>> for imx8mp, that you can get all infos you need for signing the image
>>>>> from within the image. No need to save some log output from U-Boot
>>>>> build and parse this output ...
>>>>>
>>>>
>>>> (+cc Simon)
>>>>
>>>> Heiko,
>>>>
>>>> And what are the pros from binman in general? I've read over
>>>> tools/binman/binman.rst so I'm assuming you mean what is described
>>>> there as benefits.
>>>>
>>>> How do you get all the details needed for signing the image from binman?
>>>>
>>>> If I make imx8mm_evk_defconfig which produces via binman flash.bin and
>>>> u-boot.itb I get the following:
>>>>
>>>> $ ./tools/binman/binman ls -i flash.bin
>>>> binman: Cannot find FDT map in image
>>>> $ ./tools/binman/binman ls -i u-boot.itb
>>>> binman: Cannot find FDT map in image
>>>
>>> As the message says, you need an 'fdtmap' in the image:
>>>
>>>    fdtmap {
>>>    }:
>>>
>>
>> Simon,
>>
>> Sorry I still don't quite understand:
>>
>> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
>> b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
>> index f200afac9f..c6d8932fa4 100644
>> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
>> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
>> @@ -163,6 +163,9 @@
>>         itb {
>>                 filename = "u-boot.itb";
>>
>> +               fdtmap {
>> +               };
>> +
>>                 fit {
>>                         description = "Configuration to load ATF before U-Boot";
>>                         #address-cells = <1>;
>>
>>
>> $ make imx8mm_evk_defconfig
>> $ make
>> $ ./tools/binman/binman ls -i u-boot.itb
>> Name          Image-pos  Size    Entry-type  Offset  Uncomp-size
>> ------------------------------------------------------------------
>> main-section          0   a3875  section          0
>>   fdtmap              0     48d  fdtmap           0
>>   fit               48d   a33e8  fit            48d
>>
>> For signing we need the loadaddr/offset/size of the components within
>> the FIT image. Since binman is calling mkimage to create FIT images it
>> seems outside the scope of binman to be able to dump details on the
>> actual FIT image. Perhaps mkimage or another tool is to be used for
>> that detail?
> 
> Yes, binman does not look inside FITs at presnt. You may want to look
> at dump_image?
> 
>>
>>>>
>>>> I would very much like to understand how to use binman to get the
>>>> various offsets needed for signing an IMX image for use with HAB.
>>>
>>> You should be able to add signing support to binman for your use case.
>>> See for example how vblock.py works.
>>
>> I see... so your saying instead of using an external tool to generate
>> a txt template with the offset/size values for the various blobs
>> instead we need to implement for example a habv4.py to add a habv4
>> entry and the python class would have access to the content handles to
>> determine the addr/size in order to create the text template file fed
>> to the NXP code signing tool?
> 
> Yes that should work. It is in fact what binman is designed for
> (producing images, with all the signing, etc.)

Ah, sounds interesting!

@Tim: Do you have time to look into this topic?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de