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
Software
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
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.
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!
-----------------------------------------------------------------------------------------------------------------------
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.
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
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.
Hi Abraham
which reference board is based customer board and what bsp used in the case.
Best regards
igor
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.
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:
Best regards
igor
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!
Hi Abraham
could you try memory transfer tests not using ddr, use OCRAM.
Best regards
igor
Could you explain us how to measure OCRAM transfer performance?
Thank you in advance,
Abraham.
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
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:
This test seems to show that L2 cache is not working properly, as we suppose.
to exclude linux sideeffects please try tests as standalone application
Best regards
igor