[Top] [All Lists]

Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0

To: Thomas Bogendoerfer <>
Subject: Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0
From: Ralf Baechle <>
Date: Sun, 11 Nov 2007 21:31:28 +0000
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.5.14 (2007-02-12)
On Sun, Nov 11, 2007 at 03:33:02PM +0100, Thomas Bogendoerfer wrote:

> I tried to get a working 64bit kernel for SNI RM. Most of things
> to fix were quite obvious, but there is one thing, which I haven't
> understood yet.
> The firmware is only able to boot ELF32 images, which mean I need to
> use BOOT_ELF32.
> RM machines have 256MB memory mapped to KSEG0, anything else is outside.
> To me that would mean I need to use the default spaces from
> mach-generic/spaces.h. A kernel built that way will hang after calling
> schedule() in rest_init() (init/main.c). Has anybody seen this
> as well ?


schedule() doesn't directly depend on very much else working so I get the
feeling that your problem may be quite far away.

> Before digging into schedule() I decided to try mach-ip22/spaces.h
> and limit the installed memory to 256MB. This kernel boots and
> runs fine.
> Then I booted that kernel with all memory (512MB) and it died, when
> init had troubles mapping libc. That result didn't surprise me
> that much, since the kernel probably tried to map memory > 256MB
> via CKSEG0, which won't work. Correct ?

You should keep all memory mapped in the same kernel segment.  Since
you have too much to do that in CKSEG0 it will have to be XKPHYS which
means the generic spaces.h which will be used when you have none in
in mach-rm200/space.h.

I suspect what happens is the kernel is trying to access memory at above
phys. 512MB.  In your setup it would compute a CKSEG1 address for that
and stomp over something it better shouldn't ...


<Prev in Thread] Current Thread [Next in Thread>