ARMv8: New board bring up hangs in kernel start?

Commit Message

Dirk Behme April 16, 2016, 5:39 p.m. UTC

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]

Comments

Julien Grall April 18, 2016, 8:17 a.m. UTC | #1

On 16/04/2016 18:39, Dirk Behme wrote:
> Hi Julien,

Hi Dirk,

>
> On 06.04.2016 12:48, Julien Grall wrote:
>>
>> On 04/04/2016 16:44, Dirk Behme wrote:
>>> Hi Julien,
> 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.

Those offsets are normal, this platform seems to have a GIC using 
64KB-aligned region rather than the classic 4KB-aligned one.

> 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.

Xen is checking if the platform is using an aliased GIC when the CPU 
interface size is 128KB (see gicv2_is_aliased and commit 
21550029f709072aacf3b90edd574e7d3021b400).

If you see "GICv2: Adjusting CPU interface base to..." then your GIC is 
aliased.

In any case, the device-tree does not correctly describe the hardware on 
your platform. Can you send a patch to fix the upstream device-tree?

Regards,

Dirk Behme April 19, 2016, 1:59 p.m. UTC | #2

On 18.04.2016 10:17, Julien Grall wrote:
>
>
> On 16/04/2016 18:39, Dirk Behme wrote:
>> Hi Julien,
>
> Hi Dirk,
>
>>
>> On 06.04.2016 12:48, Julien Grall wrote:
>>>
>>> On 04/04/2016 16:44, Dirk Behme wrote:
>>>> Hi Julien,
>> 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.
>
> Those offsets are normal, this platform seems to have a GIC using
> 64KB-aligned region rather than the classic 4KB-aligned one.
>
>> 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.
>
> Xen is checking if the platform is using an aliased GIC when the CPU
> interface size is 128KB (see gicv2_is_aliased and commit
> 21550029f709072aacf3b90edd574e7d3021b400).
>
> If you see "GICv2: Adjusting CPU interface base to..." then your GIC
> is aliased.
>
> In any case, the device-tree does not correctly describe the hardware
> on your platform. Can you send a patch to fix the upstream device-tree?


Done:

http://article.gmane.org/gmane.linux.kernel.renesas-soc/2951

Thanks!

Dirk

Patch

--- 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)>;
  		};