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
But even if you get that wrong the expected failure mode is different ...