From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752023AbcFULnS (ORCPT ); Tue, 21 Jun 2016 07:43:18 -0400 Received: from mail-lb0-f179.google.com ([209.85.217.179]:36347 "EHLO mail-lb0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751059AbcFULnI convert rfc822-to-8bit (ORCPT ); Tue, 21 Jun 2016 07:43:08 -0400 Subject: Re: Using DT overlays for adding virtual hardware Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Pantelis Antoniou In-Reply-To: <57692378.8010909@siemens.com> Date: Tue, 21 Jun 2016 14:35:26 +0300 Cc: Mark Rutland , devicetree , Linux Kernel Mailing List , Jailhouse , =?utf-8?Q?M=C3=A5ns_Rullg=C3=A5rd?= , Antonios Motakis Content-Transfer-Encoding: 8BIT Message-Id: References: <575828C0.5000008@siemens.com> <20160608151745.GB13355@leverpostej> <28BC1AEC-6A7D-4A97-82F4-5670E884C41D@konsulko.com> <20160608162343.GD13355@leverpostej> <999B1CFF-C204-4C19-AE76-AF9DB54E51E4@konsulko.com> <57584A2C.4030507@siemens.com> <5759069B.4080800@siemens.com> <57691342.2020502@siemens.com> <57692378.8010909@siemens.com> To: Jan Kiszka X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jan, > On Jun 21, 2016, at 14:22 , Jan Kiszka wrote: > > On 2016-06-21 12:24, Pantelis Antoniou wrote: >> Hi Jan, >> >>> On Jun 21, 2016, at 13:13 , Jan Kiszka wrote: >>> >>> 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__ { >>> }; >>> }; >>> }; >>> >> >> ^ This is not going to work: You need the reference to the real gic not the empty fragment >> here that has a target there. >> >> You need to compile with the correct dtc, and you also need to compile the base dts >> with dtc too, using the -@ flag. You can hack around it by adding something like >> >> __symbols__ { >> gic = "/soc@01c00000/interrupt-controller@01c81000”; >> }; >> >> But you really need the __symbols__ node of the base dts generated by the dtc proper cause >> the above is a dirty hack. >> > > OK, re-building the kernel with DTC="/your/dtc -@", thus building the > base dtb with symbols, fixes proper overlay format loading. > > However, no luck yet with the interrupt topic - maybe a different issue. > Digging deeper… > Remove the gic: fragment and build both the kernel and the overlay with the -@ option. That’s what makes it not to work. > Thanks, > Jan > > -- > Siemens AG, Corporate Technology, CT RDA ITP SES-DE > Corporate Competence Center Embedded Linux