Thank you Jan. Yes, the issue was related to the UART clock as pointed out in
the another link.
To fix it, I added the following to the system-user.dtsi file:
/include/ "system-conf.dtsi"
/include/ "zynqmp-clk-ccf.dtsi"
/ {
clk100: clk100 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <100000000>;
u-boot,dm-pre-reloc;
};
};
&pcie {
status = "disabled";
};
&uart1 {
clocks = <&clk100 &clk100>;
};
After that, it was possible to see the output from the gic-demo.bin in the
/dev/ttyUSB1.
Regarding the address range 8000000000-8000ffffff, it is related to the PCI
bridge. After disabling the pcie (see the dtsi above), the address range is not
mapped anymore and lspci runs correctly.
However, the problem now is related to the vPCI mapping. I can see the
following outputs regarding vPCI when I run the root and non-root cells:
Adding virtual PCI device 00:00.0 to cell "ZynqMP-ZCU102" Cell Id = 0 (from the
root cell)
Shared memory connection established: "gic-demo-ivshmem" <--> "ZynqMP-ZCU102"
(from the non-root cell).
But no devices are mapped (lspci is empty), so I believe the problem is in the
uio driver.
Does the uio driver (https://github.com/henning-schild-work/ivshmem-guest-code)
need some specific flag enabled in the kernel? Or does it have a conflict with
other driver? In the vanilla kernel, it creates interrupt 38 for the new vPCI
device, but in the Xilinx kernel, interrupt 38 is already in use:
38: 0 0 0 GICv2 58 Level ffa60000.rtc
The uio driver does not display the usual messages informing that new devices
are mapped when jailhouse root cell is created. Also, /proc/interrupts does not
contain the new interrupt for the vPCI device that should have been created.
> > Hello,
> >
> > I have a full Jailhouse setup (including ivshmem and interrupts) running on
> > top of the vanilla 4.14 kernel on the Xilinx Ultrascale+ platform. However,
> > I need to use some drivers only available on the Xilinx 4.14 kernel, so I
> > am trying to run Jailhouse on it.
> >
> > I was able to compile and load Jailhouse using the Xilinx kernel. But when
> > I load the gic-demo, I can't see any output on the terminal (/dev/ttyUSB1).
> > Also, when I check the cell stats, it seems that it not running (the stats
> > do not increment).
>
> This might be the same issue that was reported earlier today:
>
> https://www.mail-archive.com/[email protected]/msg05086.html
>
> >
> > # jailhouse enable zynqmp-zcu102.cell
> >
> > Initializing Jailhouse hypervisor v0.8 (37-g1fa90014-dirty) on CPU 1
> > Code location: 0x0000ffffc0200060
> > Page pool usage after early setup: mem 33/995, remap 64/131072
> > Initializing processors:
> > CPU 1... OK
> > CPU 3... OK
> > CPU 0... OK
> > CPU 2... OK
> > Adding virtual PCI device 00:00.0 to cell "ZynqMP-ZCU102" Cell Id = 0
> > Page pool usage after late setup: mem 41/995, remap 69/131072
> > Activating hypervisor
> > [ 94.525270] The Jailhouse is opening.
> >
> > # jailhouse cell create zynqmp-zcu102-gic-demo.cell
> >
> > [ 107.815785] CPU3: shutdown
> > [ 107.818406] psci: CPU3 killed.
> > Created cell "gic-demo"
> > Page pool usage after cell creation: mem 53/995, remap 69/131072
> > [ 107.829653] Created Jailhouse cell "gic-demo"
> >
> > #jailhouse cell load 1 gic-demo.bin
> >
> > Cell "gic-demo" can be loaded
> >
> > #jailhouse cell start 1
> >
> > Started cell "gic-demo"
> >
> > Any suggestion about the causes of this issue?
> >
> > Another problem is that I have something mapped in 0x8000000000:
> >
> > 8000000000-8000ffffff : cfg (does anyone know that is this? - I generated
> > the linux images using petalinux tools)
> >
> > After I load the root-cell and type lspci, I got an unhandled data read in
> > that address:
> >
> > root@linaro-gnome:~# lspci
> > Unhandled data read at 0x8000000000(4)
> >
> > FATAL: unhandled trap (exception class 0x24)
> > Cell state before exception:
> > pc: ffffff800847c8dc lr: ffffff800847c8c8 spsr: 200001c5 EL1
> > sp: ffffff800a0abc90 esr: 24 1 1810005
> > x0: ffffff800b000000 x1: ffffff800b000000 x2: 0000000000000000
> > x3: ffffffc04cf8bb98 x4: ffffffc04cf8b000 x5: ffffff8008de0308
> > x6: 0000000000000000 x7: ffffff800848ac48 x8: ffffffc04cf8ce80
> > x9: 0000007ffecb7c80 x10: 0101010101010101 x11: 000000000000001b
> > x12: 000000000000000f x13: ffffffffffffffff x14: 0000000000000000
> > x15: 0000007fbdc31cc0 x16: ffffff8008198598 x17: 0000007fbdbed170
> > x18: 0000000000000a03 x19: 0000000000000004 x20: ffffff800a0abcec
> > x21: ffffff8008e8b000 x22: ffffff800a0abd5c x23: 0000000000000040
> > x24: 000000000000000f x25: ffffffc04ccfa480 x26: 0000000000000004
> > x27: ffffffc04ccfa480 x28: 0000000000000000 x29: ffffff800a0abc90
>
> Did you mark the RAM that is used for the hypervisor and also the
> inmates as reserved in the device tree that Linux boots from?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
