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.
>
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 so
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
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
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 dif
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
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
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
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] exite
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] c
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 i
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_add
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
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
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 tho
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:/
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
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
> trea
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 nego
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
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
_
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
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
me
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 s
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 boot
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-77a23
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 issu
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)
> 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
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
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_
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,
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
___
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 S
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 lis
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
> descri
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 befo
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,1
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
@@
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
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 t
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 ( !(re
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
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.xenproje
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
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.
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/dri
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 ealyco
> 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
___
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
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(
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
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 f
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
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
___
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 confirm
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 i
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 act
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
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
> t
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
__
61 matches
Mail list logo
