Re: [RFC PATCH] ARM: mach-shmobile: Parse DT to get ARCH timer memory region

From: Julien Grall
Date: Mon May 13 2019 - 05:21:28 EST


On 5/10/19 5:22 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>

Don't use hardcoded address, retrieve it from device-tree instead.

And besides, this patch fixes the memory error when running
on top of Xen hypervisor:

(XEN) traps.c:1999:d0v0 HSR=0x93830007 pc=0xc0b097f8 gva=0xf0805000

Which shows that VCPU0 in Dom0 is trying to access an address in memory
it is not allowed to access (0x000000e6080000).
Put simply, Xen doesn't know that it is a device's register memory
since it wasn't described in a host device tree (which Xen parses)
and as the result this memory region wasn't assigned to Dom0 at
domain creation time.

Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>


This patch is meant to get feedback from the community before
proceeding further. If we decide to go this direction, all Gen2
device-trees should be updated (add memory region) before
this patch going in.

e.g. r8a7790.dtsi:

timer {
compatible = "arm,armv7-timer";
interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+ reg = <0 0xe6080000 0 0x1000>;

This looks incorrect, the "arm,armv7-timer" bindings doesn't offer you the possibility to specify an MMIO region. This makes sense because it is meant to describe the Arch timer that is only access via co-processor registers.

Looking at the code, I think the MMIO region corresponds to the coresight (based on the register name). So you may want to describe the coresight in the Device-Tree.

Also, AFAICT, the code is configuring and turning on the timer if it has not been done yet. If you are here running on Xen, then you have probably done something wrong. Indeed, it means Xen would not be able to use the timer until Dom0 has booted. But, shouldn't newer U-boot do it for you?


Julien Grall