TMS570 BSP testing and problem with VFP enabled build

[Martin Galvan]

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 <pisa at 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