Gentoo Linux - Taking it On!


I agree with you Vorporeal, but as bronek touched on, I am concerned with excessive writes on the internal NAND with what I would argue would be a higher volume on a gentoo system because of the portage system; resyncs, compiles, etc, etc. Either method could be tailored so that you can minimize this, i.e. PORT_TMPDIR and similar alternatives.

I've been considering a hybrid approach for my gentoo build.
Internal: Core programs and functionality will be stored on the internal NAND. This should be able to boot, start X and a WM and provide full hardware functionality, but otherwise be as static as possible. If there is room, maybe add a couple of things that make it enjoyable. This would tie in nicely with javajake's .7z image at its core.
External: The external SDHC then could store parts of the system that require more read/write calls and additional software that while not vital to the system, add to the customization ability of your software preferences.

It may be readily apparent to casual gentoo users that this may be making the entire system much more difficult to manage, maintain, and for general use. But hey, then I wouldn't have a project to do and thats what our community is known for...
 
We should DEFINITELY mount /home and /usr on the SD, as well as /var. We don't want any of these frequent-write directories residing on the NAND. I'm almost tempted to try to offload ALL writing to the SD, and forcing the NAND parts of the FS to mount RO.
 
Ok, I'm not a Gentoo guy and I've not been following this thread all that closely, but why not just put everything on SD and leave the NAND well alone?
 
I don't know, if you took this into consideration, yet, so I will quote myself:
off topic
Regarding the NAND in general, I wouldn't be surprised, if booting from SD would be faster at the end. I don't know which kind of NAND TI used this time, but my sandisk cheapo 4GB (I don't know which class, there is a small 2 in a circle printed on the card, maybe that means class 2) is about 10 percent faster than build in NAND on my N800(OMAP2) in boot time. If it is the same on the OMAP3, I will use SD to boot and maybe the NAND for backing up the system in case the SD breakes. That would have the side-effect, that the NAND would be preserved.
/off topic
Click to expand...
 
Vorporeal said:
Capn_Fish said:
As much as I like Gentoo, aren't many of the benefits removed? I mean, you'd get the same speed benefits with a custom-built Debian/Arch/Ubuntu/yourfavoritedistrohere, and the packages would be easier to install. I suppose you still get to specify what options are used and don't have to wait for new packages to get built to use them...

You might also have the issue of flash wear with all of the compiling (I suspect it's worse than regular package installation, but I guess I don't know that for sure).

All the same, best of luck to you! I'll likely still try it at the very least (and maybe stick with it...just not update as often as on my laptop. I've already got a box set up for dev work that I could put distcc on... :)).
Click to expand...

There would be a great deal of distcc used, and I'm thinking of attempting to move all frequently written (or written at all) files to the SD, and mounting the NAND as read-only. This might be taking things a bit too far, but we can at least start by moving /usr, /home, and /var to the SD to preserve the NAND.
Click to expand...
Well, I'd put it totally on SD to begin with. If you could get the frequently-written stuff actually off the device, that would be great.

What about having a network share and downloading/unpacking stuff there? I'm assuming distcc isn't smart enough to realize if it's on the same box and will copy twice as much over the network?

Moved here from the "preinstalled OS" thread.
 
Thanks for your input gerd, I don't have any data to show about the boot time on an SD vice the onboard NAND, however prior to changing the onboard OS it would be prudent to see if it is even worth it. The idea of putting gentoo on the internal NAND should not be an immediate concern, getting a bootable gentoo build that works on the SD card is, such as the one javajake is attempting. Once we have an image, we then can look into whether or not its a good idea to put it on the NAND and what path would be beneficial to that end. Maybe someone has some knowledge on the internal NAND on the MK0 or beagleboard that we can look into.
 
Well, once the first Pandoras arrive, some simple hdparm commands will tell whether using the internal NAND is worth the hassle. Or maybe someone can ask a dev with a dev board to test the speed for us (if they have the time)?
 
A small update: viridior and I have resolved our small tension that surfaced earlier. We're looking into hosting our efforts on a bazaar repository so others can join in a bit easier. Here's how I plan on doing this:

  • If you want to be getting all the latest, greatest, crashing, theoretical ideas and changes, you can use the repository.
  • If you want to follow along at a safe distance, completing tested, 75% certain-to-work steps, follow updates to this thread and the first post of this thread.

viridior has generously offered to host such a repository on his system, so once he gets that set up, we'll post the link here.
 
Why overcomplicate things?

Just toss / on the SD Card and be done with it. No separate partitions, no touching the NAND.

The ONLY possible exception is swap, depending on the benefits of swap partitions vs files.
 
cfdisk /dev/sdx

*add a normal linux partition*
*add a swap partition*
*write partition table*

Now you have an SD card with a swap partition, no need for crappy swap files.
 
What OS doesn't support SD cards with multiple partitions?
I'm quite sure both Windows and Linux support it.
 
Well, about package management, I believe it won't be hard to repackage apps in the PXML format (default distribution method according to devs) and make Portage packages. A semi-automated way should be possible.

We should also keep in mind that we will have to copy the original kernel if we want to retain all functionality, due to the binary blobs that control BT/Wi-Fi and also the graphics adapter.
 
Code: 
dd if=/dev/zero of=/mnt/sdxx/swapfile.swp bs=128M count=512

mkswap /mnt/sdxx/swapfile.swp

swapon /mnt/sdxx/swapfile.swp

swap partition? who needs that? i doubt there is much overhead either

i have used it on a 64mb laptop and it seemed to work pretty decent

Ps another advantage is that it doesn't use up your primary partitions so you can have multiple partitions ie for XP Linux BSD etc... and not be useing extented partitions which can be a real pain if you mess them up
 
Etinin said:
We should also keep in mind that we will have to copy the original kernel if we want to retain all functionality, due to the binary blobs that control BT/Wi-Fi and also the graphics adapter.
Click to expand...

Well, that's the thing. I don't know what will have to be copied and what won't. If the sources used to create the kernel are provided, there could be a way to apply patches automatically to gentoo-sources. The .config file will also come in handy, of course.

A lot of this sort of thing will have to wait until Pandora is shipped, I think, after which the developers will have more free time to work on releasing sources and whatnot.
 
If something like the NVIDIA installer to recompile the module's interface to present kernels (not sure how it works but it allows the driver to be closed source but still work with most kernel versions), then we can compile our own version, however that might not be the case.
Anyway, an open source driver will eventually be available for the video chip, as we have very competent people working on that.

Also, having a system with 128MB RAM without swap is suicide, expect programs to immediately crash if they request a single byte more than available.
 
Etinin said:
If something like the NVIDIA installer to recompile the module's interface to present kernels (not sure how it works but it allows the driver to be closed source but still work with most kernel versions), then we can compile our own version, however that might not be the case.
Click to expand...
Kernel interface is in fact open-source, but most of the driver resides in user-space. User-space part is a binary, and AFAIK is not dependent on any system libraries (but feel free to correct me if I'm wrong). So we could add kernel mode part to any kernel/distro and just copy the user-space binary. Should work. :)

Etinin said:
Also, having a system with 128MB RAM without swap is suicide, expect programs to immediately crash if they request a single byte more than available.
Click to expand...
No it is not a suicide. :D Most network hardware (like for example wireless routers - sometimes heavily modded) are running Linux and work with less RAM. And well-written programs will not crash, but should exit gracefully.
But yes - as a user you have to pick your programs wisely. And if you're developer... write good code, because memory leak will kill application heluva lot faster when there's no swap...

Some people (me included) were running customized kernel 2.4 on PC machines with 8MB RAM - so for Linux everything is possible. :D
 
You must log in or register to reply here.

Similar threads

javaJake
Gentoo
Replies
9
Views
2K
Vorporeal
Vorporeal
E
Anyway to emulate or closely emulate a pandora?
Replies
3
Views
2K
javaJake
javaJake
V
Gentoo Stories
Replies
10
Views
4K
Vitel
V
javaJake
Gentoo Linux
4 5 6
Replies
100
Views
29K
viridior
V
jgeiss
Cross Install Gentoo
Replies
2
Views
5K
Eight Bit
Eight Bit
Back
Top