Hi,
Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI.
[VW] Thanks for the heads up.
what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself?
[VW] We can assume tens of KB. In the worst case, a few hundred KB. The manifest is targeted towards the SP and not meant for Hafnium. Just curious, do you see any pitfalls?
To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there.
[VW] Thanks for the links. I will review and leave comments - although we are not looking at introducing yet another script.
Cheers.
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Wednesday, June 16, 2021 12:59 PM To: Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy raghupathyk@nvidia.com; Nicolas Benech nbenech@nvidia.com Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset"
External email: Use caution opening links or attachments
Hi Varun,
See inline [OD]
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 16 June 2021 13:07 To: Olivier Deprez; tf-a@lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset"
HI Olivier,
[OD] Just to be clear, is this about SEL0 partitions using an SEL1 shim
No, this issue can be seen even without the shim. I don't think the usage of shim or VHE really matters here.
[OD] All right. Just a small heads up VHE SEL0 changes are tested within the Hafnium CI presently and do not relate to TF-A CI. sptool is a TF-A tool and there is no link to the Hafnium CI. Not an issue as such but just making sure you have the full picture. At some point in time, when Hf VHE changes are merged we can create a specific TF-A test config to cover this case if necessary. Out of curiosity what is the order in size for the manifest dtb you require in Tegra platform? Are the supplementary nodes in this manifest consumed by Hafnium or the SP itself?
[OD] This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems.
I agree, this approach is good for the short term. But I propose we craft a forward-looking solution. Are you planning on merging the sptool patch[1]? If not, I propose we come up with a way to dynamically update the SP manifest - I understand this involves adding libfdt to update the manifest.
[OD] There is no pressing need to merge [1] in the short term so this can wait for a better solution. To set the complete picture, Joao had made some exploration around more dynamic SP configuration [2], maybe there are ideas to gather from there.
-Varun
[1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tru... [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Wednesday, June 16, 2021 11:42 AM To: tf-a@lists.trustedfirmware.org; Nicolas Benech nbenech@nvidia.com Cc: Raghupathy Krishnamurthy raghupathyk@nvidia.com; Varun Wadekar vwadekar@nvidia.com Subject: Re: SP manifest: avoid manual updates to "entrypoint-offset"
External email: Use caution opening links or attachments
Hi,
See few comments inline [OD]
Regards, Olivier.
________________________________________ From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Varun Wadekar via TF-A tf-a@lists.trustedfirmware.org Sent: 16 June 2021 11:41 To: tf-a@lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: [TF-A] SP manifest: avoid manual updates to "entrypoint-offset"
Hello,
We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms
[OD] Just to be clear, is this about SEL0 partitions using an SEL1 shim (as per https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tru...) )?
and recently hit an issue, where the "entrypoint-offset" field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the "entrypoint-offset" field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the "entrypoint-offset", we must manually update it. This needs to be fixed.
We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the "entrypoint-offset" past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal.
Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling.
[OD] We had an attempt (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tru...) to move the entry point farther in the image such that we can support 64KB granules in the Stage-1 translation regime. This does not relate exactly to your problem but the effect is the "same" (aka there is more room for the manifest dtb). Agree this still requires hard-coding the entry point. At this stage I had thought of pushing the entry point even farther at a reasonably large 64KB aligned offset such that it helps with both problems.
Cheers.
[1] 14. FF-A manifest binding to device tree - Trusted Firmware-A documentationhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustedfirmware-a.readthedocs.io%2Fen%2Flatest%2Fcomponents%2Fffa-manifest-binding.html&data=04%7C01%7Cvwadekar%40nvidia.com%7C74eaad0725d545fc6cb308d930be1953%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637594415297852137%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=a77j8Cu3OdzWA4YhGM09UhBZYlVQfMqxrQAQhjwKX%2FY%3D&reserved=0