Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?

[Dirk Behme <dirk.behme@xxxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel