Feature Suggestion - Adding platform data into FIP

[yonghong-ren]

Hi.

I need to store some platform-specific data in a non-volatile storage. Specifically, I need to store DDR PHY tuning parameters to avoid re-tuning. After looking at different approaches, I think leveraging FIP seems the best way. For example, doing so avoids developing different IO access support by reusing what FIP already handles.

To do this, a few things would be needed:

1. fiptool needs to support a new option, say "--platform-data".
2. add a UUID
3. add a support routine to load the data.
4. optionally add a certificate for the data.

I did 1-3 for my needs, but I would like to ask whether this should be in the common ATF.

[danh-arm]

This is a reasonable use-case. We are already thinking about more general dynamic configuration support in TF; this use-case could potentially be added on top.

Currently, we're envisaging one or more config files in the FIP that are loaded/authenticated by BL2. BL2 would then use these files to generate the structures it needs. Any config information needed by subsequent images would be passed during image handover; other images would not parse the config files directly, to avoid bloating those images with lots of extra code.

Since the codebase already contains libfdt, we were thinking of using DT as a format (though this would be completely distinct from the kernel DTs).

In terms of certificates, I'd expect the existing certificate scheme can be used, just with an extra image hash in one of the certs to represent the config file.

Does this align with what you want?

[yonghong-ren]

What you described would be perfect. I will use what I have for now, but will look forward to this general mechanism. Thanks

[danh-arm]

OK, I'll leave this issue open so we know that it still needs doing!

[masahir0y]

Hi, any update about this work?

I was just about to suggest a new option --user-fw (User Defined Firmware)
for fiptool, then I found this thread.

In my specific case, I need to load firmware for another co-processor
in addition to a SCP.

--platform-data sounds like more generic
to cover data files as well as executables.

For my system, I guess one more file should be enough,
but do we need to support a bit more, like
--platform-data0, --platform-data1, ...?
I do not think we need many.

I am not quite sure about DT.
I came from U-Boot. The SPL in U-Boot supports DT, but
DT-parsing has impact for memory-footprint to some extent.
For my specific needs, the simple struct plat_io_policy approach
seems enough. I am not keen on DT for my platform at this moment.

If somebody is working on this task, I am looking forward to seeing it.
Thanks!

[danh-arm]

Hi @masahir0y

Your use-case sounds a bit different. To store other firmware in a FIP, you can edit the tbbr_config.c to add additonal entries for your image/certs. There would need to be corresponding changes to the TBBR related source files in the device parsing side. Note this will be easier to achieve with the IMAGE_LOAD_V2 build option, since this makes BL2 generic code no longer dependent on specific BL3X images.

To more easily support this, it would be better if the FIP makefile pulled in a platform makefile (which chose which tbbr_config to use), to match what happens in the device side makefiles. That would not be a big change.

The dynamic configuration support I previously mentioned could build on this so that a single firmware could load multiple image configurations. I'm not sure if that would help your but that is where the DT parsing support would come in. We acknowledge this would have a negative impact on memory footprint. It would not be a mandatory feature and we would expect the memory used for parsing to be reclaimed at runtime.

Anyway, we have a done some prototyping of this but implementing it fully is not a high priority for us right now. Part of the issue is that this might radically change the FIP format as a whole, since some of the information in the FIP header could migrate to the dynamic configuration.

Regards

Dan.

[masahir0y]

Hi Dan.

Your use-case sounds a bit different.

I could not understand how different.

To store other firmware in a FIP, you can edit the tbbr_config.c to add additonal entries for your image/certs.

Yes. I think I can edit tbbr_config.c
My question is, is that acceptable in the upsteam?
I do not want to keep my patches locally because it is fragile
in terms of the long-term maintainability.

[danh-arm]

I could not understand how different

In your case, the TBBR config is known statically (at build time), whereas this issue talks about configurability at boot time - i.e. the firmware does not need to be rebuilt, only the FIP.

Yes. I think I can edit tbbr_config.c
My question is, is that acceptable in the upsteam?

If you upstream a platform port, you can provide a modified tbbr_config.c along with the platform port. A modified tbbr_config.c on its own would not be upstreamable.

[davidcunado-arm]

Hi @masahir0y
Please take a look at ARM-software/arm-trusted-firmware#797 as that has a commit that we believe addresses your requirement.
Feedback welcome!
Thanks,
David