i.MX6SX L2 cache issue

[adinu]

Hi, All,

We have designed our own PCB using i.MX6SX SABRE SDB board as a reference. The CPU model of this development board is MCIMX6X4EVM10AB and we are using the model MCIMX6X1EVO10AB in our custom PCB. The problem is that we are not able to enable the L2 cache in our custom PCB.

When the kernel starts and configures / enables the L2 cache (L2C-310 r3p2), the CPU hangs. If we delete the L2 cache definition from DTB, the kernel does not configure / enable the L2 cache and the system starts normally (although the performance is really poor because the cache is disabled). However, we are able to enable the L2 cache in the u-boot as we have already checked reading the 0x00a02100 register and it seems to work properly.

We have the following specific hardware and software configurations:

Hardware

• Model: i.MX6SX MCIMX6X1EVO10AB (MCIMX6X4EVM10AB in i.MX6SX SABRE SDB) . According to NXP documentation, our model does not include the following modules:
  • 2D&3D GPU
  • PCIe
  • LVDS
  • Video ADC
• DDR: Nanya 2x NT5CB64M16GP-DII with size of 256 MBytes (MICRON 2x MT41K256M16HA-125 with a size of 1 GByte in i.MX6SX SABRE SDB)). The layout is almost the same for both boards.
• PMIC: MC32PF3000A3EP (MMPF0200F6AEP in i.MX6SX SABRE SDB). We have done all required modifications which are explanined in AN5161 application note ("Powering an i.MX 6SX-based System using the PF3000 PMIC").

Software

• U-boot: 2015.04 version. We have tried with the latest version (2017.07), and the issue is also present. We have done the following changes in the u-boot configuration compared to i.MX6SX SABRE SDB:
  • In include/configs/mx6sxsabresd.h file:
    • We have modified the RAM size from SZ_1G to SZ_256M.
    • We have disabled the PCIe.
  • In board/freescale/mx6sxsabresd/mx6sxsabresd.c file, we have modified the pin configuration.
  • Device Configuration Data (DCD). We have run the "DDR Stress Test Tool" and updated calibration registers in DCD. Additionally, we have also modified some registers in DCD according to I.MX6SX_DDR3_Script_Aid_V0.01.xlsx. imximage.cfg file attached to this post.
• Kernel version: 4.4.7 with rt16 real time patch. Kernel configuration attached to this post.
• DTS: The default kernel DTS for i.MX6SX SABRE SDB with little modifications.

It is important to point out that we had used successfully the same kernel and u-boot versions in the i.MX6SX SABRE SDB development board.

Thanks for reading and any help will be highly appreciated!

Original Attachment has been moved to: files.tar.gz

[adinu]

Hi Igor,

We have fixed the issue. The problem was that we have not properly configured the GPIO boot override, in particular the pin LCD1_DATA08. This pin is associated to eFUSE BOOT_CFG2[0] which is defined as "L2 cache memory to be configured as OCRAM". For this reason, the L2 cache has been used as OCRAM and not as cache. We have removed the pull-up resistor that we had set to this pin, and now the L2 cache works perfectly.

Thank you for your help.

Best regards,
Abraham.

[igorpadykov]

Hi Abraham

CPU may hang with enabled L2 due to ddr errors, as

L2 enables more faster code execution. Please run ddr test

i.MX6/7 DDR Stress Test Tool V2.60 

and update dcd header (in uboot/.../mx6sxsabresd/imximage.cfg) with new calibration coefficients

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[adinu]

Hi Igor,

Thanks for your help. We have run ddr test again with the latest version (v2.60) and obtained the following calibration values:

MMDC registers updated from calibration

Write leveling calibration
MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x0029001F
MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x0024001B

Read DQS Gating calibration
MPDGCTRL0 PHY0 (0x021b083c) = 0x41540144
MPDGCTRL1 PHY0 (0x021b0840) = 0x01400130

Read calibration
MPRDDLCTL PHY0 (0x021b0848) = 0x4044464A

Write calibration
MPWRDLCTL PHY0 (0x021b0850) = 0x3A3A3A34

We have updated DCD file with these values but the problem persists. Attached to this post you can find the full calibration log.

Could you give us any more ideas?

Thank you in advance.

Best regards,
Abraham.

[igorpadykov]

Hi Abraham

hanging also may happen due to power supplies, please

check it with oscilloscope, use IMX6SXHDG Hardware Development Guide for i.MX 6SoloX

http://www.nxp.com/assets/documents/data/en/user-guides/IMX6SXHDG.pdf

Common requirement for ripple noise should be less than 5% Vp-p of supply voltage average value.
Related power rails affected: all VDD_xxx_IN and VDD_xxx_CAP.

Best regards
igor

[adinu]

Hi Igor,

We have measured all voltages. Attached to this post you can find a document which shows the screenshots of all of them for our custom PCB. Everything seems to be ok.

PD: We want to point out that if we do not enable the L2 cache in DTB, our custom PCB works without hangs. Additionally, we have run ddr test tool for more than 48h in u-boot without any issue.

Could you suggest us any more checks?

Thank you in advance.

Abraham.

[igorpadykov]

Hi Abraham

which reference board is based customer board and what bsp used in the case.

Best regards
igor

[adinu]

Hi Igor,

Our custom board is based on i.MX6SX SABRE SDB (i.MX 6SoloX SABRE Development Board|NXP). We are not using any BSP, we are using 4.4.7 vanilla kernel with rt16 real time patch.

Thank you in advance.

Abraham.

[igorpadykov]

Hi Abraham

this kernel is not offcially supported by nxp, please post issue on mainline

kernel or meta-fsl-arm mailing list, so that someone familiar with it could try to assist you.
https://lists.yoctoproject.org/listinfo/meta-freescale

Offcial nxp bsps are described on:

http://www.nxp.com/products/software-and-tools/software-development-tools/i.mx-software-and-tools/i....

Best regards
igor

[adinu]

Hi Igor,

Thanks for your help.

We have downloaded and compiled the latest BSP Linux for i.MX6 platform (4.1.15_2.1.0 version) and the issue is also present.

We have disabled CONFIG_SMP option in BSP Linux 4.1.15_2.1.0 menuconfig, and the kernel boots with L2 cache enabled, apparently (register 0x00a02100 = 1). i.MX6SX SABRE SDB board boots with and without CONFIG_SMP (custom board only without CONFIG_SMP). Nevertheless, the CPU performance is awful. We have checked it using "sysbench" utility and the memory transfer rate is lower in our custom board compared to development one. If we disable the L2 cache in i.MX6SX SABRE SDB board (removing it from DTB), we get the same memory transfer rate as the custom board. In this way, it seems like L2 cache is not working in our custom board regardless of the value read from 0x00a02100 register.

Additionally, we have booted our custom board using NXP zImage (from file L4.1.15_2.0.0-ga_images_MX6SXALL), getting the same results.

The silicon revision is 1.2, the same for both CPUs.

Thanks for reading and any help will be highly appreciated!

[igorpadykov]

Hi Abraham

could you try memory transfer tests not using ddr, use OCRAM.

Best regards
igor

[adinu]

Could you explain us how to measure OCRAM transfer performance?

Thank you in advance,

Abraham.

[igorpadykov]

one can use standalone memcpy:

memcpy assembly code

copy_words_using_eight_registers:
    stmfd   sp!, {r3-r10}
/* mov r2,r2,LSL #2  */
loop_eight:
    PLD      [r1,#0xC0]   /* cache preload instruction, improves performance */
    ldmia   r1!, {r3-r10}
    stmia   r0!, {r3-r10}
    subs    r2, r2, #32
    bne     loop_eight

    ldmfd  sp!, {r3-r10}
    mov    pc, lr

    .endfunc

and use

https://community.nxp.com/thread/351961 

Best regards
igor

[adinu]

We have measured the time that custom and SABRE boards expend executing this code (which reads all OCRAM):

for i in `seq 0x918000 4 0x91cffc`; do printf "0x%x " $i; devmem $i; done;

We have obtained the following times:

• Custom board: 37 seconds.
• SABRE board: 23 seconds.
• SABRE board (without L2 cache): 36 seconds.

This test seems to show that L2 cache is not working properly, as we suppose.

[igorpadykov]

to exclude linux sideeffects please try tests as standalone application

Best regards
igor