topic Re: iMX51 EVK Board issue when accessing RAM in i.MX Processors

iMX51 EVK Board issue when accessing RAM

nmnz — Mon, 31 Oct 2011 08:30:55 GMT

Dear all,

Thank you for reading my post.

I just have downloaded and compiled the latest u-boot from Freescale’s website (11.09.01 version), and I have RAM issues.

When booting on the iMX51 EVK, the command “mw 90000000 a5 100000” results in a crash.

In a similar way, if I do the following sequence : “mw 90000000 a5 40000” followed by “mw 91000000 a5 40000”, the board crashes. If I do the same sequence, but in the reverse order, I get no crash.

Could someone confirm that he is experiencing the same issues with u-boot? What could fix this issue?

Thank you and best regards,

Re: iMX51 EVK Board issue when accessing RAM

KrishnaPavan — Mon, 31 Oct 2011 10:06:21 GMT

From Which device did you boot from?

Can You Please Specify?

SPI-NOR?

NAND?

MMC/SD?

Re: iMX51 EVK Board issue when accessing RAM

nmnz — Mon, 31 Oct 2011 10:23:44 GMT

I boot from SDCard.

Any idea ?

Regards,

Re: iMX51 EVK Board issue when accessing RAM

nmnz — Mon, 31 Oct 2011 12:02:19 GMT

I boot from the SDcard (the EVK has no NAND).

On the other hand,I just made some tests on a custom design on which I boot from NAND, and the behavior is identical...

Do you have an idea about this bug?

Thank you again,

Regards,

Re: iMX51 EVK Board issue when accessing RAM

LilyZhang — Mon, 31 Oct 2011 16:16:41 GMT

You can add the logs into common/cmd_mem.c and see what's happening.

From the description, it seems when the address exceed one range and do the operation, the memory is corrupt.

Re: iMX51 EVK Board issue when accessing RAM

nmnz — Tue, 01 Nov 2011 07:57:55 GMT

Hi,

I added some comments but for the moment I didn't succeed in tracing the bug.

Is there somebody who faces the same bug on the EVK and can confirm it ?

Regards,

Re: iMX51 EVK Board issue when accessing RAM

LilyZhang — Tue, 01 Nov 2011 12:31:25 GMT

Hello, Nicolas:

We saw the problem. We think It's related to MMU mapping.

        X_ARM_MMU_SECTION(0x900, 0x000, 0x1FF,
                        ARM_CACHEABLE, ARM_BUFFERABLE,
                        ARM_ACCESS_PERM_RW_RW); /* SDRAM */
        X_ARM_MMU_SECTION(0x900, 0x900, 0x200,
                        ARM_CACHEABLE, ARM_BUFFERABLE,
                        ARM_ACCESS_PERM_RW_RW); /* SDRAM */
        X_ARM_MMU_SECTION(0x900, 0xE00, 0x200,
                        ARM_UNCACHEABLE, ARM_UNBUFFERABLE,
                        ARM_ACCESS_PERM_RW_RW); /* SDRAM 0:128M*/

If you disabled MMU, you should not see this problem. We will see how to resolve it.

diff --git a/include/configs/mx51_bbg.h b/include/configs/mx51_bbg.h
index 6115f24..4c26ad0 100644
--- a/include/configs/mx51_bbg.h
+++ b/include/configs/mx51_bbg.h
@@ -40,7 +40,7 @@
#define CONFIG_MX51_HCLK_FREQ 24000000 /* RedBoot says 26MHz */

#define CONFIG_ARCH_CPU_INIT
-#define CONFIG_ARCH_MMU
+//#define CONFIG_ARCH_MMU

Re: iMX51 EVK Board issue when accessing RAM

nmnz — Tue, 01 Nov 2011 13:00:08 GMT

Hi Lily,

Thanks a lot for your quick response.

You're right, if we deactivate MMU we don't have the problem anymore. But unfortunately we need to active MMU.

Do you know if there is a fix to this issue, with the MMU activated ?

Thanks.

Regards,

Re: iMX51 EVK Board issue when accessing RAM

TerryLv — Wed, 02 Nov 2011 02:00:42 GMT

Hi,

0x90004000 in mx51 is mmu entry table. User should not modify this table when mmu is enabled, unless you move this table to another place.

"mw 90000000 a5 100000" will modify TLB, thus it crashed.

We will set this region as read-only later.

But now you may know the reason.

Thanks~~

Yours

Terry

Re: iMX51 EVK Board issue when accessing RAM

nmnz — Wed, 02 Nov 2011 08:46:14 GMT

Hi,

Thanks for your answer Terry.

Your solution is working ! In order to fix this, I applied the following changement in mx51_bbg.c:

unsigned long ttb_base = PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE - ARM_FIRST_LEVEL_PAGE_TABLE_SIZE;

This line will move the ttb table at the end of the ram and fix the issue.

Thanks for your quick answer.

Regards,

Nicolas