Skip to main content
Visitor II
January 5, 2022
Solved

Issue in accessing RAM address in STM32MP1 series board

  • January 5, 2022
  • 1 reply
  • 1784 views

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

    This topic has been closed for replies.
    Best answer by Olivier GALLIEN

    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

    • the 2 device tree (U-Boot and Linux) are not aligned on memory reserved location

    or

    • the U-Boot relocation address is not correctly managed in

    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

    1 reply

    Technical Moderator
    January 5, 2022

    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

    • the 2 device tree (U-Boot and Linux) are not aligned on memory reserved location

    or

    • the U-Boot relocation address is not correctly managed in

    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