<br><br><div class="gmail_quote">On Wed, Jun 15, 2011 at 7:40 AM, Suzuki Poulose <span dir="ltr"><<a href="mailto:suzuki@in.ibm.com">suzuki@in.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 06/15/11 15:41, Benjamin Herrenschmidt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 2011-06-15 at 11:43 +0530, Suzuki Poulose wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06/14/11 17:34, Michal Simek wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
have someone tried to support RELOCATABLE kernel on ppc44x?<br>
</blockquote>
As Josh, mentioned, I will be working on this. In fact I was trying a couple of<br>
patches towards this on PPC440x. But, I am stuck in debugging the hang that I am<br>
experiencing with the changes. I am setting up a RISCWatch processor probe to<br>
debug the same.<br>
<br>
Here is some information that I wanted to share :<br>
<br>
The PPC440X currently uses 256M TLB entries to pin the lowmem. When we go for a<br>
relocatable kernel we have to :<br>
<br>
1) Restrict the kernel load address to be 256M aligned<br>
</blockquote>
<br>
Wait a minute ... :-)<br>
<br>
There's a difference between having the kernel run from any address and<br>
mapping the linear mapping not starting at 0.<br>
<br>
Those are completely orthogonal.<br>
<br>
I don't see why off hand you are changing the way the TLB is used.<br>
</blockquote>
<br></div>
I started off with PHYSICAL_START support and that kind of hogged me into<br>
this approach :-).<div class="im"><br>
The<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
only possible change needed is to make sure the initial bolted entry set<br>
by the asm code properly covers the kernel in whatever it's "current"<br>
location is. The rest is a matter of fixing up the relocations...<br>
</blockquote></div>
Could we do something like,<br>
<br>
If kernel is loaded at X,<br>
<br>
1. map : ((X-1) & ~256M) to PAGE_OFFSET and so on to cover the kernel in 256M<br>
chunks.<br>
2. Then process the relocations with (X % 256M)<br>
<br>
Thanks<br><font color="#888888">
<br></font></blockquote><div>[marri] I had to deal with kernel relocation to non-zero physical address. I  hacked</div><div>few places to make this work. In my case there were holes(mutliple of 250MB) in</div><div>the low-memory region.  To handle these memory holes I manipulated "lmb" structure.</div>
<div><br></div><div> I had to depend on the bootloader making sure that it is running from non-zero</div><div>physical address and during linux boot it checks for the current TLB where it is </div><div>running from and creates the same new TLB in linux. And everything else should</div>
<div>take care of it.</div><div><br></div><div>--marri</div><div><br></div><div><br></div><div><br></div></div>