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

Re: [Xen-devel] ARM64:Porting xen to new hardware





On Thu, Feb 22, 2018 at 2:13 PM, bharat gohil <ghl.bhrt@xxxxxxxxx> wrote:


On Fri, Oct 6, 2017 at 6:59 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
Hello,

On 03/10/17 08:05, bharat gohil wrote:


On Fri, Sep 29, 2017 at 11:12 PM, Julien Grall <julien.grall@xxxxxxx <mailto:julien.grall@xxxxxxx>> wrote:



    On 09/29/2017 09:15 AM, bharat gohil wrote:

        Hello


    Hi,

    Please avoid top-posting.

        The patch didn't work in my case.


    The patch will be useful only if the compatible string in the DT of
    your UART is "snps,dw-apb-uart". What is the compatible string for it?

In my case, compatible string is "ns16550a".
Thanks,

Hmmm, looking back at the conversation your dom0 command line is:

console=hvc0,921600n8 earlyprintk=xen debug ignore_loglevel rw root=/dev/mmcblk0p7

earlyprintk=xen will do nothing as there are no Xen specific earlyprintk for Arm. For Dom0, I would recommend to use same same earlyprintk options as you would use on baremetal.

This would allow you to get some early input if the kernel get stuck before the console has been setup.
I have tried your suggestion, I got following crash. It unable find interrupt controller but this kernel working fine without Xen.
Do you have any suggestion?

[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] OF: of_irq_init: children remain, but no parents
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Kernel panic - not syncing: No interrupt controller found.
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.44+ #15
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Hardware name: XXXXX board (DT)
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Call trace:
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008089f88>] dump_backtrace+0x0/0x1d8
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff800808a184>] show_stack+0x24/0x30
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff800838a0e4>] dump_stack+0x94/0xb8
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008196da0>] panic+0x124/0x270
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c92c08>] init_IRQ+0x24/0x2c
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c909f8>] start_kernel+0x230/0x388
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] [<ffffff8008c901e0>] __primary_switched+0x5c/0x64
[2018-02-22 14:04:15] (XEN) DOM0: [    0.000000] Rebooting in 1 seconds..
 

SoC has different interrupt parent than GIC so I make GIC as interrupt parent and I am able to move ahead. update you once Dom0 boot completely.

Furthermore, on a previous e-mail it has been mentioned that your problem might be because Linux will disable what it thinks unused clock. A way to prevent that (at least for debugging) is using add 'clk_ignore_unused' on the Linux command line.

If the 2 suggestions above does not work, then you would have to instrument the kernel. When the hypervisor is build with debug enabled, there are is set a debug hvc provided. A useful one is hvc 0xfffd. For all of them, you can look at do_debug_trap in arch/arm/traps.c.

I hope this will help.

Cheers,

--
Julien Grall



--
Regards,
Bharat Gohil
Sr.Software Engineer



--
Regards,
Bharat Gohil
Sr.Software Engineer
+919427054633
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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