> firstname.lastname@example.org wrote:
>>> On Tue, 22 May 2007, email@example.com wrote:
>>>> scripts/basic/fixdep.c:107:23: error: sys/types.h: No such file or
>>> You're missing the basic libraries for native compilation.
>>> | apt-get install libc6-dev
>> Thanks, I feel like a real idiot. Somehow a bunch of development
>> (libc6-dev, ncurses5-dev, and a few others) got uninstalled on that
>> Anyway... I was somewhat able to cross-compile a kernel.
>> Shiva:/usr/src/linux-22.214.171.124# file vmlinux
>> vmlinux: ELF 64-bit MSB executable, MIPS, MIPS-IV version 1 (SYSV),
>> statically linked, not stripped
>> However, when I rsync it over to my O2, it does not boot. It panics
>> immediately, like all other kernels I compiled natively (on the O2) from
>> something other than the Debian sources. This is the full panic as
>> displayed from the PROM:
>> Status register: 0x34010082<CUI,CU0,FR,DE,IPL=8,KX,MODE=KERNEL>
>> Cause register: 0x8014<CE=0,IP8,EXC=WADE>
>> Exception PC: 0x801da9fc, Exception RA: 0x8047b0ec
>> Write address error exception, bad address: 0xfffff000
>> Saved user regs in hex (&gpda 0x81061838, &_regs 0x81061a38):
>> arg: 81070000 50000 8049f510 2
>> tmp: 81070000 a800 804b5808 fff804d9 ffffffff 81412ef4 a13fab68 8
>> sve: 81070000 c064d6ca 0 46136478 0 c02b80ce 0 be4acb69
>> t8 81070000 0 t9 0 at 0 v0 c04936d8 v1 0 k1 fffff000
>> gp 81070000 fp0 sp 0 ra 0
>> Just to make sure I'm not doing something stupid. Here are the command
>> my kernel build sequence:
>> make CROSS_COMPILE=mips-linux-gnu- oldconfig
>> make -j 3 CROSS_COMPILE=mips-linux-gnu- all
>> make CROSS_COMPILE=mips-linux-gnu- INSTALL_MOD_PATH=~/ modules_install
>> cp vmlinux ~/boot/vmlinux-126.96.36.199
>> cp System.map ~/boot/System.map-188.8.131.52
>> cp .config ~/boot/config-184.108.40.206
>> cd ~/
>> tar -cf kernel.tar lib boot
>> CONFIG_CROSSCOMPILE=y in my .config.
>> I also tried rsyncing the Debian sources over to my Core Duo 2 Debian
>> machine for cross-compiling. I was unable to get past the .config step.
>> Debian's patches must hinder cross-compiling in some manner. For
>> make menuconfig seems to refuse to display MIPS as the architecture
>> I've been mainly using a working Debian 2.6.18 config (i.e. the one from
>> their package which lets me compile working 2.6.18 from the Debian
>> sources), but the default config (set to IP32, RK5, etc.) panics at boot
>> as well. Not sure if the message is 100% identical, I can double check
>> anyone thinks that would help.
>> Thanks again for all the help, it's appreciated.
> One, make sure you're doing "make vmlinux.32", and two, CONFIG_BUILD_ELF64
> _not_ enabled. For 2.6.20, I had to cram in a patch from Frank to get
> things to not PROM crash (due to the elimination of CPHYSADDY and
> replacement by
> __pa()), but on 2.6.21, this patch was unnecessary. Unsure about
I tried the vmlinux.32 I had been generating previously, same response
from the PROM.
Didn't see any options something like CONFIG_BUILD_ELF64 in menuconfig
(the closest thing was kernel code model which is 64-bit only), so I just
manually edited the .config. I think my issue is that Debian's working
.config is setting some options contrary to what they need to be for a
later kernel or one without Debian's patches. With CONFIG_BUILD_ELF64=n
and the Debian .config I got compile errors.
Building from the default make menuconfig, then selecting the appropriate
O2 hardware, actually compiled and didn't panic at boot. However, nothing
happened after the PROM loaded the kernel. This happens for both the
vmlinux and vmlinux.32 kernels produced. The framebuffer (4Mb) didn't
start and I couldn't ssh in. This is more or less the same behavior as the
2.6.22-rc test kernel posted.
Anybody have a confirmed working .config for an O2?
> O2's will boot a pure 64bit kernel, but my experience is that they are
> ridiculously slow at it (the console lags severely). vmlinux.32 is the
> method of 64bit-code-in-a-32bit-shell, which the O2's and IP22 systems
> swallow much better.
> Also, gbefb must be no greater than 4MB memory in menuconfig.
> And what's the MHz of your R5000? 300MHz?, if so, it'll be the RM5200,
> you'll want "RM52xx" for CPU instead.
Its 300 Mhz, but I'm not actually sure as to whether its an R5000 or
R5200. hinv and dmesg show it as R5000, though apparently this is normal
hinv behavior for the R5200. If I switched R5000 to R5200 in the Debian
sources, the resulting kernel won't boot. Is it possible that my compiling
woes might be from the necessity to compile for R5200? Or should it be
backwards compatible, so I only miss out on optimizations.
> Gentoo/MIPS Team Lead
> "Such is oft the course of deeds that move the wheels of the world: small
> do them because they must, while the eyes of the great are elsewhere."