i.MX28 MMU configuration problem (kernel hangs on RAM memory access)

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

i.MX28 MMU configuration problem (kernel hangs on RAM memory access)

708 Views
italosampaio
Contributor I

Hi, I have a custom board with the imx28 and i am trying to boot Linux 2.6.35.3 based on Freescale BSP. The kernel starts the boot process normally, but hangs always at the same point (boot log attached). After some debug, we found out that the exact point where the boot stops is at file clear_user.S (linux-2.6.35.3/arch/arm/lib/clear_user.S), inside the function __clear_user_std. In my understanding, this function is called right before running /sbin/init, to clean the memory area that will be used to hold the program code.

 

After a deeper debug, we found out that the boot hangs because the processor tries to access an invalid memory region. The processor tries to write the memory address 0x000986d9, while the valid memory area for the imx28 starts at 0x40000000. When this happens, the processor hangs and the boot stops.

 

Based on that, our suspect is a problem with the MMU. The contents of the Control Register c1 before the error is 0x0005317f, which means that the MMU is enabled (bit 0 == 1). Control Register c2 gives us the base address of the first-level translation table, which is 0x467ec000. After disabling the MMU, we read 0x00000000 from address 0x467ec000, which means that the MMU is using 0x00000000 as offset, instead of 0x40000000 (maybe 0xC0000000 based on the log attached?).

 

Does anybody have any insight on this problem? Is my interpretation of the internal registers correct? Which Linux files configure the MMU and why are they configuring the wrong values? Am i missing something?

 

Thanks

 

 

Italo Sampaio

Original Attachment has been moved to: boot.log.zip

Labels (2)
1 Reply

384 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

Would you be nice enough to share the modifications you performed to the BSP?

That could give us clue of the possible issue. One thing we can try is to compare with a non-modified  BSP and check the behavior. 

Regards,

Alejandro

0 Kudos