[PATCH 00/12] Fixing TI Keystone2 kexec

[Dave Young]

On 05/11/16 at 10:32am, Russell King - ARM Linux wrote:
> On Wed, May 11, 2016 at 05:13:38PM +0800, Dave Young wrote:
> > On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:
> > > I think you're confusing things.  DT doesn't contain the boot alias
> > > memory ranges - it's not a separate chunk of memory.  It's an alias
> > > of the same physical address space found higher in the physical
> > > address range.
> > 
> > Hmm, if we forget about kexec how does the 1st kernel get boot memory?
> > not from DT?
> 
> Just like any other ARM system, it pulls itself up by its shoe laces.
> 
> The kernel assumes that it has been placed into RAM with at least 32KiB
> of writable memory below it, which it uses for the initial page tables.
> It "guesses" that the executing address, rounded down to I-forget-what-
> boundary gives the base address of physical memory.
> 
> It sets the page table up using that assumption.  The kernel gets going
> with C code, and only _then_ parses the DTB.
> 
> If we then find that we're running on TI Keystone 2, part of the early
> platform initialisation specifies to the ARM core code that the kernel
> is to switch a high physical address space > 4GiB, and this provokes
> a "dance" where we tear the MMU back down, run some more assembly code
> to fix up the page tables, and re-initialise the MMU before returning
> to the kernel C code, this time running in the high physical address
> space.  This break-modify-make is an architecture requirement.  We
> also record the physical address delta between the original physical
> address space and the high physical address space so that we can reverse
> the translation for code which needs identity mapping (eg, SMP bringup.)
> 
> The DTB only contains the high physical address space memory information,
> and the kernel now parses the DTB, and sets the page tables up properly
> for the running system.

Thanks for the explanation, so the DTB does not contain the delta info
Please ignore the noise then.

> 
> > > If we put it in DT, then we need a way to also describe that it is an
> > > alias of some other bit of physical memory.
> > 
> > I may missed the background, I just want kexec to get infomation just like
> > the normal kernel.
> 
> See above.  What you're asking for isn't really possible.