Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1441972
| From | Dave Young <dyoung@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC 0/3] extend kexec_file_load system call |
| Date | 2016-07-13 04:40 +0200 |
| Message-ID | <rUifD-5fa-1@gated-at.bofh.it> (permalink) |
| References | <rTUQ1-6xe-5@gated-at.bofh.it> <rU6xR-5Z5-61@gated-at.bofh.it> <rU6Hv-62T-7@gated-at.bofh.it> <rU6Rd-66R-59@gated-at.bofh.it> <rU7ke-6jl-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 07/12/16 at 03:50pm, Mark Rutland wrote: > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > > into dynamically allocated data structures. After a kexec, the runtime > > > > interface to the firmware is not available, so the flattened DT format > > > > was created as a way to pass the same data in a binary blob to the new > > > > kernel in a format that can be read from the kernel by walking the > > > > directories in /proc/device-tree/*. > > > > > > So this DT is available inside kernel and running kernel can still > > > retrieve it and pass it to second kernel? > > > > The kernel only uses the flattened DT blob at boot time and converts > > it into the runtime data structures (struct device_node). The original > > dtb is typically overwritten later. > > On arm64 we deliberately preserved the DTB, so we can take that and > build a new DTB from that kernel-side. > > > > > - we typically ship devicetree sources for embedded machines with the > > > > kernel sources. As more hardware of the system gets enabled, the > > > > devicetree gains extra nodes and properties that describe the hardware > > > > more completely, so we need to use the latest DT blob to use all > > > > the drivers > > > > > > > > - in some cases, kernels will fail to boot at all with an older version > > > > of the DT, or fail to use the devices that were working on the > > > > earlier kernel. This is usually considered a bug, but it's not rare > > > > > > > > - In some cases, the kernel can update its DT at runtime, and the new > > > > settings are expected to be available in the new kernel too, though > > > > there are cases where you actually don't want the modified contents. > > > > > > I am assuming that modified DT and unmodifed one both are accessible to > > > kernel. And if user space can make decisions which modfied fields to use > > > for new kernels and which ones not, then same can be done in kernel too? > > > > The unmodified DT can typically be found on disk next to the kernel binary. > > The option you have is to either read it from /proc/devicetree or to > > read it from from /boot/*.dtb. > > /proc/devicetree (aka /sys/firmware/devicetree) is a filesystem derived > from the raw DTB (which is exposed at /sys/firmware/fdt). > > The blob that was handed to the kernel at boot time is exposed at > /sys/firmware/fdt. I believe the blob can be read and passed to kexec kernel in kernel code without the extra fd. But consider we can kexec to a different kernel and a different initrd so there will be use cases to pass a total different dtb as well. From my understanding it is reasonable but yes I think we should think carefully about the design. Thanks Dave > Thanks, > Mark. > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC 0/3] extend kexec_file_load system call AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-12 03:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-12 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-12 16:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-12 16:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 01:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-12 16:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-12 16:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-12 16:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-12 17:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-13 04:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 10:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 11:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 15:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-13 20:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 22:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-14 04:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-14 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 03:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-15 09:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-15 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-15 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 17:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-15 17:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-15 15:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-15 22:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-15 23:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-22 02:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Jeremy Kerr <jeremy.kerr@au1.ibm.com> - 2016-07-22 03:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Michael Ellerman <michael@ellerman.id.au> - 2016-07-22 05:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-22 22:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-15 10:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-15 15:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 11:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call AKASHI Takahiro <takahiro.akashi@linaro.org> - 2016-07-13 19:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-13 20:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-13 22:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Mark Rutland <mark.rutland@arm.com> - 2016-07-14 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-14 04:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-14 04:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-12 18:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-12 23:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-12 23:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call ebiederm@xmission.com (Eric W. Biederman) - 2016-07-13 00:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-13 00:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 00:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 07:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 09:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-07-13 09:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 10:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 10:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 10:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Dave Young <dyoung@redhat.com> - 2016-07-13 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Petr Tesarik <ptesarik@suse.cz> - 2016-07-13 11:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:10 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-13 19:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 20:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Balbir Singh <bsingharora@gmail.com> - 2016-07-18 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-18 15:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-18 15:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Balbir Singh <bsingharora@gmail.com> - 2016-07-20 05:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-07-20 10:40 +0200
Re: [RFC 0/3] extend kexec_file_load system call Arnd Bergmann <arnd@arndb.de> - 2016-07-20 13:20 +0200
Re: [RFC 0/3] extend kexec_file_load system call Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> - 2016-07-20 18:00 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-20 14:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-20 14:30 +0200
Re: [RFC 0/3] extend kexec_file_load system call Stewart Smith <stewart@linux.vnet.ibm.com> - 2016-07-13 01:50 +0200
Re: [RFC 0/3] extend kexec_file_load system call Vivek Goyal <vgoyal@redhat.com> - 2016-07-13 15:30 +0200
csiph-web