On Tue, Jul 02, 2013 at 05:39:18PM -0500, Scott Wood wrote:

On 07/01/2013 10:24:47 PM, Kevin Hao wrote:

quoted

On Mon, Jul 01, 2013 at 07:30:45PM -0500, Scott Wood wrote:

quoted

On 06/30/2013 02:33:10 AM, Kevin Hao wrote:

quoted

On Thu, Jun 27, 2013 at 08:47:27PM -0500, Scott Wood wrote:

quoted

On 06/27/2013 08:36:37 PM, Kevin Hao wrote:

quoted

On Thu, Jun 27, 2013 at 02:58:34PM -0500, Scott Wood wrote:

quoted

On 06/26/2013 09:00:33 PM, Kevin Hao wrote:

quoted

This is based on the codes in the head_44x.S. Since we always

align to

quoted

quoted

256M before mapping the PAGE_OFFSET for a relocatable kernel,

we also

quoted

quoted

change the init tlb map to 256M size.

Why 256M?

For two reasons:
 1. This is the size which both e500v1 and e500v2 support.
 2. Since we always use the PAGE_OFFSET as 0xc0000000, the

256M is

quoted

quoted

quoted

quoted

    max alignment value we can use for this virtual address.

Is there any reason why 64M won't continue to work here?

Yes. In general we would map the 0 ~ 256M memory region in the

first

quoted

quoted

tlb1 entry. If we align to 64M, the relocatable kernel would

not work

quoted

quoted

if loaded above 64M memory. For example, if we load a relocatable
kernel
at 64M memory, we will relocate it as:
__pa(PAGE_OFFSET) = 0x4000000

But in map_mem_in_cams function, it will create a memory map as:
__pa(PAGE_OFFSET) = 0x0

The kernel will definitely not work in this case.

That's a problem with map_mem_in_cams(), as discussed in the thread
on other patch.  Perhaps fully solving those problems is not
worthwhile at this time, but we should at least be able to determine
the TLB size automatically based on the alignment of the address
you're trying to map.  64M would be used unless (address & (256M -
1)) >= 64M.  I hope we can continue to assume the kernel won't cross
a 64M boundary.

No. The problem is we don't know the physical address of the start of
lowmem at booting. So we have to align to physical address (phys1)
blindly
and map the PAGE_OFFSET from there. Then once we get the physical
address
(phys2) of the start of lowmem from the device tree later, we will
map the
PAGE_OFFSET to the start of lowmem. If the phys1 is not equal to
phys2,
we get a problem.

How would you get phys1 != phys2, unless the kernel begins in a
256M-aligned region other than the first (which you said is already
not supported)?

Yes, this is the only case which phys1 != phys2 if we align to 256M.
I plan to also fix this in the next version.

If (phys1 & (256M - 1)) < 64M, then you'd get the same phys2
regardless of whether you align it to 64M or 256M.
Otherwise, we use a 256M page which is what you're already doing.

Yes, you are right. I am just trying to say we will run into problem
when loading a kernel between 64M ~ 256M if we don't align to 256M.

quoted

quoted

quoted

And maybe someone still want to use this relocation method.

Then you don't get to dismiss claims that you're changing
DYNAMIC_MEMSTART alignment requirements by saying that RELOCATABLE
is a strict superset. :-)  Given the requirement that the kernel be
in the first TLB entry, though, using RELOCATABLE rather than
DYNAMIC_MEMSTART doesn't fix the alignment problem.

I don't think it makes sense to keep both mechanisms around unless
there's some obvious reason to prefer DYNAMIC_MEMSTART.

The DYNAMIC_MEMSTART still can be used for such as AMP kernel. It
does have
a more small footprint than RELOCATABLE and also doesn't have the
overhead
of the relocation. So I don't want to drop it in a rush.

How much overhead (space and time) is this really?

The following is the additional sections when relocatable is enabled for
a p2020rdb board.
   section        size
  .dynsym       000007f0
  .dynstr       00000926
  .dynamic      00000080
  .hash         00000388
  .interp       00000011
  .rela.dyn     00215250

The time for the relocation is about 32ms on a p2020rdb board.

It will keep the code (and especially the diff) simpler to have this
replace DYNAMIC_MEMSTART rather than add to it.

OK. If you think that the above overhead is acceptable, I can drop the
DYNAMIC_MEMSTART in the next version.

Thanks,
Kevin

-Scott