On 6/11/26 16:09, Erich E. Hoover wrote:
On Thu, Jun 11, 2026 at 5:31 AM Michal Simek <[email protected]> wrote:
On 6/5/26 15:57, Erich E. Hoover wrote:
...
options, like so:
===
image : {
[init] fsbl.int
please use different name then fsbl because fsbl is not doing this programming.
That's done by bootrom itself.
Topic board is defining it like this.
board/topic/zynq/zynq-topic-miamiplus/ps7_regs.txt
but that's for zynq
My apologies, maybe "reginit.int" like the example for the Versal in
UG1283? I'll remove this line as well, since that's more specific to
what we're doing:
[destination_cpu=none] fsbl.tcl
definitely not fsbl.
reginit.int name is fine.
Actually I think would be good to recap format because origin format
is different compare to what it is used by bootgen right now.
https://docs.amd.com/r/en-US/ug1283-bootgen-user-guide/Initialization-Pairs-and-INT-File-Attribute
...
Are you suggesting adding an additional comment to the commit akin to
"This currently uses the same register initialization file format as
zynqmpimage (ASCII text hex values with each line composed of a pair
of register address and value) and is not yet compatible with the
format used by bootgen."?
Description is fine I would put it as example like this.
0xff003248 0x12345678
static const struct bif_flags bif_flags[] = {
+ { "init", BIF_FLAG_INIT },
{ "fsbl_config", BIF_FLAG_FSBL_CONFIG },
{ "trustzone", BIF_FLAG_TZ },
{ "pmufw_image", BIF_FLAG_PMUFW_IMAGE },
@@ -279,7 +280,7 @@ static int bif_add_blob(const void *data, size_t len,
size_t *offset)
return 0;
}
-static int bif_init(void)
+static int bif_initialize(void)
What's the reason for this rename? I don't think you should rename it because it
is just distracting.
I was trying to match nearby behavior with other flags
("bif_fsbl_config" as an example). How about I change the new
function to "bif_add_reginit" (similar to bif_add_pmufw instead)?
If you want to change names to be aligned, do it in separate patch with own
description. And no issue with it.
Anyway I have tested this patch and output looks reasonable. I would obviously
prefer to add more features there (like ignoring comments) or unify the format
but that's out of the purpose of this patch.
I would be happy to add some more features to this, would you like
patches for this added as part of a series or submitted separately?
It can be done separately and I think it would be better for you too.
Thanks,
Michal
