iMX51 EVK Board issue when accessing RAM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX51 EVK Board issue when accessing RAM

2,421 Views
nmnz
Contributor I

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,

Tags (1)
0 Kudos
Reply
9 Replies

2,311 Views
nmnz
Contributor I

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

0 Kudos
Reply

2,311 Views
TerryLv
Contributor II

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

0 Kudos
Reply

2,311 Views
nmnz
Contributor I

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,

0 Kudos
Reply

2,311 Views
LilyZhang
Contributor I

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

0 Kudos
Reply

2,311 Views
nmnz
Contributor I

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,

0 Kudos
Reply

2,311 Views
LilyZhang
Contributor I

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.

0 Kudos
Reply

2,311 Views
nmnz
Contributor I

Hi 

 

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,

0 Kudos
Reply

2,311 Views
nmnz
Contributor I

I boot from SDCard.

 

Any idea ?

 

Regards,

0 Kudos
Reply

2,311 Views
KrishnaPavan
Contributor II

From Which device did you boot from?

Can You Please Specify?

SPI-NOR?

NAND?

MMC/SD?

0 Kudos
Reply