We use fiptool extensively to generate the FIP blobs for NVIDIA platforms. But, we encountered the following issues during deployment.
1. fiptool has a dependency on the host machine for OpenSSL and gcc.
2. fiptool resides under the TF-A repo and is used by Hafnium and SPs. This creates a cross-repository dependency.
As a workaround, we ship a prebuilt fiptool. But, due to OS dependency, this approach is not scalable across OS versions. E.g. One OS distribution might be using a lower OpenSSL version compared another, creating an incompatibility.
I was thinking if converting fiptool to a python script might help resolve these issues. Sptool was converted into a Python script, so was wondering if anyone has tried converting fiptool to a Python script too.
I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum
will be hosting a presentation on OpenCI and MISRA presented by Paul
Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being
enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists
since users in both domains may be interested in the session.
Meeting time and dial up info can be found in the TF community calendar
located here: https://www.trustedfirmware.org/meetings/
TrustedFirmware Community Manager
Typically, BL31 runs in SRAM which tends to be limited. As we add
support for newer architectural features e.g. CCA, general features
and standards, the size of BL31 image will grow and become harder to
fit in most SRAMs.
This email is to share ideas on how to address this problem.
A simple approach will be to identify parts of NOBITS ELF sections of
BL31 which can be moved out to DRAM. Since NOBITS sections aren't part
of the file image, loading and authentication code doesn't have to
change. The challenge will be to come up with some criteria to help
decide what kind of buffers can be kept in DRAM vs SRAM.
Other ideas are also welcome. Please share your thoughts.
I'll answer on behalf of Benjamin and Sieu because I think they are offline now.
I reached out to these guys privately this morning and they said they will post patches to fix these defects.
It has happened in the past that developers have posted patches for review, but have been unable to respond to the comments on those patches for a long time and hence, maintainers pitched in and abandoned the patches in such cases.
I created a patch  to make this official because the coding-review guidelines didn't mention it today. I would appreciate your help in reviewing this patch. Please let us know if you disagree about this approach. If you'd like, we can discuss this upcoming tech-forum.