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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
