i.MX53/compact 7 MMU problem

[c393]

I have a custom i.MX53 board running compact 7. The BSP is cloned from IMX53 ARD Mobility. I am booting from SDIO, boots until it enables the MMU and starts to execute at the virtual address. At that point it is in the weeds. The IMX53 ARD mobility bsp had 1GB of DDR3 RAM my board has 512MB of DDR3 RAM. In the project I have environment variable "imgram512" set. Any suggestions on why it gets lost when switching to virtual world?

Area in startup.s that program gets lost:

ACTIVATEMMU

    ; The 1st Level Section Descriptors are setup. Initialize the MMU and turn it on.

   ;

    mov     r1, #1

    mcr     p15, 0, r1, c3, c0, 0   ; Set up access to domain 0.

    mov     r0, #0

    mcr     p15, 0, r0, c8, c7, 0   ; Flush the instruction and data TLBs.

    mcr     p15, 0, r1, c7, c10, 4  ; Drain the write and fill buffers.

    mrc     p15, 0, r1, c1, c0, 0   ; Read control register

    orr     r1, r1, #0x1            ; Enable MMU.

    orr     r1, r1, #0x1000         ; Enable IC.

    orr     r1, r1, #0x4            ; Enable DC.

    ldr     r4, =VirtualStart       ; Get virtual address of 'VirtualStart' label.

    cmp     r4, #0                  ; Make sure no stall on "mov pc,r4" below.

    mcr     p15, 0, r1, c1, c0, 0   ; Enable MMU and caches

    mov     pc, r4                  ; Jump to virtual address

    nop

     nop

     nop

ALIGN

    ; We are now running virtual address space.

VirtualStart

additional information  address of mov pc, r4  0x7000_1608 , address of VitualStart 0x8004_2608

[JerryZeng · Accepted solution]

Your issue has nothing to do with 512M/1G memory. If your DDR init script is correct, such different DDR configuration will only impact NK not eboot. And since you have already set IMGRAM512, even in NK there should be no problem with 512M DDR.

This issue is also not a MMU problem. MMU is a standard unit in the ARM core, as long as you reuse all the ARM init code from original MX53 ARD BSP, MMU should work without any problem.

Your issue should be configuration issue. I don't remember the exact virtual address, but I feel your virtual address has a 4k offset (0x70001608 vs 0x80042608). Did you change anything in bib files (eboot.bib/config.bib) or other files which may impact the virtual address configuration in your BSP?

Since you have the debug tool to trace the code, another suggestion is that you can try Freescale's default BSP on MX53 SMD or ARD board (if you have these boards :smileyhappy:) and check the physical address / virtual address to quick confirm if this is the cause of your issue.