2022-01-05 06:14 AM
Hi STM-Team,
I am working with STM32MP1 evolution board. It has 512MB of RAM memory.
I want to load some custom data (1024 byes) in the last some offset of RAM memory (~500MB offset address). So, I am trying to use below command from u-boot prompt. But, getting error like accessing reserved memory.
RAM Base address is 0xC000 0000 + 0x1F40 0000 (500MB offset) = 0xDF40 0000
Case-1: STM32MP1>ext4load mmc 0:5 0xDF400000 file.bin
Entering do_load
argc:5
argv[0]:load
argv[1]:mmc
argv[2]:0:5
argv[3]:0xDF400000
argv[4]:file.bin
** Reading file would overwrite reserved memory **
File read ret:-28
But, I am able to access the address offset ~381MB (0xD7DEF0DC).
Case-2: STM32MP1> ext4load mmc 0:5 0xD7DEF0DC file.bin
Entering do_load
argc:5
argv[0]:load
argv[1]:mmc
argv[2]:0:5
argv[3]:0xD7DEF0DC
argv[4]:mtd3
File read ret:0
1024 bytes read in 339 ms (2.9 KiB/s)
Can anyone help me out to understand what is going wrong while accessing the RAM memory addresses around 500MB offset?
Attaching the full logs file for reference.
Thank You,
Pratik Manvar
Solved! Go to Solution.
2022-01-05 06:56 AM
Hi @Pratik Manvar ,
I guess this is due to Uboot relocation at end of DDR.
Copy here useful comment from https://community.st.com/s/question/0D53W00001DMfdlSAD/what-parts-of-the-ddr-can-i-reserve-using-device-tree-without-upsetting-uboot
"
At boot, the U-Boot binary is loaded at the beginning of the memory,
than it find the DDR memory size (=> board_get_usable_ram_top() )
and relocate the U-Boot binary at the END of the DDR
U-Boot let a the start of memory (up to U-Boot relocation address - alloc size - other U-Boot reseved memeory)
https://wiki.st.com/stm32mpu/wiki/U-Boot_overview#U-Boot_execution_sequence
I have information with the U-Boot command: "bdinfo", the relocation address for exmaple.
In the last U-Boot version (in OpenSTLinux v3.1) , the arch/arm/mach-stm32mp/dram_init.c::board_get_usable_ram_top()
avoids the reserved memory with lmb livrary, present in U-Boot device tree
=> The reserved memory need ot be present in U-Boot device tree
then when the U-Boot load the kernel image and the kernel device tree
the bootm command parse the LINUX device tree to chack possible conflict
with U-boot relocation added and memory address
to avoid conflict (it is linked to EFI support, activated by default)
=> The reserved memory need to be present also in LINUX device tree
accroding the decription, I assume
or
arch/arm/mach-stm32mp/dram_init.c::board_get_usable_ram_top()
=> you can experiment by traces in this function or hack it with :
ulong board_get_usable_ram_top(ulong total_size)
{
return 0xDFFF0000;
}
"
Hope it help
Olivier
2022-01-05 06:56 AM
Hi @Pratik Manvar ,
I guess this is due to Uboot relocation at end of DDR.
Copy here useful comment from https://community.st.com/s/question/0D53W00001DMfdlSAD/what-parts-of-the-ddr-can-i-reserve-using-device-tree-without-upsetting-uboot
"
At boot, the U-Boot binary is loaded at the beginning of the memory,
than it find the DDR memory size (=> board_get_usable_ram_top() )
and relocate the U-Boot binary at the END of the DDR
U-Boot let a the start of memory (up to U-Boot relocation address - alloc size - other U-Boot reseved memeory)
https://wiki.st.com/stm32mpu/wiki/U-Boot_overview#U-Boot_execution_sequence
I have information with the U-Boot command: "bdinfo", the relocation address for exmaple.
In the last U-Boot version (in OpenSTLinux v3.1) , the arch/arm/mach-stm32mp/dram_init.c::board_get_usable_ram_top()
avoids the reserved memory with lmb livrary, present in U-Boot device tree
=> The reserved memory need ot be present in U-Boot device tree
then when the U-Boot load the kernel image and the kernel device tree
the bootm command parse the LINUX device tree to chack possible conflict
with U-boot relocation added and memory address
to avoid conflict (it is linked to EFI support, activated by default)
=> The reserved memory need to be present also in LINUX device tree
accroding the decription, I assume
or
arch/arm/mach-stm32mp/dram_init.c::board_get_usable_ram_top()
=> you can experiment by traces in this function or hack it with :
ulong board_get_usable_ram_top(ulong total_size)
{
return 0xDFFF0000;
}
"
Hope it help
Olivier