linux-mips
[Top] [All Lists]

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

To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: problem with 64bit kernel, BOOT_ELF32 and memory outside CKSEG0
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 12 Nov 2007 10:44:23 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <20071112083242.GA6065@alpha.franken.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20071111143302.GA26458@alpha.franken.de> <20071111213127.GA26297@linux-mips.org> <20071112083242.GA6065@alpha.franken.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.14 (2007-02-12)
On Mon, Nov 12, 2007 at 09:32:42AM +0100, Thomas Bogendoerfer wrote:

> > schedule() doesn't directly depend on very much else working so I get the
> > feeling that your problem may be quite far away.
> 
> well it depends on getting a kernel thread started. And I guess there
> lies the problem.
> 
> Maybe I need to ask more precisely what I want to know: Should a
> kernel linked to CSKEG0 with a CAC_BASE 0x980000000000 work or is 
> this setup "wrong" ? If the answer is yes, I'd say there is still
> a bug left. If no how do we solve the issue of having a 32bit firmware
> and a kernel linked for XPHYS (using some sort of bootloader is not
> want I want to have, if it's avoidable) ?

Typically systems try to put the kernel into CKSEG0 as long as the given
platform happens to have memory mapped there.  Using CKSEG0 allows using
a shorter sequence to load the address of an in-kernel symbol resulting
in a much smaller kernel binary.

One implication of this is that kernel modules will have to be allocated
to CKSEG2/3 because they're built using the same code model.  Modules
are allocated using vmalloc so the vmalloc space needs to be in
CKSEG2/3.  Most people don't care if that space is restricted to just
one gig.

But even if you get that wrong the expected failure mode is different ...

  Ralf

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