kernel crash in __create_pgd_mapping when I growing up ram size

[cedric_thamin]

Hi everybody

I am working with a Freescale i.MX8MQ EVK

And I have a crash in kernel file arch/arm64/mm/mmu.c function  __create_pgd_mapping when I change u-boot "U-Boot 2019.04-4.19.35-1.1.0+g9d5089bdf4" for growing up my ram size.

Call stack :

[ 0.000000] Call trace:
[ 0.000000] __create_pgd_mapping+0x7c/0x7a8
[ 0.000000] map_kernel_segment+0x70/0xa4
[ 0.000000] paging_init+0x154/0x7f4
[ 0.000000] setup_arch+0x1c0/0x518
[ 0.000000] start_kernel+0x70/0x400

Actually it is working with 1 DRAM_BANK of 3G. I have 4G available on my board so I apply a patch in u-boot for adding a second DRAM_BANK :

#define PHYS_SDRAM_2 0x100000000
#define PHYS_SDRAM_2_SIZE 0x40000000 /* 1GB */

Uboot extract with result of patch: board/freescale/imx8mq_evk/imx8mq_evk.c

int dram_init(void)
{
/* rom_pointer[1] contains the size of TEE occupies */
if (rom_pointer[1])
gd->ram_size = PHYS_SDRAM_SIZE - rom_pointer[1];
else
gd->ram_size = PHYS_SDRAM_SIZE;

#if CONFIG_NR_DRAM_BANKS > 1
gd->ram_size += PHYS_SDRAM_2_SIZE;
#endif

return 0;
}

int dram_init_banksize(void)
{
gd->bd->bi_dram[0].start = PHYS_SDRAM;
if (rom_pointer[1])
{
gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE -rom_pointer[1];
}
else
gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
#if CONFIG_NR_DRAM_BANKS > 1
gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
#endif
return 0;
}

phys_size_t get_effective_memsize(void)
{
if (rom_pointer[1])
return (PHYS_SDRAM_SIZE - rom_pointer[1]);
else
return PHYS_SDRAM_SIZE;
}

This patch is working with "U-Boot SPL 2018.03-imx_v2018.03_4.14.78_1.0.0_ga+ge60de51"

__create_pgd_mapping take as argument pgd_t *pgdir, but when I try to access to this pointer the crash occur if I boot with "U-Boot 2019.04-4.19.35-1.1.0+g9d5089bdf4" and it is working with  "U-Boot SPL 2018.03-imx_v2018.03_4.14.78_1.0.0_ga+ge60de51"

(see __create_pgd_mapping sources attached, it should be printed, like with u-boot-2018.03,

[ 0.000000] arch/arm64/mm/mmu.c - 334 - __create_pgd_mapping : CTHHHHHHHHHHHHHHHHHHHHHHHHH phys_addr_t phys '0x40480000'

But no ....it is craching

Do you have any idea?

I checked value of pgd_t *pgdir it is the same in both case.

Do you have a documentation reference for adding a RAM_BANK which explain difference between u-boot 2018-03 and u-boot 2019-04?

I add kernel boot trace with u-boot 2018.03 and u-boot 2019.04

Thanks for your help.

Best regards,

Cedric Thamin.

[Aditya2125]

hello @cedric_thamin,

I am getting same error regarding mapping with LPDDR4 6gb RAM in my custom board. i am using imx8mp processor.

can you look in to this? suggest solution for the same.

https://community.nxp.com/t5/i-MX-Processors/IMX8MPlus-LPDDR4-6GB-quot-Starting-Kernel-quot/m-p/1528...

[harshitshah]

Hi @cedric_thamin ,

Are you able to boot the i.MX8MQ board with 4GB DDR configuration? In my case as well the U-boot works fine with 2018.03 however it is not working in the case of 2019.04 and the kernel is crashing at the same location as yours.

Can you please provide the patchset if the issue is resolved at your end? 

Regards.

[cedric_thamin]

Hi sorry for delai.

Find attached the patch.

For using it you should :
uncomment CONFIG_IMX8M_4G_LPDDR4=y in configs/imx8mq_evk_defconfig
Remove optee functionalities :
In yocto-meta/nxp/meta-fsl-bsp-release/imx/meta-bsp/conf/layer.conf
Comment line : DISTRO_FEATURES_append = " optee"

I didn't fix my problem with tee

[weidong_sun]

Hello Cedric,

Below is the answer from i.MX Expert, check it, please!

-------------------------------------------

Just a quick suggestion. On the imx_v2019.04_4.19.35_1.1.0 U-Boot there is a CONFIG_IMX8M_4G_LPDDR4 option that should be selected to suport 4GB operation.

The target that uses it is a imx8mm evk target, but the same idea can be applied to imx8mq.

1. In the defconfig file customer needs to select CONFIG_IMX8M_4G_LPDDR4

See configs/imx8mm_evk_4g_android_defconfig:

CONFIG_IMX8M_4G_LPDDR4=y

2. In include/configs/imx8mm_evk_android.h we have:

#ifdef CONFIG_IMX8M_4G_LPDDR4
#undef PHYS_SDRAM_SIZE
#define PHYS_SDRAM_SIZE 0xC0000000 /* 3GB */
#define PHYS_SDRAM_2 0x100000000
#define PHYS_SDRAM_2_SIZE 0x40000000 /* 1GB */
#undef CONFIG_NR_DRAM_BANKS
#define CONFIG_NR_DRAM_BANKS 2
#endif

3. In the board file board/freescale/imx8mm_evk/imx8mm_evk.c:

Please check dram_init() and dram_init_banksize() as an example on how to use the full 4GB.

By following these 3 steps the customer will be able to use the full 4GB of RAM on their i.MX8MQ board.

---------------------------------------------

Hope the answer is helpful to you!

Have a nice day!

B.R,

Weidong

[cedric_thamin]

Hi

Many thanks for your answer. Patch which I used is delivered by partner... and I didn't understand it a lot. With your message I can use imx8mm as reference and try to understand.
So I start from scratch or nearly, and follow yours recommendation.

And I add some idea :

  In board/freescale/imx8mq_evk/imx8mq_evk.c I added function : get_effective_memsize found in imx8mm_evk.c and in patch delivered by partner.

   I add so lpddr4_timing_4g.c. I tried without it (lpddr4_timing.o is used), with file found in board/freescale/imx8mm_evk/ and with file delivred by partner.
In all case I had same issue.

Do you think my issue can come from this file? Partner tested it with u-boot 2018-03 and told us it is working fine...

Find attached u-boot-2019.04 patch and boot trace.

Thanks for your help.

Best regards,

Cedric T

[weidong_sun]

Hello Cedric,

Don't recommend old patch for 4.19.35, because the patch doesn't change linux kernel.

Correct method is below:

--------------------

I.MX8MM supports CONFIG_IMX8M_4G_LPDDR4, then I.MX8MQ can refer to I.MX8MM to modify it to support 4GB LPDDR4

1. The code of spl.c itself does not need to be modified.
2. imx8mq_evk.h modifies the DDR size according to imx8mm_evk.h.
3. lpddr4_timg.c
- Use RPA to generate a 4GB script
https://community.nxp.com/docs/DOC-340179
--Use ddr stress test tool to verify and generate timg.c
---Replace timg.c of imx8mq with timg.c
[comment]
No manual modification is required, all are automatic.

---------------------

Hope abvoe advice is helpful to you.

Have a nice day!

B.R,

Weidong

[cedric_thamin]

Hi

Again many thanks for your help.

I don't understand clearly

"Don't recommend old patch for 4.19.35, because the patch doesn't change linux kernel."

    Can you confirme to me : No change needs in linux kernel? All change should be done in u-boot?
I am going try to follow instructions ...but it is not in my usual work . I need time.

[weidong_sun]

Hello Cedric,

>>"Don't recommend old patch for 4.19.35, because the patch doesn't change linux kernel."

Yes, I confirmed it with i.MX Exper team member who is in charge of  memory calibration/stress test. so we gave you above feedback

>>No change needs in linux kernel? All change should be done in u-boot?

Yes, just in u-boot.

Have  a nice day!

B.R,

Weidong

[cedric_thamin]

Hi Wigros

Again and again many thanks for your help. All yours suggestions was right and help me.

Sorry for delay but I had some difficulties to do what you purpose to me ... and I failed :smileysilly:.
Create lpddr4_timg.c with your tools is too hard for me, so I push very strong to my partner and they checked NXP BSP config. OPTEE feature was deactivated in file /meta-fsl-bsp-release/imx/meta-bsp/conf/layer.conf
When I did same-thing everything is working.
So I hope this thread can be useful for other people.
Patch attached is working fine but only if optee is deactivated.
Now my question is (if you have some time again for me ) :
How to configure optee for working with this new config?
Have you any suggestion?

Best regards and many thanks.

Cedric Thamin.

[weidong_sun]

Hello Cedric ,

   OPTEE is not releated to DDR configurations, after compilation is done in yocto, optee image will be created in deploy path, for exampe, optee.tar. it can be programmed to flash together with other images by uuu tool.

    if the reminder can't help you understand optee , create a new ticket for it , please!

Have a nice day!

B.R,

Weidong

[cedric_thamin]

Hi

And optee no need ram configuration? No way to tell it 4Gram is available? Perhaps if optee is configured with only 3g ram and  kernel with 4 gram the issue occurs?

[weidong_sun]

No relations to 3GB or 4GB. 

your DDR is managed by linux system.

weidong

[weidong_sun]

Hello Cedric,

I sent a document to you by personal email.

check it , please!

Have a nice day!

B.R,

Weidong

[cedric_thamin]

Hi

I said in one week ...Only one month later I found time for doing this job...sorry for delay.

I received you document and it is a good example for growing ram from 2G to 3G but I am trying to growing it from 3G to 4G ..and I meted some problem.

Option 1 : disable TEE
    It is not possible because we need TEE

Option 2 :
    Patch 2.1 : optee-os-imx => build OK

           In core/arch/arm/plat-imx/conf.mk

               I replace CFG_DDR_SIZE ?= 0xC0000000 by CFG_DDR_SIZE ?= 0x100000000
           In core/arch/arm/plat-imx/tzasc.c

                I do nothing ....trust zone memory region was already configured for 4G
    Patch 2.2 : imx-atf => build OK

            In plat/imx/imx8mm/include/platform_def.h

                 I replaced #define BL32_BASE 0xfe000000 by #define BL32_BASE 0x13e000000
                 For 3G 0xfe000000 = PHYS_SDRAM + PHYS_SDRAM_SIZE - 0x10000000
                 So for 4G 0x13e000000 = PHYS_SDRAM_2 + PHYS_SDRAM_2_SIZE - 0x10000000
           In same plat/imx/imx8mq/imx8mq_bl31_setup.c

                 Same idea..
                 bl33_image_ep_info.args.arg1 = 0xFE000000; become bl33_image_ep_info.args.arg1 = 0x13E000000
                 bl33_image_ep_info.args.arg2 = 0x100000000 become bl33_image_ep_info.args.arg2 = 0x140000000
    Patch 2.3 imx-boot => BUILD KO

           In iMX8M/soc.mak TEE_LOAD_ADDR = 0xfe000000 become TEE_LOAD_ADDR = 0x13e000000
           But i have build error : 
               | ./mkimage_uboot -E -p 0x3000 -f u-boot.its u-boot.itb
               | Error: u-boot.its:36.12-23 Value out of range for 32-bit array element
               | Error: u-boot.its:37.13-24 Value out of range for 32-bit array element

Have you an idea?
Attached the 3 patched adapted ....

Thanks for your time.

[benson_lin]

Dear Sir

Did you solve it?

I modified TEE_LOAD_ADDR to 0x13e000000 (imx-boot) and encountered the same error ( Error: u-boot.its:36.12-23 Value out of range for 32-bit array element ).

Would you please give me some suggestions about these errors?

My error is as follows:

tmp/work/imx8mmevk-poky-linux/imx-boot/1.0-r0/teump/run.do_compile.18220' failed with exit code 2:
24058+0 records in
24058+0 records out
96232 bytes (96 kB, 94 KiB) copied, 0.0375925 s, 2.6 MB/s
./../scripts/pad_image.sh tee.bin
tee.bin is padded to 2113120
./../scripts/pad_image.sh bl31.bin
bl31.bin is padded to 45536
./../scripts/pad_image.sh u-boot-nodtb.bin evk.dtb
DEK_BLOB_LOAD_ADDR=0x40400000 TEE_LOAD_ADDR=0x13e000000 ATF_LOAD_ADDR=0x00920000 ./mkimage_fit_atf.sh evk.dtb > u-boot.its
bl31.bin size:
45536
Building with TEE support, make sure your bl31 is compiled with spd. If you do not want tee, please delete tee.bin
tee.bin size:
2113120
u-boot-nodtb.bin size:
788968
evk.dtb size:
35640
./mkimage_uboot -E -p 0x3000 -f u-boot.its u-boot.itb
Error: u-boot.its:36.12-23 Value out of range for 32-bit array element
Error: u-boot.its:37.13-24 Value out of range for 32-bit array element
FATAL ERROR: Syntax error parsing input tree
./mkimage_uboot: Can't open u-boot.itb.tmp: No such file or directory
soc.mak:148: recipe for target 'u-boot.itb' failed
make[1]: *** [u-boot.itb] Error 255
Makefile:22: recipe for target 'flash_evk' failed
make: *** [flash_evk] Error 2
WARNING: exit code 2 from a shell command.

[cedric_thamin]

HI

No I didn't solved it.

Actually I can support TEE and 3Gram
Or no tee and 4GRam.

Sorry.

Next step ..I don't know when perhaps never, will be to update kernel/uboot to last version of sdk.

Best Reagrds,
Cedric T

[benson_lin]

Dear Cedric T

My test results are the same. ( Tee + 3GB ram ok, no tee + 4GB ram ok )

Thank you very much for your information.

Best Reagrds,

Benson

[cedric_thamin]

Many thanks!!!!

I will try it this patch next week ... other priorities have caught up with me.
I keep you informed as soon as possible :smileyhappy: