From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754551AbcGLOZo (ORCPT ); Tue, 12 Jul 2016 10:25:44 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:50818 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754262AbcGLOZl (ORCPT ); Tue, 12 Jul 2016 10:25:41 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Vivek Goyal , bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro , "Eric W. Biederman" , bauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Tue, 12 Jul 2016 16:24:10 +0200 Message-ID: <293705810.hBL93OOmOz@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160712141810.GB30181@redhat.com> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <1911992.H2WpLRr2Fi@wuerfel> <20160712141810.GB30181@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:zlQ+uc4Ly83G7DEwSStT1lxlwrx51mCNx/t2DqSAkrSuQxOaTWJ oSVTA4H13w4ekWlFzHdk9rgSYcybkwd8YoZnCbKzVLP7QFrejFcl66CPYok1quC/aU0jpLP cUJxkrx6QwJLuNEMSqAS9nXUz+5noeIaVqFiLnBsPBo96zishYhcL31AoKmphSXmZcF6MW+ MTODZ/PyTm5fhZfnLJyyQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:DfcMjJC8kZs=:yCqih+xwTjHw20XcvnZ9Pb qH/jlcMMqM1c+Vi633SACfL922DAGCzBnIOuN66ldaiDL5/Fyp1PNuFTQTDVg04S8H5R+g/n3 vTtPjoDIoqUR9t9y1i0CVgSRQZhk1mPJFSPk/1dvYY48cLEdJfEIM8PRyndcToV1odVGEItAE Z58fsQXWMuJXe5MWxao+kU5J2G1o+hCx5OF1Fi1rMnJXWHBYKWgd/aUHssmNXNDC4i4Sb6cxI mV0TNB7hS6CV2jGPJe+k/pFU18ppZB7yV8YY3+C7npYwOIARL3gsvSutrk0M2nsXKUrKt0hod 6ojcyzKw7SZgVzLJ769jxb8/98dEqn1GKssyzr7IPvWEQ3kkwULTaoVl5VDceeoEKMY5eVXFl FzKq15xwwyo2/NqheQp727KVrx7iPLqKE5Me+runTWK212TZKl7CCdfLYHxgIsq2wb6MrcEC/ v7ttbQHT8mGz+C+X1YLTsqWxuixXsjreHu2S1ZnkXqgo1pIdo313Y11IkVveFY6Udls06yHtV N0w57wFbGcX7qvKzF68a/uzGkSmhrg68u5ojtsjJCNtw3mGOINS8ylFbUHopkEjNu1jaDA+/g 13whRqj2AHgPtOQo4w0GcPtesY/KsOGWnpa24DKgm1o6ZcWEPgTcVsPQN2KBgyLDmOC84Xta7 nur7c5Ss87F9ynzyYTCB85G18BaSEoEvGMJTU40sz+4l4vM5B7+nEyiHCpChf3RNAff96D2am 1p3k50nO8R4rasy8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > - 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. Arnd