TMS570 BSP testing and problem with VFP enabled build

[Martin Galvan]

Hi Pavel, I'll give it a look. What issues are you having? Did you see
this problem on the RTEMS samples (e.g. HelloWorld, Ticker) as well?

On Sun, Nov 22, 2015 at 8:12 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello Martin and others,
>
> we have checked actual state of 4.11 on TMS570 HDK hardware.
> SCI close path change has been checked by "cp" and "cat"
> commands to the second SCI port (other than console is run on).
> It should check last close path and code behaves correctly.
>
> Other changes do not cause build problems.
> Then we have checked run of ticker and our full LwIP test
> application. But there seem to be issues at least if we run
> tests from SDRAM (tms570ls3137_hdk_sdram build variant).
> The problem goes away when "-mfpu=vfpv3-d16 -mfloat-abi=hard"
> is removed in "tms570ls3137.inc".
>
> We have used soft-float mostly for our previous tests but
> default Flash target BSP build has been switched to hard-float
> in March by Martin Galvan.
>
> --- a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg
> +++ b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg
> @@ -6,7 +6,7 @@ include $(RTEMS_ROOT)/make/custom/default.cfg
>
>  RTEMS_CPU = arm
>
> -CPU_CFLAGS = -march=armv7-r -mthumb -mbig-endian
> +CPU_CFLAGS = -march=armv7-r -mthumb -mbig-endian -mfpu=vfpv3-d16 -mfloat-abi=hard
>
>  CFLAGS_OPTIMIZE_V = -O2 -ggdb
>  BINEXT?=.bin
>
> I expect that Tallertechnologies build in this variant
> has been long term tested and it is optimal setup
> for CPU, so there has not been problems with that
> setup in their RTEMS version, toolchain and setup
> combination.
>
> That is why I have united options over all build variants
> now because having different build for RAM and Flash
> variants would lead to surprises when working code
> for RAM would break for Flash or code for internal SRAM
> runs many times slower than Flash etc.
>
> But we do not have environment to test default build
> for application starting at address 0 yet because it requires
> direct linking with HalCoGen generated stuff and then handcrafting
> it into RTEMS. We did not used that option intentionally in
> past due to licensing problems.
> That problem seems to go mostly away but we do not have
> such hand modified HalCoGen output prepared.
>
> Martin, please, check actual RTEMS 4.11 branch and run the tests
> for Flash variant and or publish your setup to check if VFP
> problem is due some uninitialized registers or setup code
> missing in our loader/setup code for tms570ls3137_hdk_sdram
> build. We can/do tests of all other build variants in our
> setup (tms570ls3137_hdk_sdram, tms570ls3137_hdk_with_loader,
> tms570ls3137_hdk_intram).
>
> I am not 100% sure but I think that our test of VFP builds
> has worked even for other linking variants in past. So if
> thinks broke even for Tallertechnologies setup than it means
> that some mainline commit makes the problem probably.
> If VFP build continues to work well for Martin then we invest
> some time to find if problem is caused by our loader
> or tool-chain (which has been updated from our last VFP test).
>
> Best wishes,
>
>              Pavel
>
> PS: I have tested i386, csb336 and lpc40xx rtems-4.11 candidate.
>     i386 with SuiTk and Microwindows, OK - no issue
>     lpc40xx with networking, shell over telnet, etc, OK - no issue
>     csb336 with our full medical deice firmware and Microwindows
>         in port not intended for production - one issue found with
>         or SDcard over SSI wokaround for MX1 defect SDHC controller.
>         Code works reliably against 4.10. But is is external to RTEMS
>         so I do not consider this as blocker, artifact for 4.11 release.
>         Rest of quick test on MXS haredware run OK - console, communication
>         with motor controler MCU, Microwindows, SuiTk graphics etc.
>



-- 


Martin Galvan

Software Engineer

Taller Technologies Argentina


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211