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] 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.
-Varun
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/8536
-----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%7Cc826626398d04eb8fd6c08d930b35aca%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637594369748380511%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=acROgLyh5ApAE6LdHhtoto9U3m1tN0y9pIAnEyF4PtE%3D&reserved=0