• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 376 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5726: Dynamic RAM size allocation in U-boot

Gert van der Merwe81
Prodigy 60 points
Part Number: AM5726

Good Day all

II have seen a post before regarding this question but for the life of me I can't seem to get it again through the search engine.

I am currently using a custom board where we can control the hardware build to add 2G or 4G or Ram at production.

My question

For U-Boot and Kernel release. can one set to detect Populated RAM size and then adjust U-Boot and Kernel parameters for the allocated RAM on board?.

U-Boot : 2018-01

SDK: 5.02.00.10

Regards

  • 0
    TI__Guru 69582 points

    Hi Gert,

    Gert van der Merwe81 said:
    For U-Boot and Kernel release. can one set to detect Populated RAM size and then adjust U-Boot and Kernel parameters for the allocated RAM on board?

    Sounds like you want to auto-detect RAM size?

    There might be a way to get this to work on AM57xx by leveraging the size auto-detect function in U-Boot by doing the following modifications:

    • The central function in U-Boot leveraged to determine the DDR size on those devices is arch/arm/mach-omap2/hwinit-common.c:omap_sdram_size()
    • Update this function to call get_ram_size((void *)CONFIG_SYS_SDRAM_BASE, CONFIG_MAX_RAM_BANK_SIZE) rather than reading and determining the DDR size based on EMIF settings
    • The Kernel should automatically see these changes due to the fact that U-Boot updates the Kernel's device tree memory description on the fly

    The potential issue I see with this is that the device may not "like" the fact that you try accessing non-existing memory locations during the probe process, which may manifest itself in exceptions even later in the boot flow (during Kernel startup). There may also be similar limitations with this approach specifically as it relates to HS (high secure) device variants (think firewalls).

    Do you have any other way to distinguish different HW versions of your board? For example a GPIO pin you could probe during device startup? I think this would make for a cleaner solution.

    Regards, Andreas