在 2018年11月5日星期一 UTC+8下午2:50:00，J. Kiszka写道：
> On 05.11.18 03:16, jjzhu1...@gmail.com wrote:
> > 在 2018年11月2日星期五 UTC+8下午4:39:23，J. Kiszka写道：
> >> On 02.11.18 09:14, jjzhu1989 wrote:
> >>> 在 2018年11月2日星期五 UTC+8下午3:33:15，jjzh...@gmail.com写道：
> >>>> 在 2018年11月1日星期四 UTC+8下午4:50:27，Jan Kiszka写道：
> >>>>> On 01.11.18 09:21, jjzhu wrote:
> >>>>>> 在 2018年11月1日星期四 UTC+8上午10:34:44，jjzh...@gmail.com写道：
> >>>>>>> 在 2018年11月1日星期四 UTC+8上午1:18:59，J. Kiszka写道：
> >>>>>>>> On 31.10.18 08:30, jjzhu wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> I am trying to run the Jailhouse on UltraZed SOM evaluation board
> >>>>>>>>> with UltraZed-EG IO Carrier Card provided by AVNET.
> >>>>>>>>>
> >>>>>>>>> I followed the manual document "setup-on-zynqmp-zcu102.md" at
> >>>>>>>>> https://github.com/siemens/jailhouse/blob/master/Documentation/setup-on-zynqmp-zcu102.md
> >>>>>>>>>
> >>>>>>>>> I finished the compile of Jailhouse and installed it onto the
> >>>>>>>>> rootfs.
> >>>>>>>>> When I try to enable the Root cell "zynqmp-zcu102.cell", the system
> >>>>>>>>> just stuck, console has no response. and no print output at second
> >>>>>>>>> UART either.
> >>>>>>>>>
> >>>>>>>>> Attached is the log file of the whole starting procedure.
> >>>>>>>>> Could anyone give some hint on what I should modify to make it work?
> >>>>>>>>>
> >>>>>>>>> Thank you in advance!
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> PetaLinux 2017.4 jh_01 /dev/ttyPS0
> >>>>>>>>>
> >>>>>>>>> jh_01 login: [ 10.265514] random: crng init done
> >>>>>>>>> root
> >>>>>>>>> Password:
> >>>>>>>>> root@jh_01:~# modprobe jailhouse
> >>>>>>>>> [ 22.786682] jailhouse: loading out-of-tree module taints kernel.
> >>>>>>>>> root@jh_01:~#
> >>>>>>>>> root@jh_01:~#
> >>>>>>>>> root@jh_01:~# jailhouse enable zynqmp-zcu102.cell
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> [...]
> >>>>>>>>
> >>>>>>>>> [ 0.000000] Kernel command line: earlycon clk_ignore_unused
> >>>>>>>>> earlyprintk mem=1536M root=/dev/mmcblk1p2 rw rootfstype=ext4
> >>>>>>>>> rootwait
> >>>>>>>>
> >>>>>>>> Note that the zcu102 config we have in Jailhouse expects a
> >>>>>>>> reservation via the
> >>>>>>>> device tree at 0x80000000 to 0x83fffffff. You likely leave that
> >>>>>>>> region in use
> >>>>>>>> and may thus overwrite kernel memory when loading the hypervisor
> >>>>>>>> binary.
> >>>>>>>>
> >>>>>>>> Jan
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >>>>>>>> Corporate Competence Center Embedded Linux
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi Jan,
> >>>>>>>
> >>>>>>> Thank you for your feedback!
> >>>>>>> I didn't make any reservation in Device tree, just modified the
> >>>>>>> bootargs 'mem=1536M'
> >>>>>>> Attached is my device tree.
> >>>>>>> Where and how should I add the reservation for Jailhouse?
> >>>>>>>
> >>>>>>> Thank you in advance!
> >>>>>>
> >>>>>> Hi Jan,
> >>>>>>
> >>>>>> I added the following reservation in the zynqmp.dtsi
> >>>>>>
> >>>>>> /memreserve/ 0x800000000 0x40000000
> >>>>>>
> >>>>>> and rebuild the system.
> >>>>>> It still stuck at the same place (enabling the root cell)
> >>>>>>
> >>>>>> Attached is the modified zynqmp.dtsi.
> >>>>>>
> >>>>>> Is this the right way to add reservation?
> >>>>>> Thank you!
> >>>>>>
> >>>>>
> >>>>> Reservation looks good from here (I don't have the board as reference
> >>>>> in reach ATM).
> >>>>>
> >>>>> Could it be that your kernel has KVM enabled? That must be off.
> >>>>>
> >>>>> Jan
> >>>>
> >>>> Hi Jan,
> >>>>
> >>>> I have check the kernel menu config, all the KVM related is off.
> >>>>
> >>>> I have printed out the interrupts and memory running on my system before
> >>>> I enable the root cell.
> >>>>
> >>>> ---
> >>>>
> >>>>
> >>>> root@jh_01:~# cat /proc/interrupts
> >>>> CPU0 CPU1 CPU2 CPU3
> >>>> 2: 0 0 0 0 GICv2 29 Level
> >>>> arch_timer
> >>>> 3: 5001 2376 53465 426853 GICv2 30 Level
> >>>> arch_timer
> >>>> 10: 0 0 0 0 GICv2 67 Level
> >>>> zynqmp_pm
> >>>> 12: 0 0 0 0 GICv2 156 Level
> >>>> zynqmp-dma
> >>>> 13: 0 0 0 0 GICv2 157 Level
> >>>> zynqmp-dma
> >>>> 14: 0 0 0 0 GICv2 158 Level
> >>>> zynqmp-dma
> >>>> 15: 0 0 0 0 GICv2 159 Level
> >>>> zynqmp-dma
> >>>> 16: 0 0 0 0 GICv2 160 Level
> >>>> zynqmp-dma
> >>>> 17: 0 0 0 0 GICv2 161 Level
> >>>> zynqmp-dma
> >>>> 18: 0 0 0 0 GICv2 162 Level
> >>>> zynqmp-dma
> >>>> 19: 0 0 0 0 GICv2 163 Level
> >>>> zynqmp-dma
> >>>> 21: 0 0 0 0 GICv2 109 Level
> >>>> zynqmp-dma
> >>>> 22: 0 0 0 0 GICv2 110 Level
> >>>> zynqmp-dma
> >>>> 23: 0 0 0 0 GICv2 111 Level
> >>>> zynqmp-dma
> >>>> 24: 0 0 0 0 GICv2 112 Level
> >>>> zynqmp-dma
> >>>> 25: 0 0 0 0 GICv2 113 Level
> >>>> zynqmp-dma
> >>>> 26: 0 0 0 0 GICv2 114 Level
> >>>> zynqmp-dma
> >>>> 27: 0 0 0 0 GICv2 115 Level
> >>>> zynqmp-dma
> >>>> 28: 0 0 0 0 GICv2 116 Level
> >>>> zynqmp-dma
> >>>> 32: 0 0 0 0 GICv2 50 Level
> >>>> cdns-i2c
> >>>> 33: 0 0 0 0 GICv2 42 Level
> >>>> ff960000.memory-controller
> >>>> 34: 14 0 0 0 GICv2 47 Level
> >>>> ff0f0000.spi
> >>>> 35: 0 0 0 0 GICv2 58 Level
> >>>> ffa60000.rtc
> >>>> 36: 0 0 0 0 GICv2 59 Level
> >>>> ffa60000.rtc
> >>>> 37: 0 0 0 0 GICv2 165 Level
> >>>> ahci-ceva[fd0c0000.ahci]
> >>>> 38: 506 0 0 0 GICv2 80 Level
> >>>> mmc0
> >>>> 39: 1069 0 0 0 GICv2 81 Level
> >>>> mmc1
> >>>> 40: 840 0 0 0 GICv2 53 Level
> >>>> xuartps
> >>>> 42: 0 0 0 0 GICv2 88 Level
> >>>> ams-irq
> >>>> 43: 411414 0 0 0 GICv2 151 Level
> >>>> fd4a0000.dp
> >>>> 44: 0 0 0 0 GICv2 154 Level
> >>>> fd4c0000.dma
> >>>> 219: 0 0 0 0 GICv2 97 Level
> >>>> xhci-hcd:usb1
> >>>> IPI0: 2468 1127 1392 2035 Rescheduling
> >>>> interrupts
> >>>> IPI1: 80 68 77 36 Function call
> >>>> interrupts
> >>>> IPI2: 0 0 0 0 CPU stop
> >>>> interrupts
> >>>> IPI3: 9150 11243 2777 7818 Timer broadcast
> >>>> interrupts
> >>>> IPI4: 1 0 0 0 IRQ work
> >>>> interrupts
> >>>> IPI5: 0 0 0 0 CPU wake-up
> >>>> interrupts
> >>>> Err: 0
> >>>>
> >>>> ---
> >>>>
> >>>> root@jh_01:~# cat /proc/meminfo
> >>>> MemTotal: 1526984 kB
> >>>> MemFree: 1487152 kB
> >>>> MemAvailable: 1460352 kB
> >>>> Buffers: 3428 kB
> >>>> Cached: 6608 kB
> >>>> SwapCached: 0 kB
> >>>> Active: 9376 kB
> >>>> Inactive: 3876 kB
> >>>> Active(anon): 3284 kB
> >>>> Inactive(anon): 128 kB
> >>>> Active(file): 6092 kB
> >>>> Inactive(file): 3748 kB
> >>>> Unevictable: 0 kB
> >>>> Mlocked: 0 kB
> >>>> SwapTotal: 0 kB
> >>>> SwapFree: 0 kB
> >>>> Dirty: 0 kB
> >>>> Writeback: 0 kB
> >>>> AnonPages: 3292 kB
> >>>> Mapped: 4364 kB
> >>>> Shmem: 200 kB
> >>>> Slab: 15600 kB
> >>>> SReclaimable: 4140 kB
> >>>> SUnreclaim: 11460 kB
> >>>> KernelStack: 1968 kB
> >>>> PageTables: 236 kB
> >>>> NFS_Unstable: 0 kB
> >>>> Bounce: 0 kB
> >>>> WritebackTmp: 0 kB
> >>>> CommitLimit: 763492 kB
> >>>> Committed_AS: 30340 kB
> >>>> VmallocTotal: 263061440 kB
> >>>> VmallocUsed: 0 kB
> >>>> VmallocChunk: 0 kB
> >>>> AnonHugePages: 0 kB
> >>>> ShmemHugePages: 0 kB
> >>>> ShmemPmdMapped: 0 kB
> >>>> CmaTotal: 262144 kB
> >>>> CmaFree: 258404 kB
> >>>> HugePages_Total: 0
> >>>> HugePages_Free: 0
> >>>> HugePages_Rsvd: 0
> >>>> HugePages_Surp: 0
> >>>> Hugepagesize: 2048 kB
> >>>>
> >>>> ---
> >>>>
> >>>>
> >>>> And I have some questions about the zynqmp-zcu102.c:
> >>>>
> >>>>
> >>>> .platform_info = {
> >>>> .pci_mmconfig_base = 0xfc000000,
> >>>> .pci_mmconfig_end_bus = 0,
> >>>> .pci_is_virtual = 1,
> >>>> .pci_domain = -1,
> >>>> .arm = {
> >>>> .gic_version = 2,
> >>>> .gicd_base = 0xf9010000,
> >>>> .gicc_base = 0xf902f000,
> >>>> .gich_base = 0xf9040000,
> >>>> .gicv_base = 0xf906f000,
> >>>> .maintenance_irq = 25,
> >>>> },
> >>>> },
> >>>>
> >>>> Here, what does this maintenance irq mean? where is the 25 come from?
> >>>>
> >>>>
> >>>> .root_cell = {
> >>>> .name = "ZynqMP-ZCU102",
> >>>>
> >>>> .cpu_set_size = sizeof(config.cpus),
> >>>> .num_memory_regions = ARRAY_SIZE(config.mem_regions),
> >>>> .num_irqchips = ARRAY_SIZE(config.irqchips),
> >>>> .num_pci_devices = ARRAY_SIZE(config.pci_devices),
> >>>>
> >>>> .vpci_irq_base = 136-32,
> >>>> },
> >>>>
> >>>> also I have question about the vpci_irq_base.Where does this come from?
> >>>> I did not find any description in my device tree.
> >>>>
> >>>> Can you find anything unusual or mismatching in this information?
> >>>>
> >>>> Thank you in advance!
> >>>
> >>> Hi Jan,
> >>>
> >>> I noticed that there is some information printed in the startup log as:
> >>>
> >>> [ 0.000000] Virtual kernel memory layout:
> >>> [ 0.000000] modules : 0xffffff8000000000 - 0xffffff8008000000 (
> >>> 128 MB)
> >>> [ 0.000000] vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000 (
> >>> 250 GB)
> >>> [ 0.000000] .text : 0xffffff8008080000 - 0xffffff8008960000 (
> >>> 9088 KB)
> >>> [ 0.000000] .rodata : 0xffffff8008960000 - 0xffffff8008cc0000 (
> >>> 3456 KB)
> >>> [ 0.000000] .init : 0xffffff8008cc0000 - 0xffffff8008d40000 (
> >>> 512 KB)
> >>> [ 0.000000] .data : 0xffffff8008d40000 - 0xffffff8008dd2200 (
> >>> 585 KB)
> >>> [ 0.000000] .bss : 0xffffff8008dd2200 - 0xffffff8008e356b4 (
> >>> 398 KB)
> >>> [ 0.000000] fixed : 0xffffffbefe7fd000 - 0xffffffbefec00000 (
> >>> 4108 KB)
> >>> [ 0.000000] PCI I/O : 0xffffffbefee00000 - 0xffffffbeffe00000 (
> >>> 16 MB)
> >>> [ 0.000000] vmemmap : 0xffffffbf00000000 - 0xffffffc000000000 (
> >>> 4 GB maximum)
> >>> [ 0.000000] 0xffffffbf00000000 - 0xffffffbf01500000 (
> >>> 21 MB actual)
> >>> [ 0.000000] memory : 0xffffffc000000000 - 0xffffffc060000000 (
> >>> 1536 MB)
> >>>
> >>> Here, the reserved memory is 0xffffffc000000000 - 0xffffffc060000000
> >>
> >> These are kernel-virtual addresses. You do not see the (guest-)physical
> >> ones
> >> here. /proc/iomem provides an overview, just as well as the device tree.
> >> BTW,
> >> you may also want to compare your DT to the one of the ZCU102.
> >>
> >> Jan
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> >
> > Hi, Jan,
> >
> > Below is the log of iomem before I run the jailhouse.
> > jh_01 login: root
> > Password:
> > root@jh_01:~# modprobe jailhouse
> > [ 76.106601] jailhouse: loading out-of-tree module taints kernel.
> > root@jh_01:~# cat /proc/iomem
> > 00000000-5fffffff : System RAM
> > 00080000-00cbffff : Kernel code
> > 00d40000-00e3afff : Kernel data
> > fd0c0000-fd0c1fff : /amba/ahci@fd0c0000
> > fd3d0000-fd3d0fff : siou
> > fd400000-fd43ffff : serdes
> > fd4a0000-fd4a0fff : /amba/dp@fd4a0000
> > fd4aa000-fd4aafff : blend
> > fd4ab000-fd4abfff : av_buf
> > fd4ac000-fd4acfff : aud
> > fd4c0000-fd4c0fff : /amba/dma@fd4c0000
> > fd500000-fd500fff : /amba/dma@fd500000
> > fd510000-fd510fff : /amba/dma@fd510000
> > fd520000-fd520fff : /amba/dma@fd520000
> > fd530000-fd530fff : /amba/dma@fd530000
> > fd540000-fd540fff : /amba/dma@fd540000
> > fd550000-fd550fff : /amba/dma@fd550000
> > fd560000-fd560fff : /amba/dma@fd560000
> > fd570000-fd570fff : /amba/dma@fd570000
> > fd6e9000-fd6edfff : /amba/cci@fd6e0000/pmu@9000
> > fe200000-fe207fff : /amba/usb0@ff9d0000/dwc3@fe200000
> > fe200000-fe207fff : /amba/usb0@ff9d0000/dwc3@fe200000
> > fe20c100-fe23ffff : /amba/usb0@ff9d0000/dwc3@fe200000
> > ff000000-ff000fff : xuartps
> > ff010000-ff010fff : xuartps
> > ff030000-ff030fff : /amba/i2c@ff030000
> > ff0a0000-ff0a0fff : /amba/gpio@ff0a0000
> > ff0f0000-ff0f0fff : /amba/spi@ff0f0000
> > ff160000-ff160fff : /amba/sdhci@ff160000
> > ff170000-ff170fff : /amba/sdhci@ff170000
> > ff5e0000-ff5e0fff : lpd
> > ff960000-ff960fff : /amba/memory-controller@ff960000
> > ff9d0000-ff9d00ff : /amba/usb0@ff9d0000
> > ffa50000-ffa507ff : ams-base
> > ffa60000-ffa600ff : /amba/rtc@ffa60000
> > ffa80000-ffa80fff : /amba/dma@ffa80000
> > ffa90000-ffa90fff : /amba/dma@ffa90000
> > ffaa0000-ffaa0fff : /amba/dma@ffaa0000
> > ffab0000-ffab0fff : /amba/dma@ffab0000
> > ffac0000-ffac0fff : /amba/dma@ffac0000
> > ffad0000-ffad0fff : /amba/dma@ffad0000
> > ffae0000-ffae0fff : /amba/dma@ffae0000
> > ffaf0000-ffaf0fff : /amba/dma@ffaf0000
> > root@jh_01:~#
>
> According to this, you will likely have much less memory on your board, and
> not
> at the high location that we use on the ZCU102 also for the hypervisor. Move
> its
> region into your reservation that is RAM-backed.
>
> >
> > I don't have the dts for ZCU102. Could you share your dts with me so that I
> > can compare it? Thank you!
> >
>
> linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu102-revB.dts
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
Hi Jan,
Yes, you are right!
I have checked the board guide, It only has 2GB memory (and in its dts only
0x0-0x80000000).
our dts:
memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x80000000>;
};
while in zcu102.dts
it has two memory region
memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x80000000>, <0x8 0x00000000 0x0 0x80000000>;
};
So about the next step:
1. If I change the bootargs as mem=1024M and reserve the memory of 0x40000000
to 0x80000000 in the device tree.
Where should I modify accordingly in Jailhouse side?
My guess was only to modify zynqmp-zcu102.c and put all the address back to the
region starting at 0x40000000.
Is there any more place to modify?
Thank you!
--
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 jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
