Any NON-OpenEmbedded based HowTos for GL and DSP?

I've been trying to get either the DSP bridge code OR the GLES code
running on a Beagleboard. However, every Howto I've found has always
assumed you are using OpenEmbedded.

I have tried numerous times to get OpenEmbedded working, and have
NEVER been able to conduct what I consider to be the basic test:
rebuild Angstrom from source and run it. I've come to the conclusion
that for what I want to do, I need to be able to cross-compile without
relying upon OpenEmbedded.

Trying to work out from OpenEmbedded magic spells^W^Wrecipes what you
need to do in any other environment makes my poor old head hurt.

Does anybody have a good Howto on integrating the DSP bridge code and
the GLES code that does NOT read like "Install OpenEmbedded. Wave dead
chicken over computer. Profit!"

I've been trying to get either the DSP bridge code OR the GLES code
running on a Beagleboard. However, every Howto I've found has always
assumed you are using OpenEmbedded.

I have tried numerous times to get OpenEmbedded working, and have
NEVER been able to conduct what I consider to be the basic test:
rebuild Angstrom from source and run it. I've come to the conclusion
that for what I want to do, I need to be able to cross-compile without
relying upon OpenEmbedded.

Something sounds funny, have you ever tried asking for help?

Philip

Repeatedly, and the experience left a very bad taste in my mouth WRT
OpenEmbedded. The people who responded focused upon minutia rather
than the real problem (OMFG U R UZING ENV VARIABLE), and even after I
had removed the minutia ("OK, here I am doing everything step by step
from the command line without that variable, and it still doesn't
work. Now what?") continued to focus upon it ("LAMER U CANT USE ENV
VAR!"). I was told "OMFG NOOB YOU R USING RELEASED NOT SVN
LUZER!" (paraphrasing the responses, but that really seemed to be the
attitude), and when I then pulled the SVN of BitBake as per their
suggestions it went from almost working to not working at all (as in
"BitBake segfaulting). When a software engineer of multiple decades,
who has been working with Linux since the 0.9* days, running under
Debian, targeting a supposedly well supported platform like
Beagleboard cannot even pull a nominally supported distribution like
Angstrom and build it successfully - that doesn't give me warm fuzzy
feelings about basing a critical project on OE. And when I ask
questions of the OE community, following every aspect of ESR's "How to
ask questions the smart way" - when I bend over backwards to test
every suggestion given to me, and to show every step of my work, and
to show that the suggestions aren't working, and eventually the
"support" trails off into crickets_chirp.wav - again, that leaves
rather a bad taste in my mouth. But I considered all of that to be "-1
offtopic" for *this* board.

It seems to me that, if this code is even remotely at the state it
should ideally be, it should be possible to have series of steps,
given only the assumptions of a binutils/GCC/glibc/Linux kernel build
environment and a glibc based runtime environment on the target, to
build and run the code.

Perhaps I am asking too much.

Hello!

[...]

I have tried numerous times to get OpenEmbedded working, and have
NEVER been able to conduct what I consider to be the basic test:
rebuild Angstrom from source and run it. I've come to the conclusion
that for what I want to do, I need to be able to cross-compile without
relying upon OpenEmbedded.

[...]

Would you be willing to give Poky a try?:
  http://elinux.org/BeagleBoard/Poky
  http://pokylinux.org/

Even though it is based on OpenEmbedded, it's really easy to build it.
I'd be glad to hear your comments.

Greetings!

Daniel Díaz
yosoy@danieldiaz.org

I'll try anything that might get me moving forward. (after my little
rant I'd be a damn hypocrite were I to refuse!)

I can even use this to bring up my new Rev C Beagleboard, in addition
to the Rev B board I have.

I'll try this with the Debian sarge base install, with the sarge
bitbake package and see what happens.

Have you considered following http://www.angstrom-distribution.org/building-ångström ?

Per the previous comment, using:
BitBake Build Tool Core version 1.8.10, bitbake version 1.8.10
Description: Debian GNU/Linux 5.0 (lenny)

and following the instructions as per http://elinux.org/BeagleBoard/Poky,
Quickstart, it fails due to my not having the toolchain where it
expects.

When I modify the $POKY/meta-texasinstruments/conf/distro/include/poky-
external-csl2008q3.inc to point to my toolchain (BTW: Suggestion:
parameterize the assumed prefix for the toolchain: mine is built to
the GNU standard of "arm-none-linux-gnueabi-"), I get the following
errors:

ddhagood@sage:..src/poky> source poky-init-build-env

### Shell environment set up for Poky builds. ###

ddhagood@sage:..poky/build> bitbake omap-image-min-gst
NOTE: Handling BitBake files: \ (1182/1182) [100 %]
NOTE: Parsing finished. 1120 cached, 0 parsed, 62 skipped, 0 masked.
NOTE: Cache is clean, not saving.
NOTE: build 200904061458: started

OE Build Configuration:
BB_VERSION = "1.8.11"
METADATA_REVISION = "5728"
TARGET_ARCH = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE = "beagleboard"
DISTRO = "tilinux"
DISTRO_VERSION = "0.1"
TARGET_FPU = "soft"

NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 3.18 of tiopenmax-core not available (for item
tiopenmax-core)
NOTE: preferred version 3.18 of tiopenmax-clock not available (for
item tiopenmax-clock)
NOTE: preferred version 3.18 of tiopenmax-perf not available (for item
tiopenmax-perf)
NOTE: preferred version 3.18 of tiopenmax-lcml not available (for item
tiopenmax-lcml)
NOTE: preferred version 3.18 of tiopenmax-policymanager not available
(for item tiopenmax-policymanager)
NOTE: preferred version 3.18 of tiopenmax-resourcemanager not
available (for item tiopenmax-resourcemanager)
NOTE: preferred version 3.18 of tiopenmax-audiomanager not available
(for item tiopenmax-audiomanager)
NOTE: preferred version 3.18 of tiopenmax-jpegdec not available (for
item tiopenmax-jpegdec)
NOTE: preferred version 3.18 of tiopenmax-jpegenc not available (for
item tiopenmax-jpegenc)
NOTE: preferred version
1.1.99.1+gitrd23aad31338e7d869d878d5aa1b6b91d20287005 of libx11-native
not available (for item libx11-native)
NOTE: preferred version 3.18 of tiopenmax-core not available (for item
tiopenmax-core)
NOTE: preferred version 3.18 of tiopenmax-clock not available (for
item tiopenmax-clock)
NOTE: preferred version 3.18 of tiopenmax-perf not available (for item
tiopenmax-perf)
NOTE: preferred version 3.18 of tiopenmax-lcml not available (for item
tiopenmax-lcml)
NOTE: preferred version 3.18 of tiopenmax-policymanager not available
(for item tiopenmax-policymanager)
NOTE: preferred version 3.18 of tiopenmax-resourcemanager not
available (for item tiopenmax-resourcemanager)
NOTE: preferred version 3.18 of tiopenmax-audiomanager not available
(for item tiopenmax-audiomanager)
NOTE: preferred version 3.18 of tiopenmax-jpegdec not available (for
item tiopenmax-jpegdec)
NOTE: preferred version 3.18 of tiopenmax-jpegenc not available (for
item tiopenmax-jpegenc)
NOTE: Preparing runqueue
NOTE: Executing runqueue
NOTE: Running task 63 of 2092 (ID: 243, /USER/src/poky/meta/packages/
libtool/libtool-native_2.2.6.bb, do_qa_configure)
NOTE: Running task 75 of 2092 (ID: 375, /USER/src/poky/meta-
texasinstruments/packages/meta/external-csl-toolchain_2008q3-72.bb,
do_install)
NOTE: Running task 78 of 2092 (ID: 292, /USER/src/poky/meta/packages/
zlib/zlib-native_1.2.3.bb, do_unpack)
NOTE: package libtool-native-2.2.6: started
NOTE: package libtool-native-2.2.6-r18: task do_qa_configure: started
NOTE: Checking sanity of the config.log file
NOTE: package external-csl-toolchain-2008q3-72: started
NOTE: Running task 80 of 2092 (ID: 1351, /USER/src/poky/meta/packages/
gdbm/gdbm-native_1.8.3.bb, do_setscene)
NOTE: package external-csl-toolchain-2008q3-72-r1: task do_install:
started
NOTE: package libtool-native-2.2.6-r18: task do_qa_configure:
completed
NOTE: package libtool-native-2.2.6: completed
NOTE: package zlib-native-1.2.3: started
NOTE: package zlib-native-1.2.3-r6: task do_unpack: started
NOTE: Unpacking /space/src/poky/sources/zlib-1.2.3.tar.bz2 to /space/
src/poky/build/tmp/work/i686-linux/zlib-native-1.2.3-r6/
NOTE: package gdbm-native-1.8.3: started
NOTE: package gdbm-native-1.8.3-r2: task do_setscene: started
NOTE: Running task 81 of 2092 (ID: 244, /USER/src/poky/meta/packages/
libtool/libtool-native_2.2.6.bb, do_compile)
ERROR: function do_install failed
ERROR: log data follows (/USER/src/poky/build/tmp/work/armv7a-none-
linux-gnueabi/external-csl-toolchain-2008q3-72-r1/temp/log.do_install.
26884)

EXTERNAL_TOOLCHAIN is /USER/tools/i686-linux-gnu/
cp: cannot stat `/USER/tools/i686-linux-gnu//arm-none-linux-gnueabi/

libc/lib/*': No such file or directory
NOTE: Task failed: /USER/src/poky/build/tmp/work/armv7a-none-linux-
gnueabi/external-csl-toolchain-2008q3-72-r1/temp/log.do_install.26884
NOTE: package external-csl-toolchain-2008q3-72-r1: task do_install:
failed
ERROR: TaskFailed event exception, aborting
NOTE: package external-csl-toolchain-2008q3-72: failed
ERROR: Build of /USER/src/poky/meta-texasinstruments/packages/meta/
external-csl-toolchain_2008q3-72.bb do_install failed
NOTE: package libtool-native-2.2.6: started
NOTE: package libtool-native-2.2.6-r18: task do_compile: started
NOTE: Checking if staging package installed
ERROR: Task 375 (/USER/src/poky/meta-texasinstruments/packages/meta/
external-csl-toolchain_2008q3-72.bb, do_install) failed
NOTE: Waiting for 3 active tasks to finish
NOTE: 1: /USER/src/poky/meta/packages/gdbm/gdbm-native_1.8.3.bb,
do_setscene (26888)
NOTE: 2: /USER/src/poky/meta/packages/libtool/libtool-native_2.2.6.bb,
do_compile (26897)
NOTE: 3: /USER/src/poky/meta/packages/zlib/zlib-native_1.2.3.bb,
do_unpack (26885)
NOTE: Unpacking /space/src/poky/meta/packages/zlib/files/
1.2.3.3.dfsg.patch.gz to /space/src/poky/build/tmp/work/i686-linux/
zlib-native-1.2.3-r6/
NOTE: No. Manually removing any installed files
NOTE: package zlib-native-1.2.3-r6: task do_unpack: completed
NOTE: package zlib-native-1.2.3: completed
NOTE: Waiting for 2 active tasks to finish
NOTE: 1: /USER/src/poky/meta/packages/gdbm/gdbm-native_1.8.3.bb,
do_setscene (26888)
NOTE: 2: /USER/src/poky/meta/packages/libtool/libtool-native_2.2.6.bb,
do_compile (26897)
NOTE: Checking if staging package installed
NOTE: No. Manually removing any installed files
NOTE: package gdbm-native-1.8.3-r2: task do_setscene: completed
NOTE: package gdbm-native-1.8.3: completed
NOTE: Waiting for 1 active tasks to finish
NOTE: 1: /USER/src/poky/meta/packages/libtool/libtool-native_2.2.6.bb,
do_compile (26897)
NOTE: package libtool-native-2.2.6-r18: task do_compile: completed
NOTE: package libtool-native-2.2.6: completed
NOTE: Tasks Summary: Attempted 77 tasks of which 76 didn't need to be
rerun and 1 failed.
ERROR: '/USER/src/poky/meta-texasinstruments/packages/meta/external-
csl-toolchain_2008q3-72.bb' failed
NOTE: build 200904061458: completed
ddhagood@sage:..poky/build>

Yes, and I had no luck getting it to work - and I've already detailed
what happened when I asked for help....

Hi,

I've been trying to do the same as David, mainly to get my hands on a
smaller version of linux, and got the same results: it chokes on the
toolchain part of the build. In my case though , I don't have any
toolchain installed (anyway, not any that I'm aware of).

Any thoughts about what can cause the problem?

Hello!

Hi,
I've been trying to do the same as David, mainly to get my hands on a
smaller version of linux, and got the same results: it chokes on the
toolchain part of the build. In my case though , I don't have any
toolchain installed (anyway, not any that I'm aware of).

Any thoughts about what can cause the problem?

Yes, you need a toolchain. If you follow
  http://elinux.org/BeagleBoard/Poky
one of the steps is to download CodeSourcery G++ Lite 2008q3-72.
Install it in /usr/local/csl/arm-2008q3/ and the rest of that wiki
should work.

Greetings!

Daniel Díaz
yosoy@danieldiaz.org

I have to call you out on that, since those instructions radically changed last week. So let me ask again:

Have you considered following http://www.angstrom-distribution.org/building-ångström ?

Hi,

I've been trying to do the same as David, mainly to get my hands on a
smaller version of linux, and got the same results: it chokes on the
toolchain part of the build. In my case though , I don't have any
toolchain installed (anyway, not any that I'm aware of).

Any thoughts about what can cause the problem?

I suspect more things can go wrong with the external toolchain based
OE builds. Try using the OE generated toolchians first, then moving to
the exxternal toolchains if needed.

And, like Koen notes, try the new Angstrom instructions.

Philip

I would love to see a how-to on GLES for Ubuntu and/or Maemo, but, in the meantime, maybe the SD card from http://specialcomp.com/beagleboard includes something working with the GLES code already? Can someone confirm?

It's not in the images sent to Bill at specialcomp since no-one is able to tell me if it's allowed to redistribute the GLES userspace that way. My interpretation of the license says yes, but I'm not a lawyer nor is English my first language.

regards,

Koen

No, I hadn't, because of the (non-)support I got when I was having
problems previously. There are 2 aspects to choosing an environment
for development of a long-term commercial project:
1) Does it work now?
2) In the future, if it stops working, how hard will it be to make it
work?

If the answer to #1 is "Yes" you might be tempted to skip checking the
answer to #2, but my experience is that #2 is the far more important
question. Given the poor responses I got the last time I *had* to
answer #2, and given that I don't have infinite time and resources, I
stopped considering Angstrom and OpenEmbedded as viable choices.

Now, perhaps the answer to #1 is now "Yes" - GREAT.

But has the answer to #2 changed since the last time? If I have
problems, if I bend over backwards to ask meaningful questions, will I
get meaningful answers or will I get more attitude?

Compare
  " I have to call you out on that...."
rather than
  "Well, we've put a lot of work into fixing that this last week -
maybe you should look again?"

I have to call you out on that, since those instructions radically
changed last week. So let me ask again:

Have you considered followinghttp://www.angstrom-distribution.org/building-ångström
  ?

No, I hadn't, because of the (non-)support I got when I was having
problems previously. There are 2 aspects to choosing an environment
for development of a long-term commercial project:
1) Does it work now?
2) In the future, if it stops working, how hard will it be to make it
work?

If the answer to #1 is "Yes" you might be tempted to skip checking the
answer to #2, but my experience is that #2 is the far more important
question. Given the poor responses I got the last time I *had* to
answer #2, and given that I don't have infinite time and resources, I
stopped considering Angstrom and OpenEmbedded as viable choices.

Now, perhaps the answer to #1 is now "Yes" - GREAT.

But has the answer to #2 changed since the last time? If I have
problems, if I bend over backwards to ask meaningful questions, will I
get meaningful answers or will I get more attitude?

Compare
" I have to call you out on that...."
rather than
"Well, we've put a lot of work into fixing that this last week -
maybe you should look again?"

Let us know what solution you end up selecting ...

Philip

Hello,

I have to call you out on that, since those instructions radically
changed last week. So let me ask again:

problems previously. There are 2 aspects to choosing an environment
for development of a long-term commercial project:
1) Does it work now?
2) In the future, if it stops working, how hard will it be to make it
work?

and in many cases:

3) Is it maintained
4) does it move forward?

The thing with OpenEmbedded (and this goes especially for the
development branch) is we are progressing it forward on a day-by-day*
basis while also trying to take care about 1) and 2), but they do
collide. * http://cgit.openembedded.net/cgit.cgi?url=openembedded/log/

Especially the Beagle Board get lots of love and attention on points 3
& 4) currently, which saves you a massive amount of work and you have
got to appreciate that.

Even if you decide to roll-your-own; please do so, you can still use
OpenEmbedded as a side-reference on how-to.

Points 1 and 2 have recently become more reliable if you decide to
stick with the Stable branch, which does not care about point 4 much.

Regards,

I wrote one (google: dsp howto) that is distribution-agnostic:
http://elinux.org/BeagleBoard/DSP_Howto

I just updated it with a new branch I pushed with DSS2 and latest
dsp-bridge patches.