On Tue, Jul 02, 2013 at 05:39:18PM -0500, Scott Wood wrote: > On 07/01/2013 10:24:47 PM, Kevin Hao wrote: > >On Mon, Jul 01, 2013 at 07:30:45PM -0500, Scott Wood wrote: > >> On 06/30/2013 02:33:10 AM, Kevin Hao wrote: > >> >On Thu, Jun 27, 2013 at 08:47:27PM -0500, Scott Wood wrote: > >> >> On 06/27/2013 08:36:37 PM, Kevin Hao wrote: > >> >> >On Thu, Jun 27, 2013 at 02:58:34PM -0500, Scott Wood wrote: > >> >> >> On 06/26/2013 09:00:33 PM, Kevin Hao wrote: > >> >> >> >This is based on the codes in the head_44x.S. Since we always > >> >> >align to > >> >> >> >256M before mapping the PAGE_OFFSET for a relocatable kernel, > >> >> >we also > >> >> >> >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 > >> >> > 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 > >> >tlb1 entry. If we align to 64M, the relocatable kernel would > >not work > >> >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. > > >> >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
pgpQeXOG14Z5d.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
