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

[Andre Przywara <andre.przywara@linaro.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 <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?

Yes, that's fine for me.
We need to rethink this whole multiboot approach anyway.

Regards,
Andre.