[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.