From: Simon Glass <sjg@chromium.org> To: Tom Rini <trini@konsulko.com> Cc: "François Ozog" <francois.ozog@linaro.org>, "Albert Aribaud" <albert.u.boot@aribaud.net>, "Heinrich Schuchardt" <xypron.glpk@gmx.de>, "Ilias Apalodimas" <ilias.apalodimas@linaro.org>, "Mark Kettenis" <mark.kettenis@xs4all.nl>, "Peter Maydell" <peter.maydell@linaro.org>, "QEMU Developers" <qemu-devel@nongnu.org>, "Sean Anderson" <seanga2@gmail.com>, "Tuomas Tynkkynen" <tuomas.tynkkynen@iki.fi>, "U-Boot Mailing List" <u-boot@lists.denx.de> Subject: Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 Date: Tue, 2 Nov 2021 09:00:53 -0600 [thread overview] Message-ID: <CAPnjgZ0XeFHrXwBuTZ=eoKHCo7cMSuM_gUiTfv-Sqt8o6tPOXw@mail.gmail.com> (raw) In-Reply-To: <20211101180707.GJ24579@bill-the-cat> Hi Tom, On Mon, 1 Nov 2021 at 12:07, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote: > > Hi Simon > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass <sjg@chromium.org> a écrit : > > > > > Hi Peter, > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell <peter.maydell@linaro.org> > > > wrote: > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > > > in the U-Boot tree. > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > > > Note that the dtb you get from QEMU is only guaranteed to work if: > > > > 1) you run it on the exact same QEMU version you generated it with > > > > 2) you pass QEMU the exact same command line arguments you used > > > > when you generated it > > > > > > Yes, I certainly understand that. In general this is not safe, but in > > > practice it works well enough for development and CI. > > > > You recognize that you hijack a product directory with development hack > > facility. There is a test directory to keep things clear. There can be a > > dev-dts or something similar for Dev time tools. > > I have only seen push back on those fake dts files in the dts directory: I > > guess that unless someone strongly favors a continuation of the discussion, > > you may consider re-shaping the proposal to address concerns. > > Yes. We need to document how to make development easier. But I'm still > not on board with the notion of including DTS files for platforms where > the source of truth for the DTB is elsewhere. That's going to bring us > a lot more pain. Are you talking about QEMU specifically, or Raspberry Pi? How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat. > > It is important to make sure our "develop our project" workflow is sane > and relatively pain free. But that needs to not come by making > sacrifices to the "use our project" outcome. I would hope for example > that the new Pi zero platform is just dtb changes, as far as the linux > kernel is concerned which means that for rpi_arm64 (which uses run time > dtb) it also just works. And that's what we want to see. So long as OF_BOARD is enabled then the flow should work as you expect. Regards, Simon
WARNING: multiple messages have this Message-ID (diff)
From: Simon Glass <sjg@chromium.org> To: Tom Rini <trini@konsulko.com> Cc: "Peter Maydell" <peter.maydell@linaro.org>, "Albert Aribaud" <albert.u.boot@aribaud.net>, "François Ozog" <francois.ozog@linaro.org>, "U-Boot Mailing List" <u-boot@lists.denx.de>, "Heinrich Schuchardt" <xypron.glpk@gmx.de>, "Ilias Apalodimas" <ilias.apalodimas@linaro.org>, "QEMU Developers" <qemu-devel@nongnu.org>, "Sean Anderson" <seanga2@gmail.com>, "Tuomas Tynkkynen" <tuomas.tynkkynen@iki.fi>, "Mark Kettenis" <mark.kettenis@xs4all.nl> Subject: Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 Date: Tue, 2 Nov 2021 09:00:53 -0600 [thread overview] Message-ID: <CAPnjgZ0XeFHrXwBuTZ=eoKHCo7cMSuM_gUiTfv-Sqt8o6tPOXw@mail.gmail.com> (raw) In-Reply-To: <20211101180707.GJ24579@bill-the-cat> Hi Tom, On Mon, 1 Nov 2021 at 12:07, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote: > > Hi Simon > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass <sjg@chromium.org> a écrit : > > > > > Hi Peter, > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell <peter.maydell@linaro.org> > > > wrote: > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > > > in the U-Boot tree. > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > > > Note that the dtb you get from QEMU is only guaranteed to work if: > > > > 1) you run it on the exact same QEMU version you generated it with > > > > 2) you pass QEMU the exact same command line arguments you used > > > > when you generated it > > > > > > Yes, I certainly understand that. In general this is not safe, but in > > > practice it works well enough for development and CI. > > > > You recognize that you hijack a product directory with development hack > > facility. There is a test directory to keep things clear. There can be a > > dev-dts or something similar for Dev time tools. > > I have only seen push back on those fake dts files in the dts directory: I > > guess that unless someone strongly favors a continuation of the discussion, > > you may consider re-shaping the proposal to address concerns. > > Yes. We need to document how to make development easier. But I'm still > not on board with the notion of including DTS files for platforms where > the source of truth for the DTB is elsewhere. That's going to bring us > a lot more pain. Are you talking about QEMU specifically, or Raspberry Pi? How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat. > > It is important to make sure our "develop our project" workflow is sane > and relatively pain free. But that needs to not come by making > sacrifices to the "use our project" outcome. I would hope for example > that the new Pi zero platform is just dtb changes, as far as the linux > kernel is concerned which means that for rpi_arm64 (which uses run time > dtb) it also just works. And that's what we want to see. So long as OF_BOARD is enabled then the flow should work as you expect. Regards, Simon
next prev parent reply other threads:[~2021-11-02 15:01 UTC|newest] Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-26 0:23 [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option Simon Glass 2021-10-26 0:23 ` Simon Glass 2021-10-26 0:23 ` [PATCH v5 01/26] sandbox: Remove OF_HOSTFILE Simon Glass 2021-10-26 0:23 ` [PATCH v5 02/26] doc: Add documentation about devicetree usage Simon Glass 2021-10-26 14:06 ` Ilias Apalodimas 2021-10-26 15:27 ` Simon Glass 2021-10-27 9:29 ` Ilias Apalodimas 2021-10-26 14:31 ` François Ozog 2021-10-26 15:27 ` Simon Glass 2021-10-26 15:57 ` François Ozog 2021-10-27 14:13 ` Simon Glass 2021-10-27 15:38 ` François Ozog 2021-10-27 18:32 ` Simon Glass 2021-10-27 19:12 ` Ilias Apalodimas 2021-10-27 19:52 ` Simon Glass 2021-10-29 10:20 ` Ilias Apalodimas 2021-11-01 15:19 ` Tom Rini 2021-11-02 14:53 ` Simon Glass 2021-11-02 15:38 ` Ilias Apalodimas 2021-11-03 3:29 ` Simon Glass 2021-10-29 17:07 ` François Ozog 2021-11-02 14:53 ` Simon Glass 2021-10-27 19:46 ` François Ozog 2021-10-27 19:48 ` Tom Rini 2021-10-27 20:13 ` François Ozog 2021-10-26 0:23 ` [PATCH v5 03/26] arm: qemu: Mention -nographic in the docs Simon Glass 2021-10-26 0:23 ` Simon Glass 2021-10-26 0:23 ` [PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt Simon Glass 2021-10-26 0:23 ` Simon Glass 2021-10-26 0:23 ` [PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm Simon Glass 2021-10-26 0:23 ` Simon Glass 2021-10-26 0:23 ` [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64 Simon Glass 2021-10-26 0:23 ` Simon Glass 2021-11-01 10:48 ` Peter Maydell 2021-11-01 10:48 ` Peter Maydell 2021-11-01 16:58 ` Simon Glass 2021-11-01 16:58 ` Simon Glass 2021-11-01 17:33 ` François Ozog 2021-11-01 17:33 ` François Ozog 2021-11-01 18:07 ` Tom Rini 2021-11-01 18:07 ` Tom Rini 2021-11-02 15:00 ` Simon Glass [this message] 2021-11-02 15:00 ` Simon Glass 2021-11-02 17:28 ` Tom Rini 2021-11-02 17:28 ` Tom Rini 2021-11-03 1:29 ` Simon Glass 2021-11-03 1:29 ` Simon Glass 2021-11-03 5:29 ` François Ozog 2021-11-03 5:29 ` François Ozog 2021-11-03 14:41 ` Tom Rini 2021-11-03 14:41 ` Tom Rini 2021-11-04 11:09 ` Peter Maydell 2021-11-04 11:09 ` Peter Maydell 2021-11-04 11:22 ` François Ozog 2021-11-04 11:22 ` François Ozog 2021-11-04 11:41 ` Peter Maydell 2021-11-04 11:41 ` Peter Maydell 2021-11-04 11:48 ` François Ozog 2021-11-04 11:48 ` François Ozog 2021-11-03 14:44 ` François Ozog 2021-11-03 14:44 ` François Ozog 2021-11-03 14:39 ` Tom Rini 2021-11-03 14:39 ` Tom Rini 2021-11-02 14:59 ` Simon Glass 2021-11-02 14:59 ` Simon Glass 2021-11-02 16:57 ` Tom Rini 2021-11-02 16:57 ` Tom Rini 2021-11-03 1:32 ` Simon Glass 2021-11-03 1:32 ` Simon Glass 2021-11-03 14:39 ` Tom Rini 2021-11-03 14:39 ` Tom Rini 2021-10-26 0:23 ` [PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64 Simon Glass 2021-10-26 0:23 ` Simon Glass 2021-10-26 0:23 ` [PATCH v5 08/26] arm: rpi: Add a devicetree file for rpi_4 Simon Glass 2021-10-26 0:23 ` [PATCH v5 09/26] arm: vexpress: Add a devicetree file for juno Simon Glass 2021-10-26 0:23 ` [PATCH v5 10/26] arm: xenguest_arm64: Add a fake devicetree file Simon Glass 2021-10-26 0:23 ` [PATCH v5 11/26] arm: octeontx: " Simon Glass 2021-10-26 0:23 ` [PATCH v5 12/26] arm: xilinx_versal_virt: Add a " Simon Glass 2021-10-26 0:23 ` [PATCH v5 13/26] arm: bcm7xxx: " Simon Glass 2021-10-26 0:23 ` [PATCH v5 14/26] arm: qemu-ppce500: " Simon Glass 2021-10-26 0:23 ` [PATCH v5 15/26] arm: highbank: Add a fake " Simon Glass 2021-10-26 0:23 ` [PATCH v5 16/26] fdt: Make OF_BOARD a bool option Simon Glass 2021-10-26 0:23 ` [PATCH v5 17/26] Drop CONFIG_BINMAN_STANDALONE_FDT Simon Glass 2021-10-26 0:23 ` [PATCH v5 18/26] doc: Update info on devicetree update Simon Glass 2021-10-26 0:23 ` [PATCH v5 19/26] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() Simon Glass 2021-10-29 5:49 ` Ilias Apalodimas 2021-10-26 0:23 ` [PATCH v5 20/26] fdt: Drop #ifdefs with MULTI_DTB_FIT Simon Glass 2021-10-29 5:55 ` Ilias Apalodimas 2021-10-26 0:23 ` [PATCH v5 21/26] fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() Simon Glass 2021-10-26 0:23 ` [PATCH v5 22/26] fdt: Drop #ifdef around board_fdt_blob_setup() Simon Glass 2021-10-26 0:23 ` [PATCH v5 25/26] fdt: Drop remaining preprocessor macros in fdtdec_setup() Simon Glass 2021-10-26 0:23 ` [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD Simon Glass 2021-10-26 13:55 ` Ilias Apalodimas 2021-10-26 15:27 ` Simon Glass 2021-10-27 7:17 ` Ilias Apalodimas 2021-10-27 19:12 ` Tom Rini 2021-10-27 21:33 ` François Ozog 2021-10-27 21:44 ` Tom Rini 2021-10-26 6:07 ` [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option François Ozog 2021-10-26 6:07 ` François Ozog 2021-10-27 14:08 ` Simon Glass 2021-10-27 14:08 ` Simon Glass 2021-10-27 15:14 ` François Ozog 2021-10-27 15:14 ` François Ozog 2021-10-27 18:23 ` Simon Glass 2021-10-27 18:23 ` Simon Glass 2021-10-27 19:25 ` Tom Rini 2021-10-27 19:25 ` Tom Rini 2021-11-03 16:45 ` Simon Glass 2021-11-03 16:45 ` Simon Glass 2021-11-03 17:21 ` Tom Rini 2021-11-03 17:21 ` Tom Rini 2021-10-27 20:07 ` François Ozog 2021-10-27 20:07 ` François Ozog 2021-11-03 1:20 ` Simon Glass 2021-11-03 1:20 ` Simon Glass 2021-11-03 4:45 ` François Ozog 2021-11-03 4:45 ` François Ozog 2021-10-27 22:30 ` Mark Kettenis 2021-10-27 22:30 ` Mark Kettenis 2021-11-03 1:20 ` Simon Glass 2021-11-03 1:20 ` Simon Glass 2021-11-03 8:22 ` Mark Kettenis 2021-11-03 8:22 ` Mark Kettenis 2021-11-03 16:02 ` Tom Rini 2021-11-03 16:02 ` Tom Rini 2021-11-03 16:45 ` Simon Glass 2021-11-03 16:45 ` Simon Glass 2021-11-03 17:36 ` Mark Kettenis 2021-11-03 17:36 ` Mark Kettenis 2021-11-03 15:56 ` Tom Rini 2021-11-03 15:56 ` Tom Rini 2021-11-03 16:45 ` Simon Glass 2021-11-03 16:45 ` Simon Glass 2021-10-27 15:36 ` Tuomas Tynkkynen 2021-10-27 15:36 ` Tuomas Tynkkynen 2021-10-27 19:13 ` Tom Rini 2021-10-27 19:13 ` Tom Rini 2021-10-27 18:16 ` Tom Rini 2021-10-27 18:16 ` Tom Rini 2021-10-27 18:24 ` Tom Rini 2021-10-27 18:24 ` Tom Rini 2021-11-03 17:13 ` François Ozog 2021-11-03 17:13 ` François Ozog
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAPnjgZ0XeFHrXwBuTZ=eoKHCo7cMSuM_gUiTfv-Sqt8o6tPOXw@mail.gmail.com' \ --to=sjg@chromium.org \ --cc=albert.u.boot@aribaud.net \ --cc=francois.ozog@linaro.org \ --cc=ilias.apalodimas@linaro.org \ --cc=mark.kettenis@xs4all.nl \ --cc=peter.maydell@linaro.org \ --cc=qemu-devel@nongnu.org \ --cc=seanga2@gmail.com \ --cc=trini@konsulko.com \ --cc=tuomas.tynkkynen@iki.fi \ --cc=u-boot@lists.denx.de \ --cc=xypron.glpk@gmx.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.