• Resolved

AM5726: 4GB DDR3 not recognized in Linux

Mastermind 21620 points

Replies: 6

Views: 112

Part Number: AM5726

Team,

Can you please help?

Linux only sees 2Gbytes of DDR3 instead of a total of 4Gbytes.
What are the extra step to do to have Linux see/use the full 4GBytes memory space?
How can we narrow down where the issue is?

 The setup is as below:

 EMIF1 + EMIF2 = 4GBytes as follow:
                On EMIF1: 2x (512Mx16) = 2GB DDR3 chips as per Fig 8-2 page 378 of the datasheet SPRS953F          
                On EMIF2: 2x (512Mx16) = 2GB DDR3 chips as per Fig 8-2 page 378 of the datasheet SPRS953F

The EMIF parameters were obtained using the EMIF_RegisterConfiguration.xlsm from SPRAC36:
               www.ti.com/.../SITARA-DDR-CONFIG-TOOL

The board can boot Linux and both EMIFs are running in interleaved mode.

The LISA_MAP configuration we are applying is the following:
static const struct dmm_lisa_map_regs ingeteam_bd_lisa_regs = {

   .dmm_lisa_map_2 = 0x80740300,

   .dmm_lisa_map_3 = 0xFF020100,

   .is_ma_present = 0x1

}

 The kernel was built with he CONFIG_ARM_LPAE feature enabled. If we executed the following command (as suggested in https://e2e.ti.com/support/processors/f/791/p/803805/3005117?tisearch=e2e-sitesearch&keymatch=DRA742&pi320966=2 ):

                root@board:~# zcat /proc/config.gz | grep -i LPAE
                CONFIG_ARM_LPAE=y
                # CONFIG_IOMMU_IO_PGTABLE_LPAE is not set
It shows that the LPAE extension is enabled

But our system only sees 2GB:
                root@board:~# cat /proc/meminfo
                MemTotal:       1849496 kB
                MemFree:         1793184 kB
                MemAvailable:   1805892 kB

  • We have 4GB support for the DRA75x EVM.  I think there are a couple of u-boot changes needed in the AM57xx files to get this working:

    diff --git a/./include/configs/am57xx_evm.h b/./include/configs/dra7xx_evm.h
    index cf5cacd2f6..c9f8b12118 100644
    --- a/./include/configs/am57xx_evm.h
    +++ b/./include/configs/dra7xx_evm.h

    +#define CONFIG_VERY_BIG_RAM

    #define CONFIG_NR_DRAM_BANKS 2
    +#define CONFIG_MAX_MEM_MAPPED 0x80000000

    Correspondingly in the board/ti/am57xx/board.c file you need to add this function:

    int dram_init_banksize(void)
    {
    u64 ram_size;

    ram_size = board_ti_get_emif_size();

    gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
    gd->bd->bi_dram[0].size = get_effective_memsize();
    if (ram_size > CONFIG_MAX_MEM_MAPPED) {
    gd->bd->bi_dram[1].start = 0x200000000;
    gd->bd->bi_dram[1].size = ram_size - CONFIG_MAX_MEM_MAPPED;
    }

    return 0;
    }

    Best regards,
    Brad

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    Hi Brad,

    Thanks for the answer!

    The change you suggested was made.
    Since in this case there is no EEPROM the ram_size  value is hard-coded in the fct.
    However with this change U-boot hangs while inirtializing the DDR3.
    Could you confirm what ram_size value should be?

    int dram_init_banksize(void)
    {
        u64 ram_size;

        ram_size = 0x100000000; // NO EEPROM, value for 4GBytes

        gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
        gd->bd->bi_dram[0].size = 0x80000000;
        if (ram_size > CONFIG_MAX_MEM_MAPPED) {
            gd->bd->bi_dram[1].start = 0x200000000;
            gd->bd->bi_dram[1].size = ram_size - CONFIG_MAX_MEM_MAPPED;
        }

        return 0;
    }

  • In reply to AnBer:

    AnBer
    Could you confirm what ram_size value should be?

    Looks correct to me.  It should be 4GB, i.e. ram_size = 0x100000000.

    AnBer
    However with this change U-boot hangs while inirtializing the DDR3.

    Can you step through the code in JTAG to see where it hangs?  Or alternatively add some print statements to narrow it down?

    It would also be good if you could connect to the A15 with JTAG and open a memory window to the 2_0000_0000 address range to see if you're able to read/write memory correctly.  We need to know first and foremost whether the full 4GB of memory is being correctly configured at the register level.  Once that's working we should be able to find any remaining details in the software.

    AnBer
            gd->bd->bi_dram[1].start = 0x200000000;

    FYI, this start address has a dependency on bit 8 (HIMEM_INTERLEAVE_UN) of the MA_PRIORITY register at address 0x482A 2000.  I expect u-boot will have already set that bit (i.e. interleaving in that 2GB region).  However, please confirm that MA_PRIORITY[8]==1.

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    Brad thanks.
    some more comments:

    By trying to reduce to reduce the scope of the problem:
    if we use either EMIF1 or EMIF2 for supporting 2 GB of memory it works fine.
    So, if we configure the LISA to:

    static const struct dmm_lisa_map_regs board_lisa_regs = {
        .dmm_lisa_map_2 = 0x80740100,
        .is_ma_present  = 0x1
    };

    Or to:
    static const struct dmm_lisa_map_regs board_lisa_regs = {
        .dmm_lisa_map_2 = 0x80740200,
        .is_ma_present  = 0x1
    };

    The memory shows us 2GB and we can start Linux correctly.

        If we configure LISA for supporting 4GB:

    static const struct dmm_lisa_map_regs board_lisa_regs = {
        .dmm_lisa_map_2 = 0x80740300,
        .dmm_lisa_map_3 = 0xFF020100,
        .is_ma_present  = 0x1
    };

    And if we fix the second EMIF to only 1GB (although we have 2GB installed):

    void dram_init_banksize(void)
    {
        u64 ram_size;

        ram_size = 0x100000000;

        gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE; // CONFIG_SYS_SDRAM_BASE is 0x80000000
        gd->bd->bi_dram[0].size = 0x80000000;
        if (ram_size > CONFIG_MAX_MEM_MAPPED) {
            gd->bd->bi_dram[1].start = 0x200000000;
            gd->bd->bi_dram[1].size = ram_size - CONFIG_MAX_MEM_MAPPED;
            gd->bd->bi_dram[1].size = 0x40000000;
        }

        return;
    }

    The uBoot starts and it returns the following info:

    => bdinfo
    arch_number = 0x00000000
    boot_params = 0x80000100
    DRAM bank   = 0x00000000
    -> start    = 0x80000000
    -> size     = 0x80000000
    DRAM bank   = 0x00000001
    -> start    = 0x00000000
    -> size     = 0x40000000
    eth0name    = cpsw
    ethaddr     = 38:81:d7:75:97:7c
    current eth = cpsw
    ip_addr     = <NULL>
    baudrate    = 115200 bps
    TLB addr    = 0xFEFF0000
    relocaddr   = 0xFEF46000
    reloc off   = 0x7E746000
    irq_sp      = 0xFCF0F6C0
    sp start    = 0xFCF0F6B0
    Early malloc usage: df0 / 2000

    => md.l 0x482A2000 0x1
    482a2000: 00000104                               ....

        Showing that the MA_PRIORITY[8]==1

    If we move up from 1 GB in the second EMIF (same code but with gd->bd->bi_dram[1].size value greater than 0x40000000)  the board never starts up and hangs before showing any trace.

    -Any reasons why it can not be used simultaneously?
    -Do you think that it could be related with some HW issue?
    -We have thought that if we can use EMIF1 or EMIF2 with 2GB independently the HW should be OK. Is it true?

    Thanks.

  • In reply to AnBer:

    It looks like a 32-bit address is used to define the underlying type for the "start" and "size" fields.  To make that a 64-bit variable, add the following to your defconfig:

    CONFIG_PHYS_64BIT=y

    It was hard to see that was being done for the DRA7xx boards since it is a bit hidden in arch/arm/mach-omap2/omap5/Kconfig.

    Best regards,
    Brad

    ---------------------------------------------------------------------------------------------------------
    http://processors.wiki.ti.com/index.php/User:BradGriffis
    --------------------------------------------------------------------------------------------------------- 

  • In reply to Brad Griffis:

    Hi Brad,

    Thanks for your great help!
    I got the feedback back that it did the trick!

    Hopefully it will be added in the next SDK release.

    A.