From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751291AbcGMT7R (ORCPT ); Wed, 13 Jul 2016 15:59:17 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:50462 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751010AbcGMT7E (ORCPT ); Wed, 13 Jul 2016 15:59:04 -0400 From: Arnd Bergmann To: Mark Rutland Cc: AKASHI Takahiro , Dave Young , bhe@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Vivek Goyal , "Eric W. Biederman" , bauerman@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC 0/3] extend kexec_file_load system call Date: Wed, 13 Jul 2016 21:57:28 +0200 Message-ID: <7927804.6bj1abO0d2@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160713175630.GA2668@leverpostej> References: <20160712014201.11456-1-takahiro.akashi@linaro.org> <20160713173804.GA25723@porco> <20160713175630.GA2668@leverpostej> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:MAYc6RJvl4ozTw6NRGUtqSU9NRL0Z403I8AflvROKbtDhNAeJHu 8D7afLv1q5KkMAN9/LlzcJpTcj0plXfk/spyrQr5/nyTG+iz8fKoh//UXzpkxG5d07/e3s4 fETKH04JEIiZ5I1GPovPPiYdTi2LJukh6/GP8xcdk3y/uEsOd6DBUSjYMOgQoaPu4kvxYeM 0N8zgQI3O+/coGmNhw54w== X-UI-Out-Filterresults: notjunk:1;V01:K0:KAXGjr1Ck2o=:ClmximPcuH1rnxmJNdabYA PnDLgPLECtOn1Lq4BhAPwr3gdwWuei0SSmfaC2gFEDnqUK++0Bc8OBbku2EX0pBT0U4BjnAxD yWtbnBCeBGD5kxRVglA1KoocxwdYrNcP+zbwpyXeE2jTmbyBhqeIQWinmKnYWB5jWolTf/Cc/ sPS905Rc3fNTHFct8RIvArQxbeVV39P3hu0pH4ZmtZjt3dMjYwqnnp3Qi8vxnReFGIeLBuhXu P3vq69XBs1gbrc5lxXqbGZxPttVCiCUBg8zwGC5fUsCFEsjAMvSFk7TpdIBLFck7aarPY+7M6 qPJWwfAsmKH1f5Eptq0gg/uX0MiuZ/h/Vs5aWO9OlKO/dC76dsTN8JcGN2ln5J0XUkUpB9I4g BQFbNrF9Z4W8QWzla0ia2LEAK5UfCcgIooK15ca2hKv2bscGU86jd5X/xuQiwZ4RLraEQOMxF yPq4BBp20q1h9G8FLNM3VglmZ4qJLKqev+d0V4slWBaek/QD5IQeCC88flJ9lgG7MNuthZFmJ 8q5hexOiUBSzil0Huo2BKE3D1BBMcwtdzGVvlBhqNSeap46AcJlyDohsBokH/DDZobT7w9Hq8 W+m1BOisySoIgQk5N1Y8DykiEHMpSMUnonkwe4tzZV6+WRMACZZ89dGQLIldqTwB/gkS4tg/c cvbOi8vsi5MTYPFNPNm2Tm9frY78Kkuc28A6ZoHUyOYIY7fFml8PHnFETnyIdTt8PfO3lfsl1 J6CiOU208LJ/8Iu3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, July 13, 2016 6:58:32 PM CEST Mark Rutland wrote: > > > we may want to remove unnecessary devices and even add a dedicated > > storage device for storing a core dump image. > > I suspect that bringing up a minimal number of devices is better > controlled by a cmdline option. In general, figuring out what is > necessary and what is not is going to be board specific, so hacking the > FW tables (DTB or ACPI) is not a very portable/reliable approach. > > Do we actually add devices in practice? More so than the above that > requires special knowledge of the platform (including things that were > not described in the boot DTB). > > In the ACPI case modifying a DTB alone is not sufficient to change the > information regarding devices, as those won't be described in the DTB. > It's not possible to convert ACPI to DTB in general. A more likely scenario would be replacing ACPI tables with a DTB that describes the platform in order to use devices that the ACPI tables don't contain. > > - Say, booting BE kernel on ACPI LE kernel > > In this case, there is no useful dtb in the kernel. > If the platform only has ACPI, then you cannot boot a BE kernel to begin > with. As above one cannot convert ACPI to DTB, so one would need > extensive platform knowledge for this to work. I think what he meant was to pass a DTB to the kexec kernel in order to run BE, while the original kernel can only run LE due to ACPI. If you boot a LE kernel using DTB, the same DTB should work for a kexec boot for a BE kernel. Arnd