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

[Andre Przywara <andre.przywara@xxxxxxxxxx>]

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@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > Reviewed-by: Julien Grall <julien.grall@xxxxxxxxxx>
> > >
> > > 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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel