[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Julien,

On 01.04.2016 18:34, Julien Grall wrote:


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?


Just earlyprintk.


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.


Just an other question:

On ARMv8 64-bit Xen is supposed to be started at EL2 *nonsecure*, correct?

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 (?)


Best regards

Dirk




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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.