Hello Martin,
On Monday 23 of November 2015 21:31:46 Martin Galvan wrote:
> I'm about to test this on our setup. Just to be sure, does your
> startup code perform the register initialization required by the
> CCM-R4F? I added that to arm/shared/start/start.S a few months ago.
I am aware of your change. It is correct for sure and our setup
prepares ram first but RTEMS execution starts from _start symbol
and disassembly shows that register setup you provided is on the
code path
(gdb) x /40i _start
0x80000040 <bsp_start_vector_table_end>: bl 0x8000c8bc
<bsp_start_init_registers_core>
0x80000044 <bsp_start_vector_table_end+4>: mov r0, #211 ; 0xd3
0x80000048 <bsp_start_vector_table_end+8>: msr CPSR_fc, r0
0x8000004c <bsp_start_vector_table_end+12>: mov r0, #210 ; 0xd2
...
0x800000a4 <bsp_start_vector_table_end+100>: mov r0, #1073741824 ;
0x40000000
0x800000a8 <bsp_start_vector_table_end+104>: vmsr fpexc, r0
0x800000ac <bsp_start_vector_table_end+108>: bl 0x8000c910
<bsp_start_init_registers_vfp>
0x800000b0 <bsp_start_vector_table_end+112>: ldr lr, [pc, #92] ;
0x80000114 <twiddle+26>
0x800000b4 <bsp_start_vector_table_end+116>: orr lr, lr, #1
(gdb) x /20i bsp_start_init_registers_vfp
0x8000c910 <bsp_start_init_registers_vfp>: mov r0, #0
....
0x8000c950 <bsp_start_init_registers_vfp+64>: vmov d15, r0, r0
0x8000c954 <bsp_start_init_registers_vfp+68>: bx lr
0x8000c958 <bsp_start>: push {r3, lr}
0x8000c95a <bsp_start+2>: movw r3, #36684 ; 0x8f4c
The additional registers initialization by RTEMS should be another guarantee
that registers d0 to d15 and VFP state is OK. So there should not be problem
from this side. Other option is too small default stack size (but we tried to
enlarge it)
or something else. May it be some status register or other safety hardware
initialization skipped??? I am not sure.
Best wishes,
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
