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.

AM620-Q1: Accessing 4G of RAM

Part Number: AM620-Q1
Other Parts Discussed in Thread: SK-AM62B

Tool/software:

We have a custom board design using 2 (MT40A2G8AG-062E AUT:F) for 4GBytes SDRAM.  Can I access the full address range using the u-boot utilities (mm & md)?  If so, could you provide examples for each 2GByte chip? 

  • I think in U-Boot you are limited to the first 4GB (32-bit) of address space, which means 2GB of DDR (since DDR starts at 0x8000_0000). But let me double-check, we have some 4GB boards here.

    Regards, Andreas

  • Andreas,

    OK!  Thanks!  

    Right now it looks like I'm looking at the same memory location when I use 0x880000000 or 0x80000000 for the address with md.

  • I looked into this briefly, looks like 64-bit support for memory commands should be automatic.

    Fullscreen
    1
    2
    3
    4
    5
    README-Configuration Settings:
    README------------------------
    README-
    README:- MEM_SUPPORT_64BIT_DATA: Defined automatically if compiled as 64-bit.
    README- Optionally it can be defined to support 64-bit memory commands.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    ...some related code-snippet here...

    Fullscreen
    1
    2
    3
    4
    5
    include/compiler.h-#ifdef __LP64__
    include/compiler.h:#define MEM_SUPPORT_64BIT_DATA 1
    include/compiler.h-#else
    include/compiler.h:#define MEM_SUPPORT_64BIT_DATA 0
    include/compiler.h-#endif
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I've not gotten a chance yet to try it.

    Regards, Andreas

  • Andreas,

    Let me know what you find!

    I'm using one of the pre-built images.  I'll look for that define!

      

  • Jim,

    I just tried this on SK-AM62A, which has 4GB of DDR, using last-year's SDK v9.x U-Boot image. There was no issue accessing memory above the first 2GB.

    First, you can confirm the memory map with U-Boots `bdinfo` command. You can see that the first 2GB are mapped to address 0x8000_0000, and the second 2GB to address 0x8_8000_0000 as expected for all AM6x devices (see TRM).

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    => bdinfo
    boot_params = 0x0000000000000000
    DRAM bank = 0x0000000000000000
    -> start = 0x0000000080000000
    -> size = 0x0000000080000000
    DRAM bank = 0x0000000000000001
    -> start = 0x0000000880000000
    -> size = 0x0000000080000000
    flashstart = 0x0000000000000000
    flashsize = 0x0000000000000000
    flashoffset = 0x0000000000000000
    baudrate = 115200 bps
    relocaddr = 0x00000000ffedd000
    reloc off = 0x000000007f6dd000
    Build = 64-bit
    current eth = ethernet@8000000port@1
    ethaddr = 1c:63:49:17:21:cc
    IP addr = <NULL>
    fdt_blob = 0x00000000fde90dd0
    new_fdt = 0x00000000fde90dd0
    fdt_size = 0x000000000000bfe0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Now, let's write a sequence of words (1, 2, 3, 4) to address 0x8000_0000 and a second sequence of words (5, 6, 7, 8) to address 0x8_8000_0000 while in-between checking both memory areas, to make sure one doesn't affect another and they are truly independent.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    => md 0x80000000 10
    80000000: 01000000 02000000 40000000 00000100 ...........@....
    80000010: 80000400 20000000 00000200 00000000 ....... ........
    80000020: 00000000 40002000 00008100 a0000000 ..... .@........
    80000030: 00008000 00000400 02000000 00000000 ................
    => md 0x880000000 10
    880000000: 42400000 10100000 00000200 00000200 ..@B............
    880000010: 08000000 01000000 00000000 0a000000 ................
    880000020: 00080200 00020200 01000000 22000000 ..............."
    880000030: 00000001 10000000 06000000 02000010 ................
    => mm 0x80000000
    80000000: 01000000 ? 1
    80000004: 02000000 ? 2
    80000008: 40000000 ? 3
    8000000c: 00000100 ? 4
    80000010: 80000400 ? q
    => md 0x80000000 10
    80000000: 00000001 00000002 00000003 00000004 ................
    80000010: 80000400 20000000 00000200 00000000 ....... ........
    80000020: 00000000 40002000 00008100 a0000000 ..... .@........
    80000030: 00008000 00000400 02000000 00000000 ................
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Everything working exactly as expected.

    And this doesn't apply just to the memory command, but also to other commands. I've successfully transferred a large image over TFTP to address 0x8_8000_0000 in the past without issues.

    Regards, Andreas

  • Andreas,

    I don't see the second 2GB of DDR...

    Is there a configuration setting missing?

    Here's what I have in k3-am625-sk.dts -

    I found another thread that had some information on it but it doesn't seem to be the solution -

    AM625: How to set up AM625 4GB RAM on SDK 9.2? - Processors forum - Processors - TI E2E support forums

    I'm using 09.02.01.10.

  • SK-AM62B (with an AM62x device on it) which is what uses the k3-am625-sk.dts file you looked at only comes with 2GB of DDR, so this is expected,

    What I was testing this was a SK-AM62A (with an AM62Ax device on it), which has 4GB of DDR. Different device tree file, see...

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    $ git grep -A 5 'memory@8' arch/arm/dts/k3-am62a7-sk.dts
    arch/arm/dts/k3-am62a7-sk.dts: memory@80000000 {
    arch/arm/dts/k3-am62a7-sk.dts- device_type = "memory";
    arch/arm/dts/k3-am62a7-sk.dts- /* 4G RAM */
    arch/arm/dts/k3-am62a7-sk.dts- reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
    arch/arm/dts/k3-am62a7-sk.dts- <0x00000008 0x80000000 0x00000000 0x80000000>;
    arch/arm/dts/k3-am62a7-sk.dts- };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards, Andreas

  • Andreas,

    OK!  I tried to follow the above thread but there seems to be an issue with the Am62x driver.  Without updating to a newer version, how can we proceed.  It seems that a patch in the code is necessary. (k3-ddrss.c, etc.)

  • Without updating to a newer version, how can we proceed.  It seems that a patch in the code is necessary. (k3-ddrss.c, etc.)

    You should try moving to the latest U-Boot, at least for testing purposes. It should not be that difficult. If you have any specific challenge, pls let us know.

    Regards, Andreas

  • Andreas,

    OK!  They'll be moving me off this project by week's end.  I'll see how far I get!  For the most part, I was brought in to get USB, SPI, EMMC and Ethernet going in one of the TI Linux environments.  That has been successful.  I let them know about the upper 2 GB of memory issue.
    Thanks for your help thus far!  I'll see if I can get this last issue resolved within the time I have left!  I'll follow up within the next couple of days.

  • For the most part, I was brought in to get USB, SPI, EMMC and Ethernet going in one of the TI Linux environments.  That has been successful. 

    Glad to hear!

    I let them know about the upper 2 GB of memory issue.

    Yes trying SDK v10.0 should be the starting point there; which is also what should be used for further development (not SDK v9.x). If you must use v9.x you can always try to identify and backport specific fixes to get DDR working with 4GB on AM62x. But you'd still be missing out on many of the other fixes/improvements that U-Boot from SDK v10.0 has vs. SDK v9.x.

    Regards, Andreas

  • Andreas,

    I updated to Version 10 of the SDK to try the u-boot tool that modifies and displays memory.  With the configuration changes you mentioned above, I'm still only able to access 0x80000000 - 0x100000000,

    Here's the log:

    6523.U-Boot SPL 2024.04-dirty (Oct 25 20.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2024.04-dirty (Oct 25 2024 - 14:14:30 -0400)
    SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
    SPL initial stack usage: 13392 bytes
    Trying to boot from MMC2
    Authentication passed
    Authentication passed
    Authentication passed
    Authentication passed
    Authentication passed
    Starting ATF on ARM64 core...
    NOTICE: BL31: v2.10.0(release):v2.10.0-367-g00f1ec6b87-dirty
    NOTICE: BL31: Built : 16:09:05, Feb 9 2024
    U-Boot SPL 2024.04-dirty (Oct 25 2024 - 14:14:47 -0400)
    SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
    SPL initial stack usage: 1856 bytes
    Trying to boot from MMC2
    Authentication passed
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I'm not completely finished configuring V10 (the ethernet is not working).  ...But most everything else appears to be working.

  • I updated to Version 10 of the SDK to try the u-boot tool that modifies and displays memory.  With the configuration changes you mentioned above, I'm still only able to access 0x80000000 - 0x100000000,

    Thanks for trying this. I'm checking with the team what could be going wrong here. AFAIK the >2GG support should work with SDK v10.x+.

    Regards, Andreas

  • Andreas,

    I cleaned up my DT changes and it works now:

    Thanks!

  • Hi Jim,

    A colleague just mentioned to me you were also discussing this on a separate thread (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1430847/am620-q1-4gb-ddr---unable-to-access-upper-2gb) and that it is resolved.

    Looks like the solution was to use the very DTS configuration I pointed out in this thread here earlier. Not sure what the confusion/disconnect was that this wasn't tried in the context of SDK v10, but I'm glad it's confirmed working now.

    Regards, Andreas