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