Setting up arm chroot

Message

xteejx · Post by **xteejx** » Sat Mar 17, 2012 9:37 pm

Hi guys,

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

Any help would be very very much appreciated.

Post by **NeddySeagoon** » Sat Mar 17, 2012 11:52 pm

xteejx,

Welcome to Gentoo

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: Select all

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.

xteejx · Post by **xteejx** » Sun Mar 18, 2012 6:40 pm

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.

Thank you.

Post by **NeddySeagoon** » Sun Mar 18, 2012 7:27 pm

xteejx,

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.

xteejx · Post by **xteejx** » Sun Mar 18, 2012 10:53 pm

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!

Post by **NeddySeagoon** » Sun Mar 18, 2012 11:00 pm

xteejx,

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: Select all

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.

xteejx · Post by **xteejx** » Sun Mar 18, 2012 11:33 pm

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!

Post by **NeddySeagoon** » Mon Mar 19, 2012 12:34 am

xteejx,

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.

-- edit --

The kernel supports these

Code: Select all

 blackfin  hexagon  microblaze  parisc   sh     unicore32
alpha    cris      ia64     mips        powerpc  sparc  x86
arm      frv       m32r     mn10300     s390     tile   x86_64
avr32    h8300     m68k     openrisc    score    um     xtensa

arches.

To see what an arm kernel menuconfig looks like run

Code: Select all

ARCH=arm make menuconfig

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.

xteejx · Post by **xteejx** » Mon Mar 19, 2012 1:03 am

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

Post by **NeddySeagoon** » Mon Mar 19, 2012 1:27 pm

xteejx,

There are two rules for successful helping at a distance and possibly across a language barrier.

Rule 1. For helpers is "Assume Nothing"
Rule 2. For the helpee is "There are no stupid questions".

Ok, there is one stupid question, its the one you never ask.

Good luck. you will learn a great deal by experiment.