Hi Yuye,
You need not generate the boot information blob. SPMC(i.e., producer) passes the boot information to SP(i.e., consumer) during boot if certain conditions are met. For instance, an SP's manifest needs to contain certain device tree fields to configure support for boot protocol. Please refer to the documentation section [1] for further information.
[1] https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti...
Thanks, Madhukar
-----Original Message----- From: 梅建强(禹夜) via Hafnium hafnium@lists.trustedfirmware.org Sent: Sunday, March 26, 2023 10:09 PM To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium@lists.trustedfirmware.org; OP-TEE TrustedFirmware op-tee@lists.trustedfirmware.org Subject: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2
Hi, Olivier, Whether Boot Information Blob is a file similar to manifest.dtb or sp.pkg? How do I generate this blob? Does it need to be packaged into atf firmware at compile phase？ Thanks. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez Olivier.Deprez@arm.com 发送时间：2023年3月21日(星期二) 22:37 收件人：Jens Wiklander jens.wiklander@linaro.org 抄 送：hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; OP-TEE TrustedFirmware op-tee@lists.trustedfirmware.org 主 题：Re: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2 Hi Jens, See comments inline [OD]. Regards, Olivier. ________________________________ From: Jens Wiklander via Hafnium hafnium@lists.trustedfirmware.org Sent: 21 March 2023 09:30 To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; OP-TEE TrustedFirmware op-tee@lists.trustedfirmware.org Subject: [Hafnium] Boot arguments for S-EL1 with SPMC at S-EL2 Hi Olivier, I'm trying to implement a relocatable OP-TEE binary so it can be loaded at different physical addresses without the need to recompile it. This means that in the case with Hafnium when changing "load-address" or "entrypoint-offset" in the OP-TEE SP manifest there's no need to recompile OP-TEE. For this to work OP-TEE must be able to figure out which memory range it's supposed to reside in. [OD] Fair enough, I believe that would conflate into some generic PIE support? I can see how this helps with the multi OP-TEE instances use case, perhaps? Currently, OP-TEE knows the entry point address from PC and "memory size" from X0. However, the "memory size" is from the "load-address" so "entrypoint-offset" must be subtracted from PC in order to know the allocated memory range. Do you have ideas on how OP-TEE at runtime can determine the allocated memory range? [OD] The standard way would be to use the FF-A boot protocol e.g. if you add this to OP-TEE's SP manifest: + /* Boot protocol */ + gp-register-num = <0x0>; + + /* Boot Info */ + boot-info { + compatible = "arm,ffa-manifest-boot-info"; ffa_manifest; }; See https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti... <https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partiti... > At SP entry, x0 contains the address of a 'Boot Information Blob' (FF-A v1.1 REL0 section 5.4.2) starting with a Boot Information Header (Table 5.9). The SP manifest DT address can be extracted from a Boot Information Descriptor (Table 5.8). Eventually the SP is able to parse its own SP manifest, into which it finds FF-A standard fields (load-address...) in addition to any impdef field added. Note the partition size is not standarded (it should probably be), so for starters you can add your own memsize field. There is some sample usage in TF-a-tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_m... <https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_m... > and also in context of EDKII/StMM: https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe7... <https://github.com/odeprez/edk2/commit/7066c913cb227056d68ea99de5e92f2067fe7... > Thanks, Jens -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org