!!WARNING BLOG PURISTS!! This entry will be modified until it's done. (It's not gonna be added entries like a real blog.) I might start putting modification dates in ... like a blog in a blog ... or I might not. If you don't like that, make your own blog-generating scripts, and your own blog, and your own creative-commons-licensed duck-on-a-cd image (which I didn't make), and get gentoo working on the Nokia N810 yourself ... and if you do, could you tell me how?
So, without further ado,
Diablo flashed to n810 currently.
Internal mmc formatted ext2 (cfdisk used - compiled for arm using scratchbox previously)
External mmc formatted to 2 partitions: 1st is small (256MiB?) vfat, second is ext2
Used this page:
http://maemo.org/maemo_release_documentation/maemo4.1.x/node12.html
to build a kernel in scratchbox that has IN KERNEL ext2 support
(I suppose running the os on ext2 could be accomplished by initfs w/ the kernel module there
but thought this would be the more suitable way to go.)
The arm stages are very, very, very, very, VERY old. (2004-5). There's a arm and an armv4l stage. I'm not sure what the difference is. I'm working with the armv4l stage. n810 is an armv6l according to uname. Backward compatibility between arm revisions is not entirely clear. Perhaps a grand master of embeddedness could enlighten me here. It appears that binaries compiled for armv4l DO work on n810, so I'm gonna run with that.
I've run into an interesting snag. I've got the internal 2GiB card, and an external 2GiB mmc card. I've gotten a kernel build with ext2 support (built in). This works fine. I flashed the maemo side of the device with the new kernel and am using it while trying to set up my chroot environment.
Snag is when I ext2 format either card, there's a file count cap (somewhere near 128k files). Untarring portage barfs with errors that vaguely resemble running out of space. I got lost on that red herring for a while before finding the file-count cap with e2fsck.static (built thankfully not by me for maemo). I have a feeling the only way around this will be a larger mmc card.
homey1337 fixed this with a clever bit of file-system creation management. I didn't know enough about file systems to realize that changing my bytes-per-inode count would allow a higher file count on the partition. I put bytes-per-inode (mke2fs -i) count as low as possible (4096, if I recall -- lowest possible is the block-size for the partition), and quintupled my potential file count.
At this point, I made a gentoo subdir inside my maemo scratchbox environment. I know, I know, homey1337 says I should let scratchbox make my chroot environment for me instead of chrooting in a chroot, but I'm dumb. I couldn't make it do that, so, I'm gonna chroot inside a chroot. Anyhoo, I'm now updating portage on the n810 (chrooted inside my gentoo dir -- which is now on the mmcblk0 device instead of an mmcblk0p1 partition -- interesting that sd will let you do that), and I'm unpacking portage tarball in the scratchbox maemo chroot (1st level, not second -- yeah, this gets a bit confusing) on my T40 (PIII 1.5Ghz .75g ram). If the chrooted chroot on the laptop catches up with the process going on directly on the n810, I'll quit there, and just push on here. Right now, I'm just not sure which is faster a native arm 400, or an emulated arm on x86 1.5ghz.
Ok, new problem, scratchbox won't LET me chroot while inside a chroot. I've got to figure out how to do something more sane here.
Can't emerge --sync out of the box. I run into ebuild can't resolve to package error. Emerge portage gives similar. ebuild .../../../././/portage.#.#.#.ebuild digest followed by emerge portage looks like it worked. There's some freaky errors, but it plows on in spite of them. I DID re-softlink /etc/make.profile to an actually existing profile (2007). The softlink from the stage3 links to 2005. /usr/portage/profiles/default-linux/arm has a 2004 and a 2007.
Ok, after the emerge portage, I'm very, very broken. Need to reboot. I accidentally deleted a handful of my /dev files when I forgot to unmount a -o bound /dev.
Ok, trying a different approach with regard to emulated environment: got qemu emerged with gcc 3.4, and
using this site:
http://www.aurel32.net/info/debian_arm_qemu.php
I'm working on getting an emulated arm environment in which I will chroot and install gentoo. I'll let you
know how it progresses.
Here: this saved my ass!
http://www.nas-2000.org/download/build-root/readme.txt
I'm still in progress with this one, but it looks like this will unburry my burried shovel. (Fix portage
on the stage 3 install from 2005). Ok. The first several steps of this worked. When I got to emerge -av sandbox,
it griped about the /etc/make.profile symlink not pointing anywhere valid. I'm gonna go out on a limb and
link it to the 2007 profile. I'll let you know. Ok. I survived. sandbox is emerging as we speak ... so to
speak. Done. Moving on to updating python with quickpkg old python for later slot install.
Still doing well. Got another speed-bump. While trying to emerge python-updater according to the site mentioned above, I've got two package conflicts. The portage version is too old for bash, and this becomes a circular one. Also, util-linux is too old for coreutils. This seems fixable by one-shot emergeing util-linux. We'll get around to the fix for portage/bash ... this one is odd, because it comes up while trying to get python-updater.
Got a glitch in emerging util-linux. lncursesw issue. Vague report is that I need ncurses emerged with unicode. Trying that, and the trying to re-emerge util-linux. (This fixes a smaller problem than the portage/bash issue. I still don't know how I'll resolve that.)
Ncurses with unicode emerged alright. Trying util-linux again. This worked. Both are installed. Looks like I've
got a work-around for the bash/portage blockage. This came from
http://bugs.gentoo.org/show_bug.cgi?id=217479
emerge '<app-shells/bash-3.2_p33' ; emerge portage
was suggested. I'm doing the first part, but not necessarily updating portage until I've got a functional
python-updater. (I believe that the python-updater emerge will pull in the new portage.) We'll see once
the new-but-not-newest bash is emerged.
Ok, that fixed all the blocking issues. The python-updater emerge is in progress now with no blocks or forced 'nodeps' installs. This is a rather large set of packages, however, and includes python-updater and portage among the to-be-installed packages. I'm going to sleep. I'll let you know how well things have progressed and any new road blocks discovered in the morning. (Ideally, when I wake up, this will be done, with no fail-outs during compilation. Barring that ideal, the emerge will still be in progress, but not interrupted by failure.)
Well, surprisingly, that worked. No complications, so far as I can tell. Looks like we're on to updating portage. Had the old shadow/pam blockage. Unmerge pam-login emerge update shadow. This one is almost common knowledge... Wait, I just checked, and Yes, my grandmother _does_ know how to get around this.
Having some trouble (after all that hubris above) gettin pam updated (needs update before shadow can install).
The update says I'm using modules that won't be supported in the update, and the fixit page for gentoo
http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml#pam_stack
tells me what needs to change in the files, but NOT WHICH FILES to change... Ok, I think I got that worked out
ok. I modified everything in the /etc/pam.d directory. It looks like it worked. I've got an update world going
now. I know I've left the handbook instructions far behind, but we'll pick back up with those.
Ok, it's been a few days since my last update, but here's what's flying: I quit the world update, because I just could NOT get gentoo to boot on the 810, and my thought was, it should boot up from fanoush's modified bootloader even without the world update. When it wouldn't (no visible errors, just hang and then reboot), I started tinkering with two major pieces: 1) Why won't it boot :) 2) Can I get a frame-buffer console going to SEE kernel/init errors during boot.
On the 1) topic, I've solved some potential pitfalls, but still haven't gotten there. For the sake of record, I tarred up the /dev from the stage3 distro and put it aside, then tarred up the /dev from a maemo install and dropped that into the gentoo chroot /dev. Udev should take care of this, I know. The only things that NEED to be in /dev are console and null, but what the hell. The /etc/runlevel/[boot,default] initscripts from the arm stage3 were dangling symlinks to /tmp stuff. I fixed these to point to /etc/init.d. I found that even using fanoush's bootloader, I can NOT boot johnx's debian if the tablet's flashed os is debian. I flashed back to chinook, reflashed the initfs with fanoush's, and debian booted ok. Gentoo still a no. More on where we're going from here in a moment, but first
On the 2) topic, I wrote to johnx (creator of the native debian-on-n810 port) on internettablettalk to ask about the framebuffer console issue. He had some helpful points. The framebuffer console is not in the default chinook kernel (I think it is in diabo ... not sure). Must compile this module or rebuild kernel (scratchbox). I usually choose the latter. Then, I also needed the fb_update_mode utility to turn update mode to auto. This worked to get to a framebuffer console in maemo. I put the fb_update_mode in /root and called it in init scripts. I made no progress doing the same in gentoo. This implies a problem before the gentoo init scripts get going. Well, actually, that's not true, because even in maemo, the console doesn't come up until a chvt 1. (Maemo X is on vt2).
Here's johnx's message to me. I worry it won't stay put on ITT: 3 message limit to inbox/outbox/everything over there. Only the <p>s and <br>s have been added to protect the innocent blank lines.
-------- begin quoted message -------------
Sorry for not getting back to you earlier.
I've been working way too much lately. Anyways, the framebuffer issue you're seeing is two things.
First of all the kernel Nokia ships doesn't have framebuffer console support compiled in.
Only way to make it work is with an additional module. Even after that you need to grab the
fb_update_mode utility from here:
http://www.internettablettalk.com/forums/showthread.php?t=18948&highlight=fbcon
Hack up an initscript to load the modules and run fb_update_mode somewhere early in the boot process.
In the end, I found it easier to just load g_ether.ko, setup USB networking and run a telnet daemon
in an initscript. In your case fb console will help you troubleshoot why it's rebooting. If you have
any more questions please feel free to PM me or start a new thread in the debian section of the forum.
Just say that I told you to and you.
Also, you might want to check out some of the debian-on-n8x0 wiki pages up:
http://www.internettablettalk.com/wiki/index.php?title=Debian-old
might be something here too:
http://trac.tspre.org/projects/deblet/wiki
Anyways, it's really nice to see someone that wants Gentoo on the tablets finally stepping up to challenge. Good luck!
-John
-------- end quoted message -------------
While struggling w/ the frame-buffer issue, I came upon another interesting and possibly helpful point. The fb_update_mode utility comes w/ source and executable. The executable runs fine on maemo, but pops an obscure file-not-found bash error when I run it in the gentoo chroot. I gcc'd the source inside the gentoo chroot, and the new binary worked fine. Oddly, back in maemo, the newly gentoo-built binary did NOT work, delivering the same bash i-can't-find-this-file message. Spoke w/ glucnac on this. He suspected library linker issues. I noted that the arm stage being as old as it is has ancient gcc/glibc. I don't KNOW what the problem is, but this brought me back to the notion that updating the system/world metabuilds on 810 might not be such a bad idea. In the interest of time, I set up distcc between the 810 and my server (athlon XP 3200 1gRAM). I set up a crossdev toolchain on the athlon, and sample compiled a handful of things successfully and a few not-so-successfully. I then remembered that I have different tool-chain versions on the host and client build team. (crossdev builds the latest ~ARCH toolchain.) So, I'm now rebuilding the toolchain natively (no distcc) on the 810.
Looking at qlop values for known compiles on the two systems, it appears that build time for the n810 is approximately 10x build time for the same package on my T40. This is helpful in anticipating durations for build times of as-yet-un-emerged packages on the 810 natively. Anticipated gcc build time: 20 hours.
Oh, I also mounted two separate 256M swap partitions inside the gentoo chroot. I've had spontaneous reboots during large compilations in the past that I suspect are due to the watchdog recognizing an out-of-ram state. Hope this helps. binutils compiled natively with the swap partitions in place, and failed to (rebooted) without them.
EDIT 2008.08.23 17:23 CDT: Just realized that I reference both homey1337 and glucnac in here. He's the same guy.
He'll have to decide which psuedonym he likes. Then again, somebody would actually have to give a crap about reading
this giant tome of bullshit for it to matter.
EDIT 2008.08.23 21:35 CDT: Ok, homeyGlucnac says he likes his split personality. So, if you get to this bit, consider
it an easteregg.
EDIT 2008.08.24 09:32 CDT: gcc native recompile completed successfully in around 10 hours. Nice compared to the 20 hours expected. glibc rebuild is failing with "this gcc version doesn't support __threads." Trying some work-arounds. Already attempted a crossdev build on the Athlon server, quickpkg, and install from tbz. I can't get the 810 to accept installing anything at all from .tbz. Attempted the same methods just to check binpkg installation seemed to work the obvious ways on x86 machines, so perhaps a python update/portage rebuild is in order? Ok, dunno why that seemed to work, but it did. I need to finish a python-updater also, but it's 53 packages, and I'd prefer to let the server do most of that once we're running the same glibc on both sides.
EDIT 2008.08.24 22:10: gcc, glibc, binutils are all now up to date. I updated python as well, rebuilt portage with the
new python 2.5, and ran an "emerge --depclean" (which got rid of the old python). I'm getting "110" error on distcc on the
server for many builds. I tried putting "CC=armv4l-unknown-linux-gnu-gcc-4.2.4" into make.conf (and the complementary CXX
line), but this just prevented distcc from being used at all. Ok, armv4l-unkown-linux-gnu-g++ doesn't exist on the cross-
compiled arm gcc. It does exist when the same package is natively built. I tried symlinking armv4l-unkown-linux-gnu-cpp
to armv4l-unkown-linux-gnu-g++, but the 110 error still comes up when using crossdev with the athlon system reporting that
it doesn't have armv4l-unkown-linux-gnu-g++. Ok, looks like I've got the fix for this one. I cleared out the entire crossdev
tool chain and rebuilt with this command:
"crossdev --ex-gcc --target armv4l-unknown-linux-gnu".
The "--ex-gcc" tells it to build "extra" gcc targets, and I now have an armv4l-unknown-linux-gnu-g++. I ... rock.
Revdep-rebuild went off without a hitch. Python-updater somewhat disturbingly reports no previous version of python. This
is true; I unmerged it with a --distclean, but I'm not confident that the list of packages which it used to want
to rebuild don't still need it. It'll come out in the wash, because I'm proceeding to clean up my /var/lib/portage/world
(and world-sets) files and on to an empty-tree @system rebuild followed by an attempt to boot followed by an @world rebuild.
Somewhere in there, likely more than once, I'll also be retarballing the gentoo chroot.
2008.08.27: Got a new and very odd hurdle: Every emerge has find [gobledygook] : No such file ... (total freaky random character strings).
I thought this was a unicode issue. I think it started after updating util-linux, but I'm not sure. I've had it in
every emerge for quite some time. I stopped the @system rebuild because gcc had a hang up spot on one of its patches. (It also
has the find [randomcrap] thing going on, but that isn't stopping all builds, just some (pam-syntax and a few other
inconsequentials but mostly deps for other things).
Ok, moving back a step. I'm untarring the last tarball I had, and going to try to do two things: figure out where the find
problem comes from, and change my CHOST/use flags to make an ideal OMAP 2420 optimized build of all things. Also, in case
I forget, the reason I can't unmount /mnt/gentoo/dev is that I swapon'd the /dev/mmcblk[01]p1 partitions. Lose them inside
the chroot before attempting unmount for better happiness. Also, take CFLAGS from Mamona site:
http://dev.openbossa.org/trac/mamona/wiki/InternetTablets.
For reference, they are "-march=armv6j -mtune=arm1136jf-s -mfpu=vfp -mfloat-abi=softfp".
2008.08.30 Ok, nailed the find issue culprit, but not sure why the problem occurs. I untarred my updtodate-gcc/glib tarball, and
emerge ONLY findutils, and by the end of building itself, "find [random bullshit]" showed back up. Working on it ...
OK, abandoning that aspect for the moment. Going back to trying to build a more optimized gentoo. We're going to try
the a CHOST slightly modified from http://gentoo-wiki.com/HARDWARE_PDA.
They used armv5te-softfloat-linux-gnueabi. We'll use armv6j-softfloat-linux-gnueabi and take their advice to switch off the
fortran use flag on gcc. (Actually, I'm killing the fortran mudflap and openmp use flags.) I'll let you know how it goes.