(Re-)building firmare 1.60

[SvOlli]

Hi there,

I try to rebuild the firmware using bitbake, because I'm using it at work, so I'm accustomed to it, and I want to package some small tools I want to use on the OpenPandora properly.

Here's how what I've done so far as suggested on the SuperZaxxon 1.60 release thread:


# Clone the helper scripts for setting up the development environment
git clone https://github.com/openpandora/setup-scripts.git

# Enter the folder
cd setup-scripts

# Configure the scripts and download the build metadata:
MACHINE=openpandora ./oebb.sh config openpandora

# Source the environment file
. ./environment-angstrom-v2013.06

# Build the image
MACHINE=openpandora bitbake op-xfce-nm-image

The latter two calls are wrapped in a script to ensure that I've always the correct environment, as I'm using more than one OpenEmbedded/Bitbake environments.

Right now I'm stuck on two points.

1) the build does not complete, as X11 and Qt will not be build.

2) more important: bitbake tries to build Qt 4.8 as the SuperZaxxon firmware contains Qt 4.6

Qt was one of the main reasons, why I wanted to get this build in the first place, because I wanted to include the host tools, most notably "moc" to my cross compile toolchain, as the moc from my machine (also a 4.8) generates code that can't be compiled with Qt 4.6.

Any ideas?

 

[xekarfwtos]

Hi there,

I try to rebuild the firmware using bitbake, because I'm using it at work, so I'm accustomed to it, and I want to package some small tools I want to use on the OpenPandora properly.

Here's how what I've done so far as suggested on the SuperZaxxon 1.60 release thread:


# Clone the helper scripts for setting up the development environment
git clone https://github.com/openpandora/setup-scripts.git

# Enter the folder
cd setup-scripts

# Configure the scripts and download the build metadata:
MACHINE=openpandora ./oebb.sh config openpandora

# Source the environment file
. ./environment-angstrom-v2013.06

# Build the image
MACHINE=openpandora bitbake op-xfce-nm-image

The latter two calls are wrapped in a script to ensure that I've always the correct environment, as I'm using more than one OpenEmbedded/Bitbake environments.

Right now I'm stuck on two points.

1) the build does not complete, as X11 and Qt will not be build.

2) more important: bitbake tries to build Qt 4.8 as the SuperZaxxon firmware contains Qt 4.6

Qt was one of the main reasons, why I wanted to get this build in the first place, because I wanted to include the host tools, most notably "moc" to my cross compile toolchain, as the moc from my machine (also a 4.8) generates code that can't be compiled with Qt 4.6.

Any ideas?

You are using the master branch of the ".next development" repository, which will be the base for the next release.

Try the angstrom-v2012.12-yocto1.3 branch, which, I believe, is the base for the current release.

Keep in mind that I am totaly new here and maybe I have not understood the release plan/scheme/schedule correctly. Please anyone correct me if I am wrong.

 

[sebt3]

Qt was one of the main reasons, why I wanted to get this build in the first place, because I wanted to include the host tools, most notably "moc" to my cross compile toolchain, as the moc from my machine (also a 4.8) generates code that can't be compiled with Qt 4.6.

While cross-compiling you could use your host's moc. It works (well as long as you're using moc from the same QT release version)

 

[notaz]

The above stuff (including that angstrom-v2012.12-yocto1.3 branch) build the .next thing, to build SZ 1.60 you have to use http://git.openpandora.org/cgi-bin/gitweb.cgi , which has OE from around ~2009..

 

[aTc]

Trying to build the old firmware will give you even more problems.

A lot of the recipes want to download sources from places that don't exist anymore, and some just fail to build completely because of some fun dependency problems that crept in.

(i think it was something to do with recipes not beeing rebuilt when a recipe that they depend on got upgraded, so you get a few things that are left in an unbuildable state if they aren't compatible with the newer version)

Oh, and thanks for trying to build .next ... even though it wasn't what you wanted, any activity there is appreciated

 

[SvOlli]

*sigh*

Back to square one: where can I find documentation on how to build SZ 1.60? Wiki is at least outdated, if not completely wrong.

Using openpandora-oe-environment gives me the following:


DISTRO 'angstrom-2010.x' not found. Please set a valid DISTRO in your local.conf
Please set a valid MACHINE in your local.conf or environment

The missing archives shouldn't be _that_ much of a problem, since I've got a ~2010 for of OE at work, with all archives that we needed cached.

Is there anyone who I can ask directly? Like the one who built the SZ 1.60 images for release?

 

[aTc]

*sigh* indeed

If you can't even get that part going, just give up.

afaik there is currently only 1 place in the world where that firmware can be built, and that is on ED's server.

This isn't your "normal" OE tree, this is a badly hacked up, barely working disaster.

About the only way of building it from scratch would be to go backwards through all the commits untill you find a state where the tree would actually build, then work your way forwards again.

 

[aTc]

Actually, it's been quite a while since i even tried to build the old firmware, i'll see how far i'll get

 

[notaz]

It at starts for me, at least:

git clone git://git.openpandora.org/pandora-oe-environment.git
cd pandora-oe-environment/
sed -i -e 's/git.openembedded.net/git.openembedded.org/' initial-setup.sh # don't have commit rights to fix it..
. op-env-oe.sh
./initial-setup.sh
bitbake pandora-xfce-image

 

[aTc]

that's the easy bit, after that it starts to fail on m4, perl, intltool and a lot of fetches

currently waitng for the dsp crap to download from ti, the recipe can't download them, and ti has them stored on the slowest server on the planet behind a big "im not a terrorist" form you have to fill in

NOTE: Running task 2041 of 8609

getting closer though

 

[notaz]

I've hacked the mirror list to point to ED's server to deal with fetch breakage.

If you can send some hackspatches for m4 (and friends) breakage, I could merge them I guess.

 

[aTc]

I'm documenting all the fails and hacks to get past them, proper fixes will take a bit longer, but first i want to see what fails.

I do remember getting some serious problems later on, but then again, that was years ago and i'm slightly more familiar with oe now thanks to all the .next work.

 

[xekarfwtos]

Which head of the sgx.git repository is firmware 1.60 using?

 

[aTc]

it should be the nokia branch, but i can't find a reference to it in any of the recipes.. either i'm not looking hard enough, or it's manually built and extracted on top of the finished image by the magical tgz file.

edit:

make that magical tar.bz2 , and it seems it does get built outside of oe:

http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openpandora.oe.git;a=blob;f=recipes/linux/omap3-pandora-kernel2_3.2-pandora.bb;h=754b44b121c51c11ff4b798b6d4d4fb9e5b68c26;hb=HEAD

i told you this thing was a mess

 

[notaz]

It totally is.

 

[aTc]

Anyway, I did manage to build a working image, with a lot of hacking about.

I'm currently trying to find some nicer solutions for some things.

There are only a few major problems, mostly perl-native , squashfs-tools and some dsp related stuff, and the easy solution there is just to not have them in the image

attached is the list of failed fetches (at the top) and other fails+hacks

 

[xekarfwtos]

make that magical tar.bz2 , and it seems it does get built outside of oe: http://git.openpando...5b68c26;hb=HEAD i told you this thing was a mess

Could we get some information about that magical tar.bz2 in order to create proper recipe files for .next (which repositories were used as source for the kernel, the sgx modules, other modules, needed patches if available)?

Why does it contain all these different versions of the pvr modules?

 

[notaz]

Could we get some information about that magical tar.bz2 in order to create proper recipe files for .next (which repositories were used as source for the kernel, the sgx modules, other modules, needed patches if available)?

The tar is built from http://notaz.gp2x.de/misc/pnd/oe_rootfs_extra_modules.tar.bz2 sources, which are realtek vendor drivers and old TI dsplink stuff which are unused and can be dropped. It also includes c64_tools kernel module from http://tkscript.de/c64_tools/ sources. No patching of any kind is used.

Why does it contain all these different versions of the pvr modules?

Because all of them are broken, some work with some sets of games/emus, other work with others. The SGX driver pnd switches between these drivers, in addition to copying matching userspace blobs.

 

[aTc]

make that magical tar.bz2 , and it seems it does get built outside of oe: http://git.openpando...5b68c26;hb=HEAD i told you this thing was a mess

Could we get some information about that magical tar.bz2 in order to create proper recipe files for .next (which repositories were used as source for the kernel, the sgx modules, other modules, needed patches if available)?

Why does it contain all these different versions of the pvr modules?

.next already has all the proper recipes for most of that, it's the main reason the whole thing was started.

It avoids most of it by making the 3.2 kernel the default, and ignoring the 2.6 one.

 

[xekarfwtos]

Should we try the recipes for the sgx module from Angstrom's meta-ti?