Now that the tf.org project maintenance process  has been finalized,
it is time to think about electing new maintainers for the project. We
are delighted to announce that the following contributors have been
appointed maintainers by their peers:
- Julius Werner (Google)
- Varun Wadekar (NVIDIA)
- Andre Przywara (Arm)
- Lauren Wehrmeister (Arm)
- Madhukar Pappireddy (Arm)
As outlined in , here is the definition and responsibilities of
There are a number of maintainers assigned to the project. The project
keeps a list of them along with their contact information. Maintainers
don't necessarily need a deep domain expertise of all areas of the
project, instead they look at the project from a high level perspective.
They are expected to ensure that changes adhere to the project's quality
criteria, to its architectural direction, to its threat model and so on.
Code owners and maintainers are complementary roles.
Unlike code owners, maintainers can approve any patch, no matter what
module it concerns. They are responsible for ensuring patches have had
enough overall review and adding their own approval in a timely manner.
They also have merge rights, i.e. the ability to merge a patch in the
tree once it has received all required approvals.
These people have been granted Code-Review -2/+2 rights in Gerrit and
have been added in the maintainers.rst file as part of this patch:
Congratulations to them!
Can you please send the specific NOTICE messages which are missing, may be sending 1.5 and 2.3 logs will help.
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 27 May 2020 09:36
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs.
After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs.
Any pointers on how to fix this issue.
We have plan to work on this and come up with some design which handles
On 13/05/2020, 22:18, "TF-A on behalf of Raghu K via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Since the 2.3 release is done, can we revisit this topic? I think we
left this with finalizing on how to handle bad/incorrect DTB's.
Sandrine's latest proposal below:
"A bad DTB seems more like an integration error than a
programming error to me, and thus should be handled with runtime checks
according to the current guidelines. Incorrect values for mandatory
properties should probably be treated as unrecoverable errors (causing a
panic) and incorrect/missing optional properties as recoverable errors
(issuing a warning message)."
I agree with this proposal and think we should follow this. This
addresses my original concern of handling errors consistently and being
safe by verifying mandatory/critical properties at run-time.
On 4/13/20 10:27 AM, Raghu Krishnamurthy wrote:
> Thanks Sandrine. Revisiting after v2.3 is sounds fine.
> On 4/10/20 2:25 AM, Sandrine Bailleux wrote:
>> Hi Raghu,
>> On 4/8/20 12:50 AM, Raghu Krishnamurthy wrote:
>>> Thanks Sandrine, Louis,
>>> Agree with both of you. I'm fine with using asserts or panics, as
>>> long as we uniformly use it. The change i sent out(review 3845) was
>>> because i noticed inconsistency in handling errors. If we do use
>>> asserts, all code that checks for mandatory properties, should be
>>> changed to assert as opposed to return error code. For optional
>>> properties, we can continue to return an error code or print
>>> warnings etc.
>> Yes, I too think consistency is key here. As you said, we need to
>> settle on the expected behaviour and enforce it uniformly across the
>> fconf code. Let's revisit this code after the v2.3 release.
>>> I would like to point out that using asserts here is different from
>>> what is documented in the coding guidelines. The guidelines
>>> explicitly spells out using asserts for "programming errors".
>>> Now, is having a bad DTB considered a programming error? ;) The DTB
>>> is platform data as opposed to code. The guidelines might need to be
>>> updated based on the conclusion here.
>> Now that you point it out, and after taking a closer look at , I
>> think I was wrong. A bad DTB seems more like an integration error
>> than a programming error to me, and thus should be handled with
>> runtime checks according to the current guidelines. Incorrect values
>> for mandatory properties should probably be treated as unrecoverable
>> errors (causing a panic) and incorrect/missing optional properties as
>> recoverable errors (issuing a warning message).
>>> Also note the couple of scenarios i mentioned in an earlier email.
>>> Platforms like RPI4 don't generally enable TBBR and the DTB image
>>> could get corrupt or be modified on purpose. On a release build,
>>> this could cause silent corruption. Panic() would avoid this.
>>> In any case, it would be good to settle on the expected behavior for
>>> each of these abnormal cases. I don't have a strong preference for
>>> asserts or panics here, since each has its pros and cons as both of
>>> you called out.
TF-A mailing list
The next TF-A Tech Forum is scheduled for Thu 21st May 2020 17:00 - 18:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
* Firmware Configuration Framework (FConf) Update - Presented by Manish Badarkhe and Madhukar Pappireddy
* Discussion on how we have leveraged FConf framework in making statically configured components of TF-A to be dynamic.
A number of such components have already been identified which potentially use FConf framework. Patches for such
components are either merged or in-review
* Design discussion on CoT descriptors movement to device tree using FConf framework.
* Optional TF-A Mailing List Topic Discussions
I can give some general answers to your questions and hopefully get to
answering your real questions with further discussion. Please feel free
to ask more questions if this does not help.
>> I noticed that TF-A is designed to load FIP Image but the U-Boot
Environment have a different format. How to access the QSPI NOR memory?
NXP specific driver?
[RK] TF-A generally provides frameworks to do most things and does not
provide device specific drivers but for SPI NOR, there are drivers under
drivers/mtd/nor that could potentially be used. You will likely need to
implement the appropriate platform hooks for the SPI bus itself to use
it. The TF-A IO framework has the io_mtd layer that can be hooked into a
nor device. drivers/st/spi/stm32_qspi.c seems to use all of this and
should be a good example(perhaps some one from ST can chime in too). if
you hook you SPI driver to the TF-A layers correctly, there should be
nothing preventing you from accessing the uboot environment partition.
Also, TF-A's primary/default format for firmware images is FIP but
definitely does not preclude a platform from using it's own format.
>>The bl2 is designed to load only one FIP image, is it possible to add
an additional entry ?
[RK] Not really. BL2 is fairly generic and you should be able to hook
any image format to it. If you must use the FIP format, you can map your
images to existing image id's to create a FIP with any image that you
have. Once again, FIP is fairly flexible and generally treats firmware
images in the package as blob's.
>>if we want to use a secure boot in the future
[RK] Like with the above things, the Trusted Board Boot framework is
flexible and you should be able to implement secure boot on FIP and
other formats. TF-A provides an implementation of the TBBR specification
for secure boot.
It should be possible to implement the algorithm below, if you have an
appropriate platform port, from what i gather in your question below.
On 5/13/20 5:40 AM, florian.manoel--- via TF-A wrote:
> Hello TF-A mail list,
> I’m new here, so I quickly introduce myself.
> I am Florian Manoel, working as firmware developer at Siemens in
> Karlsruhe, Germany. Recently, we decided to start some development
> based on ARM processor, the theme TF-A is new for us.
> Currently, we have a custom board equipped with the processor NXP
> Layerscape LS1043a. So far, everything is working as planned, the
> PreBootLoader (TF-A) boots the bootloader (U-Boot) that’s boots linux
> on top.
> However, we want to have the possibility to boot an alternative u-boot
> FIP image, I explain:
> We use as boot source a QSPI NOR memory. In this memory are stored
> ‘bl2_qspi.pbl’, 2 times ‘fip.bin’, the u-boot environment and some
> We want to select the u-boot image to be booted according to the value
> of a specific variable stored in the u-boot environment ‘u-boot-select’.
> The algo is, for my eye, relatively simple :
> - Check value of the u-boot variable ‘u-boot-select’
> - Check if the corresponding u-boot image is valid, if not select the
> alternative one
> - Boot selected u-boot image
> We want this functionality in case an u-boot image is broken (ex:
> power OFF during U-Boot update).
> I already went through the source code and it rose more question than
> it answered. For example:
> I noticed that TF-A is designed to load FIP Image but the U-Boot
> Environment have a different format. How to access the QSPI NOR
> memory? NXP specific driver?
> The bl2 is designed to load only one FIP image, is it possible to add
> an additional entry ?
> On top of it come the question of the reliability and what will happen
> if we want to use a secure boot in the future..
> I am looking for advice and support on this specific topic.
> Thanks for your support,
> Mit freundlichen Grüßen
> Florian Manoël
> Siemens AG
> Digital Industries
> Process Automation
> Software House Khe
> DI PA CI R&D 2
> Östliche Rheinbrückenstr. 50
> 76187 Karlsruhe, Deutschland
> Tel.: +49 721 595-1433
> www.siemens.com/ingenuityforlife <https://siemens.com/ingenuityforlife>
> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim
> Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch,
> Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft:
> Berlin und München, Deutschland; Registergericht: Berlin
> Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
Hi Raghu and Louis,
On 4/7/20 12:14 PM, Louis Mayencourt via TF-A wrote:
> I do agree with you: case 2 and 3 are similar (wrongly formed DTB) and
> should lead to the same behavior.
> A mandatory property miss or a hit with a structurally incorrect node
> means that the DTB doesn't follow the provided binding document. Such a
> DTB shouldn't be considered as valid and should trigger a build failure
> and/or a code panic.
That's what still confuses me... Agree on cases 2 and 3 triggering a
build failure if possible, but not a code panic. A code panic stays in a
release build. With what we've been discussing so far, it would seem
more appropriate to me to have debug assertions to catch cases 2 and 3.
These debug assertions can help catching structural problems in the DTB
during the development phase and can be eliminated for a production
build, leaving no checks whatsoever in the code.
This is the strategy we've been using so far in TF-A. For lots of
platform interfaces, the generic code includes debug assertions to check
the correct implementation of these interfaces by platform integrators.
For example, checking the range of their return values. I would say this
is deeply embedded into the threat model TF-A uses today. See
On one hand, it makes sense to me. On the other hand, I take Raghu's
point that it would be unrealistic to assume that 100% of code has been
covered by tests. This is very hard to achieve in practice, especially
to cover all error cases ; thus, it seems utopian to assume that all
debug assertions have been exercised during development and can be
TF-A does provide a way to keep debug assertions in a release build
(using the ENABLE_ASSERTIONS build flag) if platform integrators judge
they would rather keep them but this is not the default behaviour.
Hello TF-A mail list,
I'm new here, so I quickly introduce myself.
I am Florian Manoel, working as firmware developer at Siemens in Karlsruhe, Germany. Recently, we decided to start some development based on ARM processor, the theme TF-A is new for us.
Currently, we have a custom board equipped with the processor NXP Layerscape LS1043a. So far, everything is working as planned, the PreBootLoader (TF-A) boots the bootloader (U-Boot) that's boots linux on top.
However, we want to have the possibility to boot an alternative u-boot FIP image, I explain:
We use as boot source a QSPI NOR memory. In this memory are stored 'bl2_qspi.pbl', 2 times 'fip.bin', the u-boot environment and some micro-code.
We want to select the u-boot image to be booted according to the value of a specific variable stored in the u-boot environment 'u-boot-select'.
The algo is, for my eye, relatively simple :
- Check value of the u-boot variable 'u-boot-select'
- Check if the corresponding u-boot image is valid, if not select the alternative one
- Boot selected u-boot image
We want this functionality in case an u-boot image is broken (ex: power OFF during U-Boot update).
I already went through the source code and it rose more question than it answered. For example:
I noticed that TF-A is designed to load FIP Image but the U-Boot Environment have a different format. How to access the QSPI NOR memory? NXP specific driver?
The bl2 is designed to load only one FIP image, is it possible to add an additional entry ?
On top of it come the question of the reliability and what will happen if we want to use a secure boot in the future..
I am looking for advice and support on this specific topic.
Thanks for your support,
Mit freundlichen Grüßen
Software House Khe
DI PA CI R&D 2
Östliche Rheinbrückenstr. 50
76187 Karlsruhe, Deutschland
Tel.: +49 721 595-1433
Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322