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.

Linux/AM5728: 4GB DDR test from U-boot

Part Number: AM5728

Tool/software: Linux

I'd like to incorporate a memory test command in to U-Boot to support some testing of our system, which uses an AM5728 processor and 4 GB of DDR RAM. U-Boot has been built to recognize the entire memory range and the bdinfo command prints the following:

=> bdinfo
arch_number = 0x00000000
boot_params = 0x80000100
DRAM bank = 0x00000000
-> start = 0x80000000
-> size = 0x7F000000
DRAM bank = 0x00000001
-> start = 0x00000000
-> size = 0x80000000
baudrate = 115200 bps
TLB addr = 0xFEFF0000
relocaddr = 0xFEF4A000
reloc off = 0x7E74A000
irq_sp = 0xFDF25640
sp start = 0xFDF25630

I've been able to successfully use the built-in mtest command as well as my own custom U-Boot command to test memory starting at 0x8000 0000 (up to a point about 1MB below sp start, to account for stack growth). This address range only covers about 2GB, or half my memory. The bdinfo dump implies that the other bank starts at location zero but trying to access this with the mtest command causes a crash.

How can I access the other half to test from U-Boot? Either from the U-Boot command prompt's built in commands or through code in my own custom command?

  • The software team have been notified. They will respond here.
  • Hi Scott,

    The upper 2GB are accessible only by Cortex-A15 MPU via LPAE. Check if you have enabled PLAE in u-boot, in this case you can access upper 2GB from u-boot with mem tests described below:

    u-boot/doc/README.memory-test

    u-boot/common/memsize.c

    Note that LPAE is enabled by default in linux kernel only.

    See also the below e2e threads:

    e2e.ti.com/.../588135
    e2e.ti.com/.../586776

    Regards,
    Pavel
  • Pavel,

    Thanks for the reply, but unfortunately the information in the files and links you referenced doesn't help answer my question.

    I've verified that my U-Boot build has LPAE enabled by ensuring that CONFIG_ARMV7_LPAE is set to "y" (as referenced in e2e.ti.com/.../588135). Your post there implies that this is all that is needed, but the information I'm really interested in is how to take advantage of the extended address space once it is enabled.

    I also have a board.c file that initializes the entire 4GiB of RAM (as referenced in e2e.ti.com/.../586776)

    The contents u-boot/common/memsize.c appear to use 32-bit addressing which wouldn't let me access the whole range of available memory (as part of the memory space is, I assume, still mapped to peripheral registers).

    The contents of README.memory-test only seem to cover basic memory testing and don't address anything LPAE related.

    The following thread seems to be on the same topic I'm interested in, but it was never resolved.
    e2e.ti.com/.../567360

    To restate my question slightly:
    Assuming that LPAE is enabled in the U-Boot build, can you provide example code that shows how to access memory beyond 2GiB?
  • Scott Jackson7 said:
    To restate my question slightly:
    Assuming that LPAE is enabled in the U-Boot build, can you provide example code that shows how to access memory beyond 2GiB?

    I can not find an example. I will check with the u-boot team if they have something, but there will be delay due to Xmas holiday. The start address of the second 2GiB half should be 0x02_0000_0000

    Meanwhile you can check if the below link will be in help:

    Regards,
    Pavel

  • Make sure you enabled LPAE in your configs/am57xx_evm_defconfig file. I looked in the latest SDK and it is enabled by default

    CONFIG_ARMV7_LPAE=y

    I also noticed that in include/configs/am57xx_evm.h, only this is set

    #define CONFIG_NR_DRAM_BANKS            2

    In the include/configs/dra7xx_evm.h there are two other CONFIGs set in addition to this one.

    #define CONFIG_VERY_BIG_RAM
    #define CONFIG_NR_DRAM_BANKS            2
    #define CONFIG_MAX_MEM_MAPPED           0x80000000

    Can you modify your am57xx_evm.h to include these two others?

    We boot to Linux and use memtester to test memory. Can you do that instead of in u-boot?

    Steve K.

  • Steve,

    I double-checked my includes and made sure that I have the same #define statements you outlined above. The problem now is that I don't know how to actually address the entire 4GB of memory since I only have 32-bits of addressing to work with. I imagine that I'll need to temporarily adjust the MMU configuration but I don't know if there are existing API calls to help do that or some sort of abstraction layer within U-Boot to help manage "VERY_BIG_RAM."

    There are basically two main reasons I am avoiding using memtester within Linux:

    1. Linux allocates a big chunk of memory for itself (about 1GB in the current configuration I have) so I can only test about 75% of available memory.
      1. While U-Boot also reserves some DDR for itself, its footprint is much smaller and thus I can test almost all the available memory for issues
    2. The impression I have is that the addresses I get in a Linux user space are virtualized away from the actual physical address so I can't necessarily know which physical address lines I'm exercising.
      1. This is important because I'd like to, at a minimum, try to verify that all my address and data lines are OK with an algorithm like this: On-the-fly RAM tests
  • The patch set you referenced in your previous post has already been applied to the u-boot code. I'm still looking into this.

    Steve K.