From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3] ARM: parse separate DT properties for different commandlines Date: Tue, 27 Aug 2013 16:03:57 +0100 Message-ID: <521CBFDD.4050809@linaro.org> References: <1377012070-22967-1-git-send-email-andre.przywara@linaro.org> <1377610488.29147.39.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1377610488.29147.39.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Stefano Stabellini , Patch Tracking , Andre Przywara , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 08/27/2013 02:34 PM, Ian Campbell wrote: > On Wed, 2013-08-21 at 23:53 +0100, Julien Grall wrote: >> On 20 August 2013 16:21, Andre Przywara wrote: >>> Currently we use the chosen/bootargs property as the Xen commandline >>> and rely on xen,dom0-bootargs for Dom0. However this brings issues >>> with bootloaders, which usually build bootargs by bootscripts for a >>> Linux kernel - and not for the entirely different Xen hypervisor. >>> >>> Introduce a new possible device tree property "xen,xen-bootargs" >>> explicitly for the Xen hypervisor and make the selection of which to >>> use more fine grained: >>> - If xen,xen-bootargs is present, it will be used for Xen. >>> - If xen,dom0-bootargs is present, it will be used for Dom0. >>> - If xen,xen-bootargs is _not_ present, but xen,dom0-bootargs is, >>> bootargs will be used for Xen. Like the current situation. >>> - If no Xen specific properties are present, bootargs is for Dom0. >>> - If xen,xen-bootargs is present, but xen,dom0-bootargs is missing, >>> bootargs will be used for Dom0. >>> >>> The aim is to allow common bootscripts to boot both Xen and native >>> Linux with the same device tree blob. If needed, one could hard-code >>> the Xen commandline into the DTB, leaving bootargs for Dom0 to be set >>> by the (non Xen-aware) bootloader. >>> >>> I will send out a appropriate u-boot patch, which writes the content >>> of the "xen_bootargs" environment variable into the xen,xen-bootargs >>> dtb property. >> >> Since we plan to support multiboot, is it relevant to send a u-boot patch >> for a temporary workaround? >> >> We could use a u-boot script to create the correct properties/nodes in >> the device tree. What do you think? > > I think a combination of propagating xen_bootargs and using a script to > populate the /chosen/modules@N nodes sounds like quite a convenient way > to do things. > > It's not clear that multiboot adds much more than some syntactic sugar > to this. > >> >>> v1 .. v2: >>> - fix whitespace issues >>> v2 .. v3: >>> - add documentation >>> >>> Signed-off-by: Andre Przywara >> >> Reviewed-by: Julien Grall >> >> BTW, I have modified this code with my latest patch series. I will >> rebase it on top of this patch. > > Does this mean I should wait for a series from you incorporating this > patch or should I consider just applying this because you've rebased > your series on it? For the moment I have rebased this patch on top of my patch series (so my patch series applied, then Andre's patch). If Andre is fine to delay this patch, I can carry it on my patch series and modify the necessary things to switch to dt_* functions. Andre, what do you think? -- Julien Grall