Hi Samuel,
On Sat, 5 Sep 2020 at 16:57, Samuel Holland samuel@sholland.org wrote:
On 9/1/20 6:13 AM, Simon Glass wrote:
Add an entry for ARM Trusted Firmware's 'BL31' payload, which is the device's main firmware. Typically this is U-Boot.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Rebase on top of earlier binman series
Changes in v2:
- Add the URL of ARM Trusted Firmware and mention of U-Boot docs
- Fix copyright year
- Update docs to indicate that BL31 is loaded from SPL
- Update docs to mention both bl31.bin and bl31.elf
tools/binman/README.entries | 14 ++++++++++++++ tools/binman/etype/atf_bl31.py | 24 ++++++++++++++++++++++++ tools/binman/ftest.py | 9 +++++++++ tools/binman/test/169_atf_bl31.dts | 16 ++++++++++++++++ 4 files changed, 63 insertions(+) create mode 100644 tools/binman/etype/atf_bl31.py create mode 100644 tools/binman/test/169_atf_bl31.dts
Does this mean every kind of firmware blob referenced by FIT generator scripts (TEE fimware, SCP firmware, OpenSBI firmware, etc.) needs its own Python package?
No, but in general I would like to do that if possible. It is easier that having random filenames in the description.
What if you need multiple versions of ATF BL31 and TEE firmware for different configurations, like Rockchip currently does?
You can always specify a filename in the node.
You would need dynamic argument names, but then how do you get them in the Makefile?
Using the -a flag.
This approach doesn't seem very flexible or scalable.
Why not have a generic Entry_blob_named_by_env, with a "filename-var" (or similar) property in addition to "filename"? Then the existing interface of the FIT generator scripts could be maintained without tons of boilerplate.
You can do that if you like (see blob-named-by-arg and -a), but the idea with binman is that it knows how to deal with various types of binaries, and each one has a name. This makes it easier to see what is going on, I think.
Also we get documentation about each binary type in README.entries
Regards, Simon