Cortex-A5 sets instr_pc to 0x00000008 after enabling MMU and using high exception vectors

Hello Community,

in our current ASIC project we have to replace an ARM926EJ-S with a Cortex-A5.

In the moment we are facing the following problem in our bootloader:

We intend to use the high exception vectors after reset (input vinithi is tied fix to '1') as our external DDR memory is mapped at address 0x00000000 and is normally not available during the early bootup phase.

After configuring and enabling the MMU (according to "Migrating a software application from ARMv5 to ARMv7-A/R, Application Note 425, topic 4.1) we see the value 0x00000008 in register instr_pc several times and some time later the core performs a read access to address 0x00000000 and the system stalls as the DDR2 controller isn't configured yet.

If we configure the DDR2 controller so that the memory at address 0x00000000 is available, the application is running as expected.

Also is we configure the mmu table entry for 0x00000000-0x000FFFFF to NOACCESS, the application is running.

But we want/need to understand the behavior.

Any suggestion what we are missing and why the core is accessing 0x00000000?

Thank you!

Daniel

Parents
  • Hello Daniel,

    it is good news.

    The NX bit will inhibit the predicted instruction fetches and I think it made good effect on your system.

    This shows the CPU had made the predicted fecth to 0x00000008.

    Could I ask you whether had you taken the following procedures?

    Have you already tried the instruction cache invalidation and branch prediction invalidation before enabling MMU?

    Or had you only set the XN bits at the MMU setting?

    For your information, the below is the summary of  instruction related operations.

    MCR p15, 0, <Rd>, c7, c5, 0
       ARMv6 explanation: Invalidate Entire Instruction Cache Register
       ARMv7 explanation: ICIALLU, Invalidate all instruction caches to PoU
    MCR p15, 0, <Rd>, c7, c5, 4
       ARMv6 explanation: Flush Prefetch Buffer Register
       ARMv7 explanation: CP15ISB, Instruction Synchronization Barrier operation
    MCR p15, 0, <Rd>, c7, c5, 6
       ARMv6 explanation: Flush Entire Branch Target Cache Register
       ARMv7 explanation: BPIALL, Invalidate all branch predictors
    MCR p15, 0, <Rd>, c7, c5, 7
       ARMv6 explanation: Flush Branch Target Cache Entry Register
       ARMv7 explanation: BPIMVA, Invalidate MVA from branch predictors

    Best regards,

    Yasuhiko Koumoto.

Reply
  • Hello Daniel,

    it is good news.

    The NX bit will inhibit the predicted instruction fetches and I think it made good effect on your system.

    This shows the CPU had made the predicted fecth to 0x00000008.

    Could I ask you whether had you taken the following procedures?

    Have you already tried the instruction cache invalidation and branch prediction invalidation before enabling MMU?

    Or had you only set the XN bits at the MMU setting?

    For your information, the below is the summary of  instruction related operations.

    MCR p15, 0, <Rd>, c7, c5, 0
       ARMv6 explanation: Invalidate Entire Instruction Cache Register
       ARMv7 explanation: ICIALLU, Invalidate all instruction caches to PoU
    MCR p15, 0, <Rd>, c7, c5, 4
       ARMv6 explanation: Flush Prefetch Buffer Register
       ARMv7 explanation: CP15ISB, Instruction Synchronization Barrier operation
    MCR p15, 0, <Rd>, c7, c5, 6
       ARMv6 explanation: Flush Entire Branch Target Cache Register
       ARMv7 explanation: BPIALL, Invalidate all branch predictors
    MCR p15, 0, <Rd>, c7, c5, 7
       ARMv6 explanation: Flush Branch Target Cache Entry Register
       ARMv7 explanation: BPIMVA, Invalidate MVA from branch predictors

    Best regards,

    Yasuhiko Koumoto.

Children
No data