I'm new to Gentoo, so I'm sorry if there is a really obvious answer staring me in the face.
I want to get gentoo onto my HTC Kaiser (arm1136EJ-S armv6) using HaRET. I know it would take years to compile on the phone, so I want to setup a chroot where I can build the entire rootfs and kernel and then copy it to an SD card to boot and run on the phone.
The problem is, I've looked everywhere and not found anything simple to understand. The Embedded Handbook looked like a good idea until I had numerous problems with trying to emerge qemu-user. I've been on IRC to ask about emerge-ing qemu-user but, although the suggestions were great and muchly appreciated, they didn't work properly.
Is the Embedded Handbook Chapter 5 what I should be using, as it appears to be out of date. I read elsewhere that qemu replaced qemu-user, and others suggested using qemu-kvm, but I don't have kvm support on my CPU (running Gentoo in Virtualbox until I can get my head around everything, but even with PAE enabled it doesn't want to know). Also, someone else said kvm isn't a good idea for what I want, and that I'd need to build qemu statically to use the file in the chroot or something?

That's about as much as I know, if I've confused any readers, I apologise, but I really want to get this working, and I *will* be contributing my findnigs, writing it all up and giving it back to the community (including via xda forums for any other interested parties).

About eight years ago I did what you are trying to do to build packages for my HP iPaq 5550. Also ARM based. It had Windows Pocket PC 2003 on it for about 30 minutes after I got it home, then swapped to Familiar, which is Linux for hardhelds. Thats died now.

Anyway, to your problem. You need a package called crossdev.

Code:

emerge crossdev

is a good start.
Whith that you can build a cross compiler tool chain for your ARM system. You don't need any chroot. qemu is only needed if you want to do an ARM install and run it on your build host. qemu performace will be poor as it has to emulate the ARM CPU and environment in software. Testing on your real target may be best.

When you are using crossdev, its smart enough to not install the packages it build on the build host. Thats a good thing as you really don't want to attempt to run ARM binaries on a PC of any sort.

kvm-qemu is no use to you at all. It will only 'emulate' the underlying CPU and its not CPU emulation in software any more, kvm-qemu lets the VM run natively on the host, as far as it can. The software targets, like the assorted ARM CPUs are still there but they are unsupported.

As you have discovered, running several layers of virtualisation doesn't work. I can think of one exception. WINE will run a Windows program that emulates an APPLE ][, alloweing the emulated APPLE ][ to run real APPLE ][ software. Maybe you would point out that WINE Is Not an Emulator._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I have tried using crossdev after your suggestion and it does indeed seem to be what I was after, so thank you for the suggestion
The thing is, with crossdev, do I build everything or copy an armv6 stage3 tarball from the mirrors, or would it be best just to compile everything with crossdev?
Where would I be able to find a list of packages that should be installed, such as the ones in the stage3 tarball? I suppose what I'm looking for is something like gentoo-base but not sure if that exists.

You don't want to 'install' anything ARM related on your build host. That will destroy your host install.
However, you may be able to do something cunnring with a stage tarball to save build time but whatever 'something cunning' is, it will not be the conventional get a stage3 tarball and untar it. You need to put the packages wherever the crossdev toolchain puts its packages.

I think I would build everything myself. Then I know how its built, its built wiith my USE flags snd when I try to run in in am emulator on or the target hardware, I know where to poke when it fails. ... maybe. At least I would be inc charge of my own destiny as I built it all.

I do intend to come back to this, since I want to get a Rasberry-pi to play with - well actually two. One to run as a web server, another to test stuff on._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I want one too, but didn't order. I kinda want to wait until it's in its 2nd or 3rd Gen, maybe with some nice plastic housing before I buy it, although I am pretty damn tempted at the mo. I can see it would be a pretty good tool for compiling for arm, testing, etc.
Regarding installing, I was thinking about using the crossdev-built binaries to do that, i.e. armv6j-unknown-linux-gnu-emerge <package> to emerge and build it. I am thinking something along the lines of finding where the toolchain is built to (/usr/bin/armxxx I think), extract the stage3 tarball there, and emerge-ing extra packages like X and a lightweight DE (gotta research that one, maybe LXDE or enlightenment). I have a cunning plan for the kernel; destroying the .config files used to get Debian onto the vogue and go from there.
Fingers crossed this big idea works!

If you are going to run that ARM code on your build host you will need qemu with the right soft target. Beware it will be slow.

You can configure and build your kernel on the host too.

Code:

ARCH=<somearch> make menuconfig

sets up menuconfig for somearch. I use that quite a lot on my amd64 install, so I can see what users on other aches see in their menuconfigs.
Of course, I try not to save on exit._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I think for me personally, it would be best if I could have a fully locked arm chroot where I can literally build a system from the arm handbook. I mean make-ing the kernel seems to be an issue at the moment (that's how far I've got). Can I just make it locally, or does it need to be done as arm? Not sure how I would do that though... I'm not giving up though!

I think we have a terminology issue here. A chroot of itself does not permit you to run code for one architecture on a different architecture. e.g. you cannot run ARM binaries, on an amd64 host because they are in a chroot. The CPU is still the host CPU both inside and outside the chroot.
Another host based install inside a chroot does mean that if you make a build error and install ARM code in your chroot, only your chroot is trashed, not your entire install.
You will need qemu to execute ARM binary code on an amd64 host. qemu can be installed inside the chroot or outside the chroot. It provides an emulated ARM system that you install ARM code into just as you install into Virtualbox.

However you build your ARM code, it must not be installed so you attempt to execute it in the host, because the host won't understand it. I will probably hear the crash :)

Indeed, you can install qemu with one of the ARM soft targets then boot a qemu instance with an ARM iso file. It will boot like a real ARM based system. Now you can go through a handbook install in this qemu instance. Like a virtualbox guest, the qemu instance has its filesystem as a file on your disk. You will die of old age running gcc inside qemu, so build things with your crossdev toolchain and move them into qemu so that they can be installed and executed.

do *NOT* save on exit.
Looking is harmless. If you want to save and build get a clean copy of the kernel in your ARM workspace and build it there, away from your system kernel.
Read the help in the () Cross Compiler Prefix option. You may want to set that._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

I know a chroot doesn't allow different arches to run on the host CPU. Sorry for the confusion, but yeah I want something like qemu in a chroot so I can do a "dumb install" and then copy the chroot's files directly to sd card partition. I'm still getting to grips with all the above but you have given me a lot to think about, read and study, so I'm (begrudgingly lol) very appreciative, but there's no better way to learn than to do it myself
Seriously though, I'm sure I'll be back to bug you all some more with some more stupid questions when I get stuck
Thanks again