100 replies to this topic

[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...mapkernel/wiki/

Edited by javaJake, 17 November 2008 - 03:57 AM.

[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.

Edited by viridior, 17 November 2008 - 03:07 PM.

[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!)

Edited by javaJake, 17 November 2008 - 04:12 PM.

[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.

Edited by Laurencevde, 17 November 2008 - 09:31 PM.

[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 (-" 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 (-" 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.launchp...oo-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.

Edited by javaJake, 18 November 2008 - 12:46 PM.

[Yannick]

You can definitely help if you're running Gentoo!

That's because you rely on portage to do the cross-compilation right?
Hmz, I am on ubuntu atm. I guess I'll have to set-up a virtual machine to check this out.

[Laurencevde]

A chroot with gentoo in it is all you need. See http://www.gentoo.or.../x86/chroot.xml, but do take a look at the normal gentoo-install-manual as well. A "stage-3 tarball" contains a basic gentoo, and can be downloaded from gentoo's mirrors. You don't have a /usr/portage in ubuntu, and you won't want /usr/src/linux and /lib/modules in this chroot. Just leave those out. Do an "emerge --sync" once you're in the chroot(you won't be able to install packages without it), and you're basically done.

It might be a good idea to make a preconfigured one available as a download, so that new users can start out quickly.

Edited by Laurencevde, 18 November 2008 - 08:09 PM.

[javaJake]

Well right now everything is in flux so much it would be pretty pointless to prepare a pre-configured development environment. I'll certainly consider that later on, though. Thanks for the idea.

[viridior]

You can definitely help if you're running Gentoo!

That's because you rely on portage to do the cross-compilation right?
Hmz, I am on ubuntu atm. I guess I'll have to set-up a virtual machine to check this out.

Yannick, yes you will need to use Gentoo in order to work with our software and documentation. Thats not saying that what we work on in the project won't have applications in other OSes, but the tools such as crossdev are Gentoo specific.

There is already a reply on using chrooted Gentoo on a non-Gentoo system which will work. I am currently working on building binary paths and tools along with distcc so that we can easily and quickly deploy packages once the Pandora is out. We can use a lot of help just cross-compiling and testing the install documentation against the software. Someone with experience using cross-compiling specifically with ARM platforms would be excellent.

Edited by viridior, 20 November 2008 - 01:32 PM.

[Creature XL]

I havew setup GENTOO in a VirtualBox on a Windows PC (I am foircd to use windows at my GF's house ).

If anyone is interestedin getting the config file and image i can upload it somewhere.
It took me around an hour to follow a HowTo to build this image. Just in case someone don't want to go to teh hazel of making an image himself.
I will tryout teh new instruction from the gentoo-pandora project the next days (maybe tonite) if I succed this time the image would/should be useable to cross-compile stuff from the project