From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751537AbcFULWz (ORCPT ); Tue, 21 Jun 2016 07:22:55 -0400 Received: from goliath.siemens.de ([192.35.17.28]:59726 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751224AbcFULWq (ORCPT ); Tue, 21 Jun 2016 07:22:46 -0400 Subject: Re: Using DT overlays for adding virtual hardware To: Pantelis Antoniou 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> Cc: Mark Rutland , devicetree , Linux Kernel Mailing List , Jailhouse , =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= , Antonios Motakis From: Jan Kiszka Message-ID: <57692378.8010909@siemens.com> Date: Tue, 21 Jun 2016 13:22:32 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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... Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux