View previous topic :: View next topic |
Author |
Message |
bbee n00b
Joined: 16 Jun 2007 Posts: 26
|
Posted: Sat Jun 06, 2009 1:15 am Post subject: Easiest way to build 64bit kernel on 32bit system? |
|
|
I'd like to dump my old power hungry Athlon64 desktop system and replace it with a thin client of sorts, so I'm working on moving all my apps from the desktop to my HTPC (with the intention of using them remotely with ssh + freenx or xvnc).
The desktop is running 64bit kernel/userland, has 4GB of memory and usually pages out a few GB to disk. The HTPC has a core2 cpu and is running 32bit userland/kernel; it will take max. 3GB of memory so memory pressure will be even higher there once I migrate the apps from the desktop. I want to keep the userland 32bit to ease some of the memory pressure, but I'd like to run a 64bit kernel to avoid stuff like highmem and to keep the ability to run 64bit KVM guests.
So my question is: Is there a "gentoo way" of producing a toolchain for a 64bit target on an otherwise 32bit system? And a way of tricking the kernel sources installed by portage to /usr/src into using it? And a way of maintaining/updating the toolchain with the regular tools (emerge) of the 32bit system?
Short of a 64bit chroot ofcourse, since that would duplicate a million utilities incl. portage itself, just to build a kernel.. I don't want a parallel install of python.. I suppose I could use buildroot to do it, but I'd like a method that fits cleanly into gentoo if possible.
Apologies if this has been answered before, I couldn't find anything relevant with the search. |
|
Back to top |
|
|
i92guboj Bodhisattva
Joined: 30 Nov 2004 Posts: 10315 Location: Córdoba (Spain)
|
Posted: Sat Jun 06, 2009 1:27 am Post subject: |
|
|
I think that you don't need anything special, since the kernel doesn't link to anything outside it, all you need is a compiler capable to produce x86_64 code, and gcc can regardless of the architecture it was compiled for.
Try this:
Code: | make ARCH=x86_64 menuconfig |
Make sure you check the options about the cpu type and all that stuff after that. |
|
Back to top |
|
|
bbee n00b
Joined: 16 Jun 2007 Posts: 26
|
Posted: Sat Jun 06, 2009 12:51 pm Post subject: |
|
|
i92guboj wrote: | I think that you don't need anything special, since the kernel doesn't link to anything outside it, all you need is a compiler capable to produce x86_64 code, and gcc can regardless of the architecture it was compiled for. | Huh, how could that possibly work? How can my system's i686-pc-linux-gnu-4.3.3 create 64bit binaries? I did try your suggestion just now; created a .config for a 64bit system with "make ARCH=x86_64 menuconfig" but then:
Code: | # make ARCH=x86_64 bzImage
CHK include/linux/version.h
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-x86
CC kernel/bounds.s
kernel/bounds.c:1: error: code model 'kernel' not supported in the 32 bit mode
kernel/bounds.c:1: sorry, unimplemented: 64-bit mode not compiled in
make[1]: *** [kernel/bounds.s] Error 1
make: *** [prepare0] Error 2 | The error message is a bit cryptic, I was expecting it to complain that it can't find x86_64-pc-linux-gcc or something, but regardless, it doesn't work. Thanks for the suggestion though. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 23082
|
Posted: Sat Jun 06, 2009 3:16 pm Post subject: |
|
|
An i686 gcc cannot create x86_64 code. I think i92guboj meant that your gcc could execute on any host architecture, and would be satisfactory if it produced x86_64 output code. You can build a gcc that runs on i686-pc-linux-gnu, but produces code for x86_64-pc-linux-gnu. Such a gcc could then execute on your 32-bit userland to build a 64-bit kernel, once you find the right options for making the kernel build process invoke it. I recall the Makefile variable CROSS_COMPILE being involved, but I have not done kernel cross compilation recently enough to provide more details.
You may find it useful to add V=1 to the make call, so that you can see the commands it executes. That should make it easier to see when you find the right set of arguments. |
|
Back to top |
|
|
bbee n00b
Joined: 16 Jun 2007 Posts: 26
|
Posted: Sat Jun 06, 2009 4:56 pm Post subject: |
|
|
After I posted I googled the error message, and I thought that i92guboj might have been referring to a multilib system, which isn't enabled by default on x86. (I'm not even sure if it's supported on x86)
Anyway I remembered that sys-devel/crossdev exists, and after 30 minutes and: Code: | crossdev -s1 --target x86_64-pc-linux-gnu
cd /usr/src/linux && make ARCH=x86_64 CROSS_COMPILE=x86_64-pc-linux-gnu- bzImage modules modules_install | I have a shiny new 64bit kernel. It even looks like the 4 cross toolchain packages will be updated by portage in the future. crossdev is a great tool. Only difficulty might be with packages that build kernel modules, but fortunately I'm not using any.
Thanks for the help. |
|
Back to top |
|
|
Captain Newbie Apprentice
Joined: 22 Dec 2006 Posts: 182 Location: Socal
|
Posted: Sat Jun 06, 2009 8:18 pm Post subject: |
|
|
bbee wrote: | After I posted I googled the error message, and I thought that i92guboj might have been referring to a multilib system, which isn't enabled by default on x86. (I'm not even sure if it's supported on x86) |
There's no point in multilib for x86, since a pure-x86 CPU can't execute 64-bit code. :/
It seems odd to me to have a 64-bit kernel and pure-32 userland, but more power to you. _________________ /* Nobody will ever see this message */
panic("Cannot initialize video hardware\n");
"As much as it pains me, we hope that developers know what they're doing." - wolf31o2 |
|
Back to top |
|
|
|