Hi, Olivier, This issue has not been resolved and further support is needed. Then I'll try to update our code base to see if anything changes. Regards, Yuye. ------------------------------------------------------------------ 发件人：Olivier Deprez Olivier.Deprez@arm.com 发送时间：2023年2月11日(星期六) 00:57 收件人：hafnium hafnium@lists.trustedfirmware.org; 梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 抄 送：常琳(特睿) terui.cl@alibaba-inc.com; 赵哲(为哲) weizhe.zz@alibaba-inc.com; 黄明(连一) hm281385@alibaba-inc.com 主 题：Re: Hafnium load-address Hi Yuye, Is this still an issue at your end? Just asking if we need to do further investigation. Regards, Olivier. From: 梅建强(禹夜) via Hafnium hafnium@lists.trustedfirmware.org Sent: 28 December 2022 10:09 To: hafnium hafnium@lists.trustedfirmware.org Cc: 常琳(特睿) terui.cl@alibaba-inc.com; 赵哲(为哲) weizhe.zz@alibaba-inc.com; 黄明(连一) hm281385@alibaba-inc.com Subject: [Hafnium] 回复：Re: Hafnium load-address Hi, Thanks for your efforts for this query. I have tried your solution. Although the Hafnium code could be built successfully, it does not work when the boot flow run into the entry of the Hafnium. I tried to debug the error with trace32 tool. And I confirmed that the Hafnium code has been loaded over 34G of free address space. However, when PC register point to the start address of Hafnium, the code data is displayed as udf #0x0. It may be a page table problem, and we are still locating the problem reason. Regards, Mei, Jianqiang. ------------------------------------------------------------------ 发件人：Olivier Deprez via Hafnium hafnium@lists.trustedfirmware.org 发送时间：2022年12月21日(星期三) 18:02 收件人：梅建强(禹夜) meijianqiang.mjq@alibaba-inc.com 抄 送：hafnium hafnium@lists.trustedfirmware.org; 常琳(特睿) terui.cl@alibaba-inc.com; 赵哲(为哲) weizhe.zz@alibaba-inc.com; 黄明(连一) hm281385@alibaba-inc.com 主 题：[Hafnium] Re: Hafnium load-address Hi, Sorry for the delay in replying to this query. After few trials I ended with this possible solution: https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 > < < >https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 <https://review.trustedfirmware.org/c/hafnium/hafnium/+/18510 > > This should permit loading the Hafnium image to an address up to 48 bits (and by updating project/reference/BUILD.gn origin_address per your suggestion). It is possible to further extend beyond 48 bits (e.g. 52 bits which is the maximum permitted VA using FEAT_LPA2). Let me know if this works for you, then I can proceed further with polishing this change. Regards, Olivier. ________________________________ From: 梅建强(禹夜) via Hafnium hafnium@lists.trustedfirmware.org Sent: 11 December 2022 09:58 To: Olivier Deprez Olivier.Deprez@arm.com Cc: hafnium hafnium@lists.trustedfirmware.org; 常琳(特睿) terui.cl@alibaba-inc.com; 赵哲(为哲) weizhe.zz@alibaba-inc.com; 黄明(连一) hm281385@alibaba-inc.com Subject: [Hafnium] Hafnium load-address Hello, expert Firstly, thanks for your answer some time ago. That's useful to our project.We combined the Hafnium (run at S-EL2) and the optee (run at S-EL1), then modified the configuration to adapt to our own environment. Now we can start the os normally. Now we want to optimize a technical point, which is to load and run hafnium over 34G of free address space. This requires hafnium to support 64-bit load-address. I tried to modify the configuration in BUILD.gn as follows: origin_address = "0x880000000" And I encountered the build error: FAILED: secure_aem_v8a_fvp_clang/hafnium.elf ld.lld -pie --gc-sections --defsym=ORIGIN_ADDRESS=0x880000000 -O2 --icf=all --fatal-warnings --color-diagnostics -T /home/yuye/hafnium/Hafnium/build/image/image.ld -o secure_aem_v8a_fvp_clang/hafnium.elf --start-group @secure_aem_v8a_fvp_clang/hafnium.elf.rsp --end-group ld.lld: error: secure_aem_v8a_fvp_clang/obj/src/arch/aarch64/entry.entry.o:(.init.entry+0xC8): relocation R_AARCH64_ABS32 out of range: 36507222016 is not in [-2147483648, 4294967295]; references ORIGIN_ADDRESS >>> defined in -defsym:1 ninja: build stopped: subcommand failed. Makefile:70: recipe for target 'all' failed make: *** [all] Error 1 + cp out/reference/secure_aem_v8a_fvp_clang/hafnium.bin ../../V2/Ali_M1_Public/Nonosi/Platform/Ali/M1/Bin/ cp: cannot stat 'out/reference/secure_aem_v8a_fvp_clang/hafnium.bin': No such file or directory In this case, it seems that the new address causes some relative addressing to reach too far. Is there any solutions or supports for this issue currently in the community? Regards, Mei, Jianqiang. -- 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 -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org