One thing that might be worth considering is versioning the library like
xlat_tables and xlat_tables_v2 for a few releases and deprecate the old
one if/when there is broad agreement from platforms to move to the new
one. Platforms can perform their independent testing like STM and can
report back over time. Obviously, for those few releases if there are
API changes in libfdt there will have to be support for both new and old
api's which will cause temporary ugliness but this might ease concerns
about testing, stability etc.
-Raghu
On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote:
>> -----Original Message-----
>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine
>> Bailleux via TF-A
>> Sent: 16 June 2020 13:09
>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy
>> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com>
>> Cc: tf-a(a)lists.trustedfirmware.org
>> Subject: Re: [TF-A] Upgrading libfdt library
>>
>> Hi Alexei,
>>
>> On 6/16/20 1:51 PM, Alexei Fedorov wrote:
>>> Thanks for your very detailed explanation of the reason behind this
>>> solution.
>>> This brings the question on how do we monitor libfdt bug fixes, code
>>> cleanup, etc. (which Madhukar pointed out) and integrate these changes
>>> in TF-A source tree.
>> Right now, it is a manual process and not only for libfdt but for all projects TF-A
>> depends on. We keep an eye on them and aim at updating them when
>> necessary. Unfortunately, like any manual process, it is error-prone and things
>> might slip through the cracks. The TF-A release tick is usually a good reminder
>> to update all dependencies but unfortunately libfdt has been left behind for
>> some time (about 2 years)...
> As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of.
>
> Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release.
>
> But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above.
>
> Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate.
>
> Best Regards
> Soby Mathew
>
>
>
>
>> Regards,
>> Sandrine
>> --
>> TF-A mailing list
>> TF-A(a)lists.trustedfirmware.org
>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine
> Bailleux via TF-A
> Sent: 16 June 2020 13:09
> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy
> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com>
> Cc: tf-a(a)lists.trustedfirmware.org
> Subject: Re: [TF-A] Upgrading libfdt library
>
> Hi Alexei,
>
> On 6/16/20 1:51 PM, Alexei Fedorov wrote:
> > Thanks for your very detailed explanation of the reason behind this
> > solution.
> > This brings the question on how do we monitor libfdt bug fixes, code
> > cleanup, etc. (which Madhukar pointed out) and integrate these changes
> > in TF-A source tree.
>
> Right now, it is a manual process and not only for libfdt but for all projects TF-A
> depends on. We keep an eye on them and aim at updating them when
> necessary. Unfortunately, like any manual process, it is error-prone and things
> might slip through the cracks. The TF-A release tick is usually a good reminder
> to update all dependencies but unfortunately libfdt has been left behind for
> some time (about 2 years)...
As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of.
Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release.
But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above.
Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate.
Best Regards
Soby Mathew
>
> Regards,
> Sandrine
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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
>
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
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
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
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
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
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
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
>
>
