Hi Simon,
On 11/2/24 17:28, Simon Glass wrote:
Hi Michal,
On Fri, 1 Nov 2024 at 14:52, Tom Rini trini@konsulko.com 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 michal.simek@amd.com 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 michal.simek@amd.com
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.simek@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