Uclibc and blackfin

[Rob Landley]

On Friday 10 August 2007 4:38:49 pm Robin Getz wrote:
> 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.

I'm trying to fix it too, by automating building a working toolchain from 
source (and cross-compiling a working native development environment with 
that) in such a way it's not only trivial to do, but easy to understand if 
you can read a shell script.

But I'm not a gcc developer, for several reasons.

> > (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.

Woot.  I look forward to it.

> > >  - 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.

Crosstool has lots of version-specific patches, and was a bit too brittle for 
my states last time I looked at it.  (Which I did, and buildroot, before 
doing my own.)



> 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.

Hmmm, PIC is position independent code...

> 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

Timeout on server.  (Tried several times.)  Google found
http://www.lsd.ic.unicamp.br/~oliva/writeups/FR-V/FDPIC-ABI.txt
though...

That document never expands FDPIC but it has a section on "Function 
Descriptors".  Presumably it's Function Descriptor Position Independent Code.  
(Well It was bothering me.  Hey, congratulations, they've reinvented the 
lookup table.  That should make all the macintosh developers from the 
previous decade happy. :) 

Now if I just knew what FRV was.  (I've heard of it, but I'm not placing it 
and google is being unhelpful.  Wikipedia says it's a processor from Fujitsu, 
which seems unrelated?)

> > 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 :)

It means I'm not going to mess with it, nor recommend it to anyone, until such 
time as it's no longer such an obscure and uninteresting platform that the 
stock Linux tools (gcc, libc, kernel) don't support it.

I still have to finish getting m68k working (which I'm assured can be done 
from the stock tools), and now that qemu has Alpha support I want to get that 
up and running, and I still need to work around Open Firmware to get PPC 
booting in qemu.  (It builds, I just can't make it _run_ yet.)  Oh yeah, and 
that sparc bug may be fixed by now, gotta give that another try...

If there are patches against mainline that add blackfin support to the most 
recent release version of gcc, I'll happily test them.  But starting from a 
separate tarball is uninteresting.

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

I doubt the board I picked up at OLS will go stale in its little baggie. :)  
(It might get separated from its power supply, but it hasn't yet.)

> -Robin

Thanks for the documentation links,

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.