Hi Bob,
I can follow your problem, but I do not have a good solution yet. I think right now, you have to live with patching the run-tool with the appropriated FPU compiler flags when building core, as I have suggested in my first mail. At least until now, everything worked fine for you when enabling the FPU even for kernel/core.
By disabling the global FPU compiler flags and re-building core, you could check however whether core/kernel use the FPU by accident at appropriated times. As long as you do not add FPU related code into the base libraries, this should hopefully not happen, as long as the compiler does not use the FPU internally.
Regards Stefan
On 12/06/2016 06:51 PM, robjsstewart@...9... wrote:
Hi Stefan, I had included in the base-hw make file a CC_MARCH option to set the hardware floating point and Neon options for my platform. That is why core was built with hardware floating point use. Removing that from the base-hw make file causes a problem because base libraries are now no longer built to use hardware fp registers. In the full build, the base libraries, libc, and core all build successfully then fails on the first application to be compiled for hardware floating point, as shown the following snippet from the build log shows:
Program app/ap_sensors/ap_sensors COMPILE main.o COMPILE sensor.o LINK ap_sensors /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/bin/ld: error: ap_sensors uses VFP register arguments, /Work/Genode/Builds/16.11/437x/var/libcache/component_entry_point/component_entry_point.lib.a(component_construct.o) does not /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /Work/Genode/Builds/16.11/437x/var/libcache/component_entry_point/component_entry_point.lib.a(component_construct.o) /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/bin/ld: error: ap_sensors uses VFP register arguments, /Work/Genode/Builds/16.11/437x/var/libcache/component_entry_point/component_entry_point.lib.a(component_entry_point.o) does not /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /Work/Genode/Builds/16.11/437x/var/libcache/component_entry_point/component_entry_point.lib.a(component_entry_point.o) /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/bin/ld: error: ap_sensors uses VFP register arguments, /Work/Genode/Builds/16.11/437x/var/libcache/ld/ld.lib.so does not /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /Work/Genode/Builds/16.11/437x/var/libcache/ld/ld.lib.so collect2: error: ld returned 1 exit status make[3]: *** [ap_sensors] Error 1 make[2]: *** [ap_sensors.prg] Error 2 make[1]: *** [gen_deps_and_build_targets] Error 2 make[1]: Leaving directory `/Work/Genode/Builds/16.11/437x' Error: Genode build failed make: *** [run/rico_fs] Error 252 bob@...297...:/Work/Genode/Builds/16.11/437x$
I'm searching for how to build the required libraries to support hardware floating point. Any suggestions would be greatly appreciated
Bob
Get Outlook for Android https://aka.ms/ghei36
On Tue, Dec 6, 2016 at 7:44 AM -0500, <robjsstewart@...9... mailto:robjsstewart@...9...> wrote:
Thanks for the reply Stefan. There is no reason for me to use FP in core! I needed to extend core functionality to allow privileged access to modify some control registers in TI Sitara processors. So I must have turned on the fpu compiler flag in the associated make files. It's been that way for a while now so I'll go back and fix it. Thank you for the hint. Bob Get Outlook for Android <https://aka.ms/ghei36> On Tue, Dec 6, 2016 at 4:41 AM -0500, "Stefan Kalkowski" <stefan.kalkowski@...1... <mailto:stefan.kalkowski@...1...>> wrote: Hi Rob, On 12/01/2016 11:08 PM, robjsstewart@...9... wrote: > Hi, > > I'm moving from 16.08 to 16.11. I had previously built and run my custom > os and apps successfully on releases since 14.xx. The kernel is base-hw > and the platform is based on TI's AM437x. > > Using the same make script that I used in 16.08, the script successfully > built all the components on 16.11 without error. However, in the last > stage, to build the boot image, it first failed with the error "unknown > platform no linker address known". I traced this to a new tool module, > tool/run/boot_dir/hw. Apparently this script requires that each unique > base-hw kernel platform have a table entry that contains the name used > for the platform plus an address which I assume is the load address for > the boot image. Is there a documentation update describing this new > feature in a bit more detail than the paragraph in the release notes? > Adding to the table the necessary entry and running the make script > again produced another error which has me stuck. The full make output is > attached but the error that is now occurring complains that modules have > been built for hardware floating point but the libgcc.a is not built to > using the vector floating point register arguments. The message output > for one of the libgcc.a modules is: > > /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/../../../../arm-none-eabi/bin/ld: > error: var/run/rico_fs.core uses VFP register arguments, > /opt/usr-local/genode-gcc/bin/../lib/gcc/arm-none-eabi/4.9.2/libgcc.a(_fixsfdi.o) > does not > > Since release 15.02 I've been compiling some of the modules with > floating point hardware flagged on, so rico_fs.core does indeed have VFP > register usage in it. So why is this error showing up now and not in > prior releases and how may I fix it? with the new release, we changed the way how the kernel/core gets linked: https://genode.org/documentation/release-notes/16.11#Unified_handling_of_boot_modules Therefore, if you changed the link/compile options for the core component, they do not necessarily apply to the final core linking in the new release. You could however extend the core linking step in the run tool (tool/run/run:713) with an additional argument for platform specific linker arguments that you specify for your platform within `tool/run/boot_dir/hw`, e.g., a function like 'core_link_opts'. In general, it is dangerous to use the FPU within core, because the kernel library is not designed to handle FPU usage of its own. Just out of curiosity, why do you need the FPU in core? Maybe you can get rid of FPU usage in core/kernel? Regards Stefan > > Thanks, > > Bob Stewart > > > Get Outlook for Android > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- Stefan Kalkowski Genode Labs https://github.com/skalk · http://genode.org/ ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main