[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Keystone Issue
Hi Julien,
The offset is already applied to the memory nodes in the device tree, meaning a direct Linux boot from uboot would have only the 36-bit addresses in the device tree (0x8_0000_0000 and 0x8_8000_0000). Linux would start executing from a 32-bit address space however and then switch over to the aliased 36-bit addresses in the device tree as discussed below by early_paging_init().
I had to add the 32-bit memory node 0x8000_0000 in uboot in place of the 0x8_0000_0000 node otherwise Xen would detect the 32-bit processor and panic on "Unable to detect the first memory bank" in domain_build.c. If I leave only the 36-bit addresses in the device tree and skip past the panic check in domain_build.c, then I could not get the dom0 kernel to boot at all. I believe I would only see "Serial input to DOM0" and nothing else at that point.
Yes, leaving LPAE support on for the kernel is preferred.
Thank you for your help in this matter.
Respectfully, Dave
(+Bertrand and Stefano)
On 01/06/2020 18:38, CodeWiz2280 wrote:
> Hi Julien,
Hi Dave,
>
> As requested please see log below from the eval board booting dom0, some
> notes are as follows:
Thanks for the logs and the notes. They are useful to understand your issue.
> 1. The offset that gets applied to the 32-bit address to translate it
> to 36-bits is 0x7_8000_0000
Is this offset present in the Device-Tree?
> 2. Uboot has been setup to not change the address of the memory in the
> device tree prior to launching xen, otherwise it would
> automatically offset it and replace it with a 36-bit address and xen
> would immediately panic at the 36-bit address for a 32-bit processor.
What is the list of the memory banks Xen will see?
Xen is able to support 36-bit address, can you point to the panic() you
are hitting?
> 3. The RAM starting address placed in the device tree is 0x8000_0000,
> which gets carved up by xen and replaced with 0xA000_0000 prior to
> booting dom0.. I had to put in test code to have the kernel offset the
> 0xA000_0000 32-bit starting address to the 36-bit address needed before
> the kernel will attempt to switch. If it stays 32-bit then it will not
> switch over the address space. Note that without xen in play uboot
> would normally replace the address in the device tree with the 36-bit one.
IIUC, in the case of Linux boot directly, the Device-Tree will not
describe the low memory range. Is that correct?
> 4. The dom0 kernel will boot from xen if the early_paging_init switch
> step is skipped, and the low mem stays in 32-bit....but there is a
> problem with the peripherals so this is not an acceptable solution.
Can you details a bit more the problem with the peripherals?
>
> It seems that either the kernel would need some API to tell xen that
> there is going to be a change in the memory its using prior to call
> early_paging_init(),
From my understanding, the problem is very specific to the KeyStone. So
I would rather avoid to introduce an hypercall specific to your
platform. But...
> or Xen would need to add the additional 36-bit
> addresses during the memory bank allocation step....but recognize that
> they are not actually different physical memory but just aliased to a
> different address.
... I think it is possible to fix it entirely in Xen without any
modification in the device-tree.
It is seems better that Xen treats the low memory region as "not usable"
and only use the high memory region internally. When allocating a Dom0
memory banks, it would need to ensure that there is a corresponding
alias in low memory.
Xen will also need to do two mappings in the Dom0 stage-2 page-tables.
The extra one is for the alias.
This approach will prevent to use hypercall buffer from low memory and
therefore require your guest to support LPAE. Is it going to be an issue
for you?
Cheers,
--
Julien Grall
|
