[PATCH 00/12] Fixing TI Keystone2 kexec

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:

quoted

On 05/11/16 at 09:52am, Russell King - ARM Linux wrote:

quoted

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.

quoted

quoted

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.