Hi Varun,
(sorry last message sent too fast) See few comments inline [OD].
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 17 June 2021 12:33 To: Olivier Deprez; tf-a@lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset"
Hi,
[OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard.
[VW] We don't have a policy for all SPs, yet. At least I don't know of one. But in our experimental setup we plan to work on some assumptions e.g. assume the manifest blob to always be present at a certain address.
[OD] The two questions are which entity is loading boot data (can be a DT blob) that is to be consumed by the SP? And how is the address for boot data conveyed to the SP? The SP manifest is made for the SPMC consumption. I guess it's ok to conflate DT information required by the SP into the SP manifest. It means the bootloader loads both the SP manifest and the SP boot data in a single "SP package". In current implementation the SP has no standard way to know where the DT blob is loaded in its own memory range. We have experimental patches around the FF-A boot protocol which may help.
[OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex.
[VW] Can we list down the next steps? Do we agree in principle that sptool needs to be upgraded to handle this use case? We can collaborate on an implementation, once we agree on the direction.
[OD] If the assumptions (implementation defined) are that the SP boot data fits into the SP manifest, and that the SP finds this data at a fixed address (e.g. offset 0 in the SP package) then yes it can be a way to go.
Cheers.
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Thursday, June 17, 2021 8:40 AM 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,
Few comments [OD]
Regards, Olivier.
________________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 16 June 2021 14:37 To: Olivier Deprez; tf-a@lists.trustedfirmware.org Cc: Raghupathy Krishnamurthy; Nicolas Benech Subject: RE: SP manifest: avoid manual updates to "entrypoint-offset"
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?
[OD] Ok. How is the SP informed about where to find the dtb (IPA address)? Saying this because the boot protocol between Hafnium and SPs is very much implementation specific at this moment and does not strictly follow the FF-A spec recommendations (data passing as TLVs). There is a trick that the manifest blob remains fortunately mapped from offset 0 in the SP IPA range. So it may be able to extract manifest data by mapping it the Stage-1 translation regime. But as said this does not follow a standard.
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.
[OD] I think review link is mysteriously broken and the review lost. But Joao can provide the new link if necessary. I understand the intent of not making things too complex.
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%7Cea511e1ce0414b159a4e08d931632696%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637595124964445862%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=84MkDKpYc4G5OByEYbLvGu6HiUYs%2FKJFWSnt89wixso%3D&reserved=0