From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH v3] ARM: parse separate DT properties for different commandlines Date: Tue, 27 Aug 2013 17:05:59 +0200 Message-ID: <521CC057.2030605@linaro.org> References: <1377012070-22967-1-git-send-email-andre.przywara@linaro.org> <1377610488.29147.39.camel@kazak.uk.xensource.com> <521CBFDD.4050809@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <521CBFDD.4050809@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: Patch Tracking , Ian Campbell , Stefano Stabellini , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 08/27/2013 05:03 PM, Julien Grall wrote: > 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? Yes, that's fine for me. We need to rethink this whole multiboot approach anyway. Regards, Andre.