Gentoo Linux

[Creature XL]

Took me a little bit to figure out how bzr works, hope this helps get you started
$mkdir -p /usr/local/build;cd /usr/local/build
$bzr whoami "John Doe <john.doe@gmail.com>"
$bzr branch lp:gentoo-arm-pandora

Once you have synced with the latest trunk branch you can check out the ./gentoo-arm-pandora/README for the guide to get you going. I have tried very hard to document every step I've taken along the way, if you see any discrepencies and/or get different results let me know and preferably add a bug on LaunchPad. javaJake made a nice little script ./gentoo-arm-pandora/bzr-update that we use to maintain our branches. ./gentoo-arm-pandora/docs/README should get you going for crossdev and base-system install. Please let me know if you have any problems... **ducks and hides**

I am not sure if we should talk it about her eor via PM. Maybe others have similar problems or know the solution

I want to say, that I am not new to programming and not new to LiNUX in generell. However, I am new to bazaar, gentoo and launchpad. My world is SVN/CVS and Fedora

I got that far that I setup a VirtualBox with a running gentoo and networking. From there I followed your instructions and even managed to do the edit of the package.keywords directory (hint: for a gentoo newbie it is not clear at first what shoiuld be done) I did NOT succedded in doing hte step with editing the unmask directoy!!! however, I don't get any mask-package-erros. I have done step 2 and 3 (LOL, check the docs for that joke!)

Step 4 gives m a headache. It is relaly simple: crossdev armv7a-softfloat-linux-gnueabi -P -v
I even read the embedded handbook you link to and understand what SHOULD happen there (to a degree at least) but I get this error:

CODE

>>> Unpacking gentoo-headers-base-2.6.27.tar.lzma to /var/tmp/cross/armv7a-softfloat-linux-gnueabi/portage/cross-armv7a-softfloat-linux-gnueabi/linux-headers-2.6.27-r2/work

LZMA 4.57 Copyright (c) 1999-2007 Igor Pavlov 2007-12-06

Error: Incorrect command


Usage: LZMA <e|d> inputFile outputFile [<switches>...]



The command which was issued is NOT given so it is hard for me to look for the problem


Hope to get some help from somebody

In the meantime I look to get the packages.unmaks thing working.


EDITFound the ebuild file. lzma is called with "lzma -dc" which is not a valid parameter. I checked on Fedora (they use still old lzma 4.32), -dc was valid back then

 

[viridior]

Took me a little bit to figure out how bzr works, hope this helps get you started
$mkdir -p /usr/local/build;cd /usr/local/build
$bzr whoami "John Doe <john.doe@gmail.com>"
$bzr branch lp:gentoo-arm-pandora

Once you have synced with the latest trunk branch you can check out the ./gentoo-arm-pandora/README for the guide to get you going. I have tried very hard to document every step I've taken along the way, if you see any discrepencies and/or get different results let me know and preferably add a bug on LaunchPad. javaJake made a nice little script ./gentoo-arm-pandora/bzr-update that we use to maintain our branches. ./gentoo-arm-pandora/docs/README should get you going for crossdev and base-system install. Please let me know if you have any problems... **ducks and hides**

I am not sure if we should talk it about her eor via PM. Maybe others have similar problems or know the solution

I want to say, that I am not new to programming and not new to LiNUX in generell. However, I am new to bazaar, gentoo and launchpad. My world is SVN/CVS and Fedora

I got that far that I setup a VirtualBox with a running gentoo and networking. From there I followed your instructions and even managed to do the edit of the package.keywords directory (hint: for a gentoo newbie it is not clear at first what shoiuld be done) I did NOT succedded in doing hte step with editing the unmask directoy!!! however, I don't get any mask-package-erros. I have done step 2 and 3 (LOL, check the docs for that joke!)

Step 4 gives m a headache. It is relaly simple: crossdev armv7a-softfloat-linux-gnueabi -P -v
I even read the embedded handbook you link to and understand what SHOULD happen there (to a degree at least) but I get this error:

CODE

>>> Unpacking gentoo-headers-base-2.6.27.tar.lzma to /var/tmp/cross/armv7a-softfloat-linux-gnueabi/portage/cross-armv7a-softfloat-linux-gnueabi/linux-headers-2.6.27-r2/work

LZMA 4.57 Copyright (c) 1999-2007 Igor Pavlov 2007-12-06

Error: Incorrect command


Usage: LZMA <e|d> inputFile outputFile [<switches>...]



The command which was issued is NOT given so it is hard for me to look for the problem


Hope to get some help from somebody

In the meantime I look to get the packages.unmaks thing working.


EDITFound the ebuild file. lzma is called with "lzma -dc" which is not a valid parameter. I checked on Fedora (they use still old lzma 4.32), -dc was valid back then


DISCLAIMER:
Let me dig through my documentation and see if I can explain what I have coherently. If I get you confused, its a mix of my lack of understanding and/or the topic itself which can be a little hard to understand!

NOTE: While I'm writing this response I am updating the docs in the bzr trunk, hopefully this will help everyone out. You should update your bzr branch now.

/etc/portage/package.unmask, /etc/portage/package.mask, /etc/portage/package.keywords can be files or directories, they should work either way. If you make them directories then you must make another file within those directories and input the appropriate items. i.e. $echo "sys-devel/crossdev-wrappers ~x86" >> /etc/portage/package.keywords/gentoo-arm-pandora

I'm not sure what the problem is with lzma, I didn't get that error, make sure with the new instructions under $BZR/docs/setting-up-environment.txt that you complete that first, prior to using $BZR/docs/base-software-install.txt

 

[ArchiMark]

Just wanted to chime in and say that I think that this project sounds great!

I've been using linux on several little mobile devices over the past few years; Zaurus SL-C3200/Debian/LXDE), Jornada 728/Debian, Aigo P8860/Midinux/XFCE, etc.

Mainly have experience with Debian distro, know the basics, but by no means an expert like others here...

This project sounds like a potentially very good learning opportunity to learn about Gentoo and thus more about linux....so, I hope that the project leaders will keep in mind those of us that are not familiar with installing Gentoo and provide some way (ie, instructions, etc...) that would allow people like me to try this out and learn without getting too frustrated, etc....

Thanks for your consideration.

 

[viridior]

Just wanted to chime in and say that I think that this project sounds great!

I've been using linux on several little mobile devices over the past few years; Zaurus SL-C3200/Debian/LXDE), Jornada 728/Debian, Aigo P8860/Midinux/XFCE, etc.

Mainly have experience with Debian distro, know the basics, but by no means an expert like others here...

This project sounds like a potentially very good learning opportunity to learn about Gentoo and thus more about linux....so, I hope that the project leaders will keep in mind those of us that are not familiar with installing Gentoo and provide some way (ie, instructions, etc...) that would allow people like me to try this out and learn without getting too frustrated, etc....

Thanks for your consideration.

ArchiMark, your enthusiasm makes the work I've done on this project worth it. My goal with the documentation is to give a step-by-step, no implied actions, on how to build a crossdev environment and compile your own Gentoo Pandora build image. As can be seen with my discussion with Creative XL, I do need to add some meat to the reasons and implications of each action, but for now I'm focused on making a working build.

I had a breakthrough last night and I may have most of the necessary stuff now to get a bootable armv7a-softfloat-linux-gnueabi, with a patched 2.6.28-r3 kernel to work. Without the kernel source, $du -lah outputs 60MB total. My next step is to start working with qemu-arm or some other software that supports a cortex-a8 and hardware as close to the pandora as possible to start testing this build. So far support software include; busybox, udhcp, dropbear, and some other low level programs. Please if anyone has some experience with qemu let me know, I have not used it before.

Eventually once the project devs get a optimized bootable boot-to-prompt image working, then there may be some work to fully support all of the hardware and getting x.org/kdrive to work. At this time that is not a goal, but a likely continuation of this project. Don't flood us with questions on this topic, we just haven't gotten that far yet, but we can always use help to get there.

 

[Creature XL]

just to let you know, I solved the problem with lzma.
I had two packages installed: lzma and lzma-utils.
The utils were an older version. So I deinstalled the lzma package and so the "lzma" of the lzma-utils package was used

 

[viridior]

Made even more progress in the last 2 days, have a patched 2.6.28 kernel with omap3/cortex-a8 support and added in the dsp bridge patch. Currently working on getting a kernel and image that will work on qemu so I can delve deeper into supporting the platform as soon as it gets out. Could use some people to start trying the cross-compiling to help refine the documentation.

 

[Creature XL]

Here I am again. But now I think it is a VirtualBox problem
While doing "crossdev blah -P v" I get a "Floating point exception" when LD wants to link the libgcc.

Due to the fact that LD shouldn't throw such an exception I guess it is the emulator (VirtualBox for Windows) which has problems and I have to wait till you get a QEMU with A8 support for Windows running and an image with the kernel and the gcc and friends

Or is it possible that you can give me a binary package for the crossdev --target arm-... ?

 

[Vorporeal]

A few points/questions:

Why -O2 instead of -O4 (as someone above posted)?

It's fine to be testing by compiling kernels, but I think it will be in our best interests to not compile our own kernels but to just use the "official" kernel, at least at the beginning. Once we get everything set up, we can update the source of the official kernel with the Gentoo patches and compile using their compile command (plus whatever further optimizations we feel necessary).

Finally, to all the people who feel Gentoo is unnecessary, it is just as Tinnus said - what makes it really good here is the ability to change the USE flags. We can compile in or leave out support for whatever we want in the software, allowing us to trim the size of our programs and customize the install exactly to our own personal "specifications".

 

[javaJake]

Hey guys, sorry for the slow responses. I've been extremely (and temporarily) busy for the last week.

Let me take this moment to thank viridior for pushing this project forward! While he claims he doesn't know much, he gets along just fine. In fact, he's done all of the work on this project since my last update.

I wouldn't recommend compiling on the Pandora; that would just take too much time. However, there's an option at /etc/make.conf you can set to package everything in some directory. That directory can then be shared/copied over network and be used as a binary repository. So you can cross-compile most (not all) ebuilds you need and offer them for public. [Edit: Not sure if that really was in make.conf but at least you can feed emerge the needed options on runtime.

I would like to know how you set that up. That would be perfect! It might mean folks won't have to deal with cross-compiling in the future, and will get a complete, unofficial Gentoo distribution with updates. B)

IMHO emulation doesn't make much sense unless you find a ready-to-run Pandora emulator supporting the exact same hardware as the current production batch.

Emulation was only meant to verify that the image could boot successfully. However, recent issues with compatibility mean we probably will have to skip QEMU altogether. This has yet to be discussed.

Why -O2 instead of -O4 (as someone above posted)?

No, no, no, we're definitely changing that to something like "-Os". :lol:

It's fine to be testing by compiling kernels, but I think it will be in our best interests to not compile our own kernels but to just use the "official" kernel, at least at the beginning. Once we get everything set up, we can update the source of the official kernel with the Gentoo patches and compile using their compile command (plus whatever further optimizations we feel necessary).

Yes, this certainly is an option. However, there are ready-to-go, up-to-date 2.6.28 kernel sources specifically patched for the OMAP3 all ready to go. Thanks to viridior, those are currently in our project's trunk. We'll probably use those first, so we can get off the ground to start.

 

[cb88]

also... one reason you would want to recompile your kernel is if you use a different toolchain from the one use to compile the "official" kerenel (which would be pretty likely on gentoo)

from what i understand there can be compatability problems (for modules etc...) and possibly instability

A course feel free to shoot me down on that if I'm wrong

 

[javaJake]

If there are problems, we'll have to deal with them when we find them. Unfortunately there is no alternative. I'm sure, though, incompatibilities are kept to a minimum - it's in their best interests.

Edit: For more information on the kernel: https://omapzoom.org/gf/project/omapkernel/wiki/

 

[viridior]

To expound a little on what javaJake responded with earlier...
The gentoo-arm-pandora project should be considered "alpha" and things are drastically changing on a daily basis until we can figure out the right fit for us. If you have an issue with a kernel, USE flag, CFLAG, etc, please let us know and don't be surprised if it shows up on the branch. Right now I and javaJake are the only main contributors and we are both fairly busy, so our attention unfortunately is fairly scattered. Our main focus is to get something that works, then tweak from there.

My justification for using Gentoo;
1. Easily modifiable package base, which I can incorporate a large library of software that SHOULD install seamlessly. I was able to insert a pandora patched kernel into the portage system with 30min worth of work and no previous knowledge. No use reinventing the wheel, or talking/searching ad nauseum for every person to figure out how to install and configure a new software package. This, again I believe, would be very beneficial to those of us that intend to modify or change the default hardware and/or software on the pandora platform. This also leads to a discussion of using distcc/rsync so that after a source is compiled we can share the binaries quickly and efficiently. I'm sure that portage already has built in variables to be able to change default directories so that compilation and temporary installation can be done on a common nfs mountpoint or a drive specifically used for large read-write use. (possibly using the 2nd SDHC slot for /tmp, /var/tmp, etc)
2. standard gnu-based toolchain, not that I have anything against codesourcery's toolchains, and it may worth looking into using that as an alternative in the future. But I am more confident on stability using something with many more users testing and fixing.
3. Incorporate new or different technologies quickly. My BRIEF look at the Angstrom system lead me to believe that the underlying system is mostly static and any fundamental change to the system would be problematic. While you can argue that any system could be in that category because if its vagueness, I find that, with Gentoo, changing the system baselayouts, initrd->initramfs, pam/no-pam, etc, etc has worked fairly well and only when I completely messed things up did it require a fresh install.

 

[javaJake]

Just to clarify what I said before, since I get the feeling people were confused by what I said: the kernel we've got is the best one there is, and there really is nothing else out there. Besides, I'm sure the little incompatibilities and whatnot are avoided as much as possible in the patches.



2008-11-17 (cross-compile environment stable enough)
At this point, I think we can consider the cross-compile environment we've created stable enough to work off of. We're now stepping forward by building the OMAP kernel and other essentials. (Thanks to viridior for getting a preliminary kernel configuration file set to go!)

 

[viridior]

Some more things to consider...

Based on some of the responses here, and on the forums, a large set-back I am having right now, is the lack of source-code or hardware data on the specifics of what will be shipped on the official MK2 board. Not saying that some headway has been made to mitigate those problems, but I suspect that we can get an operational image that will work with the pandora. It will likely need to be further tested and tweaked to maximize efficiency after the official platform is out.

I am greatly encouraged by some other projects that are also being actively developed for the pandora. I think that it is highly possible that we can develop (when necessary) a separate overlay system for portage (I'm thinking something like layman) that we in the community can use to get the latest, cutting edge, software from our community. This should be as simple as syncing the portage libraries and updating your global software. OPENGL ES 2.0 wrappers possibly?, patched media players with NEON support?, games/emulators that have been tailored to work on the Pandora?, all good ideas that could be fairly easy to implement but will require interest and time from the community. Please let me know what y'all think.

Lastly, (for this post)
Being able to change CFLAGS, kernel options, toolchains, and desired software at a very low-level is what makes Gentoo appealing to those that use it. I'm not saying that there doesn't need to be some commonality and congruency, but with this project the hope is that we can provide the documentation and best practices so others can make their own decisions on what is best for them, and use our guide accordingly.

 

[laurencevde]

If you set it up properly, all compilation can be done on you main PC(s), with no need to have an entire build-chain on the Pandora.
You can tell portage to install to another root/install with the ROOT=... -variable. Gentoo has split up build-time and run-time dependencies, build-time deps will be installed in the current install, while run-time dependencies will be installed to wherever ROOT points to. You also have a PORTAGE_CONFIGROOT -variable, so that you can keep the portage-config for the target-system and your build-system separate.
You also have the emerge-option "--buildpkg (-b)" to build a binary package of whatever you build, and you have the options "--usepkgonly (-K)", "--usepkg (-k)", "--getbinpkg (-g)", and "--getbinpkgonly (-G)" to install those packages(respectively: only use bin-packages, allow non-bin-packages, get bin-packages from a server, and get them from a server exclusively). Build-time-only dependencies won't be included for installing binary packages.
Default emerge-options can be set with the If you set it up properly, all compilation can be done on you main PC(s), with no need to have an entire build-chain on the Pandora.
You can tell portage to install to another root/install with the ROOT=... -variable. Gentoo has split up build-time and run-time dependencies, build-time deps will be installed in the current install, while run-time dependencies will be installed to wherever ROOT points to. You also have a PORTAGE_CONFIGROOT -variable, so that you can keep the portage-config for the target-system and your build-system separate.
You also have the emerge-option "--buildpkg (-b)" to build a binary package of whatever you build, and you have the options "--usepkgonly (-K)", "--usepkg (-k)", "--getbinpkg (-g)", and "--getbinpkgonly (-G)" to install those packages(respectively: only use bin-packages, allow non-bin-packages, get bin-packages from a server, and get them from a server exclusively). Build-time-only dependencies won't be included for installing binary packages.
Default emerge-options can be set with the "EMERGE_DEFAULT_OPTS"-option which can be set in make.conf.

See the man-pages of emerge, portage, and make.conf for more info.

So, you can make a gentoo-cross-compile-toolchain(preferably in a chroot, makes it easy to distribute as well), that compiles everything to a separate location, and makes binary packages from it, and install those binary packages on the pandora. You won't need gcc etc. on the pandora, and, with the "-K"-option, you won't even need a portage-tree, which takes up several 100MB, or ~50MB compressed.

Going further, you can then create a preconfigured image for the pandora, that uses a repository full of those binary packages. Users that want to roll their own packages can do so as well. Gentoo's repository is huge, and as such, this makes it easy to provide a large amount of packages.

 

[viridior]

If you set it up properly, all compilation can be done on you main PC(s), with no need to have an entire build-chain on the Pandora.
You can tell portage to install to another root/install with the ROOT=... -variable. Gentoo has split up build-time and run-time dependencies, build-time deps will be installed in the current install, while run-time dependencies will be installed to wherever ROOT points to. You also have a PORTAGE_CONFIGROOT -variable, so that you can keep the portage-config for the target-system and your build-system separate.
You also have the emerge-option "--buildpkg (-B)" to build a binary package of whatever you build, and you have the options "--usepkgonly (-K)", "--usepkg (-k)", "--getbinpkg (-g)", and "--getbinpkgonly (-G)" to install those packages(respectively: only use bin-packages, allow non-bin-packages, get bin-packages from a server, and get them from a server exclusively). Build-time-only dependencies won't be included for installing binary packages.
Default emerge-options can be set with the If you set it up properly, all compilation can be done on you main PC(s), with no need to have an entire build-chain on the Pandora.
You can tell portage to install to another root/install with the ROOT=... -variable. Gentoo has split up build-time and run-time dependencies, build-time deps will be installed in the current install, while run-time dependencies will be installed to wherever ROOT points to. You also have a PORTAGE_CONFIGROOT -variable, so that you can keep the portage-config for the target-system and your build-system separate.
You also have the emerge-option "--buildpkg (-B)" to build a binary package of whatever you build, and you have the options "--usepkgonly (-K)", "--usepkg (-k)", "--getbinpkg (-g)", and "--getbinpkgonly (-G)" to install those packages(respectively: only use bin-packages, allow non-bin-packages, get bin-packages from a server, and get them from a server exclusively). Build-time-only dependencies won't be included for installing binary packages.
Default emerge-options can be set with the "EMERGE_DEFAULT_OPTS"-option which can be set in make.conf.

See the man-pages of emerge, portage, and make.conf for more info.

So, you can make a gentoo-cross-compile-toolchain(preferably in a chroot, makes it easy to distribute as well), that compiles everything to a separate location, and makes binary packages from it, and install those binary packages on the pandora. You won't need gcc etc. on the pandora, and, with the "-K"-option, you won't even need a portage-tree, which takes up several 100MB, or ~50MB compressed.

Going further, you can then create a preconfigured image for the pandora, that uses a repository full of those binary packages. Users that want to roll their own packages can do so as well. Gentoo's repository is huge, and as such, this makes it easy to provide a large amount of packages.

You have basically described our entire system. Lets me know we are on the right track. Are you interested in doing some testing?

 

[laurencevde]

Oh, ok, nice Didn't take the time to get your code, but some comments here led me to believe you were going to compile on the pandora.
I might do some testing (or more) when I find the time, but that'll probably only be when I've got a pandora, and I was too late for the first batch I did set this up once, for an x86-based mini-pc, using uClibc(sold as thin-client, used as AP).
One more question: are you using glibc or uClibc? It's a not-unimportant decision to make, and it's best to do it early...

 

[javaJake]

glibc for sure. uClibc is really all about size over compatibility, and on the Pandora size hardly matters.

 

[Vorporeal]

BTW guys - I'm up for helping out with all of this (testing and development). I'll be more into it when I get my Pandora though - I've got a month off for winter break from December 20th to January 21st. Not much time before then, as the semester is winding down and here at Brown they pile the work on, especially towards the end of the semester.

 

[javaJake]

BTW guys - I'm up for helping out with all of this (testing and development). I'll be more into it when I get my Pandora though - I've got a month off for winter break from December 20th to January 21st. Not much time before then, as the semester is winding down and here at Brown they pile the work on, especially towards the end of the semester.

You can definitely help if you're running Gentoo! Just check out the latest revision from "trunk" and follow the instructions. If you find any bugs or you get any errors, report them here:
https://bugs.launchpad.net/gentoo-arm-pandora/

Also, if you see any bugs that are still in "New" status, see if you can reproduce the bug yourself, and report how you did so. This way we can move the bug into "Confirmed" status and work on a patch/fix.