• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 819 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.

Original question:

66AK2H14: Led GPIO use in U-boot

66AK2H14: U-boot on custom board

L.Kiet
Intellectual 520 points
Part Number: 66AK2H14

Hi,

I am currently working on a custom board using the 66AK2H14 processor. I currently flash my u-boot on the NOR flash of the board. I managed to see U-boot starting using UART.

However, It always stop get stuck at this point on my console:

Cannot read DIMM params                                                                                                
Sorry, I don't know how to configure DDR3A.                                                                            
Bye :( 

I saw that it comes from ddr3_read_spd function in arch/arm/mach-keystone/ddr3_spd.c. The code that can be found inside is the following:

    i2c_init(CONFIG_SYS_DAVINCI_I2C_SPEED, CONFIG_SYS_DAVINCI_I2C_SLAVE);    
    old_bus = i2c_get_bus_num();
    i2c_set_bus_num(1);

    ret = i2c_read(0x53, 0, 1, (unsigned char *)spd_params, 256);

    i2c_set_bus_num(old_bus);

    if (ret) {
        printf("Cannot read DIMM params\n");
        return 1;
    }

I can see that i2c_read function of course returns 1. Why the I can't read the params by I2C?

Do you have any advice or idea about this?

I did the change in board/ti/ks2_evm/ddr3_cfg.c to follow the DDR3 used on our board with our custom ddr configuration. The configuration of ddr3a phy and ddr3a emif was tested by emulation with a custom gel file including our changes. It was tested by emulation on DSP and the accesses to DDR3A were validated with success. 


Thank you for your help.

Best Regards.


K.Luong

  • 0
    TI__Guru** 116170 points

    L Kiet,

    Please refer to Rex`s response on the E2E thread posted here.

    https://e2e.ti.com/support/processors/f/791/p/618247/2999168#2999168

    He has provided detailed guidance with link to app notes that provides EMIF/DDR configuration tool for the device and also highlighted functions in uboot to update to port uboot to custom platform. Please review that response and let is know if you have any further questions.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 520 points

    Hi,

    Thank you for your answer Rahul.

    As mentionned by Rex, the boot/board/ti/ks2_evm/ddr3_cfg.c file must be modified. I already did it as mentionned in my first post. I used the value of my GEL file  (working with DSP emulator), that we already set before to access DDR3 on our custom board.


    However, the problem here is that I get stopped when I try to read the ddr3 spead.

    Do you have any idea to solve this or any idea about what I am currently missing?


    Thank you!


    Best Regards.


    K.Luong

  • 0 in reply to L.Kiet
    TI__Guru 50170 points

    Hi, 

    Could you modified ddr3 code not to read SPD info and hard code the speed and memory size of your DDR3 to get around it? At least it can verify the configuration and continue. I am not sure if it is caused by the DDR3 not having SPD info programmed or something else.

    Rex  

  • 0 in reply to Rex Chang
    Intellectual 520 points

    Hi Rex,


    I tried to hard code the size. However, I get stuck later and I need to debug u-boot function by function.

    It looks like any function is working directly after without debuging it or bypassing it.

    Moreover the function that read SPD info will fill out the structure ddr3_spd_eeprom_s that contains many parameter. Is it really possible to bypass it and hard code the size without impact.


    Thank you for your help.


    Best Regards,

    K.Luong

  • 0 in reply to L.Kiet
    TI__Guru 50170 points

    Hi, K.Luong,

    SPD info is only referred in ddr3_k2hk.c to initialize the DDR3. The dimm_name is not relevant and doesn't really need to be printed. It doesn't matter what the spdclock is in SPD, you know what the DDR3 speed you will set to. The init_pll() can be called directly with the speed ddr3a_400 or ddr3a_333 passed in. DDR PHY and EMIF can be configured with your values which you mentioned that they have been tested working instead of using phy_cfg and emif_cfg in the spd_cb structure. I don't think there is anything else that u-boot needs for DDR3 initialization. 

    Keystone-2 DDR3 were configured without using SPD info. To accommodate different requirements and configurations of DDR3, it changed to use SPD info to be flexible.

    By the way, I saw in your original post that you modified ddr3_cfg.c. That file is not used by K2HK. Please check Makefile to see what files get pulled in by K2HK build.

    Rex

  • 0 in reply to L.Kiet
    Intellectual 520 points

    I used debug mode to get more information.

    We can see on the console:

    U-Boot 2018.01-00228-gc02be9e811-dirty (Sep 25 2019 - 14:52:43 +0200)           
                                                                                    
    initcall: 0c00e6e5                                                              
    U-Boot code: 0C000000 -> 0C080840  BSS: -> 0C0E437C                             
    initcall: 0c0010ed                                                              
    CPU: 66AK2Hx SRinitcall: 0c00ead5                                               
    Model: Texas Instruments Keystone 2 Kepler/Hawking EVM                          
    initcall: 0c00e7c1                                                              
    DRAM:  initcall: 0c002559                                                       
    dram_init: entrance in dram_init()                                              
    old i2c bus used is : 0                                                         
    uclass_find_device_by_seq: 0 1                                                  
       - 1 -1 'i2c@2530400'                                                         
       - not found                                                                  
    uclass_find_device_by_seq: 1 1                                                  
       - 1 -1 'i2c@2530400'                                                         
       - found                                                                      
    malloc_simple: size=c, ptr=208, limit=400: c1ffd3c                              
    malloc_simple: size=4, ptr=20c, limit=400: c1ffd48                              
    uclass_find_device_by_seq: 0 -1                                                 
    uclass_find_device_by_seq: 0 0                                                  
       - -1 -1 'soc'                                                                
       - not found                                                                  
    uclass_find_device_by_seq: 0 1                                                  
       - 1 -1 'i2c@2530400'                                                         
       - not found                                                                  
    OF: ** translation for device i2c@2530400 **                                    
    OF: bus is default (na=1, ns=1) on soc                                          
    OF: translating address: 00045302                                               
    OF: parent bus is default (na=1, ns=1) on                                       
    OF: no ranges, 1:1 translation                                                  
    OF: parent translation for: 00000000                                            
    OF: with offset: 38994944                                                       
    OF: one level translation: 00045302                                             
    OF: reached root node                                                           
    ofnode_read_u32: clock-frequency: 0x186a0 (100000)                              
    i2c_get_chip: Searching bus 'i2c@2530400' for address 53: not found             
    malloc_simple: size=b, ptr=217, limit=400: c1ffd4c                              
    malloc_simple: size=18, ptr=230, limit=400: c1ffd58                             
    malloc_simple: size=54, ptr=284, limit=400: c1ffd70                             
    malloc_simple: size=c, ptr=290, limit=400: c1ffdc4                              
    i2c_bind_driver:  device_bind_driver: ret=0                                     
    uclass_find_device_by_seq: 0 -1                                                 
    uclass_find_device_by_seq: 0 0                                                  
       - -1 -1 'generic_53'                                                         
       - not found                                                                  
    i2c_bind_driver:  device_probe: ret=0                                           
    i2c_xfer: 2 messages                                                            
    i2c_xfer: chip=0x53, len=0x1                                                    
    i2c_write: error sending                                                        
    Cannot read DIMM params


    We can see "i2c_get_chip: Searching bus 'i2c@2530400' for address 53: not found".

     The address can be different from the EVM?

    Best Regards,

    K.Luong

  • 0 in reply to Rex Chang
    Intellectual 520 points

    Thank you for this good explanation.

    I did what you told. I hard coded the values init_ddr3param in ddr3_spd.c based on my GEL working with DSP cores. I called ddr3a_333 directly. However, it get stuck in dram_init function in board/ti/ks2_evm/board.c when it call get_ram_size :

    gd->ram_size = get_ram_size((long * CONFIG_SYS_SDRAM_BASE, CONFIG_MAX_RAM_BANK_SIZE);

    My CONFIG_SYS_SDRAM_BASE is defined in include/configs/ti_armv7_common.h with the address 0x80000000

    My CONFIG_MAX_RAM_BANK_SIZE is defined in include/configs/ti_armv7_keystone2.h with (2<<29) (our DDR size is 1GB).

    Moreover, in get_ram_size function(in common/memsize.c file), it gets stuck in the first for loop.

    Any suggestions?

    Thank you again for your help!

    Best Regards,

    K.Luong

  • 0 in reply to Rex Chang
    Intellectual 520 points

    Hi Rex,

    I told you that our GEL was working to test DDR3A. Indeed, it works when testing with DSP cores.

    However, when I try to use xtcievmk2x_arm gel with same DDR_init function that we use to initialize our DDR3, it fails. Is there something different to do for DSP DDR3A access configuration and ARM access configuration?

    Following this thread: e2e.ti.com/.../479949

    I tried to enable FXDLAT bit. However, i'm still stuck with ARM gel emulation and with U-boot too. It doesn't change anything.

    Best Regards,

    K.Luong

  • 0 in reply to L.Kiet
    TI__Guru 50170 points

    Hi, K.Luong,

    You may want to check what are the i2c address and chipselect on your custom board. I have no info.

    The DDR3 configuration in DSP and ARM gel files are the same except the PLL register names. You can compare TI's gel files in CCS to see the difference. The GEL file is used in noboot mode without u-boot running. I assume you ran it in that setup. In the past, U-boot ported DDR3 configuration in DSP gel file into its code to get DDR3 configured. My guess for failing get_ram_size() call is that it may be caused by wrong DDR3 configuration. 

    Rex

  • 0 in reply to Rex Chang
    Intellectual 520 points

    Hi Rex,

    I didn't figure out yet why I can't access to DDR3A from ARM core and then from U-boot but I think it will be figured out soon.

    Indeed, when seeing datasheet of the SoC for address 0x80 000 000 (address that I use to access DDR3A (we don't use DDR3B)), we see :

    (4) This region is mapped to DDR3A or DDR3B depending on the state of DDR3A_REMAP_EN pin at boot time. If the pin is ‘1’, this region
    is mapped to the first 2GB of DDR3A which is aliased of 08 0000 0000 to 08 7FFF FFFF. If the pin is ‘0’, this region is mapped as 2GB
    of DDR3B.

    Looking to our schema, this pin is '0'. We will then do hardware fix to put it to '1' hopping that this is why I can't access DDR3A.

    Do you confirm that it can explain my problem with DDR3?

    For better understanding, do you know what is the situation on EVMK2H. Is it 1 and then explains why I can access to EVMK2H DDR3A by ARM emulation and not my custom board DDR3A where it is '0'?

    Thank you.

    Best regards,

    K.Luong

  • 0 in reply to Rex Chang
    Intellectual 520 points

    Hi Rex,

    Thank you for your help.

    I can now access DDR3A with the hardware fix we did. It then unblocked U-boot too.

    Best regards.

    K.Luong

  • 0 in reply to L.Kiet
    TI__Guru 50170 points

    Hi, K.Luong,

    Glad the issue is resolved. I'll close it. Should you have any other issues, please submit new ones.

    Rex