This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

XN bit support on ARMv7 Cortex A15

  • Note: This was originally posted on 10th January 2013 at http://forums.arm.com

    To verify the XN bit support on Cortex A15. I executed the attached c test code.
         
    I followed below steps to test XN bit support.

    1. I compiled attached test program i.e exectest with "-z execstack"option (gcc -z execstack -o exectest exectest.c -lpthread)

    2. I removed XN bit related code in ./arch/arm/mm/mmu.c and burned kernel on target.
         Filename : arch/arm/mm/mmu.cLine:  346  
            if(cpu_is_xsc3() || (cpu_arch >= CPU_ARCH_ARMv6 && (cr & CR_XP))){
            if (!cpu_is_xsc3()) {

      #if 0

                         /*  Mark device regions on ARMv6+ asexecute-never

                 * to prevent speculativeinstruction fetches. */

                  mem_types[MT_DEVICE].prot_sect |= PMD_SECT_XN;

                  mem_types[MT_DEVICE_NONSHARED].prot_sect |= PMD_SECT_XN;

                  mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_XN;

                  mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_XN;

      #endif

                 }

          if (cpu_arch >= CPU_ARCH_ARMv7 && (cr & CR_TRE)) {

    3. Executed test program on target.

    4.    I found some times successful execution with correct output and sometimes page fault.

      As per my understanding this test program should always execute correctly and give correct output.

      If I skip step 2 (means not commenting the XN bit related code) then also I have got the same behavior.

    Please let me know how to verify XN bit support.




    Thanks & Regards,
  • Note: This was originally posted on 9th January 2013 at http://forums.arm.com

    I think the v6 and v7 page tables are (mostly) the same unless you are using the large physical address space, so yes the v6 XN should work fine for Cortex-A15.

    HTH,
    Iso
  • Note: This was originally posted on 11th June 2013 at http://forums.arm.com

    Realize this is an old post, but I hit it with a Google search, so I thought worth posting "probable cause".

    I suspect your test case is incorrect. You mention you are pushing executable code onto the stack and sometimes getting a fault, and sometimes not.

    ARMv7 does not include hardware memory coherency between I-cache and D-cache, so you are getting a cache coherency problem where you have written the code to the D cache, but the I cache is probably trying to execute the old data rather than your new code. What you are trying to do is invalid without manual cache operations to ensure I and D sides of the memory system see the same data values.

    HTH,
    Iso