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
