I tested this both with and without the VFP, and in both cases I can't
even make it to bsp_start. Even worse, Uniflash will almost fail to
load the binaries to the board, which makes it quite cumbersome to
perform the tests. While I may've done something wrong, the errors
Uniflash is reporting are the exact same as the ones we used to have
when POM was enabled by default. So there's that.
For now we'll keep working with 4.11 prior to your changes. I suspect
your issue is different than the one I'm seeing though; you may want
to check if your loader doesn't do anything with the FP registers
before you get to bsp_start_init_registers_vfp.
On Mon, Nov 23, 2015 at 5:50 PM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote:
> 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
--
Martin Galvan
Software Engineer
Taller Technologies Argentina
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: 54 351 4217888 / +54 351 4218211
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
