Re: [Xen-devel] [PATCH] xen/arm: Black list everything with a PPI
Sorry Just sent the wrong patch , Please ignore this.
On Fri, May 3, 2019 at 10:13 PM Amit Singh Tomar wrote:
>
> XEN should not forward PPIs to Dom0 as it only support SPIs.
> One of solution to this problem is to skip any device that
> uses PPI source completely while building domain itself.
>
> This patch goes through all the interrupt sources of device and skip it
> if one of interrupt source is PPI. It fixes XEN boot on i.MX8MQ by
> skipping PMU node.
>
> Suggested-by: Julien Grall
> Signed-off-by: Amit Singh Tomar
> ---
> * This replaces following patch.
> https://patchwork.kernel.org/patch/10899881/
> ---
> xen/arch/arm/domain_build.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d983677..0ae54db 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1334,6 +1334,7 @@ static int __init handle_node(struct domain *d, struct
> kernel_info *kinfo,
> DT_MATCH_COMPATIBLE("arm,cortex-a15-pmu"),
> DT_MATCH_COMPATIBLE("arm,cortex-a53-edac"),
> DT_MATCH_COMPATIBLE("arm,armv8-pmuv3"),
> +DT_MATCH_COMPATIBLE("arm,cortex-a53-pmu"),
> DT_MATCH_PATH("/cpus"),
> DT_MATCH_TYPE("memory"),
> /* The memory mapped timer is not supported by Xen. */
> @@ -1353,7 +1354,7 @@ static int __init handle_node(struct domain *d, struct
> kernel_info *kinfo,
> { /* sentinel */ },
> };
> struct dt_device_node *child;
> -int res;
> +int res, i, nirq, irq_id;
> const char *name;
> const char *path;
>
> @@ -1399,6 +1400,20 @@ static int __init handle_node(struct domain *d, struct
> kernel_info *kinfo,
> return 0;
> }
>
> +/* Skip the node, using PPI source */
> +nirq = dt_number_of_irq(node);
> +
> +for ( i = 0 ; i < nirq ; i++ )
> +{
> +irq_id = platform_get_irq(node, i);
> +
> +if ( irq_id >= 16 && irq_id < 32 )
> +{
> +dt_dprintk(" Skip node with (PPI source)\n");
> +return 0;
> +}
> +}
> +
> /*
> * Xen is using some path for its own purpose. Warn if a node
> * already exists with the same path.
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Black list everything with a PPI
Hello,
Thanks for having a look at it.
On Thu, May 16, 2019 at 12:25 AM Oleksandr wrote:
>
>
> On 03.05.19 20:02, Amit Singh Tomar wrote:
>
> Hi, Amit
>
> > XEN should not forward PPIs to Dom0 as it only support SPIs.
> > One of solution to this problem is to skip any device that
> > uses PPI source completely while building domain itself.
> >
> > This patch goes through all the interrupt sources of device and skip it
> > if one of interrupt source is PPI. It fixes XEN boot on i.MX8MQ by
> > skipping PMU node.
> >
> > Suggested-by: Julien Grall
> > Signed-off-by: Amit Singh Tomar
> > ---
> > * This replaces following patch.
> >https://patchwork.kernel.org/patch/10899881/
> > ---
> > xen/arch/arm/domain_build.c | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index d983677..8f54472 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1353,7 +1353,7 @@ static int __init handle_node(struct domain *d,
> > struct kernel_info *kinfo,
> > { /* sentinel */ },
> > };
> > struct dt_device_node *child;
> > -int res;
> > +int res, i, nirq, irq_id;
> > const char *name;
> > const char *path;
> >
> > @@ -1399,6 +1399,20 @@ static int __init handle_node(struct domain *d,
> > struct kernel_info *kinfo,
> > return 0;
> > }
> >
> > +/* Skip the node, using PPI source */
> > +nirq = dt_number_of_irq(node);
> > +
> > +for ( i = 0 ; i < nirq ; i++ )
> > +{
> > +irq_id = platform_get_irq(node, i);
>
> Do we need to do something here if platform_get_irq() returns -1?
Yeah, I should have done it. some think like following:
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/domain_build.c;h=d9836779d17c90e84b94ba32e4a20f028189fc5b;hb=HEAD#l1284
> > +
> > +if ( irq_id >= 16 && irq_id < 32 )
> > +{
> > +dt_dprintk(" Skip node with (PPI source)\n");
> > +return 0;
> > +}
> > +}
> > +
> > /*
> >* Xen is using some path for its own purpose. Warn if a node
> >* already exists with the same path.
>
> Patch looks good. Although R-Car H3 seems to not use PPIs for PMU, I
> have tested your patch just to be sure it wouldn't skip anything by a
> mistake)
Ok, Thanks for testing it. I would resend it with error condition check.
-Thanks
Amit.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Black list everything with a PPI
Hi, On Wed, May 29, 2019 at 11:17 PM Julien Grall wrote: > > Hi Amit, > > Just a quick follow-up. Is there any plan to send a new version of this patch? > Sorry for late on this, I would be able to send it(with a comment for PPI's range) on coming weekend. Thanks, -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform
Hi, Sorry for the late reply. > I have seen multiple threads from you pointing at issues on the IMX.8. Have > they > been resolved? Is this series enough to get Xen and Dom0 booting on the NXP > platform? Yeah, most of issues are resolved now and mainline DTS is used to bring XEN on this i.MX8 platform. Though there is small change that comment out GPC (which is used root interrupt parent) and instead use GIC is done in DTS. The patches has been tested booting DOM0 with ramfs. Thanks, -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform
Hi Nate , Hi Julien, > > Amit, > > Have you checked out the NXP Xen fork? > > https://source.codeaurora.org/external/imx/imx-xen/ > > While the work there hasn't been upstreamed yet, the support for the > iMX8QM > (QuadMax) is fairly complete. There are some important differences between > the > iMX8M and that SoC beyond those you've noted (no A72 cluster, no SMMU, and no > System Control Unit (SCU)), but it might solve some of the issues you've been > running into or avoid yet unknown issues when you attempt to boot a guest > domain. I looked around the work done for iMX8QM but the UART IP used on i.MX8MQ is completely different than that used on i.MXQM. The initial agenda of this series is to get particular uart driver(used on i.IMX8MQ) in first and then start booting domUs. Thanks, -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform
Hi > > What are the consequences to change the interrupt parent? I am not entirely sure about it at the moment but looks like it controllers power domain for various devices like GPU, VPU and OTG etc. So, we may not be able to support these devices for XEN domains ? Also, this IP is not present on other i.MX8 platforms, for instance iMX8QM. > > > > The patches has been tested booting DOM0 with ramfs. > > I don't think this is enough to claim support for Xen on the I.MX8M platform. > What I don't want to end up is having yet another UART driver to maintain in > Xen > but the platform is still unusable. > > You should at least be able to boot multiple domains and use a fully fledge > distro (yocto, Debian...) from a mass storage (and possibly network). > Yeah, I can understand this and would try to work on it (but not sure when can I have access to H/W). Thanks, Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] XEN on R-CAR H3
HI, Trying to boot XEN on R-CAR H3 starter Kit board. Linux image based on 5.0.0-rc5 and XEN image is 4.12 tftp 0x4800 xen;tftp 0x7a00 Image; tftp 4a00 r8a7795-h3ulcb.dtb setenv xen_addr_r 0x4800 setenv fdt_addr_r 4a00 setenv kernel_addr_r 0x7a00 fdt addr $fdt_addr_r fdt resize fdt set /chosen xen,xen-bootargs "console=dtuart dom0_mem=384M" fdt set /chosen \#address-cells <1> fdt set /chosen \#size-cells <1> fdt mknod /chosen module@0 fdt resize fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module" fdt set /chosen/module@0 reg <$kernel_addr_r 0x180> setenv bootargs "console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused rootwait earlycon=xenboot" But when It boot it, I see following crash: booti 0x4800 - 0x4a00 ## Flattened Device Tree blob at 4a00 Booting using the fdt blob at 0x4a00 reserving fdt memory region: addr=4a00 size=1 Using Device Tree in place at 4a00, end 4a012fff Starting kernel ... UART enabled - - CPU booting - - Current EL 0008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 4800 - 7fff (XEN) RAM: 0005 - 00053fff (XEN) RAM: 0006 - 00063fff (XEN) RAM: 0007 - 00073fff (XEN) RAM: 0005 - 00053fff (XEN) RAM: 0006 - 00063fff (XEN) RAM: 0007 - 00073fff (XEN) (XEN) MODULE[0]: 4a00 - 4a01 Device Tree (XEN) MODULE[1]: 7a00 - 7b80 Kernel (XEN) RESVD[0]: 4a00 - 4a01 (XEN) (XEN) (XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=384M (XEN) PFN compression on bits 19...19 (XEN) Xen BUG at page_alloc.c:274 (XEN) [ Xen-4.12.0-rc arm64 debug=y Not tainted ] (XEN) CPU:0 (XEN) PC: 0028b30c page_alloc.c#bootmem_region_add+0x184/0x194 (XEN) LR: 0028b36c (XEN) SP: 002d7d00 (XEN) CPSR: 83c9 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0050 X1: 0003 X2: 0006 (XEN) X3: 0054 X4: 88121000 X5: 0028 (XEN) X6: 0060 X7: 0004 X8: 0001 (XEN) X9: 000a X10: 002d7afa X11: 0031 (XEN) X12: 0002 X13: 0026e5e8 X14: 0020 (XEN) X15: 0040 X16: X17: (XEN) X18: 7d726e08 X19: 0050 X20: 0054 (XEN) X21: 00054000 X22: 0005 X23: 00054000 (XEN) X24: 0028b31c X25: 002b8400 X26: 4800 (XEN) X27: 00074000 X28: 0004 FP: 002d7d00 (XEN) (XEN) VTCR_EL2: 8000 (XEN) VTTBR_EL2: (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN)HCR_EL2: 0038 (XEN) TTBR0_EL2: 48114000 (XEN) (XEN)ESR_EL2: f201 (XEN) HPFAR_EL2: (XEN)FAR_EL2: (XEN) (XEN) Xen stack trace from sp=002d7d00: (XEN)002d7d40 0028b36c 0001 0005 (XEN)00054000 0005 00054000 002d7d90 (XEN)002d7d90 0029c8f8 0001 0005 (XEN)00054000 0005 00054000 0001 (XEN)002e 0005 002d7de0 0029dac0 (XEN)00054000 0005 00054000 002b83c0 (XEN) 002b83d8 4a00 4a01 (XEN)7d726a90 00200608 4800 47e0 (XEN)4a00 0040 (XEN)0001 (XEN) 0001 4a00 00013800 (XEN)002b83c0 0028b31c (XEN) 0003 0440 (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN)
Re: [Xen-devel] XEN on R-CAR H3
Hi,Thanks for prompt reply.
> Memory nodes got duplicated somehow. Likely U-Boot did something incorrect.
>
> Try to use single memory node in your device-tree instead of separated
> by each bank nodes:
>
> memory@4800 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> reg = <0x0 0x4800 0x0 0x3800>,
><0x5 0x 0x0 0x4000>,
><0x6 0x 0x0 0x4000>,
><0x7 0x 0x0 0x4000>;
> };
>
> --
Sorry, I should have read the other thread completely where Andrii
Anisov has suggested the same.
Would try changes mentioned by you.
Thanks
-Amit
> Regards,
>
> Oleksandr Tyshchenko
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hi, > Would try changes mentioned by you. We managed to boot XEN with dom0 kernel on H3. But we see following , when we try to domU guest: # xl create -c config.xl Parsing config from config.xl libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block add [2417] exited with error status 1 libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb: script: File /home/amit_new/guest_domU/rootfs.img is read-only, and so I willt mount it read-write in a guest domain. libxl: error: libxl_create.c:1318:domcreate_launch_dm: Domain 1:unable to add disk devices libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block remove [2461] exited with error status 1 libxl: error: libxl_device.c:1286:device_hotplug_child_death_cb: script: /etc/xen/scripts/block failed; error detected. (XEN) mm.c:1401:d0v0 gnttab_mark_dirty not implemented yet libxl: error: libxl_domain.c:1038:libxl__destroy_domid: Domain 1:Non-existant domain libxl: error: libxl_domain.c:993:domain_destroy_callback: Domain 1:Unable to destroy guest libxl: error: libxl_domain.c:920:domain_destroy_cb: Domain 1:Destruction of domain failed where #cat config.xl name = "guest-1" kernel = "Image" extra = "root=/dev/xvda rw xencons=tty console=hvc0" memory = 256 vcpus = 1 disk = [ 'rootfs.img,raw,xvda,rw' ] Any idea what is going wrong here ? -Thanks, Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hi,
> disk = [ 'phy:/dev/mmcblk1p1,xvda1' ]
Thanks , this worked for us and we can now boot Linux guest in domU.
But now, while booting Android as domU guest , we don't get console
login for domU and it stuck
here:
[ 10.597394] usbcore: registered new interface driver cdc_acm
[ 10.597436] cdc_acm: USB Abstract Control Model driver for USB
modems and ISDN adapters
[ 10.599829] file system registered
[ 10.611942] kauditd_printk_skb: 6 callbacks suppressed
[ 10.611947] audit: type=1400 audit(1550239280.843:17): avc: denied
{ entrypoint } for pid=864 comm="init" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[ 10.616842] audit: type=1400 audit(1550239280.847:18): avc: denied
{ map } for pid=864 comm="adbd" path="/system/bin/adbd" dev="xvda1"
ino=889 scontext=u:r:adbd:s0 tcontext=u:object_r:unlabeled:s0
tclass=file permissive=1
[ 10.617012] audit: type=1400 audit(1550239280.851:19): avc: denied
{ read execute } for pid=864 comm="adbd" path="/system/bin/adbd"
dev="xvda1" ino=889 scontext=u:r:adbd:s0
tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[ 10.747628] random: adbd: uninitialized urandom read (40 bytes read)
Is there a special way to give hvc console login in Android , the way
we do it in Ubuntu is to create hvc0.conf file?
Thanks
- Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hi,
> I am wondering what Android version you are using. What is your use-case?
We are trying with Android O 8.1 version.
> This is our development product
> https://github.com/xen-troops/meta-xt-prod-devel
> which in addition to Linux guest contains Android P guest.
>
After making some changes in domU bootargs, we can now see
console service trying to start but goes into loop with message:
[6.432864] init: starting service 'console'...
[6.433974] init: property_set("ro.boottime.console", "6432469848")
failed: property already set
[6.434580] init: setpgid failed for console: Operation not permitted
[6.434743] init: cannot setexeccon('u:r:shell:s0') for console:
Permission denied
[6.435434] init: Service 'console' (pid 781) killed by signal 6
[6.435483] init: Sending signal 9 to service 'console' (pid 781)
process group...
[6.435608] init: Successfully killed process cgroup uid 2000 pid 781 in 0ms
Also, one other query. In order to get graphics and audio up in dom0
kernel, do we
need to load special/proprietary graphics/audio driver with mainline kernel
and Ubuntu Debian rootfs on H3 platform?
Thanks
-Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hi
> [1] https://elinux.org/R-Car/Boards/Yocto-Gen3
We tried BSP release v3.15.0 from above link but see following message:
[ 45.518865] => setenv xen_addr_r 0x4800;setenv fdt_addr_r
0x4a00;setenv kernel_addr_r 0x7a00
[ 52.430467] => setenv fdt_high 0x;fdt addr $fdt_addr_r;fdt resize
[ 55.348938] => setenv xen_bootargs console=dtuart dom0_mem=512M
[ 57.661868] => setenv dom0_bootargs console=hvc0,115200n8
earlycon=xenboot debug clk_ignore_unused root=/dev/mmcblk1 rw rootwait
[ 59.813185] => fdt set /chosen xen,xen-bootargs \"$xen_bootargs\";
[ 62.037351] => fdt set /chosen xen,dom0-bootargs
\"$dom0_bootargs\";fdt mknode /chosen modules
[ 65.765571] => fdt set /chosen/modules '#address-cells' <1>;fdt set
/chosen/modules '#size-cells' <1>;fdt mknode /chosen/modules module@0
[ 68.086099] => fdt set /chosen/modules/module@0 compatible
"xen,linux-zimage" "xen,multiboot-module"
[ 70.205113] => fdt set /chosen/modules/module@0 reg <
$kernel_addr_r 0x180 >
[ 72.165412] => booti ${xen_addr_r} - ${fdt_addr_r}
[ 74.021004] ## Flattened Device Tree blob at 4a00
[ 74.026244]Booting using the fdt blob at 0x4a00
[ 74.031691]reserving fdt memory region: addr=4800 size=4
[ 74.038310]reserving fdt memory region: addr=4a00 size=12000
[ 74.044936]Loading Device Tree to 7d71, end
7d724fff ... OK
[ 74.054036]
[ 74.055489] Starting kernel ...
[ 74.058755]
- UART enabled -
- CPU booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4800 - 7fff
(XEN) RAM: 0005 - 00053fff
(XEN) RAM: 0006 - 00063fff
(XEN) RAM: 0007 - 00073fff
(XEN)
(XEN) MODULE[0]: 7d71 - 7d722000 Device Tree
(XEN) MODULE[1]: 7a00 - 7b80 Kernel
(XEN) RESVD[0]: 4800 - 4804
(XEN) RESVD[1]: 4a00 - 4a012000
(XEN) RESVD[2]: 7d71 - 7d722000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=512M
(XEN) PFN compression on bits 19...19
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "serial0", options "115200n8"
(XEN) WARNING: UART configuration is not supported
Xen 4.12.0-rc
(XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC
7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y Wed Feb 6
16:23:25 I9
(XEN) Latest ChangeSet: Thu Jan 24 14:03:48 2019 + git:755eb64
(XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3
(XEN) 64-bit Execution:
(XEN) Processor Features:
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN) Debug Features: 10305106
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 1124
(XEN) ISA Features: 00011120
(XEN) 32-bit Execution:
(XEN) Processor Features: 0131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 03010066
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 10201105 4000 0126 02102211
(XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.1
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 8 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f101
(XEN) gic_cpu_addr=f102
(XEN) gic_hyp_addr=f104
(XEN) gic_vcpu_addr=f106
(XEN) gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf102f000
(XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b).
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN) load_precision_shift: 18
(XEN) load_window_shift: 30
(XEN) underload_balance_tolerance: 0
(XEN) overload_balance_tolerance: -3
(XEN) runqueues arrangement: socket
(XEN) cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN) First cpu on runqueue, activating
(XEN) Allocated console ring of 64 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Current EL 0008 -
- Xen starting at EL2
Re: [Xen-devel] XEN on R-CAR H3
Hi, > We use earlier BSP version and we didn't face the similar issue. > > We have a plan to switch to recent BSP version (3.15). So, I will come > up with updates when we migrate. Thanks for this information, we have now built it for 3.9 but yet to test the images. Also, it would be great if you can let us know the XEN version you use with BSP images? Thanks, -Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hi,
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d9836779d1..08b9cd2c44 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info *kinfo)
> printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
>
> +dump_p2m_lookup(kinfo->d, kinfo->dtb_paddr);
> +
> left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
> kinfo->fdt,
> fdt_totalsize(kinfo->fdt));
>
Please find the logs after applying this patch:
(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading Domd0 kernel from boot module @ 7a00
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x005000-0x007000 (512MB)
(XEN) Grant table range: 0x004800-0x004804
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading zImage from 7a00 to 5008-5188
(XEN) Loading dom0 DTB to 0x5800-0x58010a44
(XEN) dom0 IPA 0x5800
(XEN) P2M @ 00080c23dc90 mfn:0x73ff5e
(XEN) 0TH[0x0] = 0x00873ff5c7ff
(XEN) 1ST[0x1] = 0x00873ff3d7ff
(XEN) 2ND[0xc0] = 0x02c0580006fd
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) Unable to copy the DTB to dom0 memory (left = 68164 bytes)
(XEN)
(XEN)
(XEN) Reboot in five seconds...
Thanks
-Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hi, > (1) > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts?h=v4.14.75-ltsi/rcar-3.9.3.rc1 > > (2) > https://elixir.bootlin.com/linux/v5.0-rc7/source/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts Yeah, this is what I thought initially but was not able to compile dts file after removing the reserve node. Will try it again, Thanks for pointing it out. Thanks -Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hello, > Did removing reserved-memory regions together with users work out well > for you? Sorry, didn't get chance to work on this today. I would test it and let you know. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hello, > > Did removing reserved-memory regions together with users work out well > > for you? Removing "reserved-memory" node along with "mmngr" worked well. Tested it with v3.15 BSP release. Also, just tried loading XEN from one of your branch[1] but it stuck with this: [ 13.793305] host 10.105.2.27 is alive [ 13.797050] => tftp 0x4800 xen [ 20.944681] ravb:0 is connected to ravb. Reconnecting to ravb [ 20.952032] ravb Waiting for PHY auto negotiation to complete... done [ 23.964201] ravb: 1000Base/Full [ 23.972794] Using ravb device [ 23.975792] TFTP from server 10.105.2.27; our IP address is 10.105.2.28 [ 23.982685] Filename 'xen'. [ 23.985588] Load address: 0x4800 [ 23.989307] Loading: # [ 29.073520] # [ 29.155589] ## [ 29.178818] 141.6 KiB/s [ 29.181540] done [ 29.183447] Bytes transferred = 754000 (b8150 hex) [ 29.188789] => booti 0x4800 [ 34.990295] Image lacks image_size field, assuming 16MiB [ 34.995837] [ 34.997362] Starting kernel ... [ 35.000628] Do we need to chose some other address where it should be loaded ? [1]: https://github.com/otyshchenko1/xen/tree/ipmmu_v2 Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/6] iomem cacheability
Hi,
> This series introduces a cacheability parameter for the iomem option, so
> that we can map an iomem region into a guest as cacheable memory.
>
> Then, this series fixes the way Xen handles reserved memory regions on
> ARM: they should be mapped as normal memory, instead today they are
> treated as device memory.
>
We tried testing this patch series on R-CAR platform but see following crash
when booting dom0 Linux.
[0.57] bd20: 08b27fa0
08b27000
[0.585639] bd40: 0804bd50 08959164
[0.590565] [] cma_init_reserved_areas+0x98/0x1d0
[0.596876] [] do_one_initcall+0x38/0x120
[0.602493] [] kernel_init_freeable+0x188/0x228
[0.608628] [] kernel_init+0x10/0x100
[0.613898] [] ret_from_fork+0x10/0x18
[0.619250] ---[ end trace c2041e247871a6ff ]---
[0.623929] Unable to handle kernel paging request at virtual
address 7dffe55c
[0.631880] Mem abort info:
[0.634715] Exception class = DABT (current EL), IL = 32 bits
[0.640684] SET = 0, FnV = 0
[0.643786] EA = 0, S1PTW = 0
[0.646990] Data abort info:
[0.649920] ISV = 0, ISS = 0x0006
[0.653821] CM = 0, WnR = 0
[0.656834] swapper pgtable: 4k pages, 48-bit VAs, pgd = 08b47000
[0.663670] [7dffe55c] *pgd=000700aef803,
*pud=000700af0803, *pmd=
[0.672652] Internal error: Oops: 9606 [#1] PREEMPT SMP
[0.678259] Modules linked in:
[0.681371] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
4.14.50-yocto-standard #1
[0.689923] Hardware name: Renesas Salvator-X board based on
r8a7795 ES2.0+ (DT)
[0.697355] task: 80001e91 task.stack: 08048000
[0.703317] PC is at cma_init_reserved_areas+0xbc/0x1d0
[0.708587] LR is at cma_init_reserved_areas+0x94/0x1d0
[0.713862] pc : [] lr : []
pstate: 6045
[0.721287] sp : 0804bd50
[0.724657] x29: 0804bd50 x28: 08a88a28
[0.730013] x27: 00057000 x26: 08994040
[0.735370] x25: 08b27fa0 x24: 08b27000
[0.740727] x23: 7e00 x22: 088ed000
[0.746084] x21: x20:
[0.751440] x19: 0004 x18:
[0.756797] x17: 0001 x16: deadbeef
[0.762154] x15: x14: 0400
[0.767511] x13: 0400 x12:
[0.772872] x11: x10: 0002
[0.778224] x9 : x8 : 80001e945800
[0.783586] x7 : x6 : 08b24868
[0.788938] x5 : 08b24868 x4 :
[0.794295] x3 : 0780 x2 : 0007
[0.799652] x1 : 08a88a28 x0 : e55c
[0.805010] Process swapper/0 (pid: 1, stack limit = 0x08048000)
[0.811747] Call trace:
[0.814254] Exception stack(0x0804bc10 to 0x0804bd50)
[0.820734] bc00:
e55c 08a88a28
[0.828598] bc20: 0007 0780
08b24868
[0.836460] bc40: 08b24868
80001e945800
[0.844322] bc60: 0002
0400
[0.852184] bc80: 0400
deadbeef 0001
[0.860047] bca0: 0004
[0.867910] bcc0: 088ed000 7e00
08b27000 08b27fa0
[0.875772] bce0: 08994040 00057000
08a88a28 0804bd50
[0.883639] bd00: 08959160 0804bd50
08959188 6045
[0.891497] bd20: 08b27fa0
08b27000
[0.899359] bd40: 0804bd50 08959188
[0.904285] [] cma_init_reserved_areas+0xbc/0x1d0
[0.910592] [] do_one_initcall+0x38/0x120
[0.916209] [] kernel_init_freeable+0x188/0x228
[0.922343] [] kernel_init+0x10/0x100
[0.927613] [] ret_from_fork+0x10/0x18
[0.932975] Code: f94262c0 aa0103fc cb803360 d37ae400 (f8776800)
[0.939104] ---[ end trace c2041e247871a700 ]---
[0.943800] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[0.943800]
[0.953021] SMP: stopping secondary CPUs
[0.957009] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b
Below is how reserved node looks like:
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
/* device specific region for Lossy Decompression */
lossy_decompress: linux,lossy_decompress@5400 {
no-map;
reg = <0x 0x5400 0x0 0x0300>;
};
/* For Audio DSP */
adsp_
Re: [Xen-devel] XEN on R-CAR H3
Hi, > The proper command is: > > mkimage -A arm64 -C none -T kernel -a 0x7808 -e 0x7808 -n "XEN" > -d xen/xen xen-uImage Yeah but it didn't boot it up :( [ 16.991035] => setenv ipaddr 10.105.2.28;setenv serverip 10.105.2.27;ping 10.105.2.27 [ 18.791456] ravb Waiting for PHY auto negotiation to complete... done [ 21.506184] ravb: 1000Base/Full [ 21.514787] Using ravb device [ 26.518321] host 10.105.2.27 is alive [ 26.522064] => tftp 0x4808 xen-uImage [ 32.859274] ravb:0 is connected to ravb. Reconnecting to ravb [ 32.866626] ravb Waiting for PHY auto negotiation to complete... done [ 35.936229] ravb: 1000Base/Full [ 35.944824] Using ravb device [ 35.947840] TFTP from server 10.105.2.27; our IP address is 10.105.2.28 [ 35.954733] Filename 'xen-uImage'. [ 35.958271] Load address: 0x4808 [ 35.961990] Loading: # [ 41.049127] # [ 41.131627] ## [ 41.154635] 141.6 KiB/s [ 41.157357] done [ 41.159264] Bytes transferred = 754064 (b8190 hex) [ 41.164605] => bootm 0x4808 [ 48.511339] ## Booting kernel from Legacy Image at 4808 ... [ 48.517501]Image Name: XEN [ 48.520855]Image Type: AArch64 Linux Kernel Image (uncompressed) [ 48.527659]Data Size:754000 Bytes = 736.3 KiB [ 48.532921]Load Address: 4808 [ 48.536731]Entry Point: 4808 [ 48.540541]Verifying Checksum ... OK [ 48.548190]Loading Kernel Image ... OK [ 48.554182] [ 48.555635] Starting kernel ... [ 48.558901] We even tried loading it to 0x7808. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] XEN on R-CAR H3
Hi, > Have you tried to enable early_prink? Yes, this is how we compiled it. make dist-xen XEN_TARGET_ARCH=arm64 debug=y CROSS_COMPILE=aarch64-linux-gnu- CONFIG_EARLY_PRINTK_salvator=scif,0xe6e88000 -j16 > AFAIR, I tested that branch (ipmmu_v2) before submitting RFC patch > series [1] and it was functional. > > But, I don't quite remember what the BSP version (U-Boot/ARM-TF) I had > based on. Ok. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/6] iomem cacheability
Hi > Thanks for testing! You might have found a real bug in the series. Could > you please also attach the full device tree? Please find the attached DTS and DTB file used for testing. Thanks -Amit r8a7795-h3ulcb.dts Description: audio/vnd.dts r8a7795-h3ulcb.dtb Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/6] iomem cacheability
Hi,
> Looking at the stack trace, this is very likely due to the issue I pointed
> out earlier on. I.e reserved-memory region should be described in the memory
> nodes.
Do you mean, something like this(reserved-memory node is under memory node) ?
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -17,23 +17,10 @@
memory@4800 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
- reg = <0x0 0x4800 0x0 0x3800>;
- };
-
- memory@5 {
- device_type = "memory";
- reg = <0x5 0x 0x0 0x4000>;
- };
-
- memory@6 {
- device_type = "memory";
- reg = <0x6 0x 0x0 0x4000>;
- };
-
- memory@7 {
- device_type = "memory";
- reg = <0x7 0x 0x0 0x4000>;
- };
+ reg = <0x0 0x4800 0x0 0x3800>,
+<0x5 0x 0x0 0x4000>,
+<0x6 0x 0x0 0x4000>,
+<0x7 0x 0x0 0x4000>;
reserved-memory {
#address-cells = <2>;
@@ -61,6 +48,7 @@
reg = <0x 0x7000 0x0 0x1000>;
};
};
+ };
Thanks
-Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/6] iomem cacheability
Hi, > Not really, the DT provided by Amit is for the host. The memory node > will be rewritten by Xen for Dom0 and does not include the > reserved-memory regions so far. > Thanks for pointing that out. Is it like we need to create "separate" reserve-memory node(make_reserved-memory_node) when memory node is encountered? Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/6] iomem cacheability
Hi, > Yes, you are right. I made a couple of quick fixes for this issue and > another issue raised by Julien during review (the usage of p2m_ram_t). > Amit, if you would like to give it a try I have a work-in-progress > branch with the fixes here: We did try new branch with new fixes but we see some other crash now. XEN) Loading kernel from boot module @ 7a00 (XEN) Allocating 1:1 mappings totalling 2048MB for dom0: (XEN) No bank has been allocated below 4GB. (XEN) BANK[0] 0x05-0x054000 (1024MB) (XEN) BANK[1] 0x06-0x064000 (1024MB) (XEN) Grant table range: 0x073fe0-0x073fe4 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading zImage from 7a00 to 00050008-00050188 (XEN) Loading dom0 DTB to 0x00050800-0x0005080117d0 (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Scrubbing free RAM on in background (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 292kB init memory. [0.00] Booting Linux on physical CPU 0x0 [0.00] Boot CPU: AArch64 Processor [411fd073] [0.00] Machine model: Renesas H3ULCB board based on r8a7795 ES2.0+ [0.00] earlycon: xenboot0 at I/O port 0x0 (options '') [0.00] bootconsole [xenboot0] enabled [0.00] Xen 4.12 support found [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: UEFI not found. [0.00] Reserved memory: created CMA memory pool at 0x5700, size 400 MiB [0.00] OF: reserved mem: initialized node linux,cma@5700, compatible id shared-dma-pool [0.00] Reserved memory: created CMA memory pool at 0x7000, size 256 MiB [0.00] OF: reserved mem: initialized node linux,multimedia@7000, compatible id shared-dma-pool [0.00] cma: dma_contiguous_reserve(limit 1) [0.00] NUMA: No NUMA configuration found [0.00] NUMA: Faking a node at [mem 0x-0x00063fff] [0.00] NUMA: NODE_DATA [mem 0x63ff90c00-0x63ff926ff] [0.00] Zone ranges: [0.00] DMA [mem 0x5700-0x] [0.00] Normal [mem 0x0001-0x00063fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x5700-0x7fff] [0.00] node 0: [mem 0x0005-0x00053fff] [0.00] node 0: [mem 0x0006-0x00063fff] [0.00] Initmem setup node 0 [mem 0x5700-0x00063fff] [0.00] On node 0 totalpages: 692224 [0.00] DMA zone: 2624 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 167936 pages, LIFO batch:31 [0.00] Normal zone: 8192 pages used for memmap [0.00] Normal zone: 524288 pages, LIFO batch:31 [0.00] bootmem alloc of 64 bytes failed! [0.00] Kernel panic - not syncing: Out of memory [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.75-ltsi-yocto-standard #3 [0.00] Hardware name: Renesas H3ULCB board based on r8a7795 ES2.0+ (DT) [0.00] Call trace: [0.00] [] dump_backtrace+0x0/0x3c0 [0.00] [] show_stack+0x14/0x20 [0.00] [] dump_stack+0x9c/0xbc [0.00] [] panic+0x11c/0x28c [0.00] [] free_bootmem_late+0x0/0x7c [0.00] [] __alloc_bootmem_low+0x2c/0x38 [0.00] [] setup_arch+0x258/0x4d8 [0.00] [] start_kernel+0x64/0x3ac [0.00] ---[ end Kernel panic - not syncing: Out of memory Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 0/6] iomem cacheability
Hi, > It might be possible to rework Dom0 memory allocation to limit the > damage or even re-order the binary in memory. Amit, could you post the > full Xen log with earlyprintk enabled? Please find XEN logs : [ 229.769854] Starting kernel ... [ 229.773120] - UART enabled - - CPU booting - - Current EL 0008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 4800 - 7fff (XEN) RAM: 0005 - 00053fff (XEN) RAM: 0006 - 00063fff (XEN) RAM: 0007 - 00073fff (XEN) (XEN) MODULE[0]: 7d70f000 - 7d722000 Device Tree (XEN) MODULE[1]: 7a00 - 7b80 Kernel (XEN) RESVD[0]: 4a00 - 4a013000 (XEN) RESVD[1]: 7d70f000 - 7d722000 (XEN) (XEN) Command line: console=dtuart dom0_mem=2048M (XEN) Placing Xen at 0x00073fe0-0x00074000 (XEN) Update BOOTMOD_XEN from 4800-48118d81 => 00073fe0-00073ff18d81 (XEN) PFN compression on bits 19...19 (XEN) Domain heap initialised (XEN) Booting using Device Tree (XEN) Platform: Generic System (XEN) Taking dtuart configuration from /chosen/stdout-path (XEN) Looking for dtuart at "serial0", options "115200n8" (XEN) WARNING: UART configuration is not supported Xen 4.12-unstable (XEN) Xen version 4.12-unstable (amit@) (aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y Fri Mar 8 13:09:49 IST 2019 (XEN) Latest ChangeSet: Thu Mar 7 13:22:10 2019 -0800 git:62617af (XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1124 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Using SMC Calling Convention v1.1 (XEN) Using PSCI v1.0 (XEN) SMP: Allowing 8 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=f101 (XEN) gic_cpu_addr=f102 (XEN) gic_hyp_addr=f104 (XEN) gic_vcpu_addr=f106 (XEN) gic_maintenance_irq=25 (XEN) GICv2: Adjusting CPU interface base to 0xf102f000 (XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b). (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Adding cpu 0 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 - CPU 0001 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) Adding cpu 1 to runqueue 0 (XEN) CPU 1 booted. (XEN) Bringing up CPU2 - CPU 0002 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) Adding cpu 2 to runqueue 0 (XEN) CPU 2 booted. (XEN) Bringing up CPU3 - CPU 0003 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) Adding cpu 3 to runqueue 0 (XEN) CPU 3 booted. (XEN) Bringing up CPU4 - CPU 0100 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU4 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073), (XEN) disable cpu (see big.LITTLE.txt under docs/). (XEN) CPU4 never came online (XEN) Failed to bring up CPU 4 (error -5) (XEN) Bringing up CPU5 - CPU 0101 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU5 MIDR (0x410fd034) does not match boot CPU MIDR (0x411fd073), (XEN) disable cpu (see big.LITTLE.txt under docs/). (XEN) CPU5 never came online (XEN) Failed to bring up CPU 5 (error -5) (XEN) Bringing up CPU6 - CPU 0102 booting - - C
Re: [Xen-devel] XEN on R-CAR H3
Hi, > > Starting kernel ... > > - UART enabled - > - CPU booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Zero BSS - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) Initrd 7640-77a230f7 > (XEN) RAM: 4800 - bfff > (XEN) RAM: 0005 - 00057fff > (XEN) RAM: 0006 - 00067fff > (XEN) RAM: 0007 - 00077fff > (XEN) > (XEN) MODULE[0]: 4800 - 48014080 Device Tree > (XEN) MODULE[1]: 7640 - 77a230f7 Ramdisk > (XEN) MODULE[2]: 7a00 - 7c00 Kernel > (XEN) MODULE[3]: 7c00 - 7c01 XSM > (XEN) RESVD[0]: 4800 - 48014000 > (XEN) RESVD[1]: 7640 - 77a230f7 > (XEN) > (XEN) Command line: dom0_mem=256M console=dtuart dtuart=serial0 > dom0_max_vcpus=4 bootscrub=0 loglvl=all > (XEN) Placing Xen at 0x00077fe0-0x00078000 > (XEN) Update BOOTMOD_XEN from 7808-781b2d81 => > 00077fe0-00077ff32d81 > (XEN) Domain heap initialised > (XEN) Booting using Device Tree > (XEN) Platform: Generic System > (XEN) Looking for dtuart at "serial0", options "" > (XEN) Unable to initialize dtuart: -9 > (XEN) Bad console= option 'dtuart' > *Xen 4.9.1-pre* > (XEN) Xen version 4.9.1-pre (otyshchenko@) (aarch64-poky-linux-gcc (GCC) > 7.3.0) debug=y Tue Mar 5 20:57:55 EET 2019 > (XEN) Latest ChangeSet: Mon May 8 13:45:21 2017 +0300 git:a438317-dirty > (XEN) Processor: 411fd073: "ARM Limited", variant: 0x1, part 0xd07, rev 0x3 > (XEN) 64-bit Execution: > (XEN) Processor Features: > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > (XEN) Extensions: FloatingPoint AdvancedSIMD > (XEN) Debug Features: 10305106 > (XEN) Auxiliary Features: > (XEN) Memory Model Features: 1124 > (XEN) ISA Features: 00011120 > (XEN) 32-bit Execution: > (XEN) Processor Features: 0131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 03010066 > (XEN) Auxiliary Features: > (XEN) Memory Model Features: 10201105 4000 0126 02102211 > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > (XEN) Using PSCI-1.0 for SMP bringup > (XEN) SMP: Allowing 8 CPUs > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=f101 > (XEN) gic_cpu_addr=f102 > (XEN) gic_hyp_addr=f104 > (XEN) gic_vcpu_addr=f106 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: Adjusting CPU interface base to 0xf102f000 > (XEN) GICv2: 512 lines, 8 cpus, secure (IID 0200043b). > (XEN) XSM Framework v1.0.0 initialized > (XEN) xsm: Policy len = 0x0001 start at 0x7c00 > (XEN) Flask: 128 avtab hash slots, 280 rules. > (XEN) Flask: 128 avtab hash slots, 280 rules. > (XEN) Flask: 4 users, 3 roles, 38 types, 2 bools > (XEN) Flask: 12 classes, 280 rules > (XEN) Flask: Starting in enforcing mode. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Allocated console ring of 64 KiB. > (XEN) Bringing up CPU1 > - CPU 0001 booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 1 booted. > (XEN) Bringing up CPU2 > - CPU 0002 booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 2 booted. > (XEN) Bringing up CPU3 > - CPU 0003 booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 3 booted. > (XEN) Bringing up CPU4 > - CPU 0100 booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 4 booted. > (XEN) Bringing up CPU5 > - CPU 0101 booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 5 booted. > (XEN) Bringing up CPU6 > - CPU 0102 booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 6 booted. > (XEN) Bringing up CPU7 > - CPU 0103 booting - > - Current EL 0008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 7 booted. > (XEN) Brought up 8 CPUs > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 >
[Xen-devel] Running XEN on imx8mq
Hi,
Trying to run XEN on imx8mq which is different from imx8qm in term of
UART controller IP(attached is the debug code).
DTS used for host is :
https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_4.9.x_2.0.0_ga/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi
But , I see following issue:
=> setenv xen_addr_r 0x4200 ;setenv fdt_addr_r 0x4300;setenv
kernel_addr_r 0x4048
=> setenv fdt_high 0x;fdt addr $fdt_addr_r;fdt resize
=> setenv xen_bootargs console=dtuart dom0_mem=1024M
=> setenv dom0_bootargs console=hvc0,115200n8 earlycon=xenboot debug
clk_ignore_unused root=/dev/mmcblk1p1 rw rootwait
=> fdt set /chosen xen,xen-bootargs \"$xen_bootargs\";
=> fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\";fdt mknode
/chosen modules
=> fdt set /chosen/modules '#address-cells' <1>;fdt set
/chosen/modules '#size-cells' <1>;fdt mknode /chosen/modules module@0
=> fdt set /chosen/modules/module@0 compatible "xen,linux-zimage"
"xen,multiboot-module"
=> fdt set /chosen/modules/module@0 reg < $kernel_addr_r 0x180 >
=>
=> booti ${xen_addr_r} - ${fdt_addr_r}
## Flattened Device Tree blob at 4300
Booting using the fdt blob at 0x4300
reserving fdt memory region: addr=4300 size=d000
Loading Device Tree to be51, end be51 ... OK
Starting kernel ...
- UART enabled -
- CPU booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: be51 - be51d000 Device Tree
(XEN) MODULE[1]: 4048 - 41c8 Kernel
(XEN) RESVD[0]: 4300 - 4300d000
(XEN) RESVD[1]: be51 - be51d000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=1024M
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@3086", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
Xen 4.12.0-rc
(XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC
7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y Mon Mar 18
12:30:38 I9
(XEN) Latest ChangeSet: Tue Mar 5 12:48:52 2019 + git:4deeaf2-dirty
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN) Processor Features: 0100
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN) Debug Features: 10305106
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 1122
(XEN) ISA Features: 00011120
(XEN) 32-bit Execution:
(XEN) Processor Features: 0131:10011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 03010066
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 10201105 4000 0126 02102211
(XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.0
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv3 initialization:
(XEN) gic_dist_addr=0x003880
(XEN) gic_maintenance_irq=25
(XEN) gic_rdist_stride=0
(XEN) gic_rdist_regions=1
(XEN) redistributor regions:
(XEN) - region 0: 0x003888 - 0x003894
(XEN) GICv3: 160 lines, (IID 0001143b).
(XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN) load_precision_shift: 18
(XEN) load_window_shift: 30
(XEN) underload_balance_tolerance: 0
(XEN) overload_balance_tolerance: -3
(XEN) runqueues arrangement: socket
(XEN) cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN) First cpu on runqueue, activating
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU1: Found redistributor in region 0 @4003a000
(XEN) Adding cpu 1 to runqueue 0
(XEN) CPU 1 booted.
(XEN) Bringing up CPU2
- CPU 0002 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) GICv3: CPU2: Found redistributor in region 0 @4005a000
(XEN) Adding cpu 2 to runqueue 0
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
- CPU 0003 booting -
- Curre
Re: [Xen-devel] Running XEN on imx8mq
Hello, > The tree you are using is dirty. What did you change? Just added the imx8mq specific debug so that we can see early prints from XEN, > > [..] > > > (XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000 > > (XEN) Adding cpu 3 to runqueue 0 > > (XEN) CPU 3 booted. > > (XEN) Brought up 4 CPUs > > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID > > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > > (XEN) I/O virtualisation disabled > > (XEN) build-id: d884da2ad279978f5b120cd02aca4034d898f133 > > (XEN) alternatives: Patching with alt table 002abbf8 -> > > 002ac240 > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Loading Domd0 kernel from boot module @ 4048 > > (XEN) Allocating 1:1 mappings totalling 1024MB for dom0: > > (XEN) BANK[0] 0x006000-0x00a000 (1024MB) > > (XEN) Grant table range: 0x004200-0x004204 > > (XEN) Allocating PPI 16 for event channel interrupt > > (XEN) Loading zImage from 4048 to > > 6008-6188 > > (XEN) dom0 IPA 0x6008 > > (XEN) P2M @ 000801bff4a0 mfn:0xbffcc > > (XEN) Using concatenated root table 0 > > (XEN) 1ST[0x1] = 0x02c046fd > > (XEN) > > (XEN) Panic on CPU 0: > > (XEN) Unable to copy the kernel in the hwdom memory > > (XEN) > > This looks like the same problem on encounter on the RCar. I.e the > reserved-memory regions are not carved from xenheap pool. This is the first thing we tried (removing reserved node from DTS file) but it didn't work :( Just wondering here, if it has some thing to do with following commit ? https://source.codeaurora.org/external/imx/imx-xen/commit/?h=imx_4.14.62_1.0.0_beta&id=502413d9240169068cde9d73e0d4aa0675978bc5 -Thanks. Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Running XEN on imx8mq
> It will be difficult to help without any log. You probably want to try with > Stefano series instead. However ... Yeah, tried Stefano series as well but show same message: Starting kernel ... - UART enabled - - CPU booting - - Current EL 0008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) fdt: node `linux,cma': missing `reg' property (XEN) Checking for initrd in /chosen (XEN) RAM: 4000 - bfff (XEN) (XEN) MODULE[0]: be51 - be51d000 Device Tree (XEN) MODULE[1]: 4048 - 4268 Kernel (XEN) RESVD[0]: 4300 - 4300d000 (XEN) RESVD[1]: be51 - be51d000 (XEN) (XEN) Command line: console=dtuart dom0_mem=2048M (XEN) Placing Xen at 0xbfe0-0xc000 (XEN) Update BOOTMOD_XEN from 4200-42118d81 => bfe0-bff18d81 (XEN) Domain heap initialised (XEN) Booting using Device Tree (XEN) Platform: Generic System (XEN) Taking dtuart configuration from /chosen/stdout-path (XEN) Looking for dtuart at "/serial@3086", options "" (XEN) Unable to initialize dtuart: -9 (XEN) Bad console= option 'dtuart' Xen 4.12-unstable (XEN) Xen version 4.12-unstable (amit@) (aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y Mon Mar 18 17:49:9 (XEN) Latest ChangeSet: Thu Mar 7 13:22:10 2019 -0800 git:62617af (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4 (XEN) 64-bit Execution: (XEN) Processor Features: 0100 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1122 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:10011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Using SMC Calling Convention v1.0 (XEN) Using PSCI v1.0 (XEN) SMP: Allowing 4 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz (XEN) GICv3 initialization: (XEN) gic_dist_addr=0x003880 (XEN) gic_maintenance_irq=25 (XEN) gic_rdist_stride=0 (XEN) gic_rdist_regions=1 (XEN) redistributor regions: (XEN) - region 0: 0x003888 - 0x003894 (XEN) GICv3: 160 lines, (IID 0001143b). (XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000 (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Adding cpu 0 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Allocated console ring of 32 KiB. (XEN) Bringing up CPU1 - CPU 0001 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU1: Found redistributor in region 0 @4003a000 (XEN) Adding cpu 1 to runqueue 0 (XEN) CPU 1 booted. (XEN) Bringing up CPU2 - CPU 0002 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU2: Found redistributor in region 0 @4005a000 (XEN) Adding cpu 2 to runqueue 0 (XEN) CPU 2 booted. (XEN) Bringing up CPU3 - CPU 0003 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000 (XEN) Adding cpu 3 to runqueue 0 (XEN) CPU 3 booted. (XEN) Brought up 4 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) I/O virtualisation disabled (XEN) build-id: 1635738d31cfca03ae48949e8cd29221cdfe458c (XEN) alternatives: Patching with alt table 002aba18 -> 002ac018 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 4048 (XEN) Allocating 1:1 mappings totalling 2048MB for dom0: (XEN) WARNING: Failed to allocate requested dom0 memory. 224MB unallocated (XEN) BANK[0] 0x004400-0x00b600 (1824MB) (XEN) Grant table range: 0x00bfe0-0x00bfe4 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Load
Re: [Xen-devel] Running XEN on imx8mq
Hello, > It will be difficult to help without any log. You probably want to try with > Stefano series instead. However ... If we comment out GPU node(gpu@3800) , we don't see this issue and Dom0 kernel is loaded into memory but we following crash: Starting kernel ... - UART enabled - - CPU booting - - Current EL 0008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 4000 - bfff (XEN) (XEN) MODULE[0]: be511000 - be51d000 Device Tree (XEN) MODULE[1]: 4048 - 4268 Kernel (XEN) RESVD[0]: 4300 - 4300c000 (XEN) RESVD[1]: be511000 - be51d000 (XEN) (XEN) (XEN) Command line: console=dtuart dom0_mem=1024M (XEN) Domain heap initialised (XEN) Booting using Device Tree (XEN) Platform: Generic System (XEN) Taking dtuart configuration from /chosen/stdout-path (XEN) Looking for dtuart at "/serial@3086", options "" (XEN) Unable to initialize dtuart: -9 (XEN) Bad console= option 'dtuart' Xen 4.12.0-rc (XEN) Xen version 4.12.0-rc (amit@) (aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y Mon Mar 18 20:31:35 I9 (XEN) Latest ChangeSet: Tue Mar 5 12:48:52 2019 + git:4deeaf2 (XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4 (XEN) 64-bit Execution: (XEN) Processor Features: 0100 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1122 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:10011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Using SMC Calling Convention v1.0 (XEN) Using PSCI v1.0 (XEN) SMP: Allowing 4 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz (XEN) GICv3 initialization: (XEN) gic_dist_addr=0x003880 (XEN) gic_maintenance_irq=25 (XEN) gic_rdist_stride=0 (XEN) gic_rdist_regions=1 (XEN) redistributor regions: (XEN) - region 0: 0x003888 - 0x003894 (XEN) GICv3: 160 lines, (IID 0001143b). (XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000 (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Adding cpu 0 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Allocated console ring of 32 KiB. (XEN) Bringing up CPU1 - CPU 0001 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU1: Found redistributor in region 0 @4003a000 (XEN) Adding cpu 1 to runqueue 0 (XEN) CPU 1 booted. (XEN) Bringing up CPU2 - CPU 0002 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU2: Found redistributor in region 0 @4005a000 (XEN) Adding cpu 2 to runqueue 0 (XEN) CPU 2 booted. (XEN) Bringing up CPU3 - CPU 0003 booting - - Current EL 0008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU3: Found redistributor in region 0 @4007a000 (XEN) Adding cpu 3 to runqueue 0 (XEN) CPU 3 booted. (XEN) Brought up 4 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) I/O virtualisation disabled (XEN) build-id: e89d2543bdd91038674917e9d0be5b56a3ef0fd7 (XEN) alternatives: Patching with alt table 002abbd8 -> 002ac220 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading Domd0 kernel from boot module @ 4048 (XEN) Allocating 1:1 mappings totalling 1024MB for dom0: (XEN) BANK[0] 0x006000-0x00a000 (1024MB) (XEN) Grant table range: 0x004200-0x004204 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading zImage from 4048 to 6008-6228 (XEN) Loading dom0 DTB to 0x6800-0x6800b99e (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN)
Re: [Xen-devel] Arm boot regression with Xen 4.12
Hi,
> Could you give a try to the below patch?
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 01ae20..2c34138bbd 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1139,7 +1139,7 @@ void free_init_memory(void)
> *(p + i) = insn;
>
> set_pte_flags_on_range(__init_begin, len, mg_clear);
> -init_domheap_pages(pa, pa + len);
> +dt_unreserved_regions(pa, pa + len, init_domheap_pages, 0);
> printk("Freed %ldkB init memory.\n",
> (long)(__init_end-__init_begin)>>10);
> }
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 444857a967..8dbc4f819b 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -764,18 +764,18 @@ void __init start_xen(unsigned long boot_phys_offset,
>"Please check your bootloader.\n",
>fdt_paddr);
>
> -fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
> -
> -cmdline = boot_fdt_cmdline(device_tree_flattened);
> -printk("Command line: %s\n", cmdline);
> -cmdline_parse(cmdline);
> -
> /* Register Xen's load address as a boot module. */
> xen_bootmodule = add_boot_module(BOOTMOD_XEN,
> (paddr_t)(uintptr_t)(_start + boot_phys_offset),
> (paddr_t)(uintptr_t)(_end - _start + 1), false);
> BUG_ON(!xen_bootmodule);
>
> +fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
> +
> +cmdline = boot_fdt_cmdline(device_tree_flattened);
> +printk("Command line: %s\n", cmdline);
> +cmdline_parse(cmdline);
> +
> setup_pagetables(boot_phys_offset);
>
> setup_mm(fdt_paddr, fdt_size);
>
I tried the above patch but still see the same crash:
tarting kernel ...
- UART enabled -
- CPU booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 4000 - bfff
(XEN)
(XEN) MODULE[0]: 4200 - 42120d81 Xen
(XEN) MODULE[1]: be51 - be51d000 Device Tree
(XEN) MODULE[2]: 4048 - 4268 Kernel
(XEN) RESVD[0]: 4300 - 4300d000
(XEN) RESVD[1]: be51 - be51d000
(XEN)
(XEN)
(XEN) Command line: console=dtuart dom0_mem=1024M
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Generic System
(XEN) Taking dtuart configuration from /chosen/stdout-path
(XEN) Looking for dtuart at "/serial@3086", options ""
(XEN) Unable to initialize dtuart: -9
(XEN) Bad console= option 'dtuart'
Xen 4.13-unstable
(XEN) Xen version 4.13-unstable (atomar@) (aarch64-linux-gnu-gcc
(Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision
d29120a424ecfbc167ef90065c0eeb7f91977701]) debug=y Tue Mar 19 19:14:9
(XEN) Latest ChangeSet: Tue Feb 12 18:33:30 2019 + git:1e780ef-dirty
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN) Processor Features: 0100
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN) Debug Features: 10305106
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 1122
(XEN) ISA Features: 00011120
(XEN) 32-bit Execution:
(XEN) Processor Features: 0131:10011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 03010066
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 10201105 4000 0126 02102211
(XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.0
(XEN) Using PSCI v1.0
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
(XEN) GICv3 initialization:
(XEN) gic_dist_addr=0x003880
(XEN) gic_maintenance_irq=25
(XEN) gic_rdist_stride=0
(XEN) gic_rdist_regions=1
(XEN) redistributor regions:
(XEN) - region 0: 0x003888 - 0x003894
(XEN) GICv3: 160 lines, (IID 0001143b).
(XEN) GICv3: CPU0: Found redistributor in region 0 @4001a000
(XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN) load_precision_shift: 18
(XEN) load_window_shift: 30
(XEN) underload_balance_tolerance: 0
(XEN) overload_balance_tolerance: -3
(XEN) runqueues arrangement: socket
(XEN) cap enforcement granularity: 10ms
(XEN) load tracking window length 1073741824 ns
(XEN) Adding cpu 0 to runqueue 0
(XEN) First cpu on runqueue, activating
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1
- CPU 0001 booting -
- Current EL 0008 -
- Xen starting at EL2 -
- Setting up control registers -
- Turning on pagin
Re: [Xen-devel] [PATCH v1 1/2] xen/arm: Add Amlogic Meson SoCs earlyprintk support
Hi, > Apart from this and the unneeded addition to early-printk.txt (which > Julien mentioned already) this looks now correct to me. I was wondering, if it's a good idea to have "CONFIG_EARLY_PRINTK=meson,0xc81004c0" documented in Rules.mk. It would give fair idea to someone who is new to Xen, how to compile meson with early printk support ? Thanks -Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Arm boot regression with Xen 4.12
Hi, > I am wondering if you had time to bisect the issue? > > We are releasing Xen 4.12 soon so we need to make the decision whether this > should be fixed after (and backport it) or before. I am planning to look at it on this weekends and let you know if I find something. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] xen/arm: Add MESON UART driver for Amlogic Meson SoCs
Hello, On Tue, Apr 9, 2019 at 3:09 PM Julien Grall wrote: > > Hi, > > On 02/04/2019 21:01, André Przywara wrote: > > On 21/03/2019 10:25, Amit Singh Tomar wrote: > >> This patch adds driver for UART controller present on Amlogic Meson > >> SoCs and it has been tested on Nanopi K2 board based on S905 SoC. > >> > >> Controller registers defination is taken from Linux 4.20. > >> https://github.com/torvalds/linux/blob/v4.20-rc1/drivers/tty/serial/meson_uart.c > >> > >> Signed-off-by: Amit Singh Tomar > > > > Thanks for the changes! > > > > Reviewed-by: Andre Przywara > > Acked-by: Julien Grall Thanks. > I have committed this patch and the following patch. Please resend the first > patch with the comments addressed. Is it the patch with following subject: [PATCH v2 1/3] xen/arm: Add Amlogic Meson SoCs earlyprintk support Really, couldn't find any comments over there. -Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] xen/arm: Add Amlogic Meson SoCs earlyprintk support
Hello, > Do all the firmware existing for this platform initialize the UART? U-boot does also initialize the uart for this platform. https://github.com/u-boot/u-boot/blob/master/drivers/serial/serial_meson.c#L44 Thanks, -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Blacklist PMU with "arm, cortex-a53-pmu"
Hello, > After talking via IRC, the problem is PPIs, that this platform uses for > PMU interrupts. When Xen tries to setup the IRQ forwarding for Dom0 for > this device, it fails because it only supports forwarding SPIs. > So interestingly we erroneously forwarded A53 PMUs (those that are > described by that particular compatible string only) to Dom0 for quite a > while, but nobody noticed (or cared). > > Amit, please adjust the commit message accordingly. > Ok but original commit "d45e9b7c53428a2aa4d067927e7ef5e30783fb8b" that blacklist PMU's clearly states that issue is due to PPI and that can not be routed to guest. I thought, This patch is just continuation of same. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Arm boot regression with Xen 4.12
Hello, On Fri, Mar 22, 2019 at 5:05 PM Amit Tomer wrote: > > Hi, > > > > I am wondering if you had time to bisect the issue? > > > > We are releasing Xen 4.12 soon so we need to make the decision whether this > > should be fixed after (and backport it) or before. Don't see this crash if I chose to have different load addresses(Load kernel at 2 MB aligned address). For instance, using "setenv xen_addr_r 0x4048 ;setenv fdt_addr_r 0x4300;setenv kernel_addr_r 0x4100" instead of "setenv xen_addr_r 0x4200 ;setenv fdt_addr_r 0x4300;setenv kernel_addr_r 0x4048" Allow it boot properly(Tested it with 4.13). Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Blacklist PMU with "arm, cortex-a53-pmu"
Hello, > Could we instead try to automatically blacklist any device using PPI? Just tested following change: diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index d983677..0c82976 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1289,6 +1289,10 @@ static int __init handle_device(struct domain *d, struct dt_device_node *dev, return res; } +/* Don't process device using PPI source */ +if ( res > 16 && res < 32) +return 0; + res = map_irq_to_domain(d, res, need_mapping, dt_node_name(dev)); if ( res ) return res; Would it be Ok ? Thanks, -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Blacklist PMU with "arm, cortex-a53-pmu"
Hello,
>
> The proper way is to detect PPI before hand and completely skip the node if
> any.
I tried the following change:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..a9ecfed 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1353,7 +1353,7 @@ static int __init handle_node(struct domain *d,
struct kernel_info *kinfo,
{ /* sentinel */ },
};
struct dt_device_node *child;
-int res;
+int res, irq_id;
const char *name;
const char *path;
@@ -1399,6 +1399,16 @@ static int __init handle_node(struct domain *d,
struct kernel_info *kinfo,
return 0;
}
+/*Skip the node, using PPI source */
+irq_id = platform_get_irq(node, 0);
+
+if ( irq_id > 16 && irq_id < 32 )
+{
+dt_dprintk(" Skip node with (PPI source)\n");
+return 0;
+}
+
+
After booting dom0, don't see PMU node is getting generated(its
skipped completely now).
Thanks,
-Amit.
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v1] xen/arm: Add MVEBU UART driver for Armada 3700 SoC
Hello, > I tested this on my board and it works like expected. I would very much > like to see this driver still in 4.11. Thanks for looking into it and Many Thanks for testing it out. > > Some (minor) comments on the code below. > > On 16/03/18 17:34, Amit Singh Tomar wrote: >> This patch adds driver for UART controller found on Armada 3700 SoC. > > Can you please mention "Marvell" in the subject? Ok. > These should be indented by one tab (plus two spaces for the help text). > It's not obvious - I got this wrong myself the other day ;-), but it's > how the rest of the file works. Ok. > No need for the brackets. Ok. > Indentation. Ok. > So why do we need this include file, in a shared directory? > All those bits are private to the UART driver and don't need to be > exposed to Xen at all. > If it's about the earlyprintk support: that's just two values needed > there, nothing worth a new include file, I think. > So I would recommend to declare the required constants directly in the > driver file. Yes, I thought earlyprintk could also use a couple of common defines and other drivers do the same way. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC
Hi, > Just a nit, but it might be smarter to first check for the receive IRQ, > because not handling this might loose information. TX is less critical. Ok, actually tried it ealier when I was debugging the Rx path issue and that time it didn't work. May be I should try it again. > Similar to the earlyprintk behaviour we are a bit pessimistic here. I > don't know if there is a way to determine the number of free characters > in the FIFO, but we could at least return 1 if the FIFO is not full: > > if (fifo_empty) > return FIFO_SIZE; > if (!fifo_full) > return 1; > return 0; Yeah, I thought of it initially like should we also return half the size of FIFO(16) when STAT_TX_FIFO_HFL bit is set ? Thanks -Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC
Hi, > Ah yes, if that works, we should. That bit is from the Linux BSP, isn't it? Yes, it's from Linux BSP code only. Hope following is fine. if ( reg & STATUS_TXFIFO_EMP ) return TX_FIFO_SIZE; else if ( reg & STAT_TX_FIFO_HFL ) return TX_FIFO_SIZE / 2; else if ( !(reg & STAT_TX_FIFO_FUL) ) return 1; return 0; Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] xen/arm: Add MVEBU UART driver for Marvell Armada 3700 SoC
Hi, > Works like a charm, can log into Dom0, Xen console works as well. So in > addition to my Reviewed-by: > > Tested-by: Andre Przywara > Thank you for your time on this! Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3 2/2] xen/arm: Add Marvell ARMADA 3700 early printk support
Hi, > Compiled with CONFIG_EARLY_PRINTK=mvebu, I see Xen's pre-DT boot > messages. In addition to my Reviewed-by: > > Tested-by: Andre Przywara > Thank you! Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [cubieboard2] Bringing up dom0
Hello > > debian@debian-armhf:~$ sudo xl list > NameID Mem VCPUsState > Time(s) > > > Now what am I missing? You may need to run following # /etc/init.d/xencommons start Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH] xen/arm64: Add Support for Marvell ARMADA 3700 SoC
Hi, Thanks for looking into. > Would you mind creating a page on Xen wiki to explain how to boot Xen on > that board? See [1]. Sure, I would do it and it was on my TODO list as well. Thanks Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC
Hi
Thanks for the comments.
> OOI, do you have any plan for adding earlyprintk support for that platform?
I didn't think about it but I would look into it.
> Please give a link to the Linux driver. This would help me for reviewing and
> also for future reference.
Ok.
> This is part of xen/drivers/char/* so even if the driver if only for ARM
> hardware, you likely want to CC "THE REST" maintainers as this is under
> drivers/char. scripts/get_maintainers.pl can help you to find relevant
> maintainers to CC on each patch.
Ok.
include should be first, then .
Ok, I was under the impression that it should be sorted in alphabetical order.
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
>
> xen/serial.h is mentioned twice.
Ok.
>
>> +#include
>> +
>> +#define UART_RX_REG 0x00
>> +#define RBR_BRK_DET BIT(15)
>> +#define RBR_FRM_ERR_DET BIT(14)
>> +#define RBR_PAR_ERR_DET BIT(13)
>> +#define RBR_OVR_ERR_DET BIT(12)
>> +
>> +#define UART_TX_REG 0x04
>> +
>> +#define UART_CTRL_REG 0x08
>> +#define CTRL_SOFT_RST BIT(31)
>> +#define CTRL_TXFIFO_RST BIT(15)
>> +#define CTRL_RXFIFO_RST BIT(14)
>> +#define CTRL_ST_MIRR_EN BIT(13)
>> +#define CTRL_LPBK_ENBIT(12)
>> +#define CTRL_SND_BRK_SEQBIT(11)
>> +#define CTRL_PAR_EN BIT(10)
>> +#define CTRL_TWO_STOP BIT(9)
>> +#define CTRL_TX_HFL_INT BIT(8)
>> +#define CTRL_RX_HFL_INT BIT(7)
>> +#define CTRL_TX_EMP_INT BIT(6)
>> +#define CTRL_TX_RDY_INT BIT(5)
>> +#define CTRL_RX_RDY_INT BIT(4)
>> +#define CTRL_BRK_DET_INTBIT(3)
>> +#define CTRL_FRM_ERR_INTBIT(2)
>> +#define CTRL_PAR_ERR_INTBIT(1)
>> +#define CTRL_OVR_ERR_INTBIT(0)
>> +#define CTRL_RX_INT (CTRL_BRK_DET_INT | CTRL_FRM_ERR_INT | \
>> + CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
>> +
>> +#define UART_STATUS_REG 0x0c
>> +#define STATUS_TXFIFO_EMP BIT(13)
>> +#define STATUS_RXFIFO_EMP BIT(12)
>> +#define STATUS_TXFIFO_FUL BIT(11)
>> +#define STATUS_TXFIFO_HFL BIT(10)
>> +#define STATUS_RX_TOGL BIT(9)
>> +#define STATUS_RXFIFO_FUL BIT(8)
>> +#define STATUS_RXFIFO_HFL BIT(7)
>> +#define STATUS_TX_EMP BIT(6)
>> +#define STATUS_TX_RDY BIT(5)
>> +#define STATUS_RX_RDY BIT(4)
>> +#define STATUS_BRK_DET BIT(3)
>> +#define STATUS_FRM_ERR BIT(2)
>> +#define STATUS_PAR_ERR BIT(1)
>> +#define STATUS_OVR_ERR BIT(0)
>> +#define STATUS_BRK_ERR (STATUS_BRK_DET | STATUS_FRM_ERR | \
>> +STATUS_PAR_ERR | STATUS_OVR_ERR)
>> +
>> +#define UART_BAUD_REG 0x10
>> +#define UART_POSSR_REG 0x14
>
>
> Can you please only define only registers/bits used in the code?
Ok.
>> +
>> +#define TX_FIFO_SIZE32
>> +#define RX_FIFO_SIZE64
>> +
>> +static struct mvebu3700_uart {
>> +unsigned int baud, data_bits, parity, stop_bits;
>
>
> Are all those fields necessary? For instance, you always set baud but never
> read it.
Not sure about this as I don't know if these fields are used by XEN
serial infrastructure later on.
>> +unsigned int irq;
>> +void __iomem *regs;
>> +struct irqaction irqaction;
>> +struct vuart_info vuart;
>> +} mvebu3700_com = {0};
>> +
>> +#define PARITY_NONE (0)
>> +
>> +#define mvebu3700_read(uart, off) readl((uart)->regs + off)
>> +#define mvebu3700_write(uart, off, val) writel(val, (uart->regs) +
>> off)
>> +
>> +static void mvebu3700_uart_interrupt(int irq, void *data, struct
>> +cpu_user_regs *regs)
>
>
> The indentation looks wrong here.
>
>> +{
>> +struct serial_port *port = data;
>> +struct mvebu3700_uart *uart = port->uart;
>> +unsigned int st = mvebu3700_read(uart, UART_STATUS_REG);
>> +
>> +if ( st & STATUS_TX_RDY )
>> +serial_tx_interrupt(port, regs);
>> +
>> +if ( st & (STATUS_RX_RDY | STATUS_OVR_ERR | STATUS_FRM_ERR |
>> STATUS_BRK_DET) )
>> +serial_rx_interrupt(port, regs);
>> +}
>> +
>> +static void __init mvebu3700_uart_init_preirq(struct serial_port *port)
>> +{
>> +struct mvebu3700_uart *uart = port->uart;
>> +unsigned ret;
>
>
> 'ret' is a bit confusion. I would expect to be the return value of the
> function but it is used a temporary variable for reading/write reg. You
> might want to rename to 'reg' for more clarity.
Ok.
> But as this is a register value (i.e specific size), please use uint32_t.
>
>> +
>> +ret = mvebu3700_read(uart, UART_CTRL_REG);
>> +ret |= (CTRL_TXFIFO_RST | CTRL_RXFIFO_RST);
>> +mvebu3700_write(uart, UART_CTRL_REG, ret);
>> +
>> +/* Before we make IRQ request, Clear the error bits of state register
>> */
>
>
> s/Clear/clear/ and missing full stop.
Ok.
>
>
>> +ret = mvebu3700_read
Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC
Hi, > This is quite useful to get output without any serial driver. I am quite > impressed you managed to debug your serial driver without it :). Actually, we have earlycon=xenboot(suggested by Andre) enabled in Dom0 bootargs and it allowed us to debug XEN boot further. I am wondering if ealycon interface can be used in absence of earlyprintk doing same work? Thanks Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH] xen/arm: Add MVEBU UART driver for Armada 3700 SoC
> earlycon=xenboot enables the early console for the hardware domain only. > What I meant is having earlyprintk for Xen (see CONFIG_EARLY_PRINTK). This > is used for low-level debug when booting the hypervisor. Ok, Thanks. It's now clear to me. Thanks Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen support on arm64 platform
Hi, On Wed, Mar 21, 2018 at 11:27 AM, Jayadev Kumaran wrote: > Hello all, > > I need to setup Xen on Snapdragon 820 platform - armv8 64 bit architecture. > Is there support available for the same ? Is there Xen implementation on any > other similar platform ? From Initial investigation(I may be wrong), it looks like there is no XEN port available for Snapdragon 820. Specially , Snapdragon 820 uses the specific uart(./drivers/tty/serial/msm_serial.c from Linux ?) that has not been ported to XEN(Without it debugging would be difficult) Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 2/2] xen/arm: Add MESON UART driver for Amlogic S905 SoC
Hello,
Thanks for having a look at it.
> The spec does not seems to provide the offset register. Where did you find
> them?
Actually, looked at couple of references from u-boot and Linux. These
headers are picked from there.
> AFAIK, {0} is not necessary.
Ok.
>> +
>> +#define meson_s905_read(uart, off) readl((uart)->regs + off)
>> +#define meson_s905_write(uart, off, val) writel(val, (uart->regs) +
>> off)
>
>
> s/(uart->regs)/(uart)->regs/
>
>> +
>> +static void meson_s905_uart_interrupt(int irq, void *data,
>> +struct cpu_user_regs *regs)
>
>
> The indentation looks wrong here.
>
>> +{
>> +struct serial_port *port = data;
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t st = meson_s905_read(uart, UART_STATUS);
>> +
>> +if ( !(st & UART_RX_EMPTY) )
>> +{
>> +serial_rx_interrupt(port, regs);
>> +}
>> +
>> +if ( !(st & UART_TX_FULL) )
>> +{
>> +if ( st & UART_TX_INT_EN )
>> +serial_tx_interrupt(port, regs);
>> +}
>> +
>
>
> NIT: No need for this newline.
>
>> +}
>> +
>> +static void __init meson_s905_uart_init_preirq(struct serial_port *port)
>> +{
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t reg;
>> +
>> +reg = meson_s905_read(uart, UART_CONTROL);
>> +reg &= ~(UART_RX_RST | UART_TX_RST | UART_CLEAR_ERR);
>
>
> I am not sure why you are clearing those bits. AFAIU, init_preirq will reset
> the serials, so you want to set thoses bits. This seems to be confirmed by
> Linux in meson_uart_reset.
Idea here is to set these bits to their default values(which is 0 ) and if you
look at other drivers in XEN, it seems to be done same thing(clear
those bits) with them.
>
>> +reg = meson_s905_read(uart, UART_CONTROL);
>> +reg &= ~(UART_RX_INT_EN | UART_TX_INT_EN);
>> +meson_s905_write(uart, UART_CONTROL, reg);
>> +}
>> +
>> +static void __init meson_s905_uart_init_postirq(struct serial_port *port)
>> +{
>> +struct meson_s905_uart *uart = port->uart;
>> +uint32_t reg;
>> +
>> +uart->irqaction.handler = meson_s905_uart_interrupt;
>> +uart->irqaction.name= "meson_s905_uart";
>> +uart->irqaction.dev_id = port;
>> +
>> +if ( setup_irq(uart->irq, 0, &uart->irqaction) != 0 )
>> +{
>> +printk("Failed to allocated meson_s905_uart IRQ %d\n",
>> uart->irq);
>> +return;
>> +}
>> +
>> +/* Configure Rx/Tx interrupts based on bytes in FIFO */
>> +reg = meson_s905_read(uart, UART_MISC);
>
>
> You read UART_MISC here but ...
>
>> +reg = (UART_RECV_IRQ_CNT_MASK & 1) |
>
>
> ... override the value here. You either want to drop reading UART_MISC or
> add | here.
Sorry, missed "|" somehow.
>
>> + (UART_XMIT_IRQ_CNT_MASK & ((TX_FIFO_SIZE / 2) << 8));
>
>
> This is a bit difficult to read. It feels like you want to use a macro with
> a parameter that will do the correct masking.
Ok, shall I take it from Linux ?
>> +
>> +static const struct dt_device_match meson_dt_match[] __initconst =
>> +{
>> +DT_MATCH_COMPATIBLE("amlogic,meson-uart"),
>
>
> Looking at Linux, this is considered as a legacy bindings. Would not it be
> better to use stable bindings in Xen?
>
Yeah, I took it from u-boot source and didn't realize that there are
stable binding exists.
Thanks
-Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support
Hello, > I would prefer if no new alias are added. The same could be achieved with > CONFIG_EARLY_PRINTK=meson,0xc81004c0. > > This could be documented on the wiki. Ok. > I would prefer if we stick with the spec name. So UART_TX_REG should be > renamed UART_WFIFO_REG. Yeah right, got your point. > > Also, it might be worth considering to prefix them with AML_ so it is easy > to find them on lookup. Initially used AML_ as prefix but then I just wanted to be consistent it with other uart drivers in XEN. > Looking at the earlyconsole implementation in Linux, it seems that TX needs > to be enabled first (see meson_uart_enable_tx_engine). > > Is it now done in the firmware? Yes, this has been done in u-boot. shouldn't we trust it? >> + */ >> +.macro early_uart_ready xb c >> +1: >> +ldrh w\c, [\xb, #UART_STATUS_REG] /* status register */ >> +tstw\c, #(1 << 21) /* Check TXFIFO FULL bit */ > > > Please define 1 << 21 rather than hardcoding it. Ok. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen:arm: Populate arm64 image header
Hello, > Yes, and in fact it seems one can work around this by cleverly > constructing the load addresses, But we are really dealing a corner case here. No matter where we load the image, it would be relocated to 0x8( since dram starts at 0x...) and unfortunately first 16MiB is reserved for ROM Firmware. > >> This unwanted situation can be fixed by updating image_size field > >> along side kernel flags so that image wouldn't relocate from initial > >> load address. > > > > I think the first step is to fix your U-boot and rethink where you load > > your binaries. > > I think U-Boot perfectly complies with the kernel document. Xen not so > much. The kernel image format was deliberately updated to become more > flexible with certain memory layout situations as we have here. > There is for instance a problem if there is something precious at 512KB > into DRAM (secure memory owned by firmware), as regardless of the load > addresses the user chooses U-Boot will (rightfully!) revert to the > original "512KB into DRAM" address to keep compatibility with older > kernels - and it believes Xen is such a one because of the ancient > header format. > > But ... > > > Regarding the patch in itself, I think this is a good addition as it > > allow Xen to be loaded in more places. But please rewrite the commit > > message accordingly, this is an update to a new version. > > I totally agree with that, the commit message should be reworded to > stress that we want to comply with a newer version of the kernel image > header (which is around for four years by now!), and just mention that > it fixes problems with non-ancient U-Boots on certain platforms as an > additional reason. > > >> [1]:https://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/lib/image.c;h=699bf44e702f7a7084997406203fd7d2aaaf87fa;hb=HEAD#l50 > >> > >> > >> These changes are derived from kernel v4.18 files > >> > >> Signed-off-by: Amit Singh Tomar > >> --- > >> xen/arch/arm/arm64/head.S | 5 ++- > >> xen/arch/arm/arm64/lib/assembler.h| 11 + > >> xen/arch/arm/xen.lds.S| 3 ++ > >> xen/include/asm-arm/arm64/linux_header_vars.h | 62 > >> +++ > >> 4 files changed, 79 insertions(+), 2 deletions(-) > >> create mode 100644 xen/include/asm-arm/arm64/linux_header_vars.h > >> > >> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S > >> index d63734f..ce72c95 100644 > >> --- a/xen/arch/arm/arm64/head.S > >> +++ b/xen/arch/arm/arm64/head.S > >> @@ -25,6 +25,7 @@ > >> #include > >> #include > >> #include > >> +#include "lib/assembler.h" > >> #define PT_PT 0xf7f /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=1 > >> P=1 */ > >> #define PT_MEM0xf7d /* nG=1 AF=1 SH=11 AP=01 NS=1 ATTR=111 T=0 > >> P=1 */ > >> @@ -120,8 +121,8 @@ efi_head: > >> add x13, x18, #0x16 > >> b real_start /* branch to kernel start */ > >> .quad 0/* Image load offset from start > >> of RAM */ > >> -.quad 0/* reserved */ > >> -.quad 0/* reserved */ > >> +le64sym _kernel_size_le /* Effective size of kernel > >> image, little-endian */ > >> +le64sym _kernel_flags_le /* Informative flags, > >> little-endian */ > > > > All the dance for to convert to little endian is not necessary on Xen. > > Please rework your series to avoid such code, this would also reduce > > quite significantly the series. > > Indeed! How about this change? index ce72c95..ec29e01 100644 --- a/xen/arch/arm/arm64/head.S +++ b/xen/arch/arm/arm64/head.S @@ -121,8 +121,8 @@ efi_head: add x13, x18, #0x16 b real_start /* branch to kernel start */ .quad 0/* Image load offset from start of RAM */ -le64sym _kernel_size_le /* Effective size of kernel image, little-endian */ -le64sym _kernel_flags_le /* Informative flags, little-endian */ +.quad _end - start /* Effective size of kernel image, little-endian */ +.quad __HEAD_FLAGS /* Informative flags, little-endian */ .quad 0/* reserved */ .quad 0/* reserved */ .quad 0/* reserved */ diff --git a/xen/arch/arm/arm64/lib/assembler.h b/xen/arch/arm/arm64/lib/assembler.h index c0ef758..05861b8 100644 --- a/xen/arch/arm/arm64/lib/assembler.h +++ b/xen/arch/arm/arm64/lib/assembler.h @@ -9,15 +9,11 @@ #define CPU_BE(x...) #define CPU_LE(x...) x -/* - * Emit a 64-bit absolute little endian symbol reference in a way that - * ensures that it will be resolved at build time, even when building a - * PIE binary. This requires cooperation from the linker script, which - * must emit the lo32/hi32 halves individually. - */ -.macro le64sym, sym -.long \sym\()_lo32 -.long
Re: [Xen-devel] [PATCH v2] xen:arm: Populate arm64 image header
Hello, Thanks for having a look. On Wed, Sep 5, 2018 at 6:07 PM Andre Przywara wrote: > > Hi, > > I don't think it's helpful to hide that KERNEL_SIZE definition in > another file. Please just put "_end - start" here. Yeah, I thought about it and felt that it would be cleaner and more readable if we use macros here. Also, wanted to have minimal changes in head.S and that is the reason for using assemble.h. > Either you call this __HEAD_FLAG_PAGE_SIZE_4K, or, even better, copy the > Linux definition, which would make it obvious where this comes from and > would alert any developer of the PAGE_SIZE dependency. > > Plus move those into head.S, as mentioned above. Ok. > > + > > +#define __KERNEL_SIZE (_end - start) > > + > > #endif /* __ASM_ASSEMBLER_H__ */ > > Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support
Hello, > I am trying to understand why Linux is doing it. Do you expect all > U-Boot version to do it? It's because Linux doesn't really trust u-boot and initializes every thing again ? Mainline U-boot does it but that may also not required since ATF does it for us. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 2/2] xen/arm: Add MESON UART driver for Amlogic S905 SoC
Hello, > >>> +reg = meson_s905_read(uart, UART_CONTROL); > >>> +reg &= ~(UART_RX_RST | UART_TX_RST | UART_CLEAR_ERR); > >> > >> > >> I am not sure why you are clearing those bits. AFAIU, init_preirq will > >> reset > >> the serials, so you want to set thoses bits. This seems to be confirmed by > >> Linux in meson_uart_reset. > > > > Idea here is to set these bits to their default values(which is 0 ) and if > > you > > look at other drivers in XEN, it seems to be done same thing(clear > > those bits) with them. > > Are you sure about this? RX_RST and TX_RST are bit to reset the > transmission and receive path. Looking at a couple of different drivers > (cache-uart.c and mvebu-uart.c), those 2 bits are set and I suspect be > cleared by the hardware once reset. It's bit confusing to me, eventually Linux driver seems to clear those bits https://github.com/torvalds/linux/blob/master/drivers/tty/serial/meson_uart.c#L266 Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] ARM: GICv3: copy Dom0 GICv3 reg property from host DT
Hi,
Thanks for the patch.
On Tue, Jan 30, 2018 at 3:05 PM, Andre Przywara wrote:
> At the moment we re-generate the Dom0 GICv3 DT node, by creating the
> "reg" property from scratch using our previously parsed and
> translated(!) host addresses. However we then write the *absolute*
> addresses into the new node, not considering possible "range" mappings
> in any of the GIC's parent nodes. So whenever one of the parents has a
> non-empty ranges property, Dom0 will wrongly translate the addresses.
> Properly incorporating the ranges properties sounds tedious, so let's
> just copy the first part of the reg property instead (as we do for GICv2),
> since the addresses for Dom0 are identical to those from the hardware.
>
> The mainline kernel DT for the Espressobin board with an Marvell 3720 SoC
> has the GIC in such an translated bus, so this patch allows this board
> to boot properly (after adding support for the SoC's UART).
>
> Signed-off-by: Andre Przywara
> ---
> xen/arch/arm/gic-v3.c | 29 +++--
> 1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a0d290b55c..6b17abd0a1 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1147,10 +1147,9 @@ static int gicv3_make_hwdom_dt_node(const struct
> domain *d,
> const struct dt_device_node *gic,
> void *fdt)
> {
> -const void *compatible = NULL;
> -uint32_t len;
> -__be32 *new_cells, *tmp;
> -int i, res = 0;
> +const void *compatible, *hw_reg;
> +uint32_t len, new_len;
> +int res;
>
> compatible = dt_get_property(gic, "compatible", &len);
> if ( !compatible )
> @@ -1173,27 +1172,21 @@ static int gicv3_make_hwdom_dt_node(const struct
> domain *d,
> if ( res )
> return res;
>
> -len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
> +new_len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
> /*
> * GIC has two memory regions: Distributor + rdist regions
> * CPU interface and virtual cpu interfaces accessesed as System
> registers
> * So cells are created only for Distributor and rdist regions
> */
> -len = len * (d->arch.vgic.nr_regions + 1);
> -new_cells = xzalloc_bytes(len);
> -if ( new_cells == NULL )
> -return -FDT_ERR_XEN(ENOMEM);
> -
> -tmp = new_cells;
> -
> -dt_set_range(&tmp, gic, d->arch.vgic.dbase, SZ_64K);
> +new_len = new_len * (d->arch.vgic.nr_regions + 1);
>
> -for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
> -dt_set_range(&tmp, gic, d->arch.vgic.rdist_regions[i].base,
> - d->arch.vgic.rdist_regions[i].size);
> +hw_reg = dt_get_property(gic, "reg", &len);
> +if ( !hw_reg )
> +return -FDT_ERR_XEN(ENOENT);
> +if ( new_len > len )
> + return -FDT_ERR_XEN(ERANGE);
>
> -res = fdt_property(fdt, "reg", new_cells, len);
> -xfree(new_cells);
> +res = fdt_property(fdt, "reg", hw_reg, new_len);
> if ( res )
> return res;
>
> --
> 2.14.1
>
Tested on Espresso bin:
Tested-by: Amit Singh Tomar
Thanks
-Amit
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH 1/2] xen/arm: Add Amlogic S905 SoC early printk support
Hi, Thanks for having a detailed look at it. > > +#define UART_STATUS_REG 0x0c > > +#define UART_TX_REG 0x00 >> Why ldrh? This is a 32-bit register, actually you can't be sure that the > device supports a 16-bit access. Besides: the bit you are after is in > the upper half, so you actually will never see the bit set. I wonder if > you are loosing characters here. Let me confess with ldrh, I do see output scattered all over the screen and really wondering why the hell I didn't notice it when I sent this RFC. Very sorry about that. > > +.macro early_uart_transmit xb wt > > + strb \wt, [\xb, #UART_TX_REG] > > TX_WFIFO is a 32-bit register, so you should rather use a 32-bit > accessor. Ok.I guess "str" would be OK to use ? Thanks -Amit. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Fix platform name for Xilinx ZynqMP
Hi, > I guess you mean: xilinx_zynqmp, ... ? Sorry, I would fix and repost it. Thanks for looking. -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: dom0 LInux 5.8-rc5 kernel failing to initialize cooling maps for Allwinner H6 SoC
Hi, > I remember this discussion. The problem was that the PMU is using > per-CPU interrupts. Xen is not yet able to handle PPIs as they often > requires more context to be saved/restored (in this case the PMU context). > > There was a proposal to look if a device is using PPIs and just remove > them from the Device-Tree. Unfortunately, I haven't seen any official > submission for this patch. But we have this patch that remove devices using PPIs http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9b1a31922ac066ef0dffe36ebd6a6ba016567d69 Thanks -Amit
Re: [Xen-devel] [RFC PATCH 0/2] XEN booting on i.MX8M platform
Hi, On Sat, Jun 8, 2019 at 1:46 AM Amit Singh Tomar wrote: > > This series tries to enable XEN booting on i.MX 8MQuad Applications > Processors[1]. > > Patch-set includes driver for UART controller found on i.MX8MQ SoC and debug > code > for earlyprintk support. > Gentle Ping. Thanks -Amit ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
