- TF-A - lists.trustedfirmware.org

by Yann GAUTIER

Hi, I've tested the libfdt update on STM32MP1. I can see a boot time increase by ~6%, thanks to U-Boot 'bootstage report' command. But I don't think this should block the lib upgrade. I've some comments about the patch, I'll send that on gerrit. Regards, Yann On 6/17/20 1:03 AM, Madhukar Pappireddy via TF-A wrote: > Hi Varun, > > I have pushed the draft patch here [1] to upgrade the libfdt source > files. I have tested this patch by running all tests that we usually run > before merging a patch to TF-A repo. I am looking forward to receiving > feedback from platform owners. > > However, I am not convinced why this effort needs an exhaustive > evaluation with various criteria as you mentioned below. I am upgrading > source files and I am not introducing a new project to TF-A. Let me know > your thoughts. > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4596 > > Thanks, > > Madhukar > > *From:* Varun Wadekar <vwadekar(a)nvidia.com> > *Sent:* Monday, June 15, 2020 2:12 PM > *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> > *Cc:* tf-a(a)lists.trustedfirmware.org > *Subject:* RE: Upgrading libfdt library > > Thanks, Madhukar. > > I think this needs a broader discussion where we form a list evaluation > criteria of features, API, metrics, KPIs etc by pooling them from the > platform owners. > > If we don’t receive any inputs, then it makes sense to execute the > current tests and make sure that they work as expected. > > Thoughts? > > -Varun > > *From:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com > <mailto:Madhukar.Pappireddy@arm.com>> > *Sent:* Monday, June 15, 2020 8:30 AM > *To:* Varun Wadekar <vwadekar(a)nvidia.com <mailto:vwadekar@nvidia.com>> > *Cc:* tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > *Subject:* RE: Upgrading libfdt library > > *External email: Use caution opening links or attachments* > > Hi Varun, > > Please find my replies inline. > > Thanks, > > Madhu > > *From:* Varun Wadekar <vwadekar(a)nvidia.com <mailto:vwadekar@nvidia.com>> > *Sent:* Friday, June 12, 2020 7:04 PM > *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com > <mailto:Madhukar.Pappireddy@arm.com>> > *Cc:* tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > *Subject:* RE: Upgrading libfdt library > > Hi Madhukar, > > Before we merge this change, can you please explain how we arrived at > this specific version? Are we tracking the stable version of the library? > > >> I was told by Andre that the releases(tags) by themselves don’t mean > much in the libfdt project and it is better to upgrade directly to the > recent commit(the latest HEAD was 85e5d83 when I started this > investigation). > > What would be the testing criteria before merging the library? Does tftf > provide any tests that can act as a smoking gun? > > >> Given that we rely more on libfdt APIs now, I plan to run all the > existing tests in our CI (includes tftf and Linux boot tests) to verify > if the libfdt library has any issues when integrating with TF-A. I > believe these tests are thorough enough. > > Does it make sense to ask platform owners to test the specific version > you plan to merge? This way we would have more confidence in the library. > > >> Yes, I wanted to take the feedback from platform owners and hence I > sent this email before actually pushing the patch to tf.org for review. > There was a performance concern in the past when upgrading libfdt source > files [1]. > > [1] https://github.com/ARM-software/tf-issues/issues/643 > > -Varun > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org > <mailto:tf-a-bounces@lists.trustedfirmware.org>> *On Behalf Of *Madhukar > Pappireddy via TF-A > *Sent:* Friday, June 12, 2020 4:48 PM > *To:* tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > *Subject:* [TF-A] Upgrading libfdt library > > *External email: Use caution opening links or attachments* > > Hello, > > I am planning to upgrade libfdt library source files in TF-A. They > haven’t been updated for a while. As the project moves towards improving > the fconf framework and adding more properties in device tree source > files, we rely more on libfdt APIs. I have done some preliminary > investigation to check if there is any performance penalty in upgrading > the libfdt source files integrated into TF-A from the current > version(which corresponds to commit aadd0b6 in the dtc repo [1]) to > master commit (85e5d83). I have run some basics tests on both x86 and > aarch64 machines and I have not seen any performance degradation. I plan > to push a patch shortly to integrate the latest version of libfdt files > in TF-A. > > Please let me know if you are aware of any performance issues or have > other concerns. > > [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git > > Thanks, > > Madhu >

5 years, 9 months

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Varun Wadekar

Hi Madhukar, Before we merge this change, can you please explain how we arrived at this specific version? Are we tracking the stable version of the library? What would be the testing criteria before merging the library? Does tftf provide any tests that can act as a smoking gun? Does it make sense to ask platform owners to test the specific version you plan to merge? This way we would have more confidence in the library. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Madhukar Pappireddy via TF-A Sent: Friday, June 12, 2020 4:48 PM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments Hello, I am planning to upgrade libfdt library source files in TF-A. They haven't been updated for a while. As the project moves towards improving the fconf framework and adding more properties in device tree source files, we rely more on libfdt APIs. I have done some preliminary investigation to check if there is any performance penalty in upgrading the libfdt source files integrated into TF-A from the current version(which corresponds to commit aadd0b6 in the dtc repo [1]) to master commit (85e5d83). I have run some basics tests on both x86 and aarch64 machines and I have not seen any performance degradation. I plan to push a patch shortly to integrate the latest version of libfdt files in TF-A. Please let me know if you are aware of any performance issues or have other concerns. [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git Thanks, Madhu

5 years, 9 months

2
3
0 0

Re: [TF-A] Upgrading libfdt library

by Sandrine Bailleux

Hi Alexei, On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote: > I'm wondering why we need to integrate libfdt sources in TF-A? Why > cannot we use the same option as for MbedTls when the build system gets > the path to the preloaded source tree? As far as I know, the question is the other way around: why is mbed TLS not integrated in the TF-A source tree? If you look at the other external libraries used by TF-A (not just libfdt, but also compiler-rt library, zlib, ...), they all are integrated. As far as I am aware, there are several reasons for keeping these projects in the TF-A tree: 1) It is more developer-friendly. Whenever you clone the TF-A repo, you get all required dependencies at the same time, no need to pull them yourself. 2) It allows us to keep local modifications on top of mainline. Such modifications are sometimes necessary or make our life easier to integrate/interface the project with the rest of the TF-A code base. 3) We don't depend on the library project infrastructure. For example if their git server is down, this would not affect us, as we've got our own copy hosted on tf.org. Not sure this third reason was actually considered at the time the decision was made but I see this as a tiny bonus. Now 1) could be achieved some other way, for example we could add the dependent projects as git submodules and have a setup script that pulls them in. We did not go for this option at the time and I don't recall exactly why. It might just be because of the infrastructure/setup required to work with git submodules. So having these projects integrated in the TF-A source tree is the common practice in our project. As far as I am aware, the reason why we treat mbed TLS differently is because it is very security sensitive, thus it's important that people keep up to date with the latest version to get all latest vulnerability fixes. If we had imported it in the TF-A project, this would have put the onus on us to monitor mbed TLS for security fixes and push updates as soon as they become available. This was deemed impractical and too much responsibility for us at the time. Regards, Sandrine

5 years, 9 months

2
2
0 0

Announcing one new maintainer for the TF-A project

by Sandrine Bailleux

Hello all, I am glad to announce that Raghu Krishnamurthy has been appointed maintainer for the TF-A project. The maintainers list has been updated accordingly in the following patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4582 Best regards, Sandrine

5 years, 9 months

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Madhukar Pappireddy

Hi Raghu, We had a discussion internally about handling the mandatory and optional properties in fconf and we believe we can use the following approach. Please let us know if it is acceptable to you. As agreed over the mailing list, we treat the scenarios of a missing/incorrect mandatory property or a structurally bad dtb as an integration error and must lead to panic in runtime. It is the responsibility of the developer providing the populate callback to detect and return an error code in such scenarios. It will be treated as an unrecoverable error and further escalated to panic() by the fconf framework itself. An incorrect or missing optional property in a dtb should lead to a warning message and the boot loader should continue after assigning a default value to the specific property. Further, every property accessed by a populate callback should be clearly defined as either mandatory or optional in a fconf based binding document such as the one shown here [1]. This must be enforced in spirit as part of the code review process. We believe the callbacks can be categorized into two: Generic vs platform-specific. Generic callbacks are the ones that are required to support a standard component supported by platforms running TF-A such as TBBR, SDEI, IO Policy, GICv3, etc. Platform-specific callbacks are provided by platform developers to work with non-standard components such as a Proprietary Hardware IP. The binding document for generic populate callbacks should be provided by the TF-A project. The generic binding will become a contract for the platforms to implement the support for integrating standard components and hence, will be platform agnostic. Correspondingly, it is the responsibility of the platform developer to provide the binding for platform-specific populate callbacks. Any thoughts? [1] https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_p… Thanks, Madhukar -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Manish Badarkhe via TF-A Sent: Wednesday, May 20, 2020 6:00 AM To: Raghu K <raghu.ncstate(a)icloud.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>; tf-a(a)lists.trustedfirmware.org; Louis Mayencourt <Louis.Mayencourt(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-A] fconf: Validating config data Hi Raghu We have plan to work on this and come up with some design which handles mandatory/critical properties. 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: Hi All, 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. Thoughts ? Thanks Raghu On 4/13/20 10:27 AM, Raghu Krishnamurthy wrote: > Thanks Sandrine. Revisiting after v2.3 is sounds fine. > > -Raghu > > 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 [1], 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). >> >> [1] >> https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guideline… >> >> >>> 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. >>> >>> Thanks >>> Raghu > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

2
1
0 0

TF-A Tech Forum Agenda @ Thr 18th June 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 18th June 2020 16:00 – 17: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. Note the new time that is an hour earlier then previous sessions. Agenda: * TF-A Unit Level Testing - Presented by Lauren Wehrmeister * General explanation of the new approach for Unit Testing in TF-A. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Thanks Joanna

5 years, 9 months

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Madhukar Pappireddy

Hi Alexei, To be clear, my current effort is to upgrade the libfdt source files in TF-A. I am not sure why the libfdt source was not integrated into TF-A as a preloaded source tree similar to MbedTLS. Perhaps, any TF-A veteran can help answer this question? Since there is an ongoing effort in the TF-A project to move to CMake build framework, I did not plan to integrate libfdt Makefile into TF-A. Hi Yann, Between commits aadd0b6 (the current version in TF-A for libfdt files) and 85e5d83, I have noticed bug fixes, code cleanups. I am not familiar with the dtc project. I can push a WIP patch with libfdt source files picked from commit 85e5d83. Please let me know if you see any issues with ST platforms. Thanks, Madhukar -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Yann GAUTIER via TF-A Sent: Monday, June 15, 2020 10:26 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Upgrading libfdt library Hi Madhukar, We had seen some issue on STM32MP1 with the previous libfdt rebase, that led to the ticket [1]. And then a partial revert [2]. I'll then try this new version to check if boot time doesn't increase too much. Do you expect other changes than the one changing __ASSEMBLY__ to __ASSEMBLER__? And maybe some updates in libfdt.mk file? If you push this new version to gerrit, it will be easier to fetch and test, as a WIP if it is better for you? Regards, Yann [1] https://github.com/ARM-software/tf-issues/issues/643 [2] https://github.com/ARM-software/arm-trusted-firmware/commit/00f588bf2cc5298… On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote: > Hi Madhukar, > > I'm wondering why we need to integrate libfdt sources in TF-A? Why > cannot we use the same option as for MbedTls when the build system > gets the path to the preloaded source tree? > > Regards. > > Alexei > > ---------------------------------------------------------------------- > -- > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> > *Sent:* 13 June 2020 01:04 > *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] Upgrading libfdt library > > Hi Madhukar, > > Before we merge this change, can you please explain how we arrived at > this specific version? Are we tracking the stable version of the library? > > What would be the testing criteria before merging the library? Does > tftf provide any tests that can act as a smoking gun? > > Does it make sense to ask platform owners to test the specific version > you plan to merge? This way we would have more confidence in the library. > > -Varun > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Madhukar Pappireddy via TF-A > *Sent:* Friday, June 12, 2020 4:48 PM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Upgrading libfdt library > > *External email: Use caution opening links or attachments* > > Hello, > > I am planning to upgrade libfdt library source files in TF-A. They > haven’t been updated for a while. As the project moves towards > improving the fconf framework and adding more properties in device > tree source files, we rely more on libfdt APIs. I have done some > preliminary investigation to check if there is any performance penalty > in upgrading the libfdt source files integrated into TF-A from the > current version(which corresponds to commit aadd0b6 in the dtc repo > [1]) to master commit (85e5d83). I have run some basics tests on both > x86 and > aarch64 machines and I have not seen any performance degradation. I > plan to push a patch shortly to integrate the latest version of libfdt > files in TF-A. > > Please let me know if you are aware of any performance issues or have > other concerns. > > [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git > > Thanks, > > Madhu > > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Yann GAUTIER

Hi Madhukar, We had seen some issue on STM32MP1 with the previous libfdt rebase, that led to the ticket [1]. And then a partial revert [2]. I'll then try this new version to check if boot time doesn't increase too much. Do you expect other changes than the one changing __ASSEMBLY__ to __ASSEMBLER__? And maybe some updates in libfdt.mk file? If you push this new version to gerrit, it will be easier to fetch and test, as a WIP if it is better for you? Regards, Yann [1] https://github.com/ARM-software/tf-issues/issues/643 [2] https://github.com/ARM-software/arm-trusted-firmware/commit/00f588bf2cc5298… On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote: > Hi Madhukar, > > I'm wondering why we need to integrate libfdt sources in TF-A? Why > cannot we use the same option as for MbedTls when the build system gets > the path to the preloaded source tree? > > Regards. > > Alexei > > ------------------------------------------------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun > Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> > *Sent:* 13 June 2020 01:04 > *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] Upgrading libfdt library > > Hi Madhukar, > > Before we merge this change, can you please explain how we arrived at > this specific version? Are we tracking the stable version of the library? > > What would be the testing criteria before merging the library? Does tftf > provide any tests that can act as a smoking gun? > > Does it make sense to ask platform owners to test the specific version > you plan to merge? This way we would have more confidence in the library. > > -Varun > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Madhukar Pappireddy via TF-A > *Sent:* Friday, June 12, 2020 4:48 PM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Upgrading libfdt library > > *External email: Use caution opening links or attachments* > > Hello, > > I am planning to upgrade libfdt library source files in TF-A. They > haven’t been updated for a while. As the project moves towards improving > the fconf framework and adding more properties in device tree source > files, we rely more on libfdt APIs. I have done some preliminary > investigation to check if there is any performance penalty in upgrading > the libfdt source files integrated into TF-A from the current > version(which corresponds to commit aadd0b6 in the dtc repo [1]) to > master commit (85e5d83). I have run some basics tests on both x86 and > aarch64 machines and I have not seen any performance degradation. I plan > to push a patch shortly to integrate the latest version of libfdt files > in TF-A. > > Please let me know if you are aware of any performance issues or have > other concerns. > > [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git > > Thanks, > > Madhu > >

5 years, 9 months

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Alexei Fedorov

Hi Madhukar, I'm wondering why we need to integrate libfdt sources in TF-A? Why cannot we use the same option as for MbedTls when the build system gets the path to the preloaded source tree? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 13 June 2020 01:04 To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Upgrading libfdt library Hi Madhukar, Before we merge this change, can you please explain how we arrived at this specific version? Are we tracking the stable version of the library? What would be the testing criteria before merging the library? Does tftf provide any tests that can act as a smoking gun? Does it make sense to ask platform owners to test the specific version you plan to merge? This way we would have more confidence in the library. -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Madhukar Pappireddy via TF-A Sent: Friday, June 12, 2020 4:48 PM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments Hello, I am planning to upgrade libfdt library source files in TF-A. They haven’t been updated for a while. As the project moves towards improving the fconf framework and adding more properties in device tree source files, we rely more on libfdt APIs. I have done some preliminary investigation to check if there is any performance penalty in upgrading the libfdt source files integrated into TF-A from the current version(which corresponds to commit aadd0b6 in the dtc repo [1]) to master commit (85e5d83). I have run some basics tests on both x86 and aarch64 machines and I have not seen any performance degradation. I plan to push a patch shortly to integrate the latest version of libfdt files in TF-A. Please let me know if you are aware of any performance issues or have other concerns. [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git Thanks, Madhu

5 years, 9 months

1
0
0 0

Re: [TF-A] Question on confine_index_array.h import in tf-a

by Sandrine Bailleux

Hello Etienne, On 6/10/20 1:19 PM, Etienne Carriere via TF-A wrote: > Dear all, > > As part of a patchset series review (topic scmi-msg), change [1] > imports confine_array_index.h header file from OP-TEE OS repository. > The file originates from the open source Fuschia project, see link in > commit message of [1]. > > As being imported for external packages, the header file inherits > Fushca and OP-TEE notices. > The helper function can protect some data structure from side channel > attacks leveraging index indirect access overflows during speculative > execution. > It is not Arm copyright. It is BSD-3-Clause license. > I'll add an entry in the docs/license.rst for the file. > > Where to locate the file? > It is ok to add such a file in include/common? > Does it deserve a specific lib path, like > include/lib/speculconfie_array_index.h? > Maybe add as include/lib/cpus/confine_array_index.h as it is CPU > speculative matters? Before we discuss the location of this header file, have we considered using the compiler support for speculative execution mitigations instead? I am referring to the __builtin_speculation_safe_value() macro, which I believe achieves the same goal as the code you propose to introduce here, i.e. protecting against Spectre v1 bounds-check bypass attacks. TF-A already uses this compiler builtin today and provides a wrapper macro around it, see SPECULATION_SAFE_VALUE() in include/lib/utils_def.f (although I would argue this is not the best location one could think of...). For reference, this was introduced by commit [1]. According to Arm's whitepaper [2], the support for this compiler builtin was added in GCC 9 and LLVM/Clang was to follow shortly. If these versions are too recent for you, then I believe the official location to get equivalent code is [3]. As stated there: The header file provided here allows a migration path to using the builtin function for users who are unable to immediately upgrade to a compiler which supports the builtin. So I would prefer we get the code from there rather than from the OP-TEE project, which got it from the Fuschia project ;) This is licensed under the Boost Software License 1.0, which we've never used in TF-A so I would need to check with our legal department whether this is OK, but I don't expect any issues there as this is described as a permissive license only requiring preservation of copyright and license notices. This is assuming that both header files (the one from OP-TEE and the one from the Arm software Github repo) are equivalent... Is this the case? Is the code provided in OP-TEE perhaps more optimized? Regards, Sandrine [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=9edd… [2] https://developer.arm.com/support/arm-security-updates/speculative-processo… [3] https://github.com/ARM-software/speculation-barrier

5 years, 9 months

2
1
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 9 months

1
0
0 0

Upgrading libfdt library

by Madhukar Pappireddy

Hello, I am planning to upgrade libfdt library source files in TF-A. They haven't been updated for a while. As the project moves towards improving the fconf framework and adding more properties in device tree source files, we rely more on libfdt APIs. I have done some preliminary investigation to check if there is any performance penalty in upgrading the libfdt source files integrated into TF-A from the current version(which corresponds to commit aadd0b6 in the dtc repo [1]) to master commit (85e5d83). I have run some basics tests on both x86 and aarch64 machines and I have not seen any performance degradation. I plan to push a patch shortly to integrate the latest version of libfdt files in TF-A. Please let me know if you are aware of any performance issues or have other concerns. [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git Thanks, Madhu

5 years, 9 months

1
0
0 0

Re: [TF-A] ATF LTS version

by Varun Wadekar

Hello Matteo, Apologies for still using an outdated term. I have trained myself to get used to "TF-A" - looks like I am still not there. >> The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers That is good to hear. For the exact scope, I think we can assume the usual expectations from any LTS software stack - stability, performance, security, bug fixes along with maintenance support. We are open to discussing the cadence and any other operational commitments. @Francois, from the description of Trusted Substrate looks like you also expect the sub-projects to provide LTS versions for the project as a whole to succeed (?) -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Matteo Carlini via TF-A Sent: Thursday, June 11, 2020 4:25 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] ATF LTS version External email: Use caution opening links or attachments Hi Francois, > I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...). > Do you have other firmware LTS needs? Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme. > Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }. > Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project. First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point. Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity. > Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2. Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising. Thanks Matteo -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] ATF LTS version

by Joanna Farley

I should also mention the Release processes we follow and the attempt to indicated the deprecation of interfaces in advance in the effort to maintain compatibility https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio… On 11/06/2020, 14:47, "TF-A on behalf of Joanna Farley via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Varun, I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings. I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know. One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests. Thanks Joanna On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote: Hi Varun, Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ). Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space). The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project. I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme. Thanks Matteo > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A > Sent: 10 June 2020 22:47 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] ATF LTS version > > Hello team, > > To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain. > > For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies. > > It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally? > > -Varun -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] ATF LTS version

by Joanna Farley

Hi Varun, I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings. I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know. One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests. Thanks Joanna On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote: Hi Varun, Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ). Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space). The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project. I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme. Thanks Matteo > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A > Sent: 10 June 2020 22:47 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] ATF LTS version > > Hello team, > > To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain. > > For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies. > > It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally? > > -Varun -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] ATF LTS version

by Matteo Carlini

Hi Francois, > I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...). > Do you have other firmware LTS needs? Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme. > Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }. > Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project. First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point. Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity. > Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2. Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising. Thanks Matteo

5 years, 9 months

1
0
0 0

Re: [TF-A] ATF LTS version

by Matteo Carlini

Hi Varun, Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ). Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space). The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project. I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme. Thanks Matteo > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A > Sent: 10 June 2020 22:47 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] ATF LTS version > > Hello team, > > To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain. > > For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies. > > It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally? > > -Varun

5 years, 9 months

1
0
0 0

Re: [TF-A] ATF LTS version

by François Ozog

Hi Varun, There are early discussions in Linaro on what would mean setting up "Collaborative LTS" for what we call Trusted Substrate (see below signature). I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...). Do you have other firmware LTS needs? Cheers François-Frédéric Ozog Linaro Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }. Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project. Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2. On Wed, 10 Jun 2020 at 23:47, Varun Wadekar via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hello team, > > > > To extend the discussion around version upgrades from our last call, I > would like to understand if there is enough interest around generating a > LTS version of the TF-A to alleviate the pain. > > > > For NVIDIA, this would be helpful as it streamlines the upgrade path for > our devices in the field. The LTS version will guarantee security fixes, > bug fixes, stability fixes for the longer term and we won’t have to upgrade > the entire firmware to get these goodies. > > > > It would be interesting to see what OEMs and maintainers think about this? > Has this been discussed at tf.org or Arm internally? > > > > -Varun > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 9 months

1
0
0 0

Cancelled event: TF-A Tech Forum @ (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been cancelled. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: United Kingdom Time Where: Zoom Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 9 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Every 2 weeks from 17:00 to 18:00 on Thursday from Thu 7 May to Wed 17 Jun (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been changed with this note: "Starting 18th June, the TF-A Tech Forum will be moved earlier by 1 hour to 1600 UK time (1500 UTC). This change is to avoid overlapping the TF Technical Steering Committee call. A new invite will be posted to the TF-A mailing list and on the trustedfirmware.org website." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Every 2 weeks from 17:00 to 18:00 on Thursday from Thu 7 May to Wed 17 Jun United Kingdom Time (changed) Where: Zoom Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=N3ZoNDBuZzZnM2k4cGszY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 9 months

1
0
0 0

Updated invitation with note: TF-A Tech Forum @ Every 2 weeks from 17:00 to 18:00 on Thursday from Thu 26 Mar to Wed 17 Jun (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been changed with this note: "Starting 18th June, the TF-A Tech Forum will be moved earlier by 1 hour to 1600 UK time (1500 UTC). This change is to avoid overlapping the TF Technical Steering Committee call. A new invite will be posted to the TF-A mailing list and on the trustedfirmware.org website." Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Every 2 weeks from 17:00 to 18:00 on Thursday from Thu 26 Mar to Wed 17 Jun United Kingdom Time (changed) Where: Zoom Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=N3ZoNDBuZzZnM2k4cGszY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 9 months

1
0
0 0

Re-scheduling TF-A Tech Forum earlier by 1 hour

by Bill Fletcher

Hi all, Starting 18th June, the TF-A Tech Forum will be moved earlier by 1 hour to 1600 UK time (1500 UTC). This change is to avoid overlapping with the TF Technical Steering Committee call. We'll delete the existing invite and send a new one to this list. Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 9 months

1
0
0 0

ATF LTS version

by Varun Wadekar

Hello team, To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain. For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won't have to upgrade the entire firmware to get these goodies. It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally? -Varun

5 years, 9 months

1
0
0 0

Measured Boot in TF-A

by Alexei Fedorov

Hello all, The initial patch for Measured Boot has been split into 5 separates buildable ones: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4473 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4508 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4509 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4510 and are ready for review/merge. The design follows "TF-A Design Notes for Measured Boot" document . The number of API changes and code modifications based on the received feedback were made, and the most important are: 1. TPM hash algorithm is now independent from the one used by Trusted Boot and can be set separately to a different value. 2. Size of Event Log is passed as a driver build option and can be tuned to meet platform specific requirements (debug/release, number of images loaded, etc.). 3. Driver accepts platform specific table of images to be loaded/measured. 4. PCR index to use for TMP records is passed in platform specific table (see above) and can be set individually for each image. Regards. Alexei

5 years, 9 months

1
0
0 0

Question on confine_index_array.h import in tf-a

by Etienne Carriere

Dear all, As part of a patchset series review (topic scmi-msg), change [1] imports confine_array_index.h header file from OP-TEE OS repository. The file originates from the open source Fuschia project, see link in commit message of [1]. As being imported for external packages, the header file inherits Fushca and OP-TEE notices. The helper function can protect some data structure from side channel attacks leveraging index indirect access overflows during speculative execution. It is not Arm copyright. It is BSD-3-Clause license. I'll add an entry in the docs/license.rst for the file. Where to locate the file? It is ok to add such a file in include/common? Does it deserve a specific lib path, like include/lib/speculconfie_array_index.h? Maybe add as include/lib/cpus/confine_array_index.h as it is CPU speculative matters? Could you help [1] review to progress? [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4055 Regards, Etienne

5 years, 9 months

1
0
0 0

Re: [TF-A] RK3399_BAUDRATE default value

by Hugh Cole-Baker

> On 6 Jun 2020, at 17:52, Heiko Stübner via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Walter, > > Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A: >> I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE >> defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot >> default value and most documentation points to a value of 1500000 for >> console. > > console baudrate on rk3399 differ a lot between boards. There are a > number using the 1.5MHz and another big number using 115200 > (including but not limited to the ChromeOS devices from the Gru line). > > Hence we have the code that selects the actual baudrate from the > devicetree attached by u-boot when calling TF-A. > > So I guess it should stay as it is right now. On the RK3399 there are currently a couple of roadblocks preventing this selection of the baudrate from the devicetree from working. Firstly in U-Boot, SPL_ATF_NO_PLATFORM_PARAM is forced on when selecting ROCKCHIP_RK3399 in Kconfig [1]. Secondly in TF-A the 64K buffer used to store the passed devicetree isn't large enough to fit some of the RK3399 device tree blobs, as I found when removing SPL_ATF_NO_PLATFORM_PARAM from U-Boot. I guess the issue in TF-A needs to be fixed first before passing the platform parameter can be enabled in U-Boot, I've submitted a TF-A patch to increase the buffer size [2]. [1]: https://gitlab.denx.de/u-boot/u-boot/-/blob/61853a7ac7e167d90899ec4e99d2e07… [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4512 > Heiko > > >> This of course means that messages printed by ATF are not visible by >> default in this context. >> >> The change from 1500000 to 115200 was introduced in >> 0c05748bdebfad9fa43a80962186438bb8fbce62, >> >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05… >> >> with the following message >> >> commit 0c05748bdebfad9fa43a80962186438bb8fbce62 >> Author: Caesar Wang <wxt(a)rock-chips.com> >> Date: Tue Apr 19 20:42:17 2016 +0800 >> >> rockchip: fixes for the required >> >> This patch has the following change for rk3399. >> >> * Set the uart to 115200 since the loader decide to set >> uart baud to 115200Hz. So the ATF also should set uart baud to 115200. >> [..] >> >> However, I'm not sure it this still applies. >> >> I'll be happy to submit a patch to update the value if it is OK. >> >> Regards, >> >> Walter >> >> > > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

2
1
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Raghu Krishnamurthy

Hello, Sorry for chiming in late. Are we sure that the msr/mrs to the GICv3 EOI register is not a context synchronizing event or ensures ordering itself ? Also did the addition of DSB() fix the issue ? If yes, can you try adding a delay or a few NOP's/dummy instructions or an ISB to see if the issue goes away? We need to know the right thing to do architecturally and confirm that the issue is really due to reordering at the core before adding the DSB. Adding a DSB might be masking a timing issue. -Raghu On 6/8/20 4:47 AM, Sandeep Tripathy via TF-A wrote: >> -----Original Message----- >> From: Soby Mathew [mailto:Soby.Mathew@arm.com] >> Sent: Monday, June 08, 2020 3:36 PM >> To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org >> Cc: nd >> Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC >> >> Just some inputs from my side: >> I agree we need at least a dsb() after the write to MMIO region to silence >> the >> peripheral and before the EOI at GIC sysreg interface. Adding it to the >> GIC EOI > > Thanks for the confirmation. Now it’s about choosing the right place. > >> API seems the logical thing to do but as Olivier mentions, there are >> interrupt >> handler which do not deal with MMIO (eg: the Systimer interrupt) so adding >> it >> to GICv3 API might be arduous for such handlers. >> >> So there is a choice here to let the interrupt handlers to deal with >> ensuring >> completeness before EOI at sysreg interface or adding it to GICv3 EOI API >> and >> take the overhead for interrupt handlers which do not have to deal with >> MMIO. >> > > Yes I feel either of these is a must to guarantee functionality > architecturally though > both approach end up with some unnecessary overhead. > > If GICv3 api takes care then it is an overhead for some ISRs dealing with > non-MMIO. > At present I do not see an active use case in reference implementation where > sys timer > ISR is in a performance intensive path where one additional DSB will be > perceivable. > But there may be some I could be totally wrong in this assumption (pmu/debug > or.. not sure). > Whereas I can certainly imagine some MMIO ISRs in performance critical path > where unnecessary > DSB is not acceptable at all. > > If the interrupt handler needs to ensure then it will generically add 'DSB' > as I think > the driver cannot and should not make assumptions about how EOI is done > afterwards. > That will be overhead for the ISRs dealing with MMIO peripherals and non > GIC-v3. > If we consider only GICv3+ then good. Otherwise I would prefer the > 'plat_ic_end_of_interrupt' > like Olivier mentioned with a #if GICv3 instead of each ISRs dealing with > it. > >> The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys >> interface is the only one GICv3 driver in TF-A supports. > > Right we can ignore the GICv3 legacy mode but GICv2 will still remain ? > >> >> Best Regards >> Soby Mathew >> > > Thanks > Sandeep > >>> -----Original Message----- >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep >>> Tripathy via TF-A >>> Sent: 08 June 2020 10:34 >>> To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf- >> a(a)lists.trustedfirmware.org >>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC >>> >>> Hi Olivier, >>>> -----Original Message----- >>>> From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] >>>> Sent: Monday, June 08, 2020 1:14 PM >>>> To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy >>>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC >>>> >>>> Hi Sandeep, >>>> >>>> gicv3_end_of_interrupt_sel1 is a static access helper macro. Its >>>> naming precisely tells what it does at gicv3 module level. It is >>>> called from >>> the weak >>>> plat_ic_end_of_interrupt function for BL32 image. >>>> >>>> I tend to think it is the driver responsibility to ensure the module >>> interrupt >>>> acknowledge register write is reaching HW in order (or "be visible to >>> all >>>> observers"). >>> >>> The driver should be agnostic of what interrupt controller is used and >>> its >>> behavior. >>> And since 'all' writes were to mmio ranges mapped Device(nGnRE) >>> /strongly-ordered(nGnRnE) >>> there was no such need. This is a special case for GICv3 system >>> interface only. >>> Adding at driver level a DSB is unnecessary for other interrupt >>> controllers. >>> >>>> Also I suspect adding a dsb might not be required generically for all >>> kind of IP. >>> >>> Here are you referring to the peripheral IP or interrupt controller IP ? >>> The issue is reordering at arm core itself (STR to device address Vs >>> msr(sysreg >>> write)). >>> So I think Its applicable for all IP. >>> >>>> Adding a barrier in generic code might incur an unnecessary >>>> bottleneck. >>> >>> But if there is a need to *ensure* presence of at least one DSB between >>> the >>> write transfer from core to device clear and gicv3 eoi icc register >>> write in a >>> generic way then what other option we have. >>>> >>>> Thus wouldn't it be better to add the barrier to the overridden >>>> platform function rather than in generic gicv3 code? >>> >>> That can be done but I feel this is more to do with gicv3 system >>> interface only. >>> Inside plat_xxx one has to check #if GICV3 ...and system interface. >>>> >>>> I have a put a comment in the review, we can continue the discussion >>> there. >>>> >>>> Regards, >>>> Olivier. >>>> >>> Thanks >>> Sandeep >>>> ________________________________________ >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of >>>> Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> >>>> Sent: 05 June 2020 19:43 >>>> To: tf-a(a)lists.trustedfirmware.org >>>> Subject: [TF-A] GICV3: system interface EOI ordering RFC >>>> >>>> Hi, >>>> In a typical interrupt handling sequence we do 1-Read IAR >>>> 2-Do interrupt handling >>>> 3-Clear the interrupt at source , so that the device de-asserts IRQ >>> request to >>>> GIC >>>> >> I am suggesting a need of DSB here in case of GICv3 +. >>>> 4-Write to GIC cpu interface to do EOI. >>>> >>>> Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write >>>> over >>> AMBA >>>> interface. The >>>> Addresses are mapped with (nR) attribute. Hence the write transfers >>> from the >>>> core will be >>>> generated at step 3 and 4 in order. Please ignore the additional >>> buffers/bridges >>>> in path from >>>> core till peripheral which has to be dealt separately as per SOC. >>>> >>>> Query: I understand GICv3 system interface accesses are not over this >>> protocol >>>> and core will not >>>> follow the ordering rule ? >>>> >>>> I have observed spurious interrupt issue/manifestation ( I don't have >>> the >>>> transfers probed) in >>>> RTOS environment where I have a primitive GICv3 driver but I wonder >>>> why things does not fail in Linux or tf-a. If it is working because >>>> from step(3) to >>> step(4) we have >>>> barriers by chace >>>> due to other device register writes then I would suggest to have one >>>> in >>> the EOI >>>> clearing API itself. >>>> >>>> RFC: >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 >>>> >>>> Thanks >>>> Sandeep >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Sandeep Tripathy

> -----Original Message----- > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > Sent: Monday, June 08, 2020 3:36 PM > To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org > Cc: nd > Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC > > Just some inputs from my side: > I agree we need at least a dsb() after the write to MMIO region to silence > the > peripheral and before the EOI at GIC sysreg interface. Adding it to the > GIC EOI Thanks for the confirmation. Now it’s about choosing the right place. > API seems the logical thing to do but as Olivier mentions, there are > interrupt > handler which do not deal with MMIO (eg: the Systimer interrupt) so adding > it > to GICv3 API might be arduous for such handlers. > > So there is a choice here to let the interrupt handlers to deal with > ensuring > completeness before EOI at sysreg interface or adding it to GICv3 EOI API > and > take the overhead for interrupt handlers which do not have to deal with > MMIO. > Yes I feel either of these is a must to guarantee functionality architecturally though both approach end up with some unnecessary overhead. If GICv3 api takes care then it is an overhead for some ISRs dealing with non-MMIO. At present I do not see an active use case in reference implementation where sys timer ISR is in a performance intensive path where one additional DSB will be perceivable. But there may be some I could be totally wrong in this assumption (pmu/debug or.. not sure). Whereas I can certainly imagine some MMIO ISRs in performance critical path where unnecessary DSB is not acceptable at all. If the interrupt handler needs to ensure then it will generically add 'DSB' as I think the driver cannot and should not make assumptions about how EOI is done afterwards. That will be overhead for the ISRs dealing with MMIO peripherals and non GIC-v3. If we consider only GICv3+ then good. Otherwise I would prefer the 'plat_ic_end_of_interrupt' like Olivier mentioned with a #if GICv3 instead of each ISRs dealing with it. > The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys > interface is the only one GICv3 driver in TF-A supports. Right we can ignore the GICv3 legacy mode but GICv2 will still remain ? > > Best Regards > Soby Mathew > Thanks Sandeep > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > > Tripathy via TF-A > > Sent: 08 June 2020 10:34 > > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf- > a(a)lists.trustedfirmware.org > > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > > > Hi Olivier, > > > -----Original Message----- > > > From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] > > > Sent: Monday, June 08, 2020 1:14 PM > > > To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy > > > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > > > > > Hi Sandeep, > > > > > > gicv3_end_of_interrupt_sel1 is a static access helper macro. Its > > > naming precisely tells what it does at gicv3 module level. It is > > > called from > > the weak > > > plat_ic_end_of_interrupt function for BL32 image. > > > > > > I tend to think it is the driver responsibility to ensure the module > > interrupt > > > acknowledge register write is reaching HW in order (or "be visible to > > all > > > observers"). > > > > The driver should be agnostic of what interrupt controller is used and > > its > > behavior. > > And since 'all' writes were to mmio ranges mapped Device(nGnRE) > > /strongly-ordered(nGnRnE) > > there was no such need. This is a special case for GICv3 system > > interface only. > > Adding at driver level a DSB is unnecessary for other interrupt > > controllers. > > > > > Also I suspect adding a dsb might not be required generically for all > > kind of IP. > > > > Here are you referring to the peripheral IP or interrupt controller IP ? > > The issue is reordering at arm core itself (STR to device address Vs > > msr(sysreg > > write)). > > So I think Its applicable for all IP. > > > > > Adding a barrier in generic code might incur an unnecessary > > > bottleneck. > > > > But if there is a need to *ensure* presence of at least one DSB between > > the > > write transfer from core to device clear and gicv3 eoi icc register > > write in a > > generic way then what other option we have. > > > > > > Thus wouldn't it be better to add the barrier to the overridden > > > platform function rather than in generic gicv3 code? > > > > That can be done but I feel this is more to do with gicv3 system > > interface only. > > Inside plat_xxx one has to check #if GICV3 ...and system interface. > > > > > > I have a put a comment in the review, we can continue the discussion > > there. > > > > > > Regards, > > > Olivier. > > > > > Thanks > > Sandeep > > > ________________________________________ > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > > > Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> > > > Sent: 05 June 2020 19:43 > > > To: tf-a(a)lists.trustedfirmware.org > > > Subject: [TF-A] GICV3: system interface EOI ordering RFC > > > > > > Hi, > > > In a typical interrupt handling sequence we do 1-Read IAR > > > 2-Do interrupt handling > > > 3-Clear the interrupt at source , so that the device de-asserts IRQ > > request to > > > GIC > > > >> I am suggesting a need of DSB here in case of GICv3 +. > > > 4-Write to GIC cpu interface to do EOI. > > > > > > Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write > > > over > > AMBA > > > interface. The > > > Addresses are mapped with (nR) attribute. Hence the write transfers > > from the > > > core will be > > > generated at step 3 and 4 in order. Please ignore the additional > > buffers/bridges > > > in path from > > > core till peripheral which has to be dealt separately as per SOC. > > > > > > Query: I understand GICv3 system interface accesses are not over this > > protocol > > > and core will not > > > follow the ordering rule ? > > > > > > I have observed spurious interrupt issue/manifestation ( I don't have > > the > > > transfers probed) in > > > RTOS environment where I have a primitive GICv3 driver but I wonder > > > why things does not fail in Linux or tf-a. If it is working because > > > from step(3) to > > step(4) we have > > > barriers by chace > > > due to other device register writes then I would suggest to have one > > > in > > the EOI > > > clearing API itself. > > > > > > RFC: > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 > > > > > > Thanks > > > Sandeep > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Soby Mathew

Just some inputs from my side: I agree we need atleast a dsb() after the write to MMIO region to silence the peripheral and before the EOI at GIC sysreg interface. Adding it to the GIC EOI API seems the logical thing to do but as Olivier mentions, there are interrupt handler which do not deal with MMIO (eg: the Systimer interrupt) so adding it to GICv3 API might be arduous for such handlers. So there is a choice here to let the interrupt handlers to deal with ensuring completeness before EOI at sysreg interface or adding it to GICv3 EOI API and take the overhead for interrupt handlers which do not have to deal with MMIO. The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys interface is the only one GICv3 driver in TF-A supports. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 08 June 2020 10:34 > To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > Hi Olivier, > > -----Original Message----- > > From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] > > Sent: Monday, June 08, 2020 1:14 PM > > To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy > > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > > > Hi Sandeep, > > > > gicv3_end_of_interrupt_sel1 is a static access helper macro. Its > > naming precisely tells what it does at gicv3 module level. It is > > called from > the weak > > plat_ic_end_of_interrupt function for BL32 image. > > > > I tend to think it is the driver responsibility to ensure the module > interrupt > > acknowledge register write is reaching HW in order (or "be visible to > all > > observers"). > > The driver should be agnostic of what interrupt controller is used and its > behavior. > And since 'all' writes were to mmio ranges mapped Device(nGnRE) > /strongly-ordered(nGnRnE) > there was no such need. This is a special case for GICv3 system interface only. > Adding at driver level a DSB is unnecessary for other interrupt controllers. > > > Also I suspect adding a dsb might not be required generically for all > kind of IP. > > Here are you referring to the peripheral IP or interrupt controller IP ? > The issue is reordering at arm core itself (STR to device address Vs msr(sysreg > write)). > So I think Its applicable for all IP. > > > Adding a barrier in generic code might incur an unnecessary bottleneck. > > But if there is a need to *ensure* presence of at least one DSB between the > write transfer from core to device clear and gicv3 eoi icc register write in a > generic way then what other option we have. > > > > Thus wouldn't it be better to add the barrier to the overridden > > platform function rather than in generic gicv3 code? > > That can be done but I feel this is more to do with gicv3 system interface only. > Inside plat_xxx one has to check #if GICV3 ...and system interface. > > > > I have a put a comment in the review, we can continue the discussion > there. > > > > Regards, > > Olivier. > > > Thanks > Sandeep > > ________________________________________ > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > > Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> > > Sent: 05 June 2020 19:43 > > To: tf-a(a)lists.trustedfirmware.org > > Subject: [TF-A] GICV3: system interface EOI ordering RFC > > > > Hi, > > In a typical interrupt handling sequence we do 1-Read IAR > > 2-Do interrupt handling > > 3-Clear the interrupt at source , so that the device de-asserts IRQ > request to > > GIC > > >> I am suggesting a need of DSB here in case of GICv3 +. > > 4-Write to GIC cpu interface to do EOI. > > > > Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write > > over > AMBA > > interface. The > > Addresses are mapped with (nR) attribute. Hence the write transfers > from the > > core will be > > generated at step 3 and 4 in order. Please ignore the additional > buffers/bridges > > in path from > > core till peripheral which has to be dealt separately as per SOC. > > > > Query: I understand GICv3 system interface accesses are not over this > protocol > > and core will not > > follow the ordering rule ? > > > > I have observed spurious interrupt issue/manifestation ( I don't have > the > > transfers probed) in > > RTOS environment where I have a primitive GICv3 driver but I wonder > > why things does not fail in Linux or tf-a. If it is working because > > from step(3) to > step(4) we have > > barriers by chace > > due to other device register writes then I would suggest to have one > > in > the EOI > > clearing API itself. > > > > RFC: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 > > > > Thanks > > Sandeep > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 9 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Olivier Deprez

Hi Sandeep, gicv3_end_of_interrupt_sel1 is a static access helper macro. Its naming precisely tells what it does at gicv3 module level. It is called from the weak plat_ic_end_of_interrupt function for BL32 image. I tend to think it is the driver responsibility to ensure the module interrupt acknowledge register write is reaching HW in order (or "be visible to all observers"). Also I suspect adding a dsb might not be required generically for all kind of IP. Adding a barrier in generic code might incur an unnecessary bottleneck. Thus wouldn't it be better to add the barrier to the overridden platform function rather than in generic gicv3 code? I have a put a comment in the review, we can continue the discussion there. Regards, Olivier. ________________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 05 June 2020 19:43 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] GICV3: system interface EOI ordering RFC Hi, In a typical interrupt handling sequence we do 1-Read IAR 2-Do interrupt handling 3-Clear the interrupt at source , so that the device de-asserts IRQ request to GIC >> I am suggesting a need of DSB here in case of GICv3 +. 4-Write to GIC cpu interface to do EOI. Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over AMBA interface. The Addresses are mapped with (nR) attribute. Hence the write transfers from the core will be generated at step 3 and 4 in order. Please ignore the additional buffers/bridges in path from core till peripheral which has to be dealt separately as per SOC. Query: I understand GICv3 system interface accesses are not over this protocol and core will not follow the ordering rule ? I have observed spurious interrupt issue/manifestation ( I don’t have the transfers probed) in RTOS environment where I have a primitive GICv3 driver but I wonder why things does not fail in Linux or tf-a. If it is working because from step(3) to step(4) we have barriers by chace due to other device register writes then I would suggest to have one in the EOI clearing API itself. RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 Thanks Sandeep

5 years, 9 months

2
1
0 0

Re: [TF-A] RK3399_BAUDRATE default value

by Heiko Stübner

Hi Walter, Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A: > I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE > defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot > default value and most documentation points to a value of 1500000 for > console. console baudrate on rk3399 differ a lot between boards. There are a number using the 1.5MHz and another big number using 115200 (including but not limited to the ChromeOS devices from the Gru line). Hence we have the code that selects the actual baudrate from the devicetree attached by u-boot when calling TF-A. So I guess it should stay as it is right now. Heiko > This of course means that messages printed by ATF are not visible by > default in this context. > > The change from 1500000 to 115200 was introduced in > 0c05748bdebfad9fa43a80962186438bb8fbce62, > > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05… > > with the following message > > commit 0c05748bdebfad9fa43a80962186438bb8fbce62 > Author: Caesar Wang <wxt(a)rock-chips.com> > Date: Tue Apr 19 20:42:17 2016 +0800 > > rockchip: fixes for the required > > This patch has the following change for rk3399. > > * Set the uart to 115200 since the loader decide to set > uart baud to 115200Hz. So the ATF also should set uart baud to 115200. > [..] > > However, I'm not sure it this still applies. > > I'll be happy to submit a patch to update the value if it is OK. > > Regards, > > Walter > >

5 years, 9 months

1
0
0 0

RK3399_BAUDRATE default value

by Walter Lozano

I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot default value and most documentation points to a value of 1500000 for console. This of course means that messages printed by ATF are not visible by default in this context. The change from 1500000 to 115200 was introduced in 0c05748bdebfad9fa43a80962186438bb8fbce62, https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c05… with the following message commit 0c05748bdebfad9fa43a80962186438bb8fbce62 Author: Caesar Wang <wxt(a)rock-chips.com> Date: Tue Apr 19 20:42:17 2016 +0800 rockchip: fixes for the required This patch has the following change for rk3399. * Set the uart to 115200 since the loader decide to set uart baud to 115200Hz. So the ATF also should set uart baud to 115200. [..] However, I'm not sure it this still applies. I'll be happy to submit a patch to update the value if it is OK. Regards, Walter

5 years, 9 months

1
0
0 0

GICV3: system interface EOI ordering RFC

by Sandeep Tripathy

Hi, In a typical interrupt handling sequence we do 1-Read IAR 2-Do interrupt handling 3-Clear the interrupt at source , so that the device de-asserts IRQ request to GIC >> I am suggesting a need of DSB here in case of GICv3 +. 4-Write to GIC cpu interface to do EOI. Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write over AMBA interface. The Addresses are mapped with (nR) attribute. Hence the write transfers from the core will be generated at step 3 and 4 in order. Please ignore the additional buffers/bridges in path from core till peripheral which has to be dealt separately as per SOC. Query: I understand GICv3 system interface accesses are not over this protocol and core will not follow the ordering rule ? I have observed spurious interrupt issue/manifestation ( I don’t have the transfers probed) in RTOS environment where I have a primitive GICv3 driver but I wonder why things does not fail in Linux or tf-a. If it is working because from step(3) to step(4) we have barriers by chace due to other device register writes then I would suggest to have one in the EOI clearing API itself. RFC: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 Thanks Sandeep

5 years, 9 months

1
0
0 0

Re: [TF-A] Slides for recent TF-A Forums

by Joanna Farley

Hi Okash, These are generally provided on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ however they are missing from 7th May onwards at the moment. I have an update pending approval on tf.org for adding the details of that session and then I need to add the information from the session on 21st May and the session yesterday. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Okash Khawaja via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Okash Khawaja <okash.khawaja(a)gmail.com> Date: Friday, 5 June 2020 at 11:29 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Slides for recent TF-A Forums Hi, Where can I find slides for recent TF-A Forum presentations? Thanks, Okash

5 years, 9 months

1
0
0 0

Slides for recent TF-A Forums

by Okash Khawaja

Hi, Where can I find slides for recent TF-A Forum presentations? Thanks, Okash

5 years, 9 months

1
0
0 0

Re: [TF-A] Gerrit seems to be broken

by Madhukar Pappireddy

Hi Bill, I continue to the error while trying to invoke “Allow-CI” or other votes as part of gerrit review. I tried multiple browsers as well and logged out before attempting again. Thanks, Madhu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-A Sent: Tuesday, June 2, 2020 12:13 PM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Gerrit seems to be broken Hi Varun, Do you still see the problem? It has been reported before. Regards Bill On Tue, 2 Jun 2020 at 18:01, Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote: Hello, The TF gerrit review dashboard seems to be broken this morning. I see “Server error” and it does not allow me to post scores or comments. Tried different browsers, but same issue persists. Anyone else seeing the same problem? Is this is a known issue? If yes, is anyone working on it? -Varun -- TF-A mailing list TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- [Image removed by sender. Linaro]<http://www.linaro.org/> Bill Fletcher | Field Engineering T: +44 7833 498336<tel:+44+7833+498336> bill.fletcher(a)linaro.org<mailto:bill.fletcher@linaro.org> | Skype: billfletcher2020

5 years, 9 months

3
4
0 0

Re: [TF-A] Gerrit seems to be broken

by Bill Fletcher

Hi Varun, Do you still see the problem? It has been reported before. Regards Bill On Tue, 2 Jun 2020 at 18:01, Varun Wadekar via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > Hello, > > > > The TF gerrit review dashboard seems to be broken this morning. I see > “Server error” and it does not allow me to post scores or comments. Tried > different browsers, but same issue persists. > > > > Anyone else seeing the same problem? Is this is a known issue? If yes, is > anyone working on it? > > > > -Varun > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 9 months

1
0
0 0

Re: [TF-A] Gerrit seems to be broken

by Joanna Farley

Working for me, the main and additional dashboards. https://review.trustedfirmware.org/admin/repos/TF-A/trusted-firmware-a,dash… I posted comments earlier ok as well. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Varun Wadekar <vwadekar(a)nvidia.com> Date: Tuesday, 2 June 2020 at 18:02 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] Gerrit seems to be broken Hello, The TF gerrit review dashboard seems to be broken this morning. I see “Server error” and it does not allow me to post scores or comments. Tried different browsers, but same issue persists. Anyone else seeing the same problem? Is this is a known issue? If yes, is anyone working on it? -Varun

5 years, 9 months

1
0
0 0

Gerrit seems to be broken

by Varun Wadekar

Hello, The TF gerrit review dashboard seems to be broken this morning. I see "Server error" and it does not allow me to post scores or comments. Tried different browsers, but same issue persists. Anyone else seeing the same problem? Is this is a known issue? If yes, is anyone working on it? -Varun

5 years, 9 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 4th June 2020 17:00-1800 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 4th June 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. Agenda: * TF-A SMC fuzzing module overview - Presented by Mark Dykes * General explanation of the approach taken to randomize the type and timing of the SMC calls in TF-A to provide a Fuzz testing capability. * Optional TF-A Mailing List Topic Discussions Thanks Joanna

5 years, 9 months

1
0
0 0

Re: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU

by Manish Badarkhe

Hi Andrzej I think recent patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493 which is currently in review may be solution for your issue where SCU presence is being checked before accessing CLUSTERCFR_EL1 register. Thanks Manish Badarkhe From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of "Witkowski, Andrzej via TF-A" <tf-a(a)lists.trustedfirmware.org> Reply to: "Witkowski, Andrzej" <andrzej.witkowski(a)intel.com> Date: Monday, 1 June 2020 at 19:38 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Cc: "Witkowski, Andrzej" <andrzej.witkowski(a)intel.com>, "Lessnau, Adam" <adam.lessnau(a)intel.com> Subject: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU Hi, I work on project which uses ARM CPU Neoverse N1 with direct connect of DSU. I noticed the following error “Unhandled Exception at EL3” in BL31 bootloader after switching from ATF 2.1 to 2.2. The root cause is that after invoking neoverse_n1_errata-report function in lib/cpus/aarch64/neoverse_n1.S file and reaching the line 525, the function check_errata_dsu_934 in lib/cpus/aarch64/dsu_helpers.S file is always invoked regardless of whether ERRATA_DSU_936184 is set to 0 or to 1. In our case, ERRATA_DSU_936184 := 0. [cid:image001.png@01D6384E.C183C050] [cid:image002.png@01D6384E.C183C050] Neoverse N1 with direct connect version of DSU doesn’t contain SCU/L3 cache and CLUSTERCFR_EL1 register. The error “Unhandled Exception at EL3” appears in BL31 bootloader during attempt to read the CLUSTERCFR_EL1 register which doesn’t exist in our RTL HW. Andrzej Witkowskie Intel Technology Poland --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN. Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

5 years, 9 months

1
0
0 0

Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU

by Witkowski, Andrzej

Hi, I work on project which uses ARM CPU Neoverse N1 with direct connect of DSU. I noticed the following error "Unhandled Exception at EL3" in BL31 bootloader after switching from ATF 2.1 to 2.2. The root cause is that after invoking neoverse_n1_errata-report function in lib/cpus/aarch64/neoverse_n1.S file and reaching the line 525, the function check_errata_dsu_934 in lib/cpus/aarch64/dsu_helpers.S file is always invoked regardless of whether ERRATA_DSU_936184 is set to 0 or to 1. In our case, ERRATA_DSU_936184 := 0. [cid:image001.png@01D63828.FA4B1440] [cid:image002.png@01D6382A.B84A0950] Neoverse N1 with direct connect version of DSU doesn't contain SCU/L3 cache and CLUSTERCFR_EL1 register. The error "Unhandled Exception at EL3" appears in BL31 bootloader during attempt to read the CLUSTERCFR_EL1 register which doesn't exist in our RTL HW. Andrzej Witkowskie Intel Technology Poland --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | Kapita zakadowy 200.000 PLN. Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

5 years, 9 months

1
0
0 0

Announcing new maintainers for the TF-A project

by Sandrine Bailleux

Hi all, Now that the tf.org project maintenance process [1] 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 [1], here is the definition and responsibilities of maintainers: ------------8<------------ 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. ------------8<------------ 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: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4298 Congratulations to them! Best regards, Sandrine [1] https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…

5 years, 9 months

1
0
0 0

Re: [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.

by Manish Pandey2

Hi Pankaj, Can you please send the specific NOTICE messages which are missing, may be sending 1.5 and 2.3 logs will help. thanks Manish ________________________________ 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. Hi 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. Thanks. Regards Pankaj

5 years, 9 months

1
0
0 0

After migrating from TFA-1.5 to TFA2.3, parts of NOTICE messages are missed, which comes as part of boot-up logs.

by Pankaj Gupta

Hi 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. Thanks. Regards Pankaj

5 years, 9 months

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Manish Badarkhe

Hi Raghu We have plan to work on this and come up with some design which handles mandatory/critical properties. 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: Hi All, 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. Thoughts ? Thanks Raghu On 4/13/20 10:27 AM, Raghu Krishnamurthy wrote: > Thanks Sandrine. Revisiting after v2.3 is sounds fine. > > -Raghu > > 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 [1], 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). >> >> [1] >> https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guideline… >> >> >>> 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. >>> >>> Thanks >>> Raghu > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years, 10 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 21sth May 2020 17:00-1800 BST

by Joanna Farley

Hi All, 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. Agenda: * 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 Thanks Joanna

5 years, 10 months

1
0
0 0

Re: [TF-A] Candidates for fconf based dynamic configuration

by Raghu K

Off the top of my head, secure world interrupts(SPI's, PPI's, SGI's), MMU mappings for anything that does not depend on image layout(platform specific devices, UEFI MM or other special regions), security policies like TZC region protections. -Raghu On 5/14/20 8:45 AM, Madhukar Pappireddy via TF-A wrote: > > Hi, > > We are in the process of leveraging the fconf framework to make the > static configurations of various components of TF-A to more dynamic > configurations. The primary motivation behind this effort is to > evaluate the possibility of having common TF-A BL images that can be > used across multiple platforms. As a start, this involves moving > compile-time C based data structures into device tree which are > extracted during runtime. We have chosen the FVP platform as a proof > of concept for this effort and have identified the following > components to be made more dynamic: > > runtime UART std-out: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3775, > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3923/ > > Topology description: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492, > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3522 > > GICv3 configuration: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4066 > > Timer configuration: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3696 > > SDEI platform setup: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3990 > > CoT descriptor: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4080, > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4081 > > Platform IO Policies: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2558 > > Please advise if there are any other components of TF-A that can be > configured dynamically in runtime. > > Thanks, > > Madhu > >

5 years, 10 months

1
0
0 0

Candidates for fconf based dynamic configuration

by Madhukar Pappireddy

Hi, We are in the process of leveraging the fconf framework to make the static configurations of various components of TF-A to more dynamic configurations. The primary motivation behind this effort is to evaluate the possibility of having common TF-A BL images that can be used across multiple platforms. As a start, this involves moving compile-time C based data structures into device tree which are extracted during runtime. We have chosen the FVP platform as a proof of concept for this effort and have identified the following components to be made more dynamic: runtime UART std-out: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3775, https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3923/ Topology description: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492, https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3522 GICv3 configuration: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4066 Timer configuration: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3696 SDEI platform setup: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3990 CoT descriptor: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4080, https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4081 Platform IO Policies: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2558 Please advise if there are any other components of TF-A that can be configured dynamically in runtime. Thanks, Madhu

5 years, 10 months

1
0
0 0

Re: [TF-A] TF-A and U-Boot: How to Boot a specific u-boot image

by Raghu K

Hi Florian, 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. Thanks -Raghu 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 > 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 : > > Start > - 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 > End > > > 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 > mailto:florian.manoel@siemens.com > 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 > >

5 years, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A