Unable to run run-time loaded code on ZedBoard

[Pavel Pisa]

Hello all,

one possible problem source.

The ARM MMU is setup according to sections from loaded
image for most ARM BSPs. The area used by heap can be marked
as nonexecutable or with some other cache/mapping
problem.

In general, I would prefer to setup all physical memory
(irrespective to the sections) to be RW, Executable
and cached (if caching is not in conflict with
unfinished drivers without correct DMA synchronization).
Then mark only these areas which are fully covered by
code and rodata sections as RO and cached.

Best wishes,

              Pavel


On Tuesday 20 of October 2015 02:04:42 Chris Johns wrote:
> On 20/10/2015 8:59 am, Patrick Gauvin wrote:
> > Here is the dissasembly with raw instructions for the rtems main
> > symbol (rtl: sym:add:20 name:30:rtems_main           bind:1  type:2
> > val:0x2138f9 sect:1 size:88):
> >
> > (gdb) disas /r 0x2138f9,0x2138f9+88
> > Dump of assembler code from 0x2138f9 to 0x213951:
> >    0x002138f9:  b5 84   push    {r7, lr}
> >    0x002138fb:  b0 00   sub     sp, #16
> >    0x002138fd:  af 78   add     r7, sp, #0
> >    0x002138ff:  60 39   str     r0, [r7, #4]
> >    0x00213901:  60 43   str     r1, [r7, #0]
> >    0x00213903:  f6 60 10 c0     movw    r0, #14688      ; 0x3960
> >    0x00213907:  f2 21 00 79     movt    r0, #33 ; 0x21
> >    0x0021390b:  68 43   ldr     r1, [r7, #4]
> >    0x0021390d:  f6 80 12 c0     movw    r2, #14720      ; 0x3980
> >    0x00213911:  f2 21 02 05     movt    r2, #33 ; 0x21
> >    0x00213915:  f7 08 fe 00     bl      0x119528 <printf>
> >    0x00213919:  23 fb   movs    r3, #0
> >    0x0021391b:  60 0f   str     r3, [r7, #12]
> >    0x0021391d:  e0 fb   b.n     0x21393e
> >    0x0021391f:  68 9b   ldr     r3, [r7, #12]
> >    0x00213921:  00 3a   lsls    r3, r3, #2
> >    0x00213923:  68 13   ldr     r2, [r7, #0]
> >    0x00213925:  44 1b   add     r3, r2
> >    0x00213927:  68 43   ldr     r3, [r3, #0]
> >    0x00213929:  f6 88 10 c0     movw    r0, #14728      ; 0x3988
> >    0x0021392d:  f2 21 00 f9     movt    r0, #33 ; 0x21
> >    0x00213931:  68 1a   ldr     r1, [r7, #12]
> >    0x00213933:  46 05   mov     r2, r3
> >    0x00213935:  f7 f8 fd fb     bl      0x119528 <printf>
>
> Looks fine.
>
> >    0x00213939:  68 01   ldr     r3, [r7, #12]
> >    0x0021393b:  33 fb   adds    r3, #1
> >    0x0021393d:  60 fa   str     r3, [r7, #12]
> >    0x0021393f:  68 7b   ldr     r2, [r7, #12]
> >    0x00213941:  68 9a   ldr     r3, [r7, #4]
> >    0x00213943:  42 eb   cmp     r2, r3
> >    0x00213945:  db 7b   blt.n   0x21391e
> >    0x00213947:  68 18   ldrirrespective     r3, [r7, #4]
> >    0x00213949:  46 10   mov     r0, r3
> >    0x0021394b:  37 bd   adds    r7, #16
> >    0x0021394d:  46 80   mov     sp, r7
> >    0x0021394f:  bd 44   pop     {r7, pc}
> > End of assembler dump.
> >
> > If you want the full object file before it is loaded, I can dump it
> > from memory but I'm not sure GDB will decode the instructions.
> >
> >>>> Note, ARM veneers is an outstanding task I need to complete.
> >>>
> >>> The bl instructions to printf inside the loaded code are within range
> >>> (16 MB for the 32bit T32 bl) so I don't think this application
> >>> requires veneers. I will keep this in mind for the future, though.
> >>
> >> Do you have a special option on? I thought the default was 24bit.
> >
> > I don't have any special option on, but GCC seems to be generating the
> > 32bit T32 encoding of bl rather than the 16bit (unless I'm
> > misinterpreting the hex dump, but even so the lesser 4MB range would
> > be enough in this case).
>
> Hmm maybe a data cache flush and instruction cache invalidate is needed.
>
> Maybe the L2 cache support being added has broken this test.
>
> Chris
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users