Re: ARMv8: New board bring up hangs in kernel start?

[Dirk Behme <dirk.behme@gmail.com>]

Hi Julien,

On 06.04.2016 12:48, Julien Grall wrote:
>
> On 04/04/2016 16:44, Dirk Behme wrote:
>> Hi Julien,
>
> Hello Dirk,
>
>> On 01.04.2016 18:34, Julien Grall wrote:
>>>
>>>
>>> On 31/03/16 18:41, Dirk Behme wrote:
>>>>> Also have you tried a newer version of Xen?
>>>>
>>>>
>>>> I've switched to the recent master
>>>>
>>>> a6f2cdb63 x86/hvm/viridian: keep APIC assist page mapped
>>>>
>>>> now. No difference.
>>>>
>>>> I'll have a deeper look into the interrupt configuration.
>>>>
>>>> Is there anywhere some basic description which interrupts are
>>>> supposed
>>>> to be handled by XEN and which by the Linux kernel? I.e. how the ARM
>>>> GIC
>>>> should be configured regarding the distributor/CPU/virtual parts?
>>>
>>> All the interrupts are taken by Xen. The function do_IRQ in Xen will
>>> dispatch the IRQ either to a guest or call a Xen specific handler.
>>>
>>> Xen handles only a limited number of interrupt:
>>>      * timers
>>>      * UART
>>>      * SMMU
>>>
>>> The rest is either routed to guests or blacklisted by Xen.
>>
>>
>> Ok, thanks, that helps :) Once I have it working, maybe I post a patch
>> to add this info to the documentation.
>
> That would be good. Thank you!
>
>>
>> Just an other question:
>>
>> On ARMv8 64-bit Xen is supposed to be started at EL2 *nonsecure*,
>> correct?
>
> That's right.
>
>>
>> It looks to me that the GICv2 on my board is already partly configured
>> by the firmware at secure EL3. That does mean, whatever
>> gicv2_dist_init() and gicv2_cpu_init() are supposed to do, they
>> can't do
>> it (completely) because they don't have access to the secure part of
>> the
>> GIC (?)
>
> Which is normal, the secure part of the GIC should have already been
> initialized by the firmware running at secure EL3.


I'm using

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi#n134

The special thing here is that it has the offsets 0x10000, 0x20000, 
0x40000 and 0x60000. Instead of the standard ones 0x1000, 0x2000, 
0x4000 and 0x6000.

Now, just by try & error, using [1] makes things working.

I'm not sure why this changes anything, though:

* To my understanding, the GIC register ranges are max 0x1000. So I'd 
think that the 0x2000 should be sufficient to map all necessary registers.

* I haven't observed any MMU fault. So it didn't look like any 
non-mapped register was accessed without this change.

Hmm ...

Best regards

Dirk

[1]

--- r8a7795.dtsi_orig	2016-04-16 19:33:09.698030462 +0200
+++ r8a7795.dtsi	2016-04-16 19:33:38.202029057 +0200
@@ -137,9 +137,9 @@
  			#address-cells = <0>;
  			interrupt-controller;
  			reg = <0x0 0xf1010000 0 0x1000>,
-			      <0x0 0xf1020000 0 0x2000>,
+			      <0x0 0xf1020000 0 0x20000>,
  			      <0x0 0xf1040000 0 0x20000>,
-			      <0x0 0xf1060000 0 0x2000>;
+			      <0x0 0xf1060000 0 0x20000>;
  			interrupts = <GIC_PPI 9
  					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
  		};


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel