<br><br><div class="gmail_quote">2012/6/18 Nicolas Pitre <span dir="ltr"><<a href="mailto:nicolas.pitre@linaro.org" target="_blank">nicolas.pitre@linaro.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, 18 Jun 2012, Michal Simek wrote:<br>
<br>
> On 06/18/2012 09:02 PM, Nicolas Pitre wrote:<br>
> > On Mon, 18 Jun 2012, Michal Simek wrote:<br>
> ><br>
> > > 2012/6/18 Nicolas Pitre<<a href="mailto:nicolas.pitre@linaro.org">nicolas.pitre@linaro.org</a>><br>
> > ><br>
> > > > On Mon, 18 Jun 2012, Michal Simek wrote:<br>
> > > ><br>
> > > > > Setup correct virtual and physical address in ELF LOAD section.<br>
> > > ><br>
> > > > We are moving to a single kernel binary for multiple targets, including<br>
> > > > targets with different physical load addresses.  The kernel code figures<br>
> > > > out at run time what the actual physical address is when<br>
> > > > CONFIG_ARM_PATCH_PHYS_VIRT is set which is the default these days.  In<br>
> > > > other words, we don't know the physical offset at build time in that<br>
> > > > case and CONFIG_PHYS_OFFSET is simply not defined.<br>
> > > ><br>
> > ><br>
> > > ok. good to know and nice features. In that case I expect that you are<br>
> > > using any binary format and you copy it to memory and run it. Code<br>
> > > find out where it runs and based on that setup things.<br>
> ><br>
> > Exact.<br>
><br>
> ok. One more question about this feature. What is the alignment for<br>
> it? I mean I have done the similar feature for Xilinx ppc440 and<br>
> alignment depends on MMU TLB size.<br>
<br>
</div>Currently the alignment is 16MB as this is the granularity that a single<br>
add or sub instruction can cover with an immediate argument.  This is<br>
highly specific to the ARM instruction set.  At some point we needed 2MB<br>
alignment which required two adds or subs, but that requirement has now<br>
been removed.<br></blockquote><div><br>ok.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> > If you want to use the ELF image, then you need to hardcode the physical<br>
> > memory location in its header, and that's something we want to get away<br>
> > from because it prevents a single kernel binary image from being used on<br>
> > different targets with different memory layouts.  Same issue with<br>
> > u-Boot's legacy uImage format.<br>
><br>
> And are you able to get these information away from ELF? Or you just<br>
> need to set it up to any default value. I would expect to 0x0.<br>
<br>
</div>We just don't use the ELF image format with bootloaders.<br></blockquote><div><br><br>ok<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im"><br>
> > > I haven't played with CONFIG_ARM_PATCH_PHYS_VIRT option but what is elf<br>
> > > entry point for this case?<br>
> ><br>
> > For the kernel image itself it is the kernel virtual address.<br>
><br>
> Is it used somewhere? Or is it just setup to virtual address and no<br>
> code use it? I mean that kernel virtual entry point.<br>
<br>
</div>Nothing uses it.  The official ARM kernel image format is a binary image<br>
and its entry point is the very beginning of it.<br></blockquote><div><br>ok.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> I expect that if CONFIG_ARM_PATCH_PHYS_VIRT=y then CONFIG_PHYS_OFFSET<br>
> is not setup Then LOAD_OFFSET should be equal to CONFIG_PAGE_OFFSET.<br>
<br>
</div>No. CONFIG_PAGE_OFFSET is the virtual address that the kernel uses for<br>
the beginning of its memory view.  That is not where the kernel is<br>
loaded.<br>
<span class="HOEnZb"></span><br></blockquote></div><br>ok. Correct. For ARM_PATCH_PHYS_VIRT default value should be used.<br><br>Thanks,<br>Michal<br><br>