16.11 build fails on boot image creation

[Stefan Kalkowski]

Hi Rob,

On 12/01/2016 11:08 PM, robjsstewart at ...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 <https://aka.ms/ghei36>
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

https://github.com/skalk · http://genode.org/