From: "Sebastian Groß" <sebastian.gross@emlix.com>
To: Marco Felsch <m.felsch@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: bootm: fit-image: hash node name too strict
Date: Tue, 7 Jan 2025 14:13:03 +0100 [thread overview]
Message-ID: <5c957c04-6ee6-4e7f-9385-899ac05a9593@emlix.com> (raw)
In-Reply-To: <20250107111302.642ikgjfqmm3qgth@pengutronix.de>
On 2025-01-07 12:13 PM, Marco Felsch wrote:
> On 25-01-07, Sebastian Groß wrote:
>> Hi Marco,
>>
>> On 2025-01-07 8:37 AM, Marco Felsch wrote:
>>>> Since the image is build by uboot's mkimage I would expect the itb's to be
>>>> compatible. Or am I missing something?
>>>>
>>>> Changing the following line in the `its`, ie. its build script
>>>> ```
>>>> - hash { algo = "${FIT_HASH_ALG}"; };
>>>> + hash@1 { algo = "${FIT_HASH_ALG}"; };
>>>> ```
>>>> made the fit-image work.
>>> I can't find this line within the U-Boot src code. Can you provide a
>>> link please?
>> Sorry for the confusion. I meant the build script within yocto that
>> generates the `its` and then the `itb`
> Can you give me some pointers please? I've checked the
> kernel-fitimage.bbclass in oe-core and which used hash@1 during the
> initial commit which was changed to hash-1 later on.
Maybe that was my mistake in the first place. I used some custom class I
found from an older BSP that used u-boot as bootloader.
I should switch to kernel-fitimage or the pengutronix fitimage class.
>
>>>> Perhaps another if-clause is required. Or some error message that states
>>>> which property/string was searched for,
>>>> since there were hashes in the image, but not where barebox expected them.
>>> We could search for the legacy single 'hash' node name as well and print
>>> a warning that this should be changed.
>> I concur!
> If we can find a valid source which still uses the old style :)
Agreed. But I find it likely to stumble upon such old thingis in the
wild and would appreciate a warning in this case.
This would spare future-me and other devs the trouble =)
Plus the fix would not increase the complexity of the code.
I could provide a patch and you might decide on this basis
>
>> Looking at `fit_image_verify_signature` this change might be necessary too
>> for `signature`
> Same here.
>
> Regards,
> Marco
Regards
Sebastian
--
Sebastian Groß, B.Sc.
emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mail info@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com
emlix - your embedded Linux partner
prev parent reply other threads:[~2025-01-07 13:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 7:14 Sebastian Groß
2025-01-07 7:37 ` Marco Felsch
2025-01-07 7:54 ` Sebastian Groß
2025-01-07 11:13 ` Marco Felsch
2025-01-07 13:13 ` Sebastian Groß [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5c957c04-6ee6-4e7f-9385-899ac05a9593@emlix.com \
--to=sebastian.gross@emlix.com \
--cc=barebox@lists.infradead.org \
--cc=m.felsch@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox