TF-A MMU/TrustZone Region Mapping Issue on LS1046A (Single Binary for 1GB & 4GB DRAM)

[gabnes]

Greetings,

We are working with the LS1046A and currently maintain separate builds for two board versions: one with 1GB DRAM and another with 4GB DRAM. Our goal is to create a single TF-A binary that works for both.

We define the following in our configuration:

#define PLAT_DEF_DRAM0_SIZE 0x40000000 // Always 1GB, even for the 4GB board version

We use static DDR configurations, and at runtime, we return the total DRAM size (1GB or 4GB) via board_static_ddr().

The primary problem lies in TrustZone and MMU region mapping. Secure memory regions are not correctly set when running on the 4GB version. In the current implementation (found in plat/nxp/common/setup/ls_common.c inside mmap_add_ddr_regions_statically), when the board has 4GB of DRAM, the secure memory region is set to:

0xFBE00000 - 0x100000000

However, security-related data is actually placed at:

0xBBE00000 - 0xC0000000

which matches the secure region layout of the 1GB DRAM board.

To resolve this, we modified mmap_add_ddr_regions_statically to behave the same way on the 4GB board as it does on the 1GB board—ensuring that 0xBBE00000 - 0xC0000000 is covered as secure RAM while treating the rest of DRAM as non-secure.

We applied similar changes in drivers/nxp/tzc/plat_tzc400.c, specifically in the populate_tzc400_reg_list function.

Despite our modifications, the updated regions are not reflected in practice. In U-Boot (on the 4GB board):

• I can access 0xBBE00000 - 0xC0000000 using md or mw commands without issues.
• However, accessing 0xFBE00000 - 0x100000000 triggers an exception.

It seems that the system is still enforcing default region settings instead of applying our intended configuration. On the 1GB board, everything works as expected.

Questions:

1. How can we correctly handle this issue to achieve a single TF-A binary for both board versions?
2. Are we missing any additional steps to ensure the MMU and TrustZone settings are updated correctly?
3. Is this approach even feasible, or do we need a different strategy?

[yipingwang]

- The predefined macro "#define PLAT_DEF_DRAM0_SIZE 0x40000000" doesn't matter, which is override by the actual total DRAM size returned via board_static_ddr() (1G or 4G at runtime).

- As customer didn't share their specific code change, it's hard to tell what may be missing in the case. suggest adding some helpful printf log in drivers/nxp/tzc/plat_tzc400.c and plat/nxp/common/setup/ls_common.c to ensure the variables match with the expected values to identify the possible problems, and share more helpful debug logs for further analysis.

[gabnes]

The #define PLAT_DEF_DRAM0_SIZE 0x40000000 macro is relevant when using a 4GB DRAM board and returning this size via board_static_ddr(), as it influences the memory layout defined in plat/nxp/common/include/default/plat_default_def.h. Below, I have attached logs from the ATF boot process with the current configuration on a 4GB board.

NOTICE: 4 GB DDR4, 64-bit, CL=11, ECC on
ERROR: Incorrect DRAM0 size is defined in platform_def.h
NOTICE: DRAM Region 0: 0x80000000 - 0xfbdfffff
NOTICE: Secure DRAM Region 0: 0xfbe00000 - 0xffffffff
NOTICE: BL2: Built : 09:26:11, Mar 24 2025
NOTICE: BL2: Booting BL31
NOTICE: DRAM Region 0: 0x80000000 - 0xfbdfffff
NOTICE: Secure DRAM Region 0: 0xfbe00000 - 0xffffffff
NOTICE: DRAM Region 1: 0x880000000 - 0x8ffffffff
NOTICE: BL31: Built : 09:26:11, Mar 24 2025

As seen in the logs, the first issue is the ERROR message generated in populate_dram_regions_info(). Additionally, the Secure DRAM regions are incorrectly configured, as the current memory map resembles the 1GB version due to the PLAT_DEF_DRAM0_SIZE definition.

As I mentioned in my initial post, the secure regions are now defined in a different location than the regions currently covered. Furthermore, modifying these regions in the ATF code does not produce the expected behavior. Despite these modifications, I am still able to read and write to the secure regions using the U-Boot CLI.

[yipingwang]

Discussing with the AE team.