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

[Julien Grall <julien.grall@xxxxxxx>]

On 31/03/16 18:41, Dirk Behme wrote:
> Hello Julien,
Hello Dirk,

> On 29.03.2016 20:53, Julien Grall wrote:
> > On 23/03/16 17:24, Dirk Behme wrote:
> > > trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I
> > > get [1] and then its hanging there.
> > The logs look normal.
> >
> > Do you know where the kernel get stuck? You can press CTRL-a 3 times
> > to get access to the Xen console and then press:
> > * 0 => dump Dom0 registers
> > * d => dump registers
>
> Hmm, CTRL-a 3 times doesn't seem to work, either.
>
> This does need working interrupts, too? I.e. that it doesn't work is an
> additional hint that anything with the interrupt handling might be wrong?
The entry point for all the interrupts is do_IRQ. You can add a 
breakpoint there to know if you receive interrupts.
> Maybe I should debug this, first.
>
> It's handled by Xen's drivers/char/console.c / serial.c and the board
> specific UART device driver, correct?
The generic IRQ code (see do_IRQ) will dispatch the interrupt directly
to the interrupt handler you specific via setup_irq/request_irq.
Usually this handler is specific to the driver.

> > > I'd guess that it hangs due to missing timer interrupt, maybe missing
> > > interrupts at all?
> > >
> > > Any hints how to debug this? Or where to look?
> > >
> > > It might be possible that the board's firmware (arm-trusted-firmware
> > > based) doesn't configure anything correctly. Firmware is running at
> > > EL3,
> > > Xen at EL2. The same kernel is running fine without Xen.
> > >
> > > Using a JTAG debugger I've put breakpoints into xen/arch/arm/time.c
> > > timer_interrupt() & vtimer_interrupt() but these don't seem to be
> > > called
> > > at all (?)
> > They should be called if the timer is configured correctly.
> >
> > > Best regards
> > >
> > > Dirk
> > >
> > > [1]
> > [...]
> >
> >  > (XEN) Checking for initrd in /chosen
> >  > (XEN) RAM: 0000000048000000 - 000000007fffffff
> >  > (XEN)
> >  > (XEN) MODULE[0]: 0000000048000000 - 00000000480058a2 Device Tree
> >  > (XEN) MODULE[1]: 0000000048200000 - 0000000048c00000 Kernel
> >  > (XEN)
> >  > (XEN) Command line: console=dtuart dom0_mem=512M loglvl=all
> >  > (XEN) Placing Xen at 0x000000007fe00000-0x0000000080000000
> >  > (XEN) Update BOOTMOD_XEN from 0000000049000000-0000000049112e01 =>
> >  > 000000007fe00000-000000007ff12e01
> >  > (XEN) Domain heap initialised
> >  > (XEN) Platform: ARMv8 Cortex A57 64-bit eval board
> >  > (XEN) Taking dtuart configuration from /chosen/stdout-path
> >  > (XEN) Looking for dtuart at "/soc/serial@e6e88000", options ""
> >  >   Xen 4.7-unstable
> >  > (XEN) Xen version 4.7-unstable (dirk@build) (aarch64-poky-linux-gcc
> >  > (Linaro GCC 4.9-2015.03) 4.9.3 20150311 (prerelease)) debug=y Mon
> > Mar 21
> >  > 09:15:03 CET 2016
> >  > (XEN) Latest ChangeSet: Tue Feb 9 09:37:15 2016 +0100 git:b0a2893
> >
> > I can't find this changeset in tree. Can you provide your baseline
> > commit and the list of patches you applied on top?
>
> This is
>
> 483ad4439f7fc7 xen-access: minor fixes
>
> plus a local patch to support the board's serial port.
Is it a patch to add earlyprintk or a completely new driver?

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

Regards,

--
Julien Grall

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