Gentoo Linux - Taking it On!


I apologize for the confusion with the gentoo-wiki site, I've been using it mostly as data collection point until I can make a coherent gentoo pandora build. My immediate intention is to get a build going that will get us to a minimal install, supporting all the hardware,with a command prompt. Afterwards I will be focusing on additional packaging such as an Xorg/Kdrive build, etc, etc. The reason that I put all of the formating options on the site is due to the two ways to use gentoo on the openpandora, you can either install your own build on an external SDHC or replace the OS on the internal one. While I'm initially going for the first option, with an external SDHC, my overall goal is to put a lean, fast, and optimized gentoo build on the internal 256MB.
 
I understand, but I'm confused as to why you go into expert mode and do all of the highly specified formatting for the SD card instead of just using a general tool to format (or using fdisk without the expert mode crazies).
 
viridior said:
For those of you that would like to become actively envolved, or just provide encouragement or insight, please talk to us on IRC @ FreeNode #gentoo-pandora

viridior, your contributions are much appreciated. However, I am unable to idle on IRC effectively, and only pop on for questions or a few minutes of chat on #gentoo-embedded (the official Gentoo Embedded room with some top-notch folks), #pandoradev, or a few others.

<mind dump>I will also be 100% honest that I am jealous for this project that I feel like I have started. However, I know that this is all open-source, and I guess it should be OK if someone else paves the path ahead of me (especially if they have more time than I do).</mind dump> :p



viridior said:
I've already started a gentoo-wiki @ http://www.gentoo-wiki.com/OpenPandora

Before anyone reads this, please be forewarned that I have already found bugs in the scripts that the Embedded group suggests for use. Also, I don't recommend such a complicated tree structure. It should be simple: /usr/arm-xxx-xxx-xxx/... is the developer root, and then you can pick whatever for the runtime (completed results) root.

I will be posting working, tested instructions as I find them, here in this thread.

In fact, I'd go as far as to ask that the Wiki page's contents be mostly removed until they've been tested and proven to work on the Pandora, or otherwise provide notes that say "these are ideas" or something like that. A lot of the commands and such up there are either obvious and brittle to the terminal-experienced, or will produce messy results for the terminal-unexperienced who punch them in in order.

I might run through and do some cleaning myself later.

I want to point out, before I submit this post, that I'm not trying to stifle contributions. There are links on the wiki I didn't know about, and some really nice gcc options up there. Let's just not rush into this. :)



viridior said:
I apologize for the confusion with the gentoo-wiki site, I've been using it mostly as data collection point until I can make a coherent gentoo pandora build. My immediate intention is to get a build going that will get us to a minimal install, supporting all the hardware,with a command prompt. Afterwards I will be focusing on additional packaging such as an Xorg/Kdrive build, etc, etc. The reason that I put all of the formating options on the site is due to the two ways to use gentoo on the openpandora, you can either install your own build on an external SDHC or replace the OS on the internal one. While I'm initially going for the first option, with an external SDHC, my overall goal is to put a lean, fast, and optimized gentoo build on the internal 256MB.

Please keep in mind that the clean .7z archive I want to make in the end should contain a standard minimal install with as few customizations as possible! Even stripping USE flags should be done only if 90% desirable for everyone.

There should only be one .7z archive - there should be no difference between internal and external. That'd create some maintenance nightmares. :p

This doesn't mean that we can't have a lean, fast, optimized Gentoo, though. How lean that should be to meet the majority requirements is what remains to be seen. :)
 
I think it would be a must to at least add an X-server and perhaps even a simple graphical interface.
 
Etinin said:
I think it would be a must to at least add an X-server and perhaps even a simple graphical interface.

By the user? Yes, absolutely. Included in the image? No

The image should start at the ground, and leave it to the user to take off. That's how Gentoo works. :)
 
Well, there have to be at least easy instructions on how to configure distcc (or perhaps we could cross-compile), because nobody will want to compile big stuff like Firefox on a 600~900MHz CPU, that'd take literally days without using your Pandora.

EDIT: Actually, I think cross-compilation is a better idea, so I can at least use my Pandora while my Core 2 Quad does the job. Crossdev makes it easy for us to emerge cross compilers at least.
 
Etinin said:
Well, there have to be at least easy instructions on how to configure distcc (or perhaps we could cross-compile), because nobody will want to compile big stuff like Firefox on a 600~900MHz CPU, that'd take literally days without using your Pandora.

Exactly. That's what I plan on doing. Anything I accomplish that will be useful in any way will be posted as close to step-by-step as I can get it.
 
No need for easy instructions. As I stated before, the Pandora has fixed hardware. This is different from the majority of devices that run Gentoo. We can put up a binary repository that people can have portage search (instead of the normal Gentoo repository) and install programs from there. As long as we have unified cross-compilation environments on our desktops that compile programs in such a way that they run as best as we can get them to run on the Pandora, we don't need everyone compiling their own software.
 
Vorporeal said:
As long as we have unified cross-compilation environments on our desktops that compile programs in such a way that they run as best as we can get them to run on the Pandora, we don't need everyone compiling their own software.

Perhaps not, and if others feel the need they can make a binary overlay, but I know that I want full control over what features get compiled for what software, so I'll be starting from scratch. :)

I hope to push forward and get a lot done today, being a Saturday and all. We'll see how far I get.
 
I visualize a future Pandora Gentoo Meeting: "Do you all have distcc ready? - yes - yes - yes - yes - yes - yes - no... *silence* ... - you fool"

Thinking about Gentoo at the Pandora means thinking about distcc I mean. It's absolutely possible to have a powerful Desktop do the compiling work for an inefficient Portable. In the past I used Gentoo at an old 1998 Thinkpad. The compiling work was done at my Desktop via LAN and distcc. But both were x86 and both used a wired connection.

First: WiFi has more delay than wired LAN, I've made the experience with distcc this matters. But the Pandora doesn't have wired LAN.
Second: Do you think emulated ARM at some powerful Desktop is any faster than native ARM at the Pandora? I'm in doubt.

(EDIT: So, maybe crosscompiling is the better alternative. But then: why gentoo? There are better distributions for crosscompiling and then using a binary packaging system)
 
hede said:
First: WiFi has more delay than wired LAN, I've made the experience with distcc this matters. But the Pandora doesn't have wired LAN.

you could use an usb eth adapter when compiling

hede said:
Second: Do you think emulated ARM at some powerful Desktop is any faster than native ARM at the Pandora? I'm in doubt.

(EDIT: So, maybe crosscompiling is the better alternative. But then: why gentoo? There are better distributions for crosscompiling and then using a binary packaging system)

doesn't distcc support the use of a crosscompiler?
 
I'm not learned in the intricacies of distcc, but if it did the logical thing and had the entire compilation take place on the desktop then have the post-compilation files sent back to the Pandora, the fact that it has WiFi and not wired Ethernet shouldn't change anything, right?
 
valhalla said:
you could use an usb eth adapter when compiling
But how fast is that? (fast not in MB/s but in "ping times")
valhalla said:
doesn't distcc support the use of a crosscompiler?
AFAIK no. You even cannot compile i686 at a i386 host. Nor you can share different gcc versions, i.e. gcc 3.x at the host and gcc 4.x at the client.
But wait, I'll figure that out...
Doh... there's some DistCC Cross-compiling Guide.
I have to withdraw my statement, sorry for my doubts :huh: It seems possible in "full speed".
Vorporeal said:
I'm not learned in the intricacies of distcc, but if it did the logical thing and had the entire compilation take place on the desktop then have the post-compilation files sent back to the Pandora, the fact that it has WiFi and not wired Ethernet shouldn't change anything, right?

I've tested this in the past and I did come to the solution to use wired lan. Ping wired LAN is ~0.5ms, WiFi is ~1ms here. 0.5ms difference sounds insignificant, for me to. But I have made this experience... maybe there's some other reasons why I made this experience...

On the one Hand, compiling an average file takes only some milliseconds, the file has to be sent, compiled and received to send the next one, so maybe this difference is noticeable. But on the other hand there's parallelization: while waiting for one file the host can still compile another file...
 
Don't forget there's USB gadget functionality (using OTG port), which can provide networking too. I'm getting ~7.5MiB/s data transfer speed (tested on samba mount), ping shows 0.1-0.3ms.
 
As far as the gentoo-wiki is concerned, and to follow the gentoo philosophy, I am providing a common resource for all gentoo pandora users. The methods, configs, and insight is intended for all of us to use as we see fit and to configure/manipulate at will. I DO NOT want it to be just for me. Please feel free to contribute your own configs and methods if you wish! I do have a lot of time that I can spend on organizing the documentation, but I do not want others to feel that its my way or else. I will reorganize the wiki so that the mainpage will be for common gentoo user builds, regardless of methodology, and I highly encourage others to append on subpages for their own tweaks and builds. Hopefully, after a while , we can post on the different pros and cons to each and let others decide what they want to do.

http://www.gentoo-wiki.com/OpenPandora

Cheers,
Jake
 
There are two different routes to take as far as compiling and merging new packages on your gentoo pandora system.
1. You can keep the traditional /usr/portage system, and tied w/ distcc, you could maintain a normal build system.
2. You can use a build host to cross compile most of your binaries, and emerge the completed product.

Advantages:
Method #1: is a bit easier and will be simple to add/maintain your gentoo system.
Method #2: may take a much smaller filesystem footprint, which may work very well with with using a minimalist system to fit on the 256MB internal NAND drive. If you are building a system on a 2/4GB SDHC, this may not be a consideration, however if you want to optimize your system and keep only the necessary programs to fully use your system, this may be your best choice.
 
Running a normal environment + distcc doesn't necessarily need to have a smaller footprint. I've never had any issues with deleting the source packages downloaded through Portage. We can always get rid of those after compilation+installation to save space on the SD.
 
I'd be reluctant building the OS locally on Pandora, not knowing how good wear-leveling algorithms are for the builtin NAND. Unless, of course, the local toolchain was setup to use SD, which I can afford to throw away.
 
Back
Top