Hi Simon,
On 11/2/24 17:28, Simon Glass wrote:
Hi Michal,
On Fri, 1 Nov 2024 at 14:52, Tom Rini <[email protected]> wrote:
On Fri, Nov 01, 2024 at 02:09:38PM +0100, Michal Simek wrote:
Hi Simon,
On 11/1/24 09:27, Michal Simek wrote:
On 10/31/24 19:03, Simon Glass wrote:
Hi Michal,
On Wed, 9 Oct 2024 at 10:33, Michal Simek <[email protected]> wrote:
There is necessary to do some steps to compose boot images. These steps
were in scripts in layers for a while. That's why introduce description via
binman to simplify wiring and remove all scripting around.
This should make sure that everybody is up2date with the latest versions.
The first step is to create fit image with DTBs with descriptions in
configuration node which is written as regular expression to match all SOM
versions.
Description is there for k24 and k26 in spite of low level psu_init
configuration is different. The reason is that it goes to u-boot.itb image
which is the same for k24 and k26.
u-boot.itb is another image which is generated. It is normally generated
via arch/arm/mach-zynqmp/mkimage_fit_atf.sh but this script is supposed to
be deprecated.
FIT image by purpose is using 64bit addresses to have default option to
move images to high DDR (above 4GB). TF-A and TEE are optional components
but in the most cases TF-A is present all the time and TEE(OP-TEE) is used
by some configurations too.
3rd generated image is boot.bin with updated user field which contains
version number. This image can be used with updated Image Selector
which supports A/B update mechanisms with rollback protection.
4th image is image.bin which binary file which contains boot.bin and
u-boot.itb together and can be programmed via origin Image Selector.
This image can be also used for creating one capsule which contains both
boot images (in SPL boot flow).
Signed-off-by: Michal Simek <[email protected]>
---
Currently I have this for testing purpose only to find missing bits and
pieces in binman for cases I want to support.
This patch depends on
https://lore.kernel.org/r/
fbed0251437b61a2f7a85596d7403b5b9c8237c1.1728306322.git.michal.si...@amd.com
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/zynqmp-som-binman.dts | 224 +++++++++++++++++++++++++++
arch/arm/mach-zynqmp/Kconfig | 17 ++
configs/xilinx_zynqmp_kria_defconfig | 2 +
4 files changed, 244 insertions(+)
create mode 100644 arch/arm/dts/zynqmp-som-binman.dts
I'm pleased to see this. My only suggestion is to use '/bits/ 64'
instead of the macros, for 64-bit values.
When I was playing with it some time ago it didn't work but it works now
that's why no issue with it.
One more thing on this one. I pretty much dislike that images are generated
to u-boot root folder. Isn't there a way that they will be written to
separate folder (deploy for example)?
Or perhaps $(obj) ?
Yes $(obj) is where they end up today. I consider output files from
binman to be on the same level as other files created by the build.
Then again, it does end up a bit of a mess, when mixed with the output
files.
Some cleanup would be good. I remember a lot of discussion about if people
should be using u-boot or u-boot.elf. Answer was simple but if output images are
in separate folder it would IMHO better to understand.
I am not keen on 'deploy' as it nothing is being deployed - also it
sounds like a satellite or military attack.
No problem with different name.
One long-standing issue is that intermediate files are created in the
same directory. Perhaps we could put those in a binman-tmp directory?
They are necessary when things go wrong, but don't need to be used all
the time.
+1
But I think we should try to move also that images which users should be using
to separate folder completely. Again it doesn't need to be done by default but a
way to configure it would be good.
Thanks,
Michal
