Hi Soby, Thanks for your replies. Currently, out BL2 size is 60KB, BL1_RW is 28KB, BL31_PROGBITS is 48KB, BL31_NOPROGBITS is 24KB. For our testchip, we don't have too strictly security requirement, so maybe putting BL31 into DDR is a way to save SRAM and we don't need to worry about PROGBITS limit between BL31 and BL2. For BL1_RW and BL2, there is 40KB used for MMU table. After I disable the MMU related code in arm_bl1_plat_arch_setup()/arm_bl2_plat_arch_setup() and also disable the build of xlat_table_lib, this 40KB space is saved. If the consequence is decreasing performance and losing MMU protection without any other functionality problem, then we might try this.
Best Regards Yan Hongliang
------------------------------------------------------------------ 发件人：Soby Mathew Soby.Mathew@arm.com 发送时间：2020年1月10日(星期五) 18:27 收件人："Xie, Shaolin" shaolin.xie@alibaba-inc.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org 抄 送：nd nd@arm.com; 严鸿亮(鸿先) hongxian.yhl@alibaba-inc.com; Ash Wilding Ash.Wilding@arm.com 主 题：Re: [TF-A] MMU Table in ARM Trust-Firmware-A
On 10/01/2020 09:05, shaolin.xie via TF-A wrote:
Hey all:
We are trying to port ARM Trust-Firmware-A to our design, however, we are facing serious SRAM size problem.
Our target SRAM is 64KB, but the compiled BL2 already taken 60K:
After some evaluation, we found that the MMU table take most of the space. Our questions are:
Hi Shaolin, There are some options to reduce the memory used for page-tables like using non-identity virtual to physical mappings. But given your SRAM size, I suspect you may not save enough to fit BL31.
- Can we disable the MMU so we can fit the BL2 into 64KB space? (However, in ARM's porting guide, enable MMU and icache/dcache is mandatory. Refer to chapter 7.3 in https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-g... https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-guide.html#introduction.）
This is a possibility although not recommended for performance reasons and you lose the protection of MMU during BL2 execution. This is not a configuration we support an I suspect some changes to BL2 code may be required for this.
- In current design, BL31 is run in SRAM. If we enable DDR in BL2 and load BL31 image to DDR, is there any potential issue?
Thanks in advances,
It is possible to create a secure carve-out in DDR and execute BL31 from there. It is less `secure` than running from SRAM but it is acceptable for some market segments depending on the threat model.
You target SRAM of 64 KB is on the lower side and fitting both BL2 and BL31 in that space could be a challenge.
Could you let us know your BL2 and BL31 size and could you break down the size in terms of PROGBITS and NOPROG BITS? The BL31 NOPROG BITS are usually overlayed on top of BL2 memory and this will let us know whether fitting both in SRAM is even possible. If both cannot fit together in SRAM, there are other options you can explore like loading BL31 directly from BootROM or using BL2 as an XIP BootROM image.
Best Regards Soby Mathew