[PATCH 12/12] [POWERPC] 85xx: Add support for relocatble kernel (and booting at non-zero)

[Kumar Gala]

On Apr 15, 2008, at 5:57 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Added support to allow an 85xx kernel to be run from a non-zero  
>> physical
>> address (useful for cooperative asymmetric multiprocessing  
>> situations) and
>> kdump.  The support can either be at compile time or runtime
>> (CONFIG_RELOCATABLE).
>>
>> Currently we are limited to running at a physical address that is  
>> module
>> 256M.  This is due to how we map TLBs to cover lowmem and should be  
>> fixed
>> up to allow 64M or maybe even 16M alignment in the future.
>
> The first 11 patches look pretty reasonable, but I think I want a bit
> more time to digest this one.  At the least it needs a bit more
> description, saying for instance why you remove USER_PGD_PTRS and
> KERNEL_PGD_PTRS (yes they are unused now but why does this patch need
> to remove them?).

No reason.  I'll separate their removal into their own patch.

>  Also, given that we changed from using a
> PPC_MEMSTART #define to a memstart_addr variable earlier in the patch
> series, why do we need to change back to a #define (MEMORY_START) now?

I re-introduced it because I wanted ARCH_PFN_OFFSET to be a compile  
time define if !CONFIG_RELOCATABLE

I can easily move the ARCH_PFN_OFFSET define inside the  
CONFIG_RELOCATABLE ifdef.

> I take it that with CONFIG_RELOCATABLE set, the kernel won't touch any
> RAM below the point where it's loaded?

that's correct.

>  Is CONFIG_PHYSICAL_START used
> at all if CONFIG_RELOCATABLE is set, and if so what does it mean?

its not used for anything but as a 'hint' for setting the physical  
address of the PHDR.

> What happens if CONFIG_KERNEL_START != CONFIG_PAGE_OFFSET and the
> kernel is loaded at some address != CONFIG_PHYSICAL_START?

> Are we sure that ARCH_PFN_OFFSET only gets applied to normal memory
> pages, not any I/O?  What happens to /dev/mem when ARCH_PFN_OFFSET !=
> 0?

I need to think on these two.

> Also, since you're changing pmd_page(), it would be better to make it
> use pfn_to_page or something similar rather than using mem_map + xxx.

I'll change it to:
pfn_to_page(__pa(pmd_val(pmd)) >> PAGE_SHIFT)

(I'll move this into a cleanup patch with the removal of USER_PGD_PTRS  
and KERNEL_PGD_PTRS)

- k