Re: 16.11 build fails on boot image creation

2016-12-09 Thread robjsstewart 


Thanks for following up on this, Stefan.


I'm not stuck with this issue as I found a way of hacking the base library 
builds to create hardware fp enabled object files while removing the use of 
hardware fp from the kernel. It does however require that all the components I 
create compile with hard fp...messy but it works. I'll use that approach for 
now as I have another issue going from 16.08 to 16.11 which is probably due to 
my poor design and lack thought on how RAM allocation works.


Bob


Get Outlook for Android






On Fri, Dec 9, 2016 at 7:12 AM -0500, "Stefan Kalkowski" 
 wrote:










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, robjsstew...@gmail.com 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@tegra-ubuntu:/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 
> 
> 
> 
> 
> On Tue, Dec 6, 2016 at 7:44 AM -0500,  > 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 
> 
> 
> 
> 
> On Tue, Dec 6, 2016 at 4:41 AM -0500, "Stefan Kalkowski"
>  > wrote:
> 
> Hi Rob,
> 
> On 12/01/2016 11:08 PM, robjsstew...@gmail.com 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.
>

Re: 16.11 build fails on boot image creation

2016-12-09 Thread Stefan Kalkowski 
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, robjsstew...@gmail.com 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@tegra-ubuntu:/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 
> 
> 
> 
> 
> On Tue, Dec 6, 2016 at 7:44 AM -0500,  > 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 
> 
> 
> 
> 
> On Tue, Dec 6, 2016 at 4:41 AM -0500, "Stefan Kalkowski"
>  > wrote:
> 
> Hi Rob,
> 
> On 12/01/2016 11:08 PM, robjsstew...@gmail.com 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

Re: 16.11 build fails on boot image creation

2016-12-06 Thread robjsstewart 


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@tegra-ubuntu:/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






On Tue, Dec 6, 2016 at 7:44 AM -0500,  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






On Tue, Dec 6, 2016 at 4:41 AM -0500, "Stefan Kalkowski" 
 wrote:










Hi Rob,

On 12/01/2016 11:08 PM, robjsstew...@gmail.com 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

Re: 16.11 build fails on boot image creation

2016-12-06 Thread robjsstewart 


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






On Tue, Dec 6, 2016 at 4:41 AM -0500, "Stefan Kalkowski" 
 wrote:










Hi Rob,

On 12/01/2016 11:08 PM, robjsstew...@gmail.com 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

Re: 16.11 build fails on boot image creation

2016-12-06 Thread Stefan Kalkowski 
Hi Rob,

On 12/01/2016 11:08 PM, robjsstew...@gmail.com 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

16.11 build fails on boot image creation

2016-12-01 Thread robjsstewart 


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?


Thanks,


Bob Stewart





Get Outlook for Android


bob@tegra-ubuntu:/Work/Genode/Builds/16.11/437x$ make run/rico_fs | tee 
build.log
including /Work/Genode/genode-16.11/tool/run/boot_dir/hw
including /Work/Genode/genode-16.11/tool/run/image/uboot
including /Work/Genobob@tegra-ubuntu:/Work/Genode/Builds/16.11/437x$ make 
run/rico_fs | tee build.log
including /Work/Genode/genode-16.11/tool/run/boot_dir/hw
including /Work/Genode/genode-16.11/tool/run/image/uboot
including /Work/Genode/genode-16.11/repos/os/run/rico_fs.run
building targets:  core init server/pin_mux_ctl server/shared_mem 
drivers/platform/spec/437x drivers/platform/spec/437x/client drivers/timer 
drivers/gpio/spec/437x drivers/pwm/spec/437x drivers/i2c/spec/437x 
drivers/uart/spec/437x drivers/sd_card/spec/437x drivers/pruss/spec/437x 
drivers/usb app/soc_leds server/ffat_fs server/report_rom app/motor_control 
app/ap_cli app/ap_sensors app/autopilot

spawn make core init server/pin_mux_ctl server/shared_mem 
drivers/platform/spec/437x drivers/platform/spec/437x/client drivers/timer 
drivers/gpio/spec/437x drivers/pwm/spec/437x drivers/i2c/spec/437x 
drivers/uart/spec/437x drivers/sd_card/spec/437x drivers/pruss/spec/437x 
drivers/usb app/soc_leds server/ffat_fs server/report_rom app/motor_control 
app/ap_cli app/ap_sensors app/autopilot
make[1]: Entering directory `/Work/Genode/Builds/16.11/437x'
checking library dependencies...
  Library platform
  Library cxx
  Library base-common
  Library syscall
  Library startup
  Library base
  Library config
  Library libc-string
  Library libc-locale
  Library libc-stdlib
  Library libc-stdio
  Library libc-gen
  Library libc-gdtoa
  Library libc-inet
  Library libc-stdtime
  Library libc-regex
  Library libc-compat
  Library libc-setjmp
  Library alarm
  Library timed_semaphore
  Library component_entry_point
  Library ldso-startup
  Library ld
  Library vfs
  Library libc
  Library libm
  Program app/ap_sensors/ap_sensors
  Library data_store
  Program app/autopilot/Autopilot
  Program app/motor_control/motor_ctl
  Program app/soc_leds/soc_leds
  Library core-perf_counter
  Library core
COMPILE  version.o
MERGEcore.lib.a
  Program core/core
  Program drivers/gpio/spec/437x/gpio_drv
  Program drivers/i2c/spec/437x/i2c_drv
  Program drivers/platform/spec/437x/client/437x_platform_client
  Program drivers/platform/spec/437x/platform_drv
  Program drivers/pruss/spec/437x/pruss_drv
  Program drivers/pwm/spec/437x/pwm_drv
  Program drivers/sd_card/spec/437x/sd_card_drv
  Library timeout
  Library timer
  Program drivers/timer/timer
  Program drivers/uart/spec/437x/uart_drv
  Library usb_include
  Library usb
  Program drivers/usb/usb_drv
  Program init/init
  Library ffat_block
  Program server/ffat_fs/ffat_fs
  Program server/pin_mux_ctl/ctrl_module
  Program server/report_rom/report_rom
  Program server/shared_mem/shared_memory
  Program app/ap_cli/ap_cli
make[1]: Leaving directory `/Work/Genode/Builds/16.11/437x'
genode build completed
/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
/