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

[Ralf Baechle <ralf@linux-mips.org>]

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