OSD: build closed-source code with my toolchain

[Gerry Boland]

Hi all,

I've not been working much recently, and so have been playing with the idea of a custom firmware for the OSD. 

I've managed to build a working toolchain (gcc4.4, hoping for speed improvements) and booting kernel (nothing 

new, same old version) and various command-line apps, all on the buildroot[1] framework. Nothing exciting however.

I'd like to get the core OSD functionality going, and this is where I need help. All the core stuff is closed source,

and mixing stuff compiled with old and new toolchain won't work - especially as old toolchain is glibc based, and my

new one is uclibc.

Is there any way of getting the closed stuff compiled with my new toolchain? I would do it myself, but I don't want 

to sign an NDA!

Any ideas/suggestions?

-Gerry (greyback)

[1] http://buildroot.uclibc.org

[Ugo Riboni]

> All the core stuff is closed source,
> and mixing stuff compiled with old and new toolchain won't work - especially
> as old toolchain is glibc based, and my
> new one is uclibc.
> Is there any way of getting the closed stuff compiled with my new toolchain?

Hey Gerry,
What is the closed source "core stuff " that you're referring to, exactly ?
The kernel modules for the media stuff ?
I doubt you can manage to make them work without having the source and
actually rebuilding them.
But I haven't been touching that stuff since ages, so I may be wrong.
Cheers,
--
nero

[Gerry Boland]

Yep, was a bit vague there, sorry.

There are 2 types of closed-source blobs AFAIK:

- kernel modules - in neuros-bsp/kernels/kos_64M (presumably incorporating the DSP code)

- arm-side libraries - in linux-r3-plugins/av/lib

I'm not worried about the kernel modules, I believe they work ok as kernel isn't changed, and libc irrelevant there.

But the libs are dependent on the compiler used, as they use Cooler and glibc..

In theory, I could supply the old toolchain's libc and precompiled Cooler library (but not sure how pthreads will work either) so that nms will work, but then things will get horribly confusing. I do doubt this will work too, hence my email.

-G

[Vladimir Pantelic]

Gerry Boland wrote:
> Hi all,
> I've not been working much recently, and so have been playing with the idea of a custom firmware for the OSD.
> I've managed to build a working toolchain (gcc4.4, hoping for speed improvements) and booting kernel (nothing
> new, same old version) and various command-line apps, all on the buildroot[1] framework. Nothing exciting however.
>
> I'd like to get the core OSD functionality going, and this is where I need help. All the core stuff is closed source,
> and mixing stuff compiled with old and new toolchain won't work - especially as old toolchain is glibc based, and my
> new one is uclibc.

so why not use glibc for your new toolchain too?

[Gerry Boland]

On 5 April 2011 06:51, Vladimir Pantelic <vlad...@gmail.com> wrote:

so why not use glibc for your new toolchain too?

Because glibc is big compared to uclibc, and I wanted to keep the firmware small.

-G

[Vladimir Pantelic]

Gerry Boland wrote:

> On 5 April 2011 06:51, Vladimir Pantelic <vlad...@gmail.com <mailto:vlad...@gmail.com>> wrote:
>
>
> so why not use glibc for your new toolchain too?
>
>
> Because glibc is big compared to uclibc, and I wanted to keep the firmware small.

Then you need to ask Ingenient to recompile the DM320 arm libs
for a different toolchain, but I doubt they will. If they even
remember the DM320 :)

[Ugo Riboni]

>>    so why not use glibc for your new toolchain too?
>>
>>
>> Because glibc is big compared to uclibc, and I wanted to keep the firmware
>> small.
>
> Then you need to ask Ingenient to recompile the DM320 arm libs
> for a different toolchain, but I doubt they will. If they even
> remember the DM320 :)

Perhaps someone with access to the original source (ex-Neuros or
someone who signed an NDA with them some time ago) can rebuild them
with your toolchain/build system and put the binaries somewhere.
Not sure (a) if we have all the sources needed and (b) how complicated
that will be, but it may be worth a shot. Maybe.
--
nero

[Gerry Boland]

On 5 April 2011 13:04, Ugo Riboni <neroc...@gmail.com> wrote:

> Then you need to ask Ingenient to recompile the DM320 arm libs
> for a different toolchain, but I doubt they will. If they even
> remember the DM320 :)

Perhaps someone with access to the original source (ex-Neuros or
someone who signed an NDA with them some time ago) can rebuild them
with your toolchain/build system and put the binaries somewhere.
Not sure (a) if we have all the sources needed and (b) how complicated
that will be, but it may be worth a shot. Maybe.

I know it's a long shot, but I thought I'd try and ask. Before trying to work around the restrictions the closed source stuff gives.

-G

[bmc]

Gerry,

I considered doing this briefly, while building OSDng.

A big win would be that by rebuilding the everything, you could have
the OSD run new EABI binaries. Then OSD and OSD2 could both run
identical executables and share packages.

It looked to be a bit of work (some kernel assembly patches,
rebuilding most everything I had source for, and writing compatibility
shims for the stuff I didn't have source for).

Doable, but a bit much to bite off when I was just doing a quick
project, and I'd break compatibility with everyone else.

I ended up just building OSDng on the old ABI and libraries that
existed. And pulled the stuff I needed from Debian, from an old
enough debian release that it was still using OABI.

For what you're considering, you could consider running it with the
old ABI flag for your toolchain, and you might find that everything
else continues to work.

A brief summary of OABI vs EABI: http://wiki.debian.org/ArmEabiPort

[Gerry Boland]

Hey bmc

my new toolchain is using EABI. That was one of my main goals. It did take a little work to get Neuros' 2.6.15 kernel working with this, but I think I've it sorted. I build kernel with OABI support too.

Right now, I'm experimenting with building a toolchain with Eglibc, as it claims to keep ABI compatibility with glibc. Perhaps I'll work in compatibility with closed-source stuff that way. Not had success building it so far, the old kernel does cause problems. Glibc adds well over 0.5MB, which I simply don't want to give away.

I would be interested in what you did to allow one to install Debian packages. I think that'd be great to add in. I did look into using EmDebian, instead went for the system I found most obvious instead: buildroot.

-G

 

--
FOR REALTIME DISCUSSION GO TO IRC #neuros on freenode

You received this message because you are subscribed to the "Neuros" group.
To post to this group, send email to Neu...@googlegroups.com
To unsubscribe from this group, send email to Neuros-un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/Neuros