Re: [PATCH v3] ARM: parse separate DT properties for different commandlines

[Julien Grall <julien.grall@linaro.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 <andre.przywara@linaro.org> 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 <andre.przywara@linaro.org>
>>
>> Reviewed-by: Julien Grall <julien.grall@linaro.org>
>>
>> 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