Re: Keystone Issue

[CodeWiz2280 <codewiz2280@xxxxxxxxx>]

Hi Julien,

Thank you for your response.  I will try and post a log for you.  I have been switching back and forth between configurations and need to take a new one.

The board has 4GB of memory. Uboot places the kernel/initramfs/dtb in the 0x8000_0000 region but then the kernel switches its code/data over to a 0x8_0000_0000 range via the pv-fixup-asm.S assembly code called from early_paging_init in arch/arm/mm/mmu.c.  That code is exclusive to the keystone in the 4.19 kernel when "CONFIG_ARM_PV_FIXUP" and "ARM_LPAE" are enabled in the kernel .  The upper 2GB of memory is above 0xFFFF_FFFF so LPAE is required. 

/proc/iomem looks like this without running xen after the switch and the kernel boots:

80000000 - 9fffffff : System RAM (boot alias)

c8000000 - ffffffff : System RAM (boot alias)

800000000 - 1fffffff : System RAM

    800008000-800dfffff : Kernel Code

    801000000-80108ab3f : Kernel data

848000000-8ffffffff : System RAM

I was able to duplicate this issue with a build of your latest "master" repository from this morning.

On Mon, Jun 1, 2020 at 9:29 AM Julien Grall <julien@xxxxxxx> wrote:

Hello,

I have a few questions in order to understand a bit more your problem.

On 01/06/2020 13:38, CodeWiz2280 wrote:
> Hello, I am using a Texas Instruments K2E Keystone Eval board with Linux
> 4.19.59.  It has a 32-bit ARM Cortex A15 processor. There is keystone
> specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that executes
> during early_paging_init for LPAE support.  This causes the kernel to
> switch its running 32-bit address space to a 36-bit address space and
> the hypervisor traps repeatedly and stops it from booting.

Without any log it is going to be difficult to help. Could you post the
hypervisor log when debug is enabled?

>  I suspect
> this is because Xen only allowed for the original 32-bit memory range
> specified by the dom0 device tree.

How much RAM did you give to your Dom0?

> The 36-bit LPAE address is a fixed
> offset from the 32-bit address and is not physically different memory.

I am not sure to understand this. Are you suggesting that the kernel is
trying to relocate itself in a different part of the physical memory?

Can you provide more details on the fixed offset?

> 
> Can you suggest any way to get through this problem? I am using the
> master branch of xen from earlier this year. 

Can you provide the exact baseline your are using? Did make any changes
on top?

> Any help is greatly
> appreciated.
Best regards,

--
Julien Grall