Uclibc and blackfin

Robin Getz rgetz at blackfin.uclinux.org
Fri Aug 10 21:38:49 UTC 2007


On Fri 10 Aug 2007 16:36, Rob Landley pondered:
> On Thursday 09 August 2007 8:19:02 pm Robin Getz wrote:
> > Why not use the toolchain/uClibc at blackfin.uclinux.org?
> >
> > https://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&pat
> >h=%2Ftrunk%2F
> 
> I'm my case I'm trying to build a dozen or so different platforms from the 
> same source code.  Needing to grab a different toolchain for a given platform 
> means that platform is broken.

broken for you - sure. But this type of thing is pretty common in the noMMU
world - it is not nice - but common :( We are trying to fix that.

> (Just FYI.  I poked you about this at OLS and you said it'd be six months 
> before all the various bits drifted upstream.  Hasn't been six months yet, 
> and I've been busy with documentation...)

We are working on this - but are just not quite there yet.

> >  - build multiple versions of uClibc
> 
> For flat and for non-flat?

There are a few versions that we build. The best way to understand things (if you care)
is to look at our buildscript - which at the end of the day - is why crosstool exists,
and why we maybe should have done it that way.

http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2Fbuildscript%2FBuildToolChain&revision=1754&view=markup

It boils down all the multi-lib support, plus functional differences to handle
issues in some older silicon (with bugs) this is for fdpic, and flat.
Our buildscript takes a _long_ time now.

It builds uClibc with/for:

bf532-none;@mcpu=bf532-none
bf532-0.3;@mcpu=bf532-0.3
mid-shared-library;@mid-shared-library
msep-data;@msep-data
mfdpic;@mfdpic
mid-shared-library/mleaf-id-shared-library;@mid-shared-library at mleaf-id-shared-library
bf532-none/mid-shared-library;@mcpu=bf532-none at mid-shared-library
bf532-none/msep-data;@mcpu=bf532-none at msep-data
bf532-none/mfdpic;@mcpu=bf532-none at mfdpic
bf532-none/mid-shared-library/mleaf-id-shared-library;@mcpu=bf532-none at mid-shared-library@mleaf-id-shared-library
bf532-0.3/mid-shared-library;@mcpu=bf532-0.3 at mid-shared-library
bf532-0.3/msep-data;@mcpu=bf532-0.3 at msep-data
bf532-0.3/mfdpic;@mcpu=bf532-0.3 at mfdpic
bf532-0.3/mid-shared-library/mleaf-id-shared-library;@mcpu=bf532-0.3 at mid-shared-library@mleaf-id-shared-library

Then it builds up the toolchain again - pointing gcc to the just built uClibcs.

> 
> >  - build bfin-uclinux- toolchain (for flat apps)
> >  - build bfin-linux-uclibc- toolchain (for fdpic)
> 
> Huh, I wonder what an fdpic is...  Probably not the Federal Data Protection 
> and Information Commissioner (first hit)...  Goggling for "fdpic blackfin" 
> has this as the first reasonable hit:
> 
> http://docs.blackfin.uclinux.org/doku.php?id=simple_hello_world_application_example_asm
> 
> Which uses it but isn't about it...

fdpic was orginally done for noMMU FRV, by Alexandre Oliva, and the nice folks 
at RedHAT - we just copied them.

Although it is listed on:
http://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels#Binary_format_support
it doesn't have it's own page, and I forget what it stands for. 

Alexandre decided (rightly so) that the limitations of flat files for noMMU suck, 
and fdpic is as close to elf as you can be, without running with virtual memory.
It provides Position Independent Code and Dynamic Shared Objects.

http://www.gtlib.gatech.edu/pub/redhat/gnupro/FRV/FDPIC-ABI.txt

http://docs.blackfin.uclinux.org/doku.php?id=:gcc_and_gas&s=fdpic%20stands#differences_between_blackfin_compilers
http://docs.blackfin.uclinux.org/doku.php?id=:elf_and_flat
http://docs.blackfin.uclinux.org/doku.php?id=:application_binary_interface#fdpic_run_time

> > > Does anybody have any pointers where I can find sources, patches or
> > > configs to get a uclibc build to complete?
> >
> > I do this daily with the sources from blackfin.uclinux.org - and don't have
> > a problem. What does the uClibc version there not support, that you want to
> > build your own with?
> 
> I continue to want to build multiple platforms from the same source.  If I 
> can't do that, the platform is not yet supported.  By definition.

Not yet supported by you is not equal to not supported by me :)

But - yes - I agree - we have heard similar things from other distribution
vendors who want to include our stuff, and are having a hard time. We are
working on getting it resolved. It is taking more time that anyone would like.

I was hoping on the end of this calendar year, but this is taking longer than
expected.

-Robin



More information about the uClibc mailing list