On 09/29/11 04:33, Benjamin Herrenschmidt wrote:

On Tue, 2011-09-27 at 17:54 +0530, Suzuki Poulose wrote:

quoted

Hi,

I am working on enabling CONFIG_RELOCATABLE for PPC44x Embedded PowerPC
boards as a foundation to enable CONFIG_CRASH_DUMP. After a discussion
on the linux-ppcdev we decided that we will follow the 'processing
relocation entries' approach for running the kernel from a different
address.

I think the best approach is to not touch KERNELBASE and PAGE_OFFSET,
and just process relocations, that way __va() and __pa() are unoutched
and plenty of other stuff won't break.

Ben,

I am processing the relocations in my approach.
But even in that case, __va(), __pa() needs modification since , on BookE,
we depend on PHYSICAL_START(kernstart_addr) to do the translations.

So depending on the kernstart_addr, the __va() keeps changing, even though
the mappings doesn't change. (Virtual to Physical mapping). Please note that,
since we use 256M mappings, any address within the 256M will result in the same
mapping.

quoted

			| Phys. Addr	| Virt. Addr	|
PageBoundary (256M)	|-------------------------------|
			|		|		|
			|		|		|
			|		|		|
(Phys. Start)%256M->	|_______________|_ _ _ _ _ _ _ _|<- Relocated. Kernel
			|		|       ^	| Virtual Address
			|		|	|	|
			|		|	|	|
			|		|  reloc_offset	|
			|		|	|	|
			|		|	|	|
			|		|_______v_______|<-(KERNELBASE)%
			|		|		|   256M
			|		|		|
			|		|		|
			|		|		|
			|		|		|
PageBoundary (256M)	|---------------|---------------|
			|		|		|
			|		|		|

Thanks

Suzuki