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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
