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.
