i.MX8mm 1GB android trusty support boot issues

Showing results for 
Search instead for 
Did you mean: 

i.MX8mm 1GB android trusty support boot issues

Contributor I

I'm trying to get trusty support running on my 1GB i.MX8mm based SoM but the bootloader is setting the amount of RAM incorrectly.

I've narrowed down the cause to being the u-boot code here https://source.codeaurora.org/external/imx/uboot-imx/tree/arch/arm/mach-imx/imx8m/soc.c?h=android-11.... Debugging on my board shows the calculation done is:

gd->bd->bi_dram[bank].size = optee_start - gd->bd->bi_dram[bank].start;

gd->bd->bi_dram[bank].size = 0xbe000000 - 0x40000000 = 7e000000

Which sets the dram bank size to the erroneous value of 7e000000 which my board passes through to the kernel. The kernel then gets stuck where I assume it's trying to use this nonexistent memory. I've tried manually setting the bank size to 3e000000 but this causes the boot to get stuck in the bootloader. The kernel reports the incorrect amount of ram during initialisation with trusty:

[ 0.000000] Memory: 1643664K/2064384K available (21692K kernel code, 2328K rwdata, 13808K rodata, 5376K init, 586K bss, 93040K reserved, 327680K cma-reserved)

on a bootloader image without trusty:

[ 0.000000] Memory: 647764K/1048576K available (21692K kernel code, 2328K rwdata, 13808K rodata, 5376K init, 586K bss, 73132K reserved, 327680K cma-reserved)

Note that using a SoM with 2GB of ram works as expected and using a bootloader not containing trusty on the 1GB module works.


0 Kudos
3 Replies

NXP TechSupport
NXP TechSupport

In general recommended to use latest NXP L5.10.35_2.0.0 linux/uboot (from

source.codeaurora.org/external/imx repository) :




>kept CONFIG_NR_DRAM_BANKS at 2 (unsure if this should be 1 or 2; hard to find good
>documenation about what this actually configures.. ) Have tried different options here, issue still persists.


0 Kudos

Contributor I

Thanks for having a look at the issue. I've checked the other two repositories. https://source.codeaurora.org/external/imx/uboot-imx/tree/?h=lf_v2021.04 has no difference in the dram_init_banksize() function and https://source.codeaurora.org/external/imx/linux-imx/tree/?h=lf-5.10.y doesn't contain the soc.c source file.

The bank sizes configure how many DRAM banks the device has. From my debug output you can see our board has 1 bank in use.

RAM Configuration:
Bank #0: 40000000 992 MiB
Bank #1: 0 0 Bytes

Two banks is only required on boards with >4GB of memory. I don't think the number of DRAM banks is relevant in this issue. The TEE is only ever going to be in bank 0.

0 Kudos

Contributor I

If I manually set the ram amount to 0x3e000000 instead of 0x7e000000 the bootloader gets stuck here:

Reset cause: POR
initcall: 000000004021843c
Model: Variscite DART-MX8M-MINI
initcall: 0000000040217d48
DRAM: initcall: 0000000040206e1c
dram_init: gd->ram_size = 0x3e000000
initcall: 0000000040217f6c
Monitor len: 000E6CC0
Ram size: 3E000000
Ram top: BE000000
initcall: 00000000402179e4
initcall: 00000000402179f8
TLB table from bdff0000 to be000000
initcall: 0000000040217d1c
Video frame buffers from bdff0000 to bdff0000
initcall: 0000000040217e30
initcall: 0000000040217b68
Reserving 923k for U-Boot at: bdf09000
initcall: 0000000040217b30
Reserving 65536k for malloc() at: b9f09000
initcall: 0000000040217cc0
Reserving 168 Bytes for Board Info at: b9f08f58
initcall: 0000000040217e38
initcall: 0000000040217af4
Reserving 400 Bytes for Global Data at: b9f08dc8
initcall: 0000000040217a84
Reserving 35392 Bytes for FDT at: b9f00388
initcall: 0000000040217e40
initcall: 0000000040217e48
initcall: 0000000040217e68
initcall: 0000000040217fe8
initcall: 0000000040206cc8
initcall: 0000000040217e7c

RAM Configuration:
Bank #0: 40000000 992 MiB
Bank #1: 0 0 Bytes

DRAM: 992 MiB
initcall: 0000000040217a60
New Stack Pointer is: b9f00370
initcall: 0000000040217c7c
initcall: 0000000040217e50
initcall: 0000000040217e58
initcall: 0000000040217c04
Relocation Offset is: 7dd09000
Relocating to bdf09000, new gd at b9f08dc8, sp at b9f00370
initcall: 0000000040217e20
initcall: 00000000bdf210bc
initcall: 00000000bdf210c4
initcall: 0000000040218330 (relocated to 00000000bdf21330)
Added memory mapping (5): 40000000 3e000000


0 Kudos