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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-07-16 at 15:25 +0000, Shameerali Kolothum Thodi wrote:

Please can you post mails in plain text not HTML, thanks.

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?

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

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

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

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.



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