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@lists.trustedfirmware.org On Behalf Of Yann GAUTIER via TF-A Sent: Monday, June 15, 2020 10:26 AM To: tf-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/00f588bf2cc5298d...

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@lists.trustedfirmware.org on behalf of Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org *Sent:* 13 June 2020 01:04 *To:* Madhukar Pappireddy Madhukar.Pappireddy@arm.com *Cc:* tf-a@lists.trustedfirmware.org tf-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@lists.trustedfirmware.org *On Behalf Of *Madhukar Pappireddy via TF-A *Sent:* Friday, June 12, 2020 4:48 PM *To:* 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

-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a