I agree with you that the approach you described above would make the whole process a bit cleaner.
One way this could be done is by passing the *.pre.dts files (generated after the initial processing from dtc) to the script that are part of the patch. Last time I worked on this, I added the possibility to generate the nodes structure to an already existing dts file. Thus, expanding the previous configuration with the values of the new nodes. However, this work needs further testing.
Alternatively, the python package I am using in the script can parse and generate dtb instead of dts. I was thinking to add the option to the dts_gen.py script (maybe rename it as well) to operate over the dtb format. So, making sure that "in-place" changes are working , and adding the option to operate over dtb files should allow for the cleaner approach that you referred. As is and making the referred changes, most of the script's logic should be preserved, so I don't think there will be a lot of changes to the current implementation, which is good. Please let me know if I was not very clear, or if you have any other comments.

Also thanks @Gyorgy Szing for the feedback on the current state of the patch, I appreciate it.

Let me know if anyone has questions, or any other comments to the scripts and/or current discussion.

Hi,

It seems like a good idea to automate it and the approach looks fine to me. Is my understanding correct that the generated *dtsi* files will need to be included in the *dts* files once and the hope is if there is a change, the dts files need not change since the dtsi files will be regenerated every time during build?

The other way this could be done is that the tool can generate dts files which have nodes that change at build time, which can then be compiled and added as dtb files, added to the FIP. That way fvp_tb_fw_config.dts and fvp_spmc_manifest.dts will remain the same and not have any dependency on a changing dtsi file. I’d prefer that dts files that change frequently like in this case be autogenerated entirely and as separate files. That _seems_ cleaner but may not work out so in practice.

Thanks

Raghu

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Joao Alves via TF-A
Sent: Monday, August 3, 2020 10:08 AM
To: tf-a@lists.trustedfirmware.org
Subject: [TF-A] Fw: Automate generation of Partition's specific configuration

Hi all,

Forwarding email below as the referred work may be useful/relevant for other parts of the TF-A project as well.

Best regards,
João Alves

_____

From: Hafnium <hafnium-bounces@lists.trustedfirmware.org <mailto:hafnium-bounces@lists.trustedfirmware.org> > on behalf of Joao Alves via Hafnium <hafnium@lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> >
Sent: Monday, August 3, 2020 5:59 PM
To: hafnium@lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> <hafnium@lists.trustedfirmware.org <mailto:hafnium@lists.trustedfirmware.org> >
Subject: [Hafnium] Automate generation of Partition's specific configuration

Hello all,

I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium.

There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions:

hypervisor {
     compatible = "hafnium,hafnium";
     vm1 {
          is_ffa_partition;
         debug_name = "cactus-primary";
         load_address = <0x7000000>;
         };
     vm2 {
         is_ffa_partition;
         debug_name = "cactus-secondary";
         load_address = <0x7100000>;
         vcpu_count = <2>;
         mem_size = <1048576>;
         };
};

Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address".
If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files.

In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files.

Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150.

The implementation is divided between two scripts:

*   "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files.
*   "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration.

Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation.
The above files contain a lot of comments on how to use them, and also describing the implementation.

If the obtained feedback is good, I can work on integrating this in TF-A's build-system.

Let me know if anyone has questions.

Best regards,
João Alves

--
Hafnium mailing list
Hafnium@lists.trustedfirmware.org <mailto:Hafnium@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/hafnium

--
Hafnium mailing list
Hafnium@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium