From: Jan Kiszka <jan.kiszka@siemens.com>
To: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
devicetree <devicetree@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
Jailhouse <jailhouse-dev@googlegroups.com>,
"Måns Rullgård" <mans@denx.de>,
"Antonios Motakis" <antonios.motakis@huawei.com>
Subject: Re: Using DT overlays for adding virtual hardware
Date: Tue, 21 Jun 2016 12:13:22 +0200 [thread overview]
Message-ID: <57691342.2020502@siemens.com> (raw)
In-Reply-To: <5759069B.4080800@siemens.com>
Hi Pantelis,
coming back to this topic:
On 2016-06-09 08:03, Jan Kiszka wrote:
> OK, trial and error, and some interesting insights: I've played with DT
> fragments and the overlay configfs patch of Pantelis [1] to have a
> convenient start. Interestingly, I wasn't able to load a fragment that
> followed the format specification for overlays ("Failed to resolve
> tree"). By chance, I got this one working:
>
> /dts-v1/;
> / {
> fragment {
> target-path = "/soc@01c00000";
> __overlay__ {
> #address-cells = <2>;
> #size-cells = <2>;
>
> vpci@0x2000000 {
> compatible = "pci-host-cam-generic";
> device_type = "pci";
> #address-cells = <3>;
> #size-cells = <2>;
> reg = <0 0x2000000 0 0x1000000>;
> ranges =
> <0x02000000 0x00 0x10000000 0x00 0x10000000 0x00 0x30000000>;
> };
> };
> };
> };
>
> It successfully makes a BananaPi kernel add a pci host with the
> specified config space and MMIO window.
>
> [ 81.619583] PCI host bridge /soc@01c00000/vpci@0x2000000 ranges:
> [ 81.619610] No bus range found for /soc@01c00000/vpci@0x2000000, using [bus 00-ff]
> [ 81.619634] MEM 0x10000000..0x3fffffff -> 0x10000000
> [ 81.620482] pci-host-generic 2000000.vpci: ECAM at [mem 0x02000000-0x02ffffff] for [bus 00-ff]
> [ 81.620779] pci-host-generic 2000000.vpci: PCI host bridge to bus 0000:00
> [ 81.620801] pci_bus 0000:00: root bus resource [bus 00-ff]
> [ 81.620814] pci_bus 0000:00: root bus resource [mem 0x10000000-0x3fffffff]
> [ 81.620851] PCI: bus0: Fast back to back transfers enabled
>
> So, no /plugin/ statement, no phandles resolution. This format even
> builds with the in-kernel dtc. Any explanations? Does the code make
> sense (at least it builds without warnings)?
>
> Now I need to back this with some code in Jailhouse.
Meanwhile I got a virtual PCI device recognized by Linux when running
over Jailhouse. However, my hack above doesn't get me to proper
interrupt mapping yet. This is what I was trying with upstream dtc:
/dts-v1/;
/ {
compatible = "lemaker,bananapi", "allwinner,sun7i-a20";
fragment@0 {
target-path = "/soc@01c00000";
__overlay__ {
#address-cells = <2>;
#size-cells = <2>;
vpci@2000000 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &gic 0 0 0 123 4>,
<0 0 0 2 &gic 0 0 0 124 4>,
<0 0 0 3 &gic 0 0 0 125 4>,
<0 0 0 4 &gic 0 0 0 126 4>;
reg = <0 0x2000000 0 0x100000>;
ranges =
<0x02000000 0x00 0x10000000 0x00 0x10000000 0x00 0x30000000>;
};
};
};
gic: fragment@1 {
target-path = "/soc@01c00000/interrupt-controller@01c81000";
__overlay__ {
};
};
};
And this is what Linux detects on that PCI bus:
00:0f.0 RAM memory: Red Hat, Inc Inter-VM shared memory
Subsystem: Red Hat, Inc Inter-VM shared memory
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: Memory at 10000000 (64-bit, non-prefetchable) [size=256]
Region 4: Memory at 10000100 (64-bit, non-prefetchable) [size=32]
Kernel modules: ivshmem_net
However, registering a handler on IRQ 17 fails (-EINVAL).
With your dtc [2] (dtc -@ -I dts -O dtb -o vpci-bpi.dtb vpci-bpi.dts)
and this fragment, I'm still not able to load the blob:
/dts-v1/;
/plugin/;
/ {
compatible = "lemaker,bananapi", "allwinner,sun7i-a20";
fragment@0 {
target-path = "/soc@01c00000";
__overlay__ {
#address-cells = <2>;
#size-cells = <2>;
vpci@2000000 {
compatible = "pci-host-ecam-generic";
device_type = "pci";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &gic 0 0 0 123 4>,
<0 0 0 2 &gic 0 0 0 124 4>,
<0 0 0 3 &gic 0 0 0 125 4>,
<0 0 0 4 &gic 0 0 0 126 4>;
reg = <0 0x2000000 0 0x100000>;
ranges =
<0x02000000 0x00 0x10000000 0x00 0x10000000 0x00 0x30000000>;
};
};
};
};
Any suggestions? Any patches I'm missing in upstream to make that work?
Jan
[1] https://github.com/pantoniou/linux-beagle-track-mainline/commit/160e68ec89eca33e8ed0abb13d52c07c54d7fc10
[2] https://github.com/pantoniou/dtc/tree/dgibson-overlay-panto
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2016-06-21 10:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 14:16 Using DT overlays for adding virtual hardware Jan Kiszka
2016-06-08 15:17 ` Mark Rutland
2016-06-08 15:27 ` Jan Kiszka
2016-06-08 15:57 ` Pantelis Antoniou
2016-06-08 15:57 ` Pantelis Antoniou
2016-06-08 16:23 ` Mark Rutland
2016-06-08 16:31 ` Pantelis Antoniou
2016-06-08 16:31 ` Pantelis Antoniou
2016-06-08 16:39 ` Jan Kiszka
2016-06-08 16:39 ` Jan Kiszka
2016-06-09 6:03 ` Jan Kiszka
2016-06-09 6:03 ` Jan Kiszka
2016-06-21 10:13 ` Jan Kiszka [this message]
2016-06-21 10:24 ` Pantelis Antoniou
2016-06-21 10:24 ` Pantelis Antoniou
2016-06-21 11:22 ` Jan Kiszka
2016-06-21 11:22 ` Jan Kiszka
2016-06-21 11:35 ` Pantelis Antoniou
2016-06-21 11:35 ` Pantelis Antoniou
2016-06-21 11:43 ` Jan Kiszka
2016-06-21 11:43 ` Jan Kiszka
2016-06-21 11:45 ` Pantelis Antoniou
2016-06-21 11:45 ` Pantelis Antoniou
2016-06-21 11:59 ` Jan Kiszka
2016-06-21 11:59 ` Jan Kiszka
2016-06-21 13:12 ` Jan Kiszka
2016-06-21 13:12 ` Jan Kiszka
2016-06-21 13:29 ` Pantelis Antoniou
2016-06-21 13:29 ` Pantelis Antoniou
2016-06-09 7:22 ` Arnd Bergmann
2016-06-09 7:22 ` Arnd Bergmann
2016-06-10 14:57 ` Jan Kiszka
2016-06-10 14:57 ` Jan Kiszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57691342.2020502@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=antonios.motakis@huawei.com \
--cc=devicetree@vger.kernel.org \
--cc=jailhouse-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mans@denx.de \
--cc=mark.rutland@arm.com \
--cc=pantelis.antoniou@konsulko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.