Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board

[Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx>]

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxx [mailto:xen-users-
> bounces@xxxxxxxxxxxxx] On Behalf Of Ian Campbell
> Sent: 16 July 2015 17:12
> To: Shameerali Kolothum Thodi
> Cc: Julien Grall; xen-users@xxxxxxxxxxxxx; Zoltan Kiss
> Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board
> 
> On Thu, 2015-07-16 at 15:25 +0000, Shameerali Kolothum Thodi wrote:
> 
> Please can you post mails in plain text not HTML, thanks.

My apologies. (Though I remember selecting the right option, I have to be more 
careful!).

> 
> Also, I think this is probably more of a xen-devel question that a xen-
> users one, since you are actually changing code...
> 
> > +                module@0x7000000 {
> >
> > +                        compatible = "xen,linux-kernel",
> > + "xen,multiboot-module";
> >
> > +                        reg = <0x7000000 0x300000>;
> 
> Is this the physical address of the Flash device where the kernel is
> burnt?
Yes.
> 
> > I have to make the following changes to the Xen src to get it booted
> > on the board. The changes are basically to enable UART and GIC. Our
> > GIC is slightly different from ARM GICv3, but I have kept the changes
> > minimal such that it boots on the board(I am yet to figure out the
> > exact differences with ARM GICv3 spec and our implementation and its
> > impact on Xen).
> 
> [...]
> 
> > The xen image and dom0 kernel image is written into nor flash and
> UEFI
> > boots Xen instead of a normal linux kernel. The Xen then, loads the
> > dom0 image to memory and tries to boot it.
> 
> Normally for a UEFI system all these things would be expected to be
> found in the ESP along with a xen.cfg describing what to load as per
> http://xenbits.xen.org/docs/unstable/misc/efi.html
> 
> However, updating the FDT to point to some artefacts in the physical
> address space ought to work, that's how we normally do things on u-boot
> systems albeit the things are in RAM not NOR flash.
> 

Ok. We used the same strategy for our hip04 board. I will consider this.

> > The problem is in getting the dom0 booted. I can't see any prints
> from
> > dom0. Please find attached log for details.
> >
> >
> >
> > As I said, our GIC is slightly different from ARM GICv3,
> 
> Is it actually a GICv4 as the code changes suggest?


It is, as per the register return. I will confirm it with our SoC guys.

> 
> >  but I am not 100% sure the dom0 boot issue is related to GIC or not.
> > From what I could analyse, dom0 stops very early. The pc points to
> the
> > __error_p (arch/arm64/kernel/head.S) symbol as per System.map file.
> > And it looks to be Invalid processor type return after
> > lookup_processor_type
> 
> Did you enable the option for your processor type in your kernel
> .config?
> 
> Also, do you have all the Xen options enabled?

Yes, I will double check though.
 
> It could be a cache issue, i..e that code isn't seeing the correct
> processor type table, but we are pretty careful to clean+invalidate the
> kernel image as we load it into RAM.
> 
> It's possible that NOR vs RAM is having an effect here, since we use a
> BUFFERABLE mapping for the source when copying the kernel. i.e. maybe
> we are not actually copying the full image correctly.
> 
> If you can't arrange for the kernel to be in RAM you could try fiddling
> with copy_from_paddr to use a DEVICE mapping instead?
> 
> With a debug build of Xen you could use the debug hvc's to add some
> tracing to your dom0 kernel, see xen/arch/arm/traps.c:do_debug_trap(),
> but in short hvc #0xff?? can be used to drop hints at various points in
> the boot.
> 
> Ian.
Many thanks for your suggestions. It indeed helped me to think in the right 
direction. The issue was, I set a wrong size in dts and Image was not fully 
copied.
I was able to go forward with the right size in dts , but now hit by another 
one. I will use the do_debug_trap() method suggested by you to debug further.

Also please find attached the latest crash dump I am seeing. Please let me know 
if this gives you any hints.

(XEN) CPU 15 booted.
(XEN) Brought up 16 CPUs
(XEN) P2M: 44-bit IPA with 44-bit PA
(XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0000000007000000
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x00000008000000-0x00000010000000 (128MB)
(XEN) Loading zImage from 0000000007000000 to 0000000008080000-0000000008980000
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x000000000fe00000-0x000000000fe01ea5
(XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs
(XEN) .done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to 
Xen)
(XEN) Freed 264kB init memory.
(XEN) d0v0: vGICD: RAZ on reserved register offset 0x00000c
(XEN) d0v0: vGICR: write r2 offset 0x000180
(XEN)  not found<G><3>traps.c:2417:d0v0 HSR=0x93820046 pc=0xffffffc000322bfc 
gva=0xffffff8000090180 gpa=0x0000008d110180
(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to 
DOM0)
(XEN) 'd' pressed -> dumping registers
(XEN)
(XEN) *** Dumping CPU0 guest state (d0v0): ***
(XEN) ----[ Xen-4.6-unstable  arm64  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     ffffffc0002ff830
(XEN) LR:     ffffffc0002ff868
(XEN) SP_EL0: 0000000000000000
(XEN) SP_EL1: ffffffc00087fa80
(XEN) CPSR:   80000145 MODE:64-bit EL1h (Guest Kernel, handler)
(XEN)      X0: 0000000000000199  X1: 000000000000000c  X2: 000000007ddbf62d
(XEN)      X3: 0000000000000000  X4: 0000000000000000  X5: 0000000000000006
(XEN)      X6: ffffffc0008eaa74  X7: 696b206f74206465  X8: 0000000000000064
(XEN)      X9: 0000000000000000 X10: ffffffc0008ea000 X11: ffffffc00089a000
(XEN)     X12: 0101010101010101 X13: 0000000000000000 X14: 0ffffffffffffffd
(XEN)     X15: 0000000000000007 X16: 0000000000000001 X17: 000000000000000e
(XEN)     X18: 0000000000000007 X19: 0000000000000031 X20: 00000000004da5bc
(XEN)     X21: 00000000004da620 X22: ffffffc0008e7000 X23: 0000000000000000
(XEN)     X24: ffffffc00088f4b0 X25: 0000000000000000 X26: 0000000000000000
(XEN)     X27: ffffffc000901c88 X28: ffffffc001801700  FP: ffffffc00087fa80
(XEN)
(XEN)    ELR_EL1: ffffffc000322bfc
(XEN)    ESR_EL1: 96000000
(XEN)    FAR_EL1: ffffff8000090180
(XEN)
(XEN)  SCTLR_EL1: 04c5d91d
(XEN)    TCR_EL1: 34b5193519
(XEN)  TTBR0_EL1: 000000000ffff000
(XEN)  TTBR1_EL1: 000000000891e000
(XEN)

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