Blackfin support

Blackfin support

[Tom Rini]

Hey all.  Has anyone built any of the blackfin boards recently?  I'm
finding things like uClibc 0.9.29+ require -mfdpic which isn't in our
gcc 4.1.x, is in gcc 4.2.x (but requires a patch to define __FDPIC__
rather than __BFIN_FDPIC__) and other issues still.  Just seeing if
anyone else has these things working before I start getting down and
dirty.  Thanks!

-- 
Tom Rini

Re: Blackfin support

[Koen Kooi]

On 09-01-09 16:52, Tom Rini wrote:
> Hey all.  Has anyone built any of the blackfin boards recently?  I'm
> finding things like uClibc 0.9.29+ require -mfdpic which isn't in our
> gcc 4.1.x, is in gcc 4.2.x (but requires a patch to define __FDPIC__
> rather than __BFIN_FDPIC__) and other issues still.  Just seeing if
> anyone else has these things working before I start getting down and
> dirty.  Thanks!

I keep starting anew with blackfin support due to the current problems:

* ADI uses their own 'distro', the rest of the world a custom buildroot
* You need to get gcc from blackfin SVN to get something to compile
* you need to choose either uclibc from blackfin svn or upstream uclibc

When you get to the point of building uclibc, the fun starts, since 
uclinux (not uclibc) has no proper shared library support, so you have 
to choose an emulation method (fdpic being one of the options).
 From that point on it's downhill, since various parts of uclibc have 
fork() in their code, gcc will ICE on other parts, etc.

My latest attempt was:

http://dominion.thruhere.net/koen/cms/blackfin-toolchain-progress

I still have the board, so if you make some progress I can test it :)

regards,

Koen

Re: Blackfin support

[Tom Rini]

On Fri, Jan 09, 2009 at 05:22:43PM +0100, Koen Kooi wrote:
> On 09-01-09 16:52, Tom Rini wrote:
>> Hey all.  Has anyone built any of the blackfin boards recently?  I'm
>> finding things like uClibc 0.9.29+ require -mfdpic which isn't in our
>> gcc 4.1.x, is in gcc 4.2.x (but requires a patch to define __FDPIC__
>> rather than __BFIN_FDPIC__) and other issues still.  Just seeing if
>> anyone else has these things working before I start getting down and
>> dirty.  Thanks!
>
> I keep starting anew with blackfin support due to the current problems:
>
> * ADI uses their own 'distro', the rest of the world a custom buildroot
> * You need to get gcc from blackfin SVN to get something to compile
> * you need to choose either uclibc from blackfin svn or upstream uclibc

Oh joy of joys.  Would it be a problem to import the ADI magic versions
of thing (and SRC_URI_append_bfin) ?

-- 
Tom Rini

Re: Blackfin support

[Koen Kooi]

On 09-01-09 19:35, Tom Rini wrote:
> On Fri, Jan 09, 2009 at 05:22:43PM +0100, Koen Kooi wrote:
>> On 09-01-09 16:52, Tom Rini wrote:
>>> Hey all.  Has anyone built any of the blackfin boards recently?  I'm
>>> finding things like uClibc 0.9.29+ require -mfdpic which isn't in our
>>> gcc 4.1.x, is in gcc 4.2.x (but requires a patch to define __FDPIC__
>>> rather than __BFIN_FDPIC__) and other issues still.  Just seeing if
>>> anyone else has these things working before I start getting down and
>>> dirty.  Thanks!
>> I keep starting anew with blackfin support due to the current problems:
>>
>> * ADI uses their own 'distro', the rest of the world a custom buildroot
>> * You need to get gcc from blackfin SVN to get something to compile
>> * you need to choose either uclibc from blackfin svn or upstream uclibc
>
> Oh joy of joys.  Would it be a problem to import the ADI magic versions
> of thing (and SRC_URI_append_bfin) ?

Not at all, my local diff for that got blown away during the git 
transition, but it's a one liner for gcc_4.<something>.inc where you 
override SRC_URI to point to svn://bf.ucl.org
I hope you get the semi-shared lib thing to work, since that's what 
would be usefull for OE, but I can see the use for static binaries.
Did Richard merge his darwin stuff yet that allows shared libs to have 
custom extensions (.e.g .dylib for OSX)? That would make this a bit 
easier to handle.

regards,

Koen

Re: Blackfin support

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

On Friday 09 January 2009 11:22:43 Koen Kooi wrote:
> On 09-01-09 16:52, Tom Rini wrote:
> > Hey all.  Has anyone built any of the blackfin boards recently?  I'm
> > finding things like uClibc 0.9.29+ require -mfdpic which isn't in our
> > gcc 4.1.x, is in gcc 4.2.x (but requires a patch to define __FDPIC__
> > rather than __BFIN_FDPIC__) and other issues still.  Just seeing if
> > anyone else has these things working before I start getting down and
> > dirty.

the FDPIC change is already in mainline gcc and has been for a while

> I keep starting anew with blackfin support due to the current problems:

let's fix this wrong info shall we ...

> * ADI uses their own 'distro', the rest of the world a custom buildroot

actually it's the uClinux distribution that has been around longer than 
buildroot

> * You need to get gcc from blackfin SVN to get something to compile
> * you need to choose either uclibc from blackfin svn or upstream uclibc

things are pushed to the relevant upstream projects, but it's not our fault 
development occurs faster on our side than upstream can make releases

either way, prebuilt toolchains are always available so people need not build 
it up themselves:
http://blackfin.uclinux.org/gf/project/toolchain/frs

> When you get to the point of building uclibc, the fun starts, since
> uclinux (not uclibc) has no proper shared library support

shockingly incorrect.  FDPIC ELF is 100% complete and exactly the same as ELF 
on your desktop.  there is no difference at all from a C API or GNU linker 
perspective.

> so you have to choose an emulation method (fdpic being one of the options).

i have no idea how you're using the term "emulation", but file formats are not 
"emulation methods".  they're file formats.  perhaps try reading this 
documentation:
http://docs.blackfin.uclinux.org/doku.php?id=toolchain:executable_file_formats

>  From that point on it's downhill, since various parts of uclibc have
> fork() in their code

sounds like you didnt configure uClibc properly

> gcc will ICE on other parts, etc.

gcc ICEs on our side a rare and always get fixed quickly.  if you're 
indirectly suggesting the Blackfin gcc port is immature or crap, that is 
absolutely not the case.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: Blackfin support

[Dmitry Eremin-Solenikov]

Mike Frysinger wrote:

> On Friday 09 January 2009 11:22:43 Koen Kooi wrote:
>> On 09-01-09 16:52, Tom Rini wrote:
>> > Hey all.  Has anyone built any of the blackfin boards recently?  I'm
>> > finding things like uClibc 0.9.29+ require -mfdpic which isn't in our
>> > gcc 4.1.x, is in gcc 4.2.x (but requires a patch to define __FDPIC__
>> > rather than __BFIN_FDPIC__) and other issues still.  Just seeing if
>> > anyone else has these things working before I start getting down and
>> > dirty.
> 
> the FDPIC change is already in mainline gcc and has been for a while
> 
>> I keep starting anew with blackfin support due to the current problems:
> 
> let's fix this wrong info shall we ...

I've started preparing update for bfin in OE. However I'm currently a bit stuck
due to the lack of time. I've pushed parts of it to the shared/blackfin branch.

Anybody is free to update/comment/fix, etc.

One of the problems I'm still facing is the lack of real fork() (i.e. not the
one from uClibc STUBS).

-- 
With best wishes
Dmitry