* Re: device tree passing feature
2016-07-01 16:15 ` device tree passing feature Thiago Jung Bauermann
@ 2016-07-04 3:26 ` Samuel Mendoza-Jonas
0 siblings, 0 replies; 2+ messages in thread
From: Samuel Mendoza-Jonas @ 2016-07-04 3:26 UTC (permalink / raw)
To: Thiago Jung Bauermann, linuxppc-dev
Cc: petitboot, George C. Wilson, Dave Heller, Mimi Zohar
On Fri, 2016-07-01 at 13:15 -0300, Thiago Jung Bauermann wrote:
> Hi Samuel,
>
> Thanks for your response.
>
> Am Freitag, 01 Juli 2016, 11:46:21 schrieb Samuel Mendoza-Jonas:
> > On Thu, 2016-06-30 at 11:27 -0300, Thiago Jung Bauermann wrote:
> > > I have a question about the petitboot feature which allows the user to
> > > specify a device tree blob to pass to the target OS being loaded. What
> > > is
> > > the use case for it? Is it a debugging and development aid, or do you
> > > expect it be useful in a production environment?
> >
> > Passing the dtb isn't really a Petitboot feature, rather part of how
> > kexec works for PowerPC and ARM. Petitboot may make modifications to, or
> > replace the dtb, but the method via with the target kernel obtains its
> > device-tree is kexec. So I suspect you would have to say it is mandatory
> > for production.
>
> Right. I already have a working kexec_file_load implementation [1], and what
> I'm doing in my patch set is taking the device tree that was used to boot
> the current kernel and modifying it as necessary to pass it to the next
> kernel.
Ah ok - I skimmed over the series but didn't notice that, great!
>
> My question is: is there any need in a production environment for userspace
> to provide a different device tree for the next kernel, or can the currently
> running kernel always use the device tree that it received when it was
> booted?
>
> So one new piece of information for me is that Petitboot makes modifications
> to the dtb. Does it do that only if the system administrator provided a
> custom dtb (either via the boot options screen or a configuration file), or
> can it change/replace the dtb even if the system administrator didn't
> provide a custom dtb? Which modifications does Petitboot make?
>
For the next kernel it's sufficient just to have the device-tree, but
Petitboot does make modifications to it to help the next kernel in
certain ways, for example:
- Sorting the device-tree properly if
firmware hasn't done so
- Setting framebuffer information on
OpenPOWER machines
- Setting the primary stdout for the next
kernel
These aren't required for *booting*, but a number of people might start shouting if they go away.
> > > I ask this because I'm implementing the kexec_file_load system call for
> > > powerpc, and given its prototype:
> > >
> > > long kexec_file_load(int kernel_fd, int initrd_fd, unsigned long
> > > cmdline_len, const char *cmdline_ptr, unsigned long flags)
> > >
> > > It wouldn't be very straightforward to allow the caller to specify a
> > > device tree blob, so I have to ask how necessary such a feature is.
> >
> > Yep, I think the problem is kexec_file_load was first implemented with a
> > focus on x86 where this isn't an issue, and now we need to consider what
> > to do :)
>
> Yes, that's true. I was able to make it work on powerpc even with that x86
> bias, but now I'm wondering if that's enough or not.
>
> > We are definitely going to need a way to pass the device-tree to the
> > target kernel - whether we do that by changing the prototype for
> > kexec_file_load() PowerPC and ARM, or by dealing with it some other way
> > I'm not sure.
>
> Do you say definitely because the kexec'd kernel needs to be passed a device
> tree, or is it because userspace needs to have some control over the device
> tree that the kexec'd kernel receives?
As above the 'definitely' comes from the kexec'd kernel needing to be
passed a device-tree, as well as some updates made by userspace.
>
> > Sounds like the start of a interesting conversation on the
> > linuxppc-dev list :)
>
> Indeed. :-) I'm copying linuxppc-dev here just in case.
>
> A conversation about this just started in the kexec mailing list (I'm
> copying the linuxppc-dev mailing list in my response as well):
>
> https://lists.infradead.org/pipermail/kexec/2016-July/016279.html
>
> []'s
> Thiago Jung Bauermann
> IBM Linux Technology Center
>
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-June/144658.html
>
^ permalink raw reply [flat|nested] 2+ messages in thread