Android 12 2.0.0 with Trusty enabled when 4GB RAM are configured

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Android 12 2.0.0 with Trusty enabled when 4GB RAM are configured

Jump to solution
3,423 Views
OliW
Contributor III

I use a custom board with i.MX8M Mini. 4G RAM is installed and configured.

Now I have enabled Trusty for this system, but loading the Trusty modules (trusty-log) fails and kernel just stop in the init sequence.

It seems there is a memory configuration problem because of the 4G of memory. Limiting the memory to 2GB for the kernel (mem=2G) solves the problem.

For Trusty the base address (MEMBASE) is configured to 0xBE000000 for i.MX8MM which is the 2GB boundary.

Looking at the address bank configuration the bootloader does it actually configures the following. CONFIG_NR_DRAM_BANKS is set to 3:

optee parameters start 0xbe000000, size 0x2000000
1. bank 0 start 0x40000000, size 0x7e000000
2. bank 1 start 0xc0000000, size 0x40000000
3. bank 2 start 0x100000000, size 0x40000000

The kernel chooses the following regions (for 4G configuration):

[ 0.000000][ T0] Zone ranges:
[ 0.000000][ T0] DMA32 [mem 0x0000000040000000-0x00000000ffffffff]
[ 0.000000][ T0] Normal [mem 0x0000000100000000-0x000000013fffffff]
[ 0.000000][ T0] Movable zone start for each node
[ 0.000000][ T0] Early memory node ranges
[ 0.000000][ T0] node 0: [mem 0x0000000040000000-0x00000000bdffffff]
[ 0.000000][ T0] node 0: [mem 0x00000000c0000000-0x000000013fffffff]
[ 0.000000][ T0] Initmem setup node 0 [mem 0x0000000040000000-0x000000013fffffff]
[ 0.000000][ T0] On node 0, zone DMA32: 8192 pages in unavailable ranges
[ 0.000000][ T0] cma: Reserved 800 MiB at 0x0000000086000000

There seems to be a gap for Trusty memory from 0xBE00 0000 to 0xC000 0000 which is OK.

Now when I try to load the Trusty log module the kernel just hangs from this point. Here is the kernel output. I have already added some debug printout giving the physical addresses of the memory regions used for shared buffers:

[ 1.908062][ T1] trusty trusty: trusty version: Project: imx8mm, Built: 07:19:24 Mar 30 2023
[ 1.909187][ T1] trusty trusty: selected api version: 5 (requested 5)
[ 1.910037][ T1] trusty trusty: trusty_init_msg_buf: FF-A version 0x10000, expected 0x10000
[ 1.911145][ T1] trusty trusty: trusty_init_msg_buf: SMC_FC_FFA_FEATURES in place
[ 1.912124][ T1] trusty trusty: trusty_init_msg_buf: FFA ID OK
[ 1.912897][ T1] trusty trusty: trusty_init_msg_buf: FFA_TX is at 0x101475000
[ 1.913832][ T1] trusty trusty: trusty_init_msg_buf: FFA_RX is at 0x101474000
[ 1.914799][ T1] trusty trusty: trusty_init_msg_buf: msg box init complete
[ 1.917074][ T1] trusty_ipc: now gets loaded
[ 1.960424][ T1] trusty_irq: now gets loaded
[ 1.974842][ T1] trusty_log: now gets loaded
[ 2.007747][ T1] trusty-log trusty:trusty-log: trusty_log_init: allocate 9 pages
[ 2.008755][ T1] trusty-log trusty:trusty-log: will add page 0x25c4000
[ 2.009614][ T1] trusty-log trusty:trusty-log: will add page 0x25c3000
[ 2.010514][ T1] trusty-log trusty:trusty-log: will add page 0x25c2000
[ 2.011374][ T1] trusty-log trusty:trusty-log: will add page 0x25c1000
[ 2.012235][ T1] trusty-log trusty:trusty-log: will add page 0x25c0000
[ 2.013098][ T1] trusty-log trusty:trusty-log: will add page 0x172000
[ 2.013951][ T1] trusty-log trusty:trusty-log: will add page 0x1d7000
[ 2.014817][ T1] trusty-log trusty:trusty-log: will add page 0x156b000
[ 2.015682][ T1] trusty-log trusty:trusty-log: will add page 0x156a000
[ 2.016546][ T1] trusty-log trusty:trusty-log: trusty_log_init: really allocate mem
[ 2.017549][ T1] trusty trusty: trusty_transfer_memory: dma map sg list
[ 2.018427][ T1] trusty trusty: trusty_transfer_memory: dma map sg list done 9
[ 2.019395][ T1] trusty trusty: trusty_transfer_memory: encode pages
[ 2.020236][ T1] trusty trusty: trusty_transfer_memory: total page len 36864
[ 2.021165][ T1] trusty trusty: trusty_transfer_memory: talk to trusty cons_mrd_offset 64

The kernal hang at the follwoing code in vendor/nxp-opensource/kernel_imx/drivers/trusty/trusty.c line 350:

		if (cons_mrd_offset) {
			u32 smc = lend ? SMC_FC_FFA_MEM_LEND :
					 SMC_FC_FFA_MEM_SHARE;
			/* First fragment */
			dev_info(dev, "%s: talk to trusty cons_mrd_offset %lu\n", __func__, cons_mrd_offset);
			smc_ret = trusty_smc8(smc, total_len,
					      fragment_len, 0, 0, 0, 0, 0);
		} else {

 

What is the correct memory configuration to run Trusty with 4G RAM on i.MX8M Mini?

Perhaps I have missed some entry in device tree?

0 Kudos
1 Solution
3,117 Views
OliW
Contributor III

Hi @brian14 ,

as I have discovered the mapping error in SPL I have digged a little bit deeper and found, that the range for virtual and physical address space is limited to 4GB (32 bit) in atf arm-trusted-firmware/plat/imx/imx8m/imx8mm/include/platform_def.h. See definition of PLAT_VIRT_ADDR_SPACE_SIZE and PLAT_PHY_ADDR_SPACE_SIZE:

#define PLAT_VIRT_ADDR_SPACE_SIZE	(1ull << 32)
#define PLAT_PHY_ADDR_SPACE_SIZE	(1ull << 32)

I have changed this to be 1ull << 34 as on imx8mp

#define PLAT_VIRT_ADDR_SPACE_SIZE	(1ull << 34)
#define PLAT_PHY_ADDR_SPACE_SIZE	(1ull << 34)

So my final patch to ATF is now:

diff --git a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
index 8702d5160..9f37a52f6 100644
--- a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
+++ b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
@@ -43,6 +43,7 @@ static const mmap_region_t imx_mmap[] = {
        MAP_REGION_FLAT(IMX_NS_OCRAM_BASE, IMX_NS_OCRAM_SIZE, MT_MEMORY | MT_RW), /* NS OCRAM */
        MAP_REGION_FLAT(IMX_ROM_BASE, IMX_ROM_SIZE, MT_MEMORY | MT_RO), /* ROM code */
        MAP_REGION_FLAT(IMX_DRAM_BASE, IMX_DRAM_SIZE, MT_MEMORY | MT_RW | MT_NS), /* DRAM */
+       MAP_REGION_FLAT(IMX_DRAM2_BASE, IMX_DRAM2_SIZE, MT_MEMORY | MT_RW | MT_NS), /* DRAM */
        MAP_REGION_FLAT(IMX_TCM_BASE, IMX_TCM_SIZE, MT_MEMORY | MT_RW | MT_NS), /* TCM */
        {0},
 };
diff --git a/plat/imx/imx8m/imx8mm/include/platform_def.h b/plat/imx/imx8m/imx8mm/include/platform_def.h
index 7691e2c90..20f284976 100644
--- a/plat/imx/imx8m/imx8mm/include/platform_def.h
+++ b/plat/imx/imx8m/imx8mm/include/platform_def.h
@@ -66,8 +66,8 @@
 #define PLAT_GICD_BASE                 U(0x38800000)
 #define PLAT_GICR_BASE                 U(0x38880000)

-#define PLAT_VIRT_ADDR_SPACE_SIZE      (1ull << 32)
-#define PLAT_PHY_ADDR_SPACE_SIZE       (1ull << 32)
+#define PLAT_VIRT_ADDR_SPACE_SIZE      (1ull << 34)
+#define PLAT_PHY_ADDR_SPACE_SIZE       (1ull << 34)

 #ifdef SPD_trusty
 #define MAX_XLAT_TABLES                        10
@@ -122,6 +122,8 @@
 #define IMX_CAAM_RAM_SIZE              U(0x10000)
 #define IMX_DRAM_BASE                  U(0x40000000)
 #define IMX_DRAM_SIZE                  U(0xc0000000)
+#define IMX_DRAM2_BASE                 ULL(0x100000000)
+#define IMX_DRAM2_SIZE                 U(0xc0000000)
 #define IMX_TCM_BASE                   U(0x7E0000)
 #define IMX_TCM_SIZE                   U(0x40000)

 With this change I can boot into Android using Trusty with FF-A and having the full 4GB address space enabled.

Can you confirm that this change to the size of virtual and physical address is valid on imx8mm? Or do think this might have bad side effects for other components?

View solution in original post

Tags (1)
0 Kudos
17 Replies
1,547 Views
paidaxing1223
Contributor I

Hello, excuse me, imx8mm android10 3G memory patch you are convenient to provide?

0 Kudos
3,389 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @OliW

For change the RAM size in your iMX8M Mini, you can reference this doc.

Solved: iMX8M Mini change RAM size - NXP Community

I hope this information will be helpful.

0 Kudos
3,379 Views
OliW
Contributor III

Hi @brian14 ,

thank you for your reply. This was a very useful information, but it is about how to move the address to valid physical address space again if less memory is installed.

What must be adjusted when I have 4GB? Is the address given relative to start address of physical memory which is at 0x40000000? Because then moving it to the end of my address space will cross the 32bit boundary and result in a 64bit address as base address. And with that I was not even able to run SPL bootloader because it had problems setting up the xlat_tables (failed in function "mmap_add_region_check" with -ERANGE) which seems not to support 64 bit address pointers.

I have tried to move it to 0xFE000000 (end of 32 bit address space) but then bootloader does not boot any more and stops with the following log:

 

 

U-Boot SPL 2022.04-ge1ea15e1a1-dirty (Apr 17 2023 - 07:59:07 +0000)
power_bd71837_init
DDRINFO: start DRAM init
DDRINFO: DRAM rate 3000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
SEC0:  RNG instantiated
Normal Boot
Trying to boot from MMC1
Magic is incorrect.
Error validating A/B metadata from disk.
Resetting and writing new A/B metadata to disk.
Booting from bootloader_a...
NOTICE:  BL31: v2.6(release):47133edca-dirty
NOTICE:  BL31: Built : 07:59:11, Apr 17 2023
ERROR:   trusty: Found unknown image, 0xffffffff
ERROR:   Error initializing runtime service trusty_fast


U-Boot 2022.04-ge1ea15e1a1-dirty (Apr 14 2023 - 13:24:56 +0000)

CPU:   i.MX8MMQ rev1.0 1800 MHz (running at 1200 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 28C
Reset cause: POR
Model: Roche i.MX8MM PID
DRAM:  1. optee parameters 0xfe000000, size 0x2000000
1. bank 0 start 0x40000000, size 0xbe000000
3. bank 1 start 0x100000000, size 0x40000000
4 GiB
HW Type: PID (0x1)
HW Version: 4.40
Core:  86 devices, 21 uclasses, devicetree: separate
POST memory PASSED
MMC:   FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Fail to setup video link
In:    serial
Out:   serial
Err:   serial

 BuildInfo:
  - ATF 47133ed

flash target is MMC:2
Net:   No ethernet found.
INFO Initializing Trusty device
INFO selected trusty api version: 0 (requested 3)
INFO Initializing Trusty IPC device

 

I have no idea why the trusty image cannot be loaded any more. This I have to analyze.

0 Kudos
3,345 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @OliW

Chapter 3.2 of "i.MX Android security user's guide.pdf" has a detailed description about changing the address. It has three steps, take i.MX8QM as an example.

1. Change the configure in "${MY_ANDROID}/vendor/nxp-opensource/imx-mkimage"

2. Modify the files in ATF:"${MY_ANDROID}/vendor/nxp-opensource/arm-trusted-firmware/plat/imx/$(PLAT)/include/platform_def.h."

3. Modify the configure in trusty: "plat/imx/imx8qm/include/platform_def.h"

Could you please share the modified patch? My team will help to check it.

Best regards, Brian.

0 Kudos
3,338 Views
OliW
Contributor III

Hi @brian14 ,

thanks for your reply.

Unfortunatly the example for i.MX8QM in the Security User's Guide is quite different from the code for i.MX8MM.

I have done my best to adopt it for i.MX8MM:

Patch to trusty in trusty/device/nxp/imx8/project/imx8mm.mk

diff --git a/project/imx8mm.mk b/project/imx8mm.mk
index 2fe5c5f..412aa56 100644
--- a/project/imx8mm.mk
+++ b/project/imx8mm.mk
@@ -19,8 +19,9 @@ TARGET := imx8mm
 WITH_SNVS_DRIVER := true

 #Enlarge imx8mm storage size to 2048 blocks.
-STORAGE_RPMB_BLOCK_COUNT = 2048
-MEMBASE           := 0xBE000000
+STORAGE_RPMB_BLOCK_COUNT = 8192
+#MEMBASE           := 0xBE000000
+MEMBASE           :=  0xFE000000

 include project/imx8-inc.mk

 

Rebuild trusty and copy "lk.bin" and "confirmationui.app" over to vendor/nxp/fsl-proprietary/uboot-firmware/imx8m/ in AOSP code.

Patch ATF

diff --git a/plat/imx/imx8m/imx8mm/platform.mk b/plat/imx/imx8m/imx8mm/platform.mk
index bfbcaed38..f387b371f 100644
--- a/plat/imx/imx8m/imx8mm/platform.mk
+++ b/plat/imx/imx8m/imx8mm/platform.mk
@@ -147,7 +147,7 @@ ERRATA_A53_835769   :=      1
 ERRATA_A53_843419      :=      1
 ERRATA_A53_855873      :=      1

-BL32_BASE              ?=      0xbe000000
+BL32_BASE              ?=      0xfe000000
 $(eval $(call add_define,BL32_BASE))

 BL32_SIZE              ?=      0x2000000

Patch imx-mkimage:

diff --git a/iMX8M/soc.mak b/iMX8M/soc.mak
index a98195e..c2bde7c 100644
--- a/iMX8M/soc.mak
+++ b/iMX8M/soc.mak
@@ -32,7 +32,7 @@ PLAT = imx8mm
 HDMI = no
 SPL_LOAD_ADDR = 0x7E1000
 SPL_FSPI_LOAD_ADDR = 0x7E2000
-TEE_LOAD_ADDR ?= 0xbe000000
+TEE_LOAD_ADDR ?= 0xfe000000
 ATF_LOAD_ADDR = 0x00920000
 VAL_BOARD = val
 #define the F(Q)SPI header file

Linux Kernel has trusty node in device tree:

       trusty {
               compatible = "android,trusty-smc-v1";
               ranges;
               #address-cells = <2>;
               #size-cells = <2>;
               trusty-irq {
                       compatible = "android,trusty-irq-v1";
                       interrupt-ranges = < 0 15 0>;
                       ipi-range = <8 15 8>;
              };
               trusty-virtio {
                       compatible = "android,trusty-virtio-v1";
               };
               trusty-log {
                       compatible = "android,trusty-log-v1";
               };
       };

LCDIF driver has trusty option:

 &lcdif {
        trusty;
        status = "okay";
 };


Do I need the ramoops. They are in my device tree. Is this related to trusty? I have not changed it when moving TEE to 0xFE000000.

&resmem {
       ramoops@0xbdf00000 {
               compatible = "ramoops";
               reg = <0 0xbdf00000 0 0x00100000>;
               record-size     = <0x00020000>;
               console-size    = <0x00020000>;
               ftrace-size     = <0x00020000>;
               rpmsg-size      = <0x00020000>;
       };
};

But the result is the same as in my first post. The kernel hangs when the trusty-log module gets loaded.

Limiting kernel memory to 2GB solves the problem.

But now I can  even go up to 3000M for kernel memory because kernel only populates the range from

[ 0.000000][ T0] node 0: [mem 0x0000000040000000-0x00000000fb7fffff]

If I limit the kernel memory to 3G (3072M) kernel populates two memory regions:

[ 0.000000][ T0] node 0: [mem 0x0000000040000000-0x00000000fdffffff]
[ 0.000000][ T0] node 0: [mem 0x0000000100000000-0x0000000101ffffff]

So it leaves a gap for TEE firmware. But then kernel hangs when trusty-log module gets loaded.

My test showed that going beyond 0x100000000 (above 4GB) for TEE base address does not work and ends up in SPL bootloader with error ERANGE when applying the xlat_tables.

0 Kudos
3,331 Views
OliW
Contributor III

BTW: I have tested Android 11 2.6.0 version for the board also running with Trusty and 4GB enabled. I can Android without any problems. The system runs succesfully with 4GB and Trusty enabled.

0 Kudos
3,323 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @OliW,

Thak you for your reply, please try the following steps:

1.For the "STORAGE_RPMB_BLOCK_COUNT = 8192", you had better not use all of the RPMB block, we also put something else in it. You can change it to be 2048 and have a try.

2.Could you send your full booting log to us? We need the full log to confirm the all the services of trusty are enabled.

3. Could you get the memory information in the uboot ? commands like bdinfo.

Have a great day!

 

0 Kudos
3,304 Views
OliW
Contributor III

I have reverted trusty (TEE) software binary to the one included in your tar file containing proprietary software. So RPMB count is reset to 2048 and adress is set back to 0xBE000000.

Please see the complete logs of booting and the bdinfo in the attachment.

Limiting memory for kernel to 3000M lets the system boot with the trusty binary from the original tar archive.

Might it be the problem if some shared buffers allocated by the kernel are in the address space above 4GB physical address?

0 Kudos
3,238 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @OliW

Thank you for your reply.

Some things need to be confirmed.

For the "a12_trusty_boot_fail_with_4GB.txt", The optee start address is 0xbe000000. Does this address still have errors (The kernel hangs when the trusty-log module gets loaded.)?

I see the error logs you sent before; it hangs in the uboot. Could you send the failure logs with RPMB count to 2048, start address as 0xfe000000?

0 Kudos
3,226 Views
OliW
Contributor III

Hi @brian14 ,

the logs were taken with the default TEE software included in the proprietary tar archive for A12.0.0_1.0.0.

So base address is at 0xBE000000 and RPM_COUNT is 2048. I have tried start address at 0xFE000000 and RPMB count set to 2048 but it does not change anything when I give the full 4GB memory size to the kernel. Limiting to 3000MB helps (limit to 3GB does not work any more).

Result is always the same that kernel stops when loading trusty_log module. Output is the same as in the logs attached.

0 Kudos
3,180 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @OliW

I suggest to may the memory after TEE region. For example:

diff --git a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
index c17ca1292..38e034dd8 100644
--- a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
+++ b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
@@ -49,6 +49,7 @@ static const mmap_region_t imx_mmap[] = {
MAP_REGION_FLAT(IMX_NS_OCRAM_BASE, IMX_NS_OCRAM_SIZE, MT_MEMORY | MT_RW), /* NS OCRAM */
MAP_REGION_FLAT(IMX_ROM_BASE, IMX_ROM_SIZE, MT_MEMORY | MT_RO), /* ROM code */
MAP_REGION_FLAT(IMX_DRAM_BASE, IMX_DRAM_SIZE, MT_MEMORY | MT_RW | MT_NS), /* DRAM */
+ MAP_REGION_FLAT(IMX_DRAM2_BASE, IMX_DRAM2_SIZE, MT_MEMORY | MT_RW | MT_NS), /* DRAM */
MAP_REGION_FLAT(IMX_TCM_BASE, IMX_TCM_SIZE, MT_MEMORY | MT_RW | MT_NS), /* TCM */
{0},
};
diff --git a/plat/imx/imx8m/imx8mm/include/platform_def.h b/plat/imx/imx8m/imx8mm/include/platform_def.h
index 430164d2c..1939876f9 100644
--- a/plat/imx/imx8m/imx8mm/include/platform_def.h
+++ b/plat/imx/imx8m/imx8mm/include/platform_def.h
@@ -125,6 +125,8 @@
#define IMX_CAAM_RAM_SIZE U(0x10000)
#define IMX_DRAM_BASE U(0x40000000)
#define IMX_DRAM_SIZE U(0xc0000000)
+#define IMX_DRAM2_BASE U(0x100000000)
+#define IMX_DRAM2_SIZE U(0x40000000)
#define IMX_TCM_BASE U(0x7E0000)
#define IMX_TCM_SIZE U(0x40000)

If still have problem, try to map all the dram in the ATF.

Please let me know if this works.

Have a great day!

0 Kudos
3,159 Views
OliW
Contributor III

Hi @brian14 ,

thank you for the reply. This was a very promising tip because it really sounds to be the reason for the problem that memory above 0x100000000 has not been mapped to ATF space.

Unfortunately the change did not help (even after a clean rebuild of the AOSP). Behaviour is still the same. Kernel stops when FF-A exchange buffers are first used for providing the Trusty log buffers.

What do you mean with mapping the whole DRAM? I far as I can see the patch you have provided already maps the complete DRAM from 0x40000000 to 0xFFFFFFFF and the added mapping maps 0x100000000 to 0x140000000 which is my complete 4GB memory space in total.

0 Kudos
3,145 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @OliW

Yes, for 4G dram. The patch is to map the whole dram.

1.Please try the following patch, this patch is used to remove the FF-A

diff --git a/services/spd/trusty/trusty.c b/services/spd/trusty/trusty.c
index 7de6633e1..ce21c58bc 100644
--- a/services/spd/trusty/trusty.c
+++ b/services/spd/trusty/trusty.c
@@ -428,7 +428,7 @@ void plat_trusty_set_boot_args(aapcs64_params_t *args)
static int32_t trusty_setup(void)
{
entry_point_info_t *ep_info;
-#ifndef PLAT_imx8mq
+#ifndef PLAT_imx8mm
uint32_t instr;
#endif
uint32_t flags;
@@ -442,7 +442,7 @@ static int32_t trusty_setup(void)
return -1;
}



-#ifndef PLAT_imx8mq
+#ifndef PLAT_imx8mm
/* memmap first page of trusty's code memory before peeking */
ret = mmap_add_dynamic_region(ep_info->pc, /* PA */
ep_info->pc, /* VA */
diff --git a/services/spd/trusty/trusty.mk b/services/spd/trusty/trusty.mk
index 5ceb6d04b..2fdd665c8 100644
--- a/services/spd/trusty/trusty.mk
+++ b/services/spd/trusty/trusty.mk
@@ -4,7 +4,7 @@
# SPDX-License-Identifier: BSD-3-Clause
#



-ifneq (${PLAT},imx8mq)
+ifneq (${PLAT},imx8mm)
TRUSTY_SPD_WITH_SHARED_MEM ?= 1
endif

2. Print more logs, modify code as following:

diff --git a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
index c17ca1292..8d6145834 100644
--- a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
+++ b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
@@ -204,7 +204,7 @@ void bl31_early_platform_setup2(u_register_t arg0, u_register_t arg1,
console_imx_uart_register(IMX_BOOT_UART_BASE, IMX_BOOT_UART_CLK_IN_HZ,
IMX_CONSOLE_BAUDRATE, &console);
/* This console is only used for boot stage */
- console_set_scope(&console, CONSOLE_FLAG_BOOT);
+ console_set_scope(&console, CONSOLE_FLAG_BOOT| CONSOLE_FLAG_RUNTIME);



imx8m_caam_init();

Then please share the logs.

Best regards, Brian.

0 Kudos
3,119 Views
OliW
Contributor III

Hi @brian14 ,

I have two comments to patches you have provided.

For the first patch (mapping memory to ATF)

Mapping the memory from 0x100000000 to ATF seems not to work because SPL bootloader gives an error:

ERROR:   mmap_add_region_check() failed. error -34

when I apply the memory mapping changes to ATF. I think that's the reason why nothing changes regarding the kernel hang when FF-A is used.

 

Now I have tried your second patch to diable FF-A:

Now the system can boot into Android with full 4GB enabled. Please see attached kernel log of the full successful boot.

0 Kudos
3,118 Views
OliW
Contributor III

Hi @brian14 ,

as I have discovered the mapping error in SPL I have digged a little bit deeper and found, that the range for virtual and physical address space is limited to 4GB (32 bit) in atf arm-trusted-firmware/plat/imx/imx8m/imx8mm/include/platform_def.h. See definition of PLAT_VIRT_ADDR_SPACE_SIZE and PLAT_PHY_ADDR_SPACE_SIZE:

#define PLAT_VIRT_ADDR_SPACE_SIZE	(1ull << 32)
#define PLAT_PHY_ADDR_SPACE_SIZE	(1ull << 32)

I have changed this to be 1ull << 34 as on imx8mp

#define PLAT_VIRT_ADDR_SPACE_SIZE	(1ull << 34)
#define PLAT_PHY_ADDR_SPACE_SIZE	(1ull << 34)

So my final patch to ATF is now:

diff --git a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
index 8702d5160..9f37a52f6 100644
--- a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
+++ b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c
@@ -43,6 +43,7 @@ static const mmap_region_t imx_mmap[] = {
        MAP_REGION_FLAT(IMX_NS_OCRAM_BASE, IMX_NS_OCRAM_SIZE, MT_MEMORY | MT_RW), /* NS OCRAM */
        MAP_REGION_FLAT(IMX_ROM_BASE, IMX_ROM_SIZE, MT_MEMORY | MT_RO), /* ROM code */
        MAP_REGION_FLAT(IMX_DRAM_BASE, IMX_DRAM_SIZE, MT_MEMORY | MT_RW | MT_NS), /* DRAM */
+       MAP_REGION_FLAT(IMX_DRAM2_BASE, IMX_DRAM2_SIZE, MT_MEMORY | MT_RW | MT_NS), /* DRAM */
        MAP_REGION_FLAT(IMX_TCM_BASE, IMX_TCM_SIZE, MT_MEMORY | MT_RW | MT_NS), /* TCM */
        {0},
 };
diff --git a/plat/imx/imx8m/imx8mm/include/platform_def.h b/plat/imx/imx8m/imx8mm/include/platform_def.h
index 7691e2c90..20f284976 100644
--- a/plat/imx/imx8m/imx8mm/include/platform_def.h
+++ b/plat/imx/imx8m/imx8mm/include/platform_def.h
@@ -66,8 +66,8 @@
 #define PLAT_GICD_BASE                 U(0x38800000)
 #define PLAT_GICR_BASE                 U(0x38880000)

-#define PLAT_VIRT_ADDR_SPACE_SIZE      (1ull << 32)
-#define PLAT_PHY_ADDR_SPACE_SIZE       (1ull << 32)
+#define PLAT_VIRT_ADDR_SPACE_SIZE      (1ull << 34)
+#define PLAT_PHY_ADDR_SPACE_SIZE       (1ull << 34)

 #ifdef SPD_trusty
 #define MAX_XLAT_TABLES                        10
@@ -122,6 +122,8 @@
 #define IMX_CAAM_RAM_SIZE              U(0x10000)
 #define IMX_DRAM_BASE                  U(0x40000000)
 #define IMX_DRAM_SIZE                  U(0xc0000000)
+#define IMX_DRAM2_BASE                 ULL(0x100000000)
+#define IMX_DRAM2_SIZE                 U(0xc0000000)
 #define IMX_TCM_BASE                   U(0x7E0000)
 #define IMX_TCM_SIZE                   U(0x40000)

 With this change I can boot into Android using Trusty with FF-A and having the full 4GB address space enabled.

Can you confirm that this change to the size of virtual and physical address is valid on imx8mm? Or do think this might have bad side effects for other components?

Tags (1)
0 Kudos
3,091 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @OliW

Modifying is OK. It should have no bad side effects for other components.

Best regards, Brian.

0 Kudos
3,205 Views
OliW
Contributor III

Hi @brian14 ,

I have digged a little big deeper and it seems, that the new feature of using FF-A in Arm Trusted Firmware for trusty communication causes this problem when kernel maps buffers (using the SMC_FC64_FFA_RXTX_MAP function) with a physical address over the 4GB limit (address more than 32bit).

I am not very familiar with that feature but I have read in the commit to ATF:

https://github.com/nxp-imx/imx-atf/commit/3d6f04c4f55630c68ae21ce9f0351390bdcf7293

that the space to contain TF-A is limited on some platforms. Where is this documented?

I can also see that not everywhere the 64 bit version of the SMC calls are used regarding exchanging buffers over FF-A to trusty. Might this be a problem?

When I limit the memory to 3000MB I see that the addresses of all exchanged buffers used fit into 32bit words.

BTW: A11 2.6.0 does not use FF-A and that's why it works correctly with 4GB memory.

0 Kudos