Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Peter Le jeu. 4 nov. 2021 à 12:41, Peter Maydell a écrit : > On Thu, 4 Nov 2021 at 11:22, François Ozog > wrote: > > Le jeu. 4 nov. 2021 à 12:09, Peter Maydell a > écrit : > >> > >> Well, our recommendation really was that the ideal thing would > >> be "you take the dtb that QEMU passes you at runtime, and at > >> runtime combine that with whatever extra information you want". > > > > That looks just reasonable this way. > > > So we need a « -mergedtb » option for Qemu to have the same > > capability. This would merge the QEMU generated one with the > > command line provided. > > No, I mean that the guest, ie u-boot, should do the merging, > not QEMU. for most of the cases it works. But, as I tried to explain some cases need earlier merging hence trying to get QEMU do the same thing as TFA as « prior loaders » in the boot chain. Worst case we can have the behavior by booting TFA then U-Boot then Linux under QEMU, but the best would be to get the facility directly when TFA is not on the path of the boot like with the VBE boot flow. > > > -- PMM > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Thu, 4 Nov 2021 at 11:22, François Ozog wrote: > Le jeu. 4 nov. 2021 à 12:09, Peter Maydell a écrit > : >> >> Well, our recommendation really was that the ideal thing would >> be "you take the dtb that QEMU passes you at runtime, and at >> runtime combine that with whatever extra information you want". > > That looks just reasonable this way. > So we need a « -mergedtb » option for Qemu to have the same > capability. This would merge the QEMU generated one with the > command line provided. No, I mean that the guest, ie u-boot, should do the merging, not QEMU. -- PMM
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
hi Peter Le jeu. 4 nov. 2021 à 12:09, Peter Maydell a écrit : > On Wed, 3 Nov 2021 at 14:41, Tom Rini wrote: > > > > On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote: > > [snip] > > > > 3. Anything else? > > > > > > > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties > > > > are present. There is no easy way to fix this. > > > > > > one clean and easy way would be to upstream a Qemu change to merge a > > > supplied overlay to the generated one. This the same idea as applying > the > > > NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders > do > > > their job properly for U-Boot : setting up the stage as needed. > > > > For the record, I believe Simon did propose this and the QEMU response > > was that no, you should dumpdtb, combine externally and pass that > > directly. > > Well, our recommendation really was that the ideal thing would > be "you take the dtb that QEMU passes you at runtime, and at > runtime combine that with whatever extra information you want". That looks just reasonable this way. Runtime merging may need to be done before control is actually transferred. We have that problem on real board where we need to inject a TPM device for measured boot and it is not énumerable and pluggable. With TFA we have the option to add the TPM description in the NT_FW_CONFIG and merge it at run time. So we need a « -mergedtb » option for Qemu to have the same capability. This would merge the QEMU generated one with the command line provided. > > The dumpdtb option is primarily intended as a debug feature, > so you can have a look at the dtb QEMU created to see why your > OS isn't booting; although you can script stuff up that does > a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the > need to invoke QEMU twice with matching arguments both times. > > -- PMM > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Wed, 3 Nov 2021 at 14:41, Tom Rini wrote: > > On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote: > [snip] > > > 3. Anything else? > > > > > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties > > > are present. There is no easy way to fix this. > > > > one clean and easy way would be to upstream a Qemu change to merge a > > supplied overlay to the generated one. This the same idea as applying the > > NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do > > their job properly for U-Boot : setting up the stage as needed. > > For the record, I believe Simon did propose this and the QEMU response > was that no, you should dumpdtb, combine externally and pass that > directly. Well, our recommendation really was that the ideal thing would be "you take the dtb that QEMU passes you at runtime, and at runtime combine that with whatever extra information you want". The dumpdtb option is primarily intended as a debug feature, so you can have a look at the dtb QEMU created to see why your OS isn't booting; although you can script stuff up that does a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the need to invoke QEMU twice with matching arguments both times. -- PMM
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon, and team On Wed, 3 Nov 2021 at 06:29, François Ozog wrote: > Hi Simon > > Le mer. 3 nov. 2021 à 02:30, Simon Glass a écrit : > >> Hi Tom, >> >> On Tue, 2 Nov 2021 at 11:28, Tom Rini wrote: >> > >> > On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: >> > > Hi Tom, >> > > >> > > On Mon, 1 Nov 2021 at 12:07, Tom Rini 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 a >> écrit : >> > > > > >> > > > > > Hi Peter, >> > > > > > >> > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell < >> peter.mayd...@linaro.org> >> > > > > > wrote: >> > > > > > > >> > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass >> wrote: >> > > > > > > > >> > > > > > > > Add this file, generated from qemu, so there is a reference >> devicetree >> > > > > > > > in the U-Boot tree. >> > > > > > > > >> > > > > > > > Signed-off-by: Simon Glass >> > > > > > > >> > > > > > > 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? >> > >> > I was using two of the more common and readily available platforms where >> > the source of truth for the DTS/DTB is not (and will not be) U-Boot. >> > >> > > 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. >> > >> > >> > To reiterate, the uniform bit of feedback on this series has been that >> > everyone else disagrees with your notion that we _must_ have a dts >> > in-tree. >> >> [I would like everyone to take a deep breath and think about what this >> actually impacts. I argue the impact outside U-Boot is approximately >> zero. What are we actually discussing here?] >> >> A few have responded that they can just add the files. I think that is >> the case for everything except QEMU, right? I think even François >> agrees with the documentation argument. > > I do providing that the sample goes into documentation, not actionable as > a build artifact in the dts directory. > >> There is no real burden in >> adding the files so we can see what is going on, add a binman node, >> SPL nodes, etc. >> >> So I am going to stand my ground on that one. It affects: >> >> - highbank >> - qemu-ppce500 >> - rpi_4 >> - xilinx_versal_virt >> - octeontx >> - xenguest_arm64 >> - juno >> >> So that is just 7 boards that I want to add devicetree files for. I >> think that is reasonable and not a burden on these maintainers. >> >> Let me deal with QEMU. >> >> Let's imagine that we were in the state that I am proposing here, >> which we would be if I were a better devicetree maintainer for U-Boot >> and had not taken my eye off the ball, basically with my review of >> [1], where I should have pushed to get a response on the questions >> before it was applied. That might have triggered me to think about the >> implications of this at the time. >> >> Anyway, in the state that I am proposing, what problems would we have? >> >> 1. QEMU has a DT which only matches the 'standard' invocation as >> documented at [2] > > >> >> 2. QEMU may get out of date if there is a new release. >> >> I don't think (1) is really a problem. People will have to remove >> CONFIG_OF_BOARD from configs/qemu_arm_spl_defconfig (or the like) to >> get into this state, and we
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote: [snip] > > 3. Anything else? > > > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties > > are present. There is no easy way to fix this. > > one clean and easy way would be to upstream a Qemu change to merge a > supplied overlay to the generated one. This the same idea as applying the > NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do > their job properly for U-Boot : setting up the stage as needed. For the record, I believe Simon did propose this and the QEMU response was that no, you should dumpdtb, combine externally and pass that directly. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Tue, Nov 02, 2021 at 07:32:54PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 2 Nov 2021 at 10:57, Tom Rini wrote: > > > > On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Mon, 1 Nov 2021 at 11:33, François Ozog > > > wrote: > > > > > > > > Hi Simon > > > > > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > > > >> > > > >> Hi Peter, > > > >> > > > >> On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > > >> wrote: > > > >> > > > > >> > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > >> > > > > > >> > > Add this file, generated from qemu, so there is a reference > > > >> > > devicetree > > > >> > > in the U-Boot tree. > > > >> > > > > > >> > > Signed-off-by: Simon Glass > > > >> > > > > >> > 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. > > > > > > As stated previously, I would like to have at least a sample DT > > > in-tree for all boards. I cannot see another way to get the Kconfig > > > > What's the point of having a sample when it's not going to always be > > correct or may be actively wrong and we can tell interested developers / > > users how to get the correct DTB/DTS to examine? > > > > > options in line. If we are able to put these files somewhere else in > > > the future and get them out of U-Boot, with perhaps just an overlay > > > for development purposes, I'd be keen to see it. But for now, this is > > > where we are, I believe. > > > > > > In this particular case, this is not just a dev hack. It is also for > > > CI tests which need to use a devicetree. See for example here: > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-...@chromium.org/ > > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-...@chromium.org/ > > > > This example would probably be better done on vexpress_ca9x4 where we do > > test in CI via QEMU but do not need to modify a device tree that is > > passed on to us, we already control the source of truth DTB in this > > case. > > But that board: > > - uses OF_EMBED, which it should not > - does not use SPL, which I need Check out the other hardware then that we emulate today, and or maybe something off of https://qemu.readthedocs.io/en/latest/system/target-arm.html that we could add. My point is that by picking the QEMU targets for where to test this feature you've gone with "I've introduced this feature so now I need to introduce this other change I've been arguing for too" in an artificial manner as it would only be used like that for testing. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Tue, Nov 02, 2021 at 07:29:54PM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 2 Nov 2021 at 11:28, Tom Rini wrote: > > > > On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 1 Nov 2021 at 12:07, Tom Rini 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 a écrit : > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Add this file, generated from qemu, so there is a reference > > > > > > > > devicetree > > > > > > > > in the U-Boot tree. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > > 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? > > > > I was using two of the more common and readily available platforms where > > the source of truth for the DTS/DTB is not (and will not be) U-Boot. > > > > > 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. > > > > > > To reiterate, the uniform bit of feedback on this series has been that > > everyone else disagrees with your notion that we _must_ have a dts > > in-tree. > > [I would like everyone to take a deep breath and think about what this > actually impacts. I argue the impact outside U-Boot is approximately > zero. What are we actually discussing here?] We're discussing what the point of these files even is. And ensuring that it doesn't lead to some sort of "feature creep" or similar where they do become required to use. > A few have responded that they can just add the files. I think that is Yes, you've asked a number of people to do something, and given your position with the community they just said OK. > the case for everything except QEMU, right? I think even François > agrees with the documentation argument. There is no real burden in > adding the files so we can see what is going on, add a binman node, > SPL nodes, etc. I know François already replied, so I'm replying for myself here. What is the point of these files, if they are not going to ever be used, other than as documentation? So that people that don't have a given platform can more easily browse the device tree for it? That's a documentation fix (doc/board/... should note where to go to find it). > So I am going to stand my ground on that one. It affects: > > - highbank > - qemu-ppce500 > - rpi_4 > - xilinx_versal_virt > - octeontx > - xenguest_arm64 > - juno > > So that is just 7 boards that I want to add devicetree files for. I > think that is reasonable and not a burden on these maintainers. It effects every board where the source of truth for the DT is not the one we're embedding because the hardware doesn't ship with one on it. That's all of the QEMU targets, all of the Pi targets and a growing list of newer hardware too, due to the push for "the hardware should come with the device tree, not the linux kernel" portion of how DT has been intended to work since forever getting realized more often. > Let me deal with QEMU.
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon Le mer. 3 nov. 2021 à 02:30, Simon Glass a écrit : > Hi Tom, > > On Tue, 2 Nov 2021 at 11:28, Tom Rini wrote: > > > > On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 1 Nov 2021 at 12:07, Tom Rini 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 a > écrit : > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell < > peter.mayd...@linaro.org> > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass > wrote: > > > > > > > > > > > > > > > > Add this file, generated from qemu, so there is a reference > devicetree > > > > > > > > in the U-Boot tree. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > > 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? > > > > I was using two of the more common and readily available platforms where > > the source of truth for the DTS/DTB is not (and will not be) U-Boot. > > > > > 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. > > > > > > To reiterate, the uniform bit of feedback on this series has been that > > everyone else disagrees with your notion that we _must_ have a dts > > in-tree. > > [I would like everyone to take a deep breath and think about what this > actually impacts. I argue the impact outside U-Boot is approximately > zero. What are we actually discussing here?] > > A few have responded that they can just add the files. I think that is > the case for everything except QEMU, right? I think even François > agrees with the documentation argument. I do providing that the sample goes into documentation, not actionable as a build artifact in the dts directory. > There is no real burden in > adding the files so we can see what is going on, add a binman node, > SPL nodes, etc. > > So I am going to stand my ground on that one. It affects: > > - highbank > - qemu-ppce500 > - rpi_4 > - xilinx_versal_virt > - octeontx > - xenguest_arm64 > - juno > > So that is just 7 boards that I want to add devicetree files for. I > think that is reasonable and not a burden on these maintainers. > > Let me deal with QEMU. > > Let's imagine that we were in the state that I am proposing here, > which we would be if I were a better devicetree maintainer for U-Boot > and had not taken my eye off the ball, basically with my review of > [1], where I should have pushed to get a response on the questions > before it was applied. That might have triggered me to think about the > implications of this at the time. > > Anyway, in the state that I am proposing, what problems would we have? > > 1. QEMU has a DT which only matches the 'standard' invocation as > documented at [2] > > 2. QEMU may get out of date if there is a new release. > > I don't think (1) is really a problem. People will have to remove > CONFIG_OF_BOARD from configs/qemu_arm_spl_defconfig (or the like) to > get into this state, and we have a message now that prints out where > the devicetree comes from ("separate" in this case): > > Core: 42 devices, 11 uclasses, devicetree: separate > > For (2), I tested QEMU 6.1.50 and the only differenc
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Tom, On Tue, 2 Nov 2021 at 10:57, Tom Rini wrote: > > On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote: > > Hi François, > > > > On Mon, 1 Nov 2021 at 11:33, François Ozog wrote: > > > > > > Hi Simon > > > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > > >> > > >> Hi Peter, > > >> > > >> On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > >> wrote: > > >> > > > >> > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > >> > > > > >> > > Add this file, generated from qemu, so there is a reference > > >> > > devicetree > > >> > > in the U-Boot tree. > > >> > > > > >> > > Signed-off-by: Simon Glass > > >> > > > >> > 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. > > > > As stated previously, I would like to have at least a sample DT > > in-tree for all boards. I cannot see another way to get the Kconfig > > What's the point of having a sample when it's not going to always be > correct or may be actively wrong and we can tell interested developers / > users how to get the correct DTB/DTS to examine? > > > options in line. If we are able to put these files somewhere else in > > the future and get them out of U-Boot, with perhaps just an overlay > > for development purposes, I'd be keen to see it. But for now, this is > > where we are, I believe. > > > > In this particular case, this is not just a dev hack. It is also for > > CI tests which need to use a devicetree. See for example here: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-...@chromium.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-...@chromium.org/ > > This example would probably be better done on vexpress_ca9x4 where we do > test in CI via QEMU but do not need to modify a device tree that is > passed on to us, we already control the source of truth DTB in this > case. But that board: - uses OF_EMBED, which it should not - does not use SPL, which I need > > And also yes, I'm behind on reviewing things I need to review. Aren't we all...I can't even keep up with these threads. Regards, Simon
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Tom, On Tue, 2 Nov 2021 at 11:28, Tom Rini wrote: > > On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 1 Nov 2021 at 12:07, Tom Rini 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 a écrit : > > > > > > > > > Hi Peter, > > > > > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > > > > wrote: > > > > > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > > > > > > > > > Add this file, generated from qemu, so there is a reference > > > > > > > devicetree > > > > > > > in the U-Boot tree. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > 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? > > I was using two of the more common and readily available platforms where > the source of truth for the DTS/DTB is not (and will not be) U-Boot. > > > 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. > > > To reiterate, the uniform bit of feedback on this series has been that > everyone else disagrees with your notion that we _must_ have a dts > in-tree. [I would like everyone to take a deep breath and think about what this actually impacts. I argue the impact outside U-Boot is approximately zero. What are we actually discussing here?] A few have responded that they can just add the files. I think that is the case for everything except QEMU, right? I think even François agrees with the documentation argument. There is no real burden in adding the files so we can see what is going on, add a binman node, SPL nodes, etc. So I am going to stand my ground on that one. It affects: - highbank - qemu-ppce500 - rpi_4 - xilinx_versal_virt - octeontx - xenguest_arm64 - juno So that is just 7 boards that I want to add devicetree files for. I think that is reasonable and not a burden on these maintainers. Let me deal with QEMU. Let's imagine that we were in the state that I am proposing here, which we would be if I were a better devicetree maintainer for U-Boot and had not taken my eye off the ball, basically with my review of [1], where I should have pushed to get a response on the questions before it was applied. That might have triggered me to think about the implications of this at the time. Anyway, in the state that I am proposing, what problems would we have? 1. QEMU has a DT which only matches the 'standard' invocation as documented at [2] 2. QEMU may get out of date if there is a new release. I don't think (1) is really a problem. People will have to remove CONFIG_OF_BOARD from configs/qemu_arm_spl_defconfig (or the like) to get into this state, and we have a message now that prints out where the devicetree comes from ("separate" in this case): Core: 42 devices, 11 uclasses, devicetree: separate For (2), I tested QEMU 6.1.50 and the only difference from 4.2.1 (a year old) is: kaslr-seed = <0x2037f53d 0x42c279e8>; It doesn't affect anything here. It boots the lastest image fine. Just for interest I went back to 2.5.0 which is nearly 6 years old! There are a few differences like dma-coherent and gpio-keys being added, but again it boots fine. So in practice that doesn't seem to be a problem from what I can tell. 3. Anything else? For qemu_arm_spl, it
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 1 Nov 2021 at 12:07, Tom Rini 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 a écrit : > > > > > > > Hi Peter, > > > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > > > wrote: > > > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > > > > > > > Add this file, generated from qemu, so there is a reference > > > > > > devicetree > > > > > > in the U-Boot tree. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > 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? I was using two of the more common and readily available platforms where the source of truth for the DTS/DTB is not (and will not be) U-Boot. > 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. To reiterate, the uniform bit of feedback on this series has been that everyone else disagrees with your notion that we _must_ have a dts in-tree. > > 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. Then we need to get things spun such that we can build the platforms where the dtb is given to us, complete and correct, at run time, to not require an in-tree dts that's not going to be used. Documentation (another area we have much improved on these past few years and for which I am grateful for all of the effort behind!) is how we make the developer use-case for those platforms better. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote: > Hi François, > > On Mon, 1 Nov 2021 at 11:33, François Ozog wrote: > > > > Hi Simon > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > >> > >> Hi Peter, > >> > >> On Mon, 1 Nov 2021 at 04:48, Peter Maydell > >> wrote: > >> > > >> > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > >> > > > >> > > Add this file, generated from qemu, so there is a reference devicetree > >> > > in the U-Boot tree. > >> > > > >> > > Signed-off-by: Simon Glass > >> > > >> > 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. > > As stated previously, I would like to have at least a sample DT > in-tree for all boards. I cannot see another way to get the Kconfig What's the point of having a sample when it's not going to always be correct or may be actively wrong and we can tell interested developers / users how to get the correct DTB/DTS to examine? > options in line. If we are able to put these files somewhere else in > the future and get them out of U-Boot, with perhaps just an overlay > for development purposes, I'd be keen to see it. But for now, this is > where we are, I believe. > > In this particular case, this is not just a dev hack. It is also for > CI tests which need to use a devicetree. See for example here: > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-...@chromium.org/ > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-...@chromium.org/ This example would probably be better done on vexpress_ca9x4 where we do test in CI via QEMU but do not need to modify a device tree that is passed on to us, we already control the source of truth DTB in this case. And also yes, I'm behind on reviewing things I need to review. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Tom, On Mon, 1 Nov 2021 at 12:07, Tom Rini 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 a écrit : > > > > > Hi Peter, > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > > wrote: > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > > > in the U-Boot tree. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > 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
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi François, On Mon, 1 Nov 2021 at 11:33, François Ozog wrote: > > Hi Simon > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : >> >> Hi Peter, >> >> On Mon, 1 Nov 2021 at 04:48, Peter Maydell wrote: >> > >> > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: >> > > >> > > Add this file, generated from qemu, so there is a reference devicetree >> > > in the U-Boot tree. >> > > >> > > Signed-off-by: Simon Glass >> > >> > 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. As stated previously, I would like to have at least a sample DT in-tree for all boards. I cannot see another way to get the Kconfig options in line. If we are able to put these files somewhere else in the future and get them out of U-Boot, with perhaps just an overlay for development purposes, I'd be keen to see it. But for now, this is where we are, I believe. In this particular case, this is not just a dev hack. It is also for CI tests which need to use a devicetree. See for example here: https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-...@chromium.org/ https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-...@chromium.org/ >> >> I am able to use >> QEMU versions that differ by two years, partly because I am not trying >> to do anything clever. >> >> I have sent a patch to add an indication of where the devicetree came >> from, to help with visibility on this. Regards, Simon
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
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 a écrit : > > > Hi Peter, > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > wrote: > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > > in the U-Boot tree. > > > > > > > > Signed-off-by: Simon Glass > > > > > > 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. 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. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > Hi Peter, > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > wrote: > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > in the U-Boot tree. > > > > > > Signed-off-by: Simon Glass > > > > 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. > I am able to use > QEMU versions that differ by two years, partly because I am not trying > to do anything clever. > > I have sent a patch to add an indication of where the devicetree came > from, to help with visibility on this. > > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Peter, On Mon, 1 Nov 2021 at 04:48, Peter Maydell wrote: > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > Add this file, generated from qemu, so there is a reference devicetree > > in the U-Boot tree. > > > > Signed-off-by: Simon Glass > > 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. I am able to use QEMU versions that differ by two years, partly because I am not trying to do anything clever. I have sent a patch to add an indication of where the devicetree came from, to help with visibility on this. Regards, Simon
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > Add this file, generated from qemu, so there is a reference devicetree > in the U-Boot tree. > > Signed-off-by: Simon Glass 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 thanks -- PMM
[PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Add this file, generated from qemu, so there is a reference devicetree in the U-Boot tree. Signed-off-by: Simon Glass --- (no changes since v1) arch/arm/dts/Makefile| 2 +- arch/arm/dts/qemu-arm64.dts | 381 +++ configs/qemu_arm64_defconfig | 1 + 3 files changed, 383 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/qemu-arm64.dts diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 7ab8b145f3f..e70293bb849 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1153,7 +1153,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb -dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb +dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb targets += $(dtb-y) diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts new file mode 100644 index 000..7590e49cc84 --- /dev/null +++ b/arch/arm/dts/qemu-arm64.dts @@ -0,0 +1,381 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Sample device tree for qemu_arm64 + + * Copyright 2021 Google LLC + */ + +/dts-v1/; + +/ { + interrupt-parent = <0x8001>; + #size-cells = <0x02>; + #address-cells = <0x02>; + compatible = "linux,dummy-virt"; + + psci { + migrate = <0xc405>; + cpu_on = <0xc403>; + cpu_off = <0x8402>; + cpu_suspend = <0xc401>; + method = "hvc"; + compatible = "arm,psci-0.2\0arm,psci"; + }; + + memory@4000 { + reg = <0x00 0x4000 0x00 0x800>; + device_type = "memory"; + }; + + platform@c00 { + interrupt-parent = <0x8001>; + ranges = <0x00 0x00 0xc00 0x200>; + #address-cells = <0x01>; + #size-cells = <0x01>; + compatible = "qemu,platform\0simple-bus"; + }; + + fw-cfg@902 { + dma-coherent; + reg = <0x00 0x902 0x00 0x18>; + compatible = "qemu,fw-cfg-mmio"; + }; + + virtio_mmio@a00 { + dma-coherent; + interrupts = <0x00 0x10 0x01>; + reg = <0x00 0xa00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000200 { + dma-coherent; + interrupts = <0x00 0x11 0x01>; + reg = <0x00 0xa000200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000400 { + dma-coherent; + interrupts = <0x00 0x12 0x01>; + reg = <0x00 0xa000400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000600 { + dma-coherent; + interrupts = <0x00 0x13 0x01>; + reg = <0x00 0xa000600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000800 { + dma-coherent; + interrupts = <0x00 0x14 0x01>; + reg = <0x00 0xa000800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000a00 { + dma-coherent; + interrupts = <0x00 0x15 0x01>; + reg = <0x00 0xa000a00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000c00 { + dma-coherent; + interrupts = <0x00 0x16 0x01>; + reg = <0x00 0xa000c00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a000e00 { + dma-coherent; + interrupts = <0x00 0x17 0x01>; + reg = <0x00 0xa000e00 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001000 { + dma-coherent; + interrupts = <0x00 0x18 0x01>; + reg = <0x00 0xa001000 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001200 { + dma-coherent; + interrupts = <0x00 0x19 0x01>; + reg = <0x00 0xa001200 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001400 { + dma-coherent; + interrupts = <0x00 0x1a 0x01>; + reg = <0x00 0xa001400 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001600 { + dma-coherent; + interrupts = <0x00 0x1b 0x01>; + reg = <0x00 0xa001600 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001800 { + dma-coherent; + interrupts = <0x00 0x1c 0x01>; + reg = <0x00 0xa001800 0x00 0x200>; + compatible = "virtio,mmio"; + }; + + virtio_mmio@a001a00