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

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

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