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: Enabling DCACHE in u-boot

Part Number: AM5728


Tool/software: Linux

Champs,

Customer is trying to enable data cache in uboot. Checking SCTRL register using JTAG on running uboot (2018.01 TI SDK 5.01.00.11) I see ICACHE enabled and DCACHE disabled. I am looking at REG_CTXA15_C15_C1_SCTLR as shown in Registers view in CCS.

Searching for CONFIG_SYS_DCACHE_OFF in build configuration files produced no results, so I assume that the flag is NOT defined, which means that the DCACHE should be enabled - in common/spl/spl.c in functionboard_init_r() I see enable_caches() call. The questions I have are:

1. Is my understanding is correct and the data cache is indeed not enabled in uboot while instruction cache is enabled.

2. If that's the case - how do I enable data cache?

thanks

Michael

  • Michael,

    L1D cache enable depends on CONFIG_SYS_DCACHE_OFF flag, when this flag is set, the cache is not enabled. Check also if function dcache_enable() is executed (file omap-cache.c). Check below pointers, seems to be related:

    u-boot-2018.01/doc/README.arm-caches

    Enabling D-cache:
    - Make sure CONFIG_SYS_DCACHE_OFF is not set and call dcache_enable().

    e2e.ti.com/.../584282
    e2e.ti.com/.../328682
    e2e.ti.com/.../312922
    e2e.ti.com/.../2098925
    e2e.ti.com/.../414572

    Regards,
    Pavel
  • Pavel,

    The issue is that I do NOT see the CONFIG_SYS_DCACHE_OFF flag being set in standard SDK uboot build environment. This means that the dcache_enable() should be executed and yet the C bit in the SCTRL registers shows 0 when I connect with debugger. Am I missing something?
    Is there an easy way to see what flags are set during uboot compilation? After building uboot I grepped the whole uboot tree for CONFIG_SYS_DCACHE_OFF and it is not found in any build configuration or .h files.

    thanks
    Michael
  • Michael,

    Michael Shklyarman said:
    The issue is that I do NOT see the CONFIG_SYS_DCACHE_OFF flag being set in standard SDK uboot build environment. This means that the dcache_enable() should be executed

    Michael Shklyarman said:
    After building uboot I grepped the whole uboot tree for CONFIG_SYS_DCACHE_OFF and it is not found in any build configuration or .h files.

    Yes, I also think that this flag CONFIG_SYS_DCACHE_OFF is NOT set in the default PSDK. In PSDK 5.01 AM572x EVM u-boot prompt, when I execute below command I have an output indicating that dcache is being enabled:

    => bdinfo
    arch_number = 0x00000000
    boot_params = 0x80000100
    DRAM bank   = 0x00000000
    -> start    = 0x80000000
    -> size     = 0x80000000
    baudrate    = 115200 bps
    TLB addr    = 0xFFFF0000
    relocaddr   = 0xFFF4F000
    reloc off   = 0x7F74F000
    irq_sp      = 0xFDF15D40
    sp start    = 0xFDF15D30
    Early malloc usage: 700 / 2000
    fdt_blob = fdf15d58

    u-boot/cmd/bdinfo.c

    #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
        print_num("TLB addr", gd->arch.tlb_addr);
    #endif

    If you need to set this flag, this should be done in u-boot/include/configs/am57xx_evm.h file, like for example in below file:

    u-boot/include/configs/ti_armv7_keystone2.h:    #define CONFIG_SYS_DCACHE_OFF

     

    Michael Shklyarman said:
    This means that the dcache_enable() should be executed and yet the C bit in the SCTRL registers shows 0 when I connect with debugger. Am I missing something?

    I can think of two possible issue:

    1. How exactly you check SCTRL register? At which point exactly? May be you are checking the wrong register or checking too early. See if you are aligned with below e2e post:

    2. dcache might be disabled after being enabled. You can trace below source code and check (with printf or breakpoints) if dcache_disable() code is being executed:

    u-boot/common/spl/spl.c

    void board_init_r(gd_t *dummy1, ulong dummy2)
    {

    #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) && \
            defined(CONFIG_ARM)
        cleanup_before_linux();
    #endif

    }

    u-boot/arch/arm/cpu/armv7/cpu.c

    int cleanup_before_linux_select(int flags)
    {

    dcache_disable()

    }

     

    u-boot/doc/README.arm-caches

    Cleanup Before Linux:
    - cleanup_before_linux() should flush the D-cache, invalidate I-cache, and
      disable MMU and caches.
    - The following sequence is advisable while disabling d-cache:
      1. dcache_disable() - flushes and disables d-cache
      2. invalidate_dcache_all() - invalid any entry that came to the cache in the short period after the cache was flushed but before the cache got disabled.

    Regards,
    Pavel

  • Hi Pavel,

    I finally got a chance to get to the bottom of it. There appear to be a discrepancy between the SCTLR register's read in uboot and through CCS. I made a few reads of the register using get_cr() function in both u-boot and SBL code using stock SDK running AM5728 IDK. Immeduiately after enable_caches() call in spl.c the register contains 0x30c5187d which means both icache, dcache and MMU are all enabled. The same value remains in the register after u-boot takes over. 

    After that, I have connected with CCS on running u-boot and looked at REG_CTXA15_CP15_C1_SCTLR register which, according to number of discussions on this forum, is the Cortex-A15 SCTLR register. The value of REG_CTXA15_CP15_C1_SCTLR in CCS is 0xC5187A which means DCACHE disabled. 

    Could you please help shed some light on this discrepancy?

    thanks,

    Michael

  • please refer further below in the thread
  • Michael,

    I can think of two possible reasons for this discrepancy:

    1. When you connect to the board with JTAG, check if some GEL file or other code is auto executed, as this code might be disabling the dcache

    2. Put a printf in dcache_disable() function. You might check with get_cr() before that function is executed and then with JTAG after that function is executed.

    Regards,
    Pavel
  • Pavel,

    The GEL files in the AM57x boards do not do anything to cache. I verified it by adding SCTRL read and printf to the bdinfo function. The register content did not change between first read after board reset and after I connected with CCS and resumed uboot by clicking "run" in CCS. I am fairly sure dcache_disable() is NOT called since if it did the CR_C bit would have been reset. 

    I tend to believe that u-boot actually does the right thing and the dcache is, in fact, enabled. My fear is that there is an issue with CCS representation of the CA-15 SCTRL register. Could you please route this concern to the right person to help verify this?

    thank you

    Michael

  • Pavel,

    I was able to confirm that dcache is indeed enabled in uboot. I ran crc32 command on uboot prompt with and without CONFIG_SYS_DCACHE_OFF flag defined in am57xx_evm.h. With the flag ON the crc32 execution over the same address range is >10 times longer. Interestingly the SCTRL register value when caches are off is 0x30C5187C which means that cache bits remain turned on but the MMU is off and as a result caches aren't used.
    This still leaves the issue of the CCS representation of this register as pointed out in my previous post.

    thanks
    Michael
  • Michael,

    To check this with CCS team, you need to post in below forum:

    e2e.ti.com/.../81

    Make sure you set the resp. org. to "Code Compose Studio".

    If you have no more questions related to dcache in u-boot, please close/verify/resolve this thread.

    Regards,
    Pavel
  • Thank you, Pavel.

    for reference the discussion continues on CCS forum: