[Qemu-devel] [Bug 1036645] Re: /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot
I see this with Ubuntu 12.04 inside of an armhf chroot. Running 'make deb-pkg' also exposes this issue ** Project changed: qemu => qemu-linaro (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1036645 Title: /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot Status in “qemu-linaro” package in Ubuntu: New Bug description: I am building the Linux kernel in a cross chroot environment. When I run "make distclean", the following messages are emitted: [user@host:/home/work/linux]: make distclean /usr/bin/xargs: rm: Argument list too long make: *** [clean] Error 126 I create the cross chroot environment by making a copy of the root file system from an ARM system. I copy qemu-arm-static to /usr/bin and then chroot into the root file system. If I modify the make file to pass "-s 122880" to xargs, it fixes the problem. I have filed a bug report on xargs: http://savannah.gnu.org/bugs/index.php?37093 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1036645/+subscriptions
Re: [PATCH v6 0/7] Resolve issues with booting distros on x86
On Thu, 04 Jan 2024 08:10:35 -0700, Simon Glass wrote: > This little series reprises the EFI-video fix, fixes a USB problem and > enables a boot script for coreboot. > > It also moves to truetype fonts for coreboot and qemu-x86, since the > menus look much better and there are no strong size constraints. > > With these changes it is possible to boot a Linux distro automatically > with U-Boot on x86, including when U-Boot is the second-stage > bootloader. > > [...] Applied to u-boot/master, thanks! -- Tom
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
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
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 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,
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 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 00/26] fdt: Make OF_BOARD a boolean option
On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog > > > wrote: > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > > > >> wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > Position unchanged on this series: adding fake dts for boards that > > > >> > generate their device tree in the dts directory is not good. If you > > > >> > have them in documentation the it is acceptable. > > > >> > > > >> I think we are going to have to disagree on this one. I actually used > > > >> the qemu one in testing/development recently. We have to have a way to > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > >> cases, so far as I know. > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from > > > > Qemu saying the same thing. > > > > I understand the advanced debug/development scenario you mention. > > > > But locating the DT files in the dts directory is mis-leading the > > > > contributors to think that they need to compile the DT for the targeted > > > > platforms. > > > > For your advanced scenario, you can still have the dts in the > > > > documentation area, or whatever directory (except dts). compile it and > > > > supply to U-Boot. > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > has noticed. U-Boot handles the build automatically. If you turn off > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > going on. > > > > Until. The Raspberry Pi foundation releases a new firmware that > > configures the hardware differently such that the addresses in the > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > as well as more recently on the rpi 4. > > So I update my SD card with a new private-binary bootloader and things > stop working? I think I can narrow that one down :-) Well, wait, no, this is the point. You can just not update your board. But that all of the users running a more recent release are now broken is the problem. It's already an opt-in thing to use U-Boot on Pis and if we make it even more annoying to be recent, there'll be even less reason to use U-Boot over over the Pi+TianoCore if you want anything more fancy that direct-to-Linux booting. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote: > > From: Simon Glass > > Date: Tue, 2 Nov 2021 19:20:51 -0600 > > > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > > > Hi François, > > > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > > > >> > > > > >> Hi François, > > > > >> > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > > > > >> wrote: > > > > >> > > > > > >> > Hi Simon > > > > >> > > > > > >> > Position unchanged on this series: adding fake dts for boards that > > > > >> > generate their device tree in the dts directory is not good. If > > > > >> > you have them in documentation the it is acceptable. > > > > >> > > > > >> I think we are going to have to disagree on this one. I actually used > > > > >> the qemu one in testing/development recently. We have to have a way > > > > >> to > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > > >> cases, so far as I know. > > > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from > > > > > Qemu saying the same thing. > > > > > I understand the advanced debug/development scenario you mention. > > > > > But locating the DT files in the dts directory is mis-leading the > > > > > contributors to think that they need to compile the DT for the > > > > > targeted platforms. > > > > > For your advanced scenario, you can still have the dts in the > > > > > documentation area, or whatever directory (except dts). compile it > > > > > and supply to U-Boot. > > > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > > has noticed. U-Boot handles the build automatically. If you turn off > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > > going on. > > > > > > Until. The Raspberry Pi foundation releases a new firmware that > > > configures the hardware differently such that the addresses in the > > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > > as well as more recently on the rpi 4. > > > > So I update my SD card with a new private-binary bootloader and things > > stop working? I think I can narrow that one down :-) > > > > > > We can add a message to U-Boot indicating where the devicetree came > > > > from, perhaps? That might be useful given everything that is going on. > > > > > > > > As in this case, quite often in these discussions I struggle to > > > > understand what is behind the objection. Is it that your customers are > > > > demanding that devicetrees become private, secret data, not included > > > > in open-source projects? Or is it just the strange case of QEMU that > > > > is informing your thinking? I know of at least one project where the > > > > first-stage bootloader produces a devicetree and no one has the source > > > > for it. I believe TF-A was created for licensing reasons...so can you > > > > be a bit clearer about what the problem actually is? If a board is > > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > > until we have a better option. At the very least, it MUST be > > > > discoverable and it must be possible to undertake U-Boot development > > > > easily without a lot of messing around. > > > > > > How many people are there out there that work on U-Boot that don't > > > have a Linux source tree checked out? Even I have several of those > > > lying around on my development systems and I am an OpenBSD developer ;). > > > > So it is OK to have the DT in Linux but not in U-Boot? I don't even > > know what to say that. How does that square with your point above? > > Ideally the DT's and DT binding would move out of the Linux tree and > into a repository of their own. But until that is the case, the Linux > tree is the source of truth. Yes, and this is a long known and slowly in progress kinda-sorta thing. A few more people helping to review things, etc, are always appreciated by upstream. > > I am not talking about disabling OF_BOARD, just making it *possible* > > to do so. > > And I don't think it makes sense to do so on most boards that have > OF_BOARD in their config. It should probably close to never be done, unless it's some case where it's crazy-hard to update the device tree correctly for the platform. So it's not a problem on Pi as it's just on the FAT32 partition right there, it's not a problem on Apple M1 as ..however you do it.., and so on. I can almost hear the argument from here about "but I'm doing some work for U-Boot and need to add..." and that's where we need to figure out what to do next. Yes, we likely need to have some bindings of our own, and developing those AND pushing them upstream will
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
On Wed, Nov 03, 2021 at 10:45:11AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 27 Oct 2021 at 13:25, Tom Rini wrote: > > > > On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog > > > wrote: > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > > > >> wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > Position unchanged on this series: adding fake dts for boards that > > > >> > generate their device tree in the dts directory is not good. If you > > > >> > have them in documentation the it is acceptable. > > > >> > > > >> I think we are going to have to disagree on this one. I actually used > > > >> the qemu one in testing/development recently. We have to have a way to > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > >> cases, so far as I know. > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from > > > > Qemu saying the same thing. > > > > I understand the advanced debug/development scenario you mention. > > > > But locating the DT files in the dts directory is mis-leading the > > > > contributors to think that they need to compile the DT for the targeted > > > > platforms. > > > > For your advanced scenario, you can still have the dts in the > > > > documentation area, or whatever directory (except dts). compile it and > > > > supply to U-Boot. > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > has noticed. U-Boot handles the build automatically. If you turn off > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > going on. > > > > That we have to have so many separate rpi build targets, and can't just > > use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi > > configs that use CONFIG_OF_EMBED are on your list of things that need to > > be cleaned up, yes? > > Yes, it should use CONFIG_OF_SEPARATE. It think it didn't for > historical reasons, but not sure why. I think because it wasn't clear enough at the time how to say "just use the dtb given to us as-is". > > > We can add a message to U-Boot indicating where the devicetree came > > > from, perhaps? That might be useful given everything that is going on. > > > > > > As in this case, quite often in these discussions I struggle to > > > understand what is behind the objection. Is it that your customers are > > > demanding that devicetrees become private, secret data, not included > > > in open-source projects? Or is it just the strange case of QEMU that > > > is informing your thinking? I know of at least one project where the > > > first-stage bootloader produces a devicetree and no one has the source > > > for it. I believe TF-A was created for licensing reasons...so can you > > > be a bit clearer about what the problem actually is? If a board is > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > until we have a better option. At the very least, it MUST be > > > discoverable and it must be possible to undertake U-Boot development > > > easily without a lot of messing around. > > > > What I don't understand here is why or how U-Boot is supposed to become > > the source of truth for device trees. The general goal is that the > > device tree be something that actually comes along on the hardware, > > because it's stable enough and correct enough that it's not going to be > > changed from one OS kernel release to the next. That should be where > > the correct and true tree comes from, the device itself. > > Is that the confusion here? I am not saying that U-Boot becomes the > 'source of truth' (horrible term). Where did that idea come from? > > By hardware you mean firmware, I think. If you are developing > firmware, you need control of the devicetree. It is part of the > firmware. I mean the case where U-Boot is provided the device tree to use, by whatever external and non-U-Boot means. I keep saying "source of truth" as a way to clarify that the correct and only required device tree is given to us at run time. If U-Boot needs to know something, it's already provided there. If it's not there, we don't need to know it. This is also why there's not a reason to normally build a device tree in U-Boot since it will not be used. And if we aren't building it, we don't need it in the source tree either since it's going to introduce confusion. Quoted in part or referenced under doc/ ? OK, that can make sense in some cases. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > Hi all, > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote: > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > Hi François, > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog > > > > > wrote: > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a > > > > > > écrit : > > > > > >> > > > > > >> Hi Tom, Bin,François, > > > > > >> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > > > > > >> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > >> > > Hi Simon, > > > > > >> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > > > > > >> > > wrote: > > > > > >> > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > >> > > > OF_HOSTFILE so > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > >> > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > >> > > > built and > > > > > >> > > > appended to U-Boot > > > > > >> > > >- OF_EMBED - for development purposes, the devicetree is > > > > > >> > > > embedded in > > > > > >> > > > the ELF file (also used for EFI) > > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > > >> > > > > > > > > >> > > > The last one is currently set up so that no devicetree is > > > > > >> > > > needed at all > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some > > > > > >> > > > don't. Some > > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > > >> > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > >> > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > > > >> > > > OF_SEPARATE. Any board > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > > > > > >> > > > devicetree built > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > >> > > > bootloader and its > > > > > >> > > > caller may have a better idea about the hardware available > > > > > >> > > > in the machine. > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > >> > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > >> > > > should be an > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > >> > > > > > > > > >> > > > This series makes this change, adding various missing > > > > > >> > > > devicetree files > > > > > >> > > > (and placeholders) to make the build work. > > > > > >> > > > > > > > >> > > Adding device trees that are never used sounds like a hack to > > > > > >> > > me. > > > > > >> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > > > > > >> > > based on > > > > > >> > > command line parameters, and the device tree you put in t
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> Hi Simon,
>
> A bit late to the party, sorry!
>
> [...]
>
> > >
> > > I really want to see what the binary case looks like since we could then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > use the device tree from build time at run time, ignoring the device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency to the
> > different components. Binman was one effort there. I feel that putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
> >
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT. It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
> >
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
>
> Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> that to the DTs that are copied over from linux isn't imho. There are
> various reasons for that. First of all syncing device trees is a huge pain
> and that's probably one of the main reasons our DTs are out of sync for a
> large number of boards.
This re-sync is only a pain because:
1. Some platforms have been modifying the core dts files LIKE THEY ARE
NOT SUPPOSED TO.
2. DTS files are getting closer to being the super stable API that has
been promised now that there's validation tools.
Some SoCs, like stm32 are doing an amazing job and keeping things in
sync, every release. Others like NXP are violating rule #1. Still
others like some TI platforms get bit by #2 (I solved one of these, and
need to cycle back to the one you and I talked about on IRC a while
back, I bet it's another node name dash changed to underbar).
> The point is this was fine in 2011 were we had SPL only, but the reality
> today is completely different. There's previous stage boot loaders (and
> enough cases were vendors prefer those over SPL). If that bootloader needs
> to use it's own device tree for whatever reason, imposing restrictions on
> it wrt to the device tree it has to include, and require them to have
> knowledge of U-Boot and it's internal config mechanism makes no sense not
> to mention it doesn't scale at all.
If you are passing the full device tree around, a few more
nodes/properties aren't going to make the situation worse. If we're
talking about a 60 kilobyte blob one more kilobyte isn't where we call
the line, especially since if we wait another 6 months it'll be a 62
kilobyte file coming in from Linux instead.
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
>
> Again, the board might decide
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> Hi Tom,
>
> On Wed, 27 Oct 2021 at 14:59, Tom Rini wrote:
>
> > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > Hi Simon,
> > >
> > > A bit late to the party, sorry!
> > >
> > > [...]
> > >
> > > > >
> > > > > I really want to see what the binary case looks like since we could
> > then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > don't
> > > > > use the device tree from build time at run time, ignoring the device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to the
> > > > different components. Binman was one effort there. I feel that putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > devicetree standard, like the /chosen node but with less history. We
> > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > of 'devicetree is a hardware description'. How do we get over that
> > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > it always has to have those properties, but with existing features
> > > > like verified boot, SPL as well as complex firmware images where
> > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > So let's just assume that we need this everywhere, since we certainly
> > > > need it in at least some places.
> > > >
> > > > (stop reading here if you disagree, because nothing below will make
> > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > OF_CONTROL :-)
> > >
> > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > that to the DTs that are copied over from linux isn't imho. There are
> > > various reasons for that. First of all syncing device trees is a huge
> > pain
> > > and that's probably one of the main reasons our DTs are out of sync for a
> > > large number of boards.
> >
> > This re-sync is only a pain because:
> > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> >NOT SUPPOSED TO.
> > 2. DTS files are getting closer to being the super stable API that has
> >been promised now that there's validation tools.
> >
> > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > sync, every release. Others like NXP are violating rule #1.
>
> With NXP commitment to SystemReady on some IMX8 boards, I think this is
> changing,
> at least for the SystemReady boards.
I'd really like to see some progress (as would the other non-NXP folks
working on NXP SoCs) in that regard.
> > Still
>
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote:
> Hi trying to reply to all at the same time!
>
> On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > >
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini wrote:
> > >
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> > > > > > > could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > > > > > > could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> > > > > > > come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the
> > > > > > > device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to
> > > > > > the
> > > > > > different components. Binman was one effort there. I feel that
> > > > > > putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the
> > > > > > past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history. We
> > > > > > should sacrifice efficiency, expedience and expandability on the
> > > > > > altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is
> > > > > > essential.
> > > > > > So let's just assume that we need this everywhere, since we
> > > > > > certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote:
> On Wed, 27 Oct 2021 at 15:38, Tom Rini wrote:
>
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > >
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini wrote:
> > >
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> > could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> > come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the
> > device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry
> > on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to
> > the
> > > > > > different components. Binman was one effort there. I feel that
> > putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> > set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the
> > past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history.
> > We
> > > > > > should sacrifice efficiency, expedience and expandability on the
> > altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses
> > devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not
> > saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is
> > essential.
> > > > > > So let's just assume that we need this everywhere, since we
> > certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> > Adding
> > > > > that to the DTs that are copied over from linux isn't imho. There
> > are
> > > > > various reasons for that.
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: [snip] > One passed to U-Boot for fixups and further passed to the OS. This > devicetree may originate from a prior boot stage, from a file loaded by > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. I assume systemd-boot is implementing the same logic that extlinux.conf has used for forever, yes? > This devicetree will not contain any U-Boot specific information. To repeat, it must only have official bindings, yes, regardless of what project they come from. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote: > Hi, > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > Hi all, > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote: > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > Hi François, > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass > > a écrit : > > > > > > > >> > > > > > > > >> Hi Tom, Bin,François, > > > > > > > >> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > > wrote: > > > > > > > >> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > >> > > Hi Simon, > > > > > > > >> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > s...@chromium.org> wrote: > > > > > > > >> > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > OF_HOSTFILE so > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > >> > > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree > > is built and > > > > > > > >> > > > appended to U-Boot > > > > > > > >> > > >- OF_EMBED - for development purposes, the > > devicetree is embedded in > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > > > > >> > > > > > > > > > > >> > > > The last one is currently set up so that no devicetree > > is needed at all > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > some don't. Some > > > > > > > >> > > > don't even provide instructions on how to boot on the > > board. > > > > > > > >> > > > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > > > >> > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > OF_SEPARATE. Any board > > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > > devicetree built > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > bootloader and its > > > > > > > >> > > > caller may have a better idea about the hardware > > available in the machine. > > > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > > > >> > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > should be an > > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > >> > > > > > > > > > > >> > > > This series makes this change, adding various missing > > devicetree files > > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > > >> > > > > > > > > > >> > > Adding device trees that are never used sounds like a > > hack to me. > > > > > > > >> > > > > > > &g
Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > François Ozog writes: > > > Hi Simon > > > > The only place I could agree with this file presence is in the > > documentation directory, not in dts. It creates a mental picture for the > > reader > > an entirely bad mind scheme around Qemu and DT. > > > > And even in a documentation directory I would place a bug warning: don’t > > use this with any kernel , Qemu generates a DT dynamically > > based on cpu, memory and devices specified at the command line. > > Certainly for the arm, aarch64 and riscv "virt" machines you should > always use the QEMU generated DTB. I'm not entirely clear what a > qemu_arm and qemu_arm64 def targets are meant to be in this context. Agreed. We cannot include random device trees in U-Boot for devices that generate their own at run time or otherwise have the source of truth elsewhere. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote: > On 10/27/21 16:55, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote: > > > > [snip] > > > One passed to U-Boot for fixups and further passed to the OS. This > > > devicetree may originate from a prior boot stage, from a file loaded by > > > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command. > > > > I assume systemd-boot is implementing the same logic that extlinux.conf > > has used for forever, yes? > > It is loading the file and then calls U-Boot's implementation of the EFI > Device Tree Fixup Protocol for fixups before passing the device-tree to the > OS. So it's using https://systemd.io/BOOT_LOADER_SPECIFICATION/ OK. > > > This devicetree will not contain any U-Boot specific information. > > > > To repeat, it must only have official bindings, yes, regardless of what > > project they come from. > > > > Don't expect prior firmware stages to provide any U-Boot specific stuff > whatever official or non-official U-Boot specific bindings exist. Failure to implement official bindings may result in failure to boot, which would be pretty silly. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis wrote: > > > > > From: François Ozog > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > Hi, > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > Hi all, > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote: > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass > > > > > > > > > > > > > > a écrit : > > > > > > > > > >> > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > >> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > > > > wrote: > > > > > > > > > >> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > > > > >> > > Hi Simon, > > > > > > > > > >> > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > s...@chromium.org> wrote: > > > > > > > > > >> > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE > > > > > > > > > >> > > > and > > > > OF_HOSTFILE so > > > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > > > >> > > > > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the > > > > > > > > > >> > > > devicetree > > > > is built and > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > >> > > >- OF_EMBED - for development purposes, the > > > > devicetree is embedded in > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > >> > > > > > > > > > > > > >> > > > The last one is currently set up so that no > > > > > > > > > >> > > > devicetree > > > > is needed at all > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > > > some don't. Some > > > > > > > > > >> > > > don't even provide instructions on how to boot on the > > > > board. > > > > > > > > > >> > > > > > > > > > > > > >> > > > The problems with this approach are documented at > > > > > > > > > >> > > > [1]. > > > > > > > > > >> > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > > OF_SEPARATE. Any board > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is has > > > > > > > > > >> > > > a > > > > devicetree built > > > > > > > > > >> > > > in U-Boot. This i
Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote: > Hi all, > > On Wed, 27 Oct 2021 at 08:56, Tom Rini wrote: > > > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > > > > > François Ozog writes: > > > > > > > Hi Simon > > > > > > > > The only place I could agree with this file presence is in the > > > > documentation directory, not in dts. It creates a mental picture for > > > > the reader > > > > an entirely bad mind scheme around Qemu and DT. > > > > > > > > And even in a documentation directory I would place a bug warning: > > > > don’t use this with any kernel , Qemu generates a DT dynamically > > > > based on cpu, memory and devices specified at the command line. > > > > > > Certainly for the arm, aarch64 and riscv "virt" machines you should > > > always use the QEMU generated DTB. I'm not entirely clear what a > > > qemu_arm and qemu_arm64 def targets are meant to be in this context. > > > > Agreed. We cannot include random device trees in U-Boot for devices > > that generate their own at run time or otherwise have the source of > > truth elsewhere. > > Until we have a way of bringing in the u-boot.dtsi that people in QEMU > can agree on, I don't see an alternative. I will send a series for the > bloblist handoff next week and I think you will all see what I mean. I think the alternative is that QEMU in U-Boot just can't be used for certain features. Which is annoying in that it would be good to use it to test certain feature, yes. It's generating a good and valid enough dtb for Linux, so it should be good enough for us in general. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 00:07, François Ozog wrote: > > > > Hi Simon > > > > Position unchanged on this series: adding fake dts for boards that generate > > their device tree in the dts directory is not good. If you have them in > > documentation the it is acceptable. > > I think we are going to have to disagree on this one. I'm not convinced either that we want or should have checked in device trees for all of the platforms where the source of truth is elsewhere. > I actually used > the qemu one in testing/development recently. We have to have a way to > develop in-tree with U-Boot. It does not impinge on any of your use > cases, so far as I know. It's certainly true that the "edit, rebuild, re-pass the dtb" cycle has been sub-optimal since inception. It's not even U-Boot related. I can count a number of times recently working with customers and just for Linux, having to spend a number of hours on the edit, rebuild, really make sure it gets populated where it's supposed to go, verify that yes really our modified dtb is the one present cycle. It's a very generic problem. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 08:08:19AM -0600, Simon Glass wrote: [snip] > But trying to do any driver / core work for a board where you don't > have the devicetree is currently not possible. The devicetree is a > core component and being unable to modify it is simply not practical. > We are talking here about an option that can be enabled or disabled. > In my case I am able to disable it locally and do my development work. This certainly is an area where it's easier to work on arm32 platforms, where we aren't getting the DT passed in, than arm64, where we almost certainly are. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > Hi Mark, > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis wrote: > > > > From: François Ozog > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > Hi, > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > Hi all, > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote: > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini > > wrote: > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > s...@chromium.org> > > > > a écrit : > > > > > > > > > >> > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > >> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > tr...@konsulko.com> > > > > wrote: > > > > > > > > > >> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > wrote: > > > > > > > > > >> > > Hi Simon, > > > > > > > > > >> > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > s...@chromium.org> wrote: > > > > > > > > > >> > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE > > and > > > > OF_HOSTFILE so > > > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > > > >> > > > > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the > > devicetree > > > > is built and > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > >> > > >- OF_EMBED - for development purposes, the > > > > devicetree is embedded in > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > >> > > > > > > > > > > > > >> > > > The last one is currently set up so that no > > devicetree > > > > is needed at all > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > > > some don't. Some > > > > > > > > > >> > > > don't even provide instructions on how to boot on > > the > > > > board. > > > > > > > > > >> > > > > > > > > > > > > >> > > > The problems with this approach are documented at > > [1]. > > > > > > > > > >> > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > > OF_SEPARATE. Any board > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is > > has a > > > > devicetree built > > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > > second-stage > > > > bootloader and its > > > > > > > > > >> > > > caller may have a better idea about the hardware > > > > available in the machine
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 06:36:12PM +0300, Tuomas Tynkkynen wrote: > Hi, > > On 27.10.2021 17.08, Simon Glass wrote: > > Hi François, > > > > On Tue, 26 Oct 2021 at 00:07, François Ozog > > wrote: > > > > > > Hi Simon > > > > > > Position unchanged on this series: adding fake dts for boards that > > > generate their device tree in the dts directory is not good. If you have > > > them in documentation the it is acceptable. > > > > I think we are going to have to disagree on this one. I actually used > > the qemu one in testing/development recently. We have to have a way to > > develop in-tree with U-Boot. It does not impinge on any of your use > > cases, so far as I know. > > > > How about having the file just contain a single line > > #include > > ... where this generated-*.dts is not checked to the source tree. Then of > course comments on how to generate it via qemu -dumpdtb + dtc, with > appropriate precautions (ie. must be regenerated if qemu command line is > changed or qemu is upgraded), intended use case, and so forth. That seems like it would help the development workflow, yes. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > Hi François, > > On Wed, 27 Oct 2021 at 09:14, François Ozog wrote: > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > >> wrote: > >> > > >> > Hi Simon > >> > > >> > Position unchanged on this series: adding fake dts for boards that > >> > generate their device tree in the dts directory is not good. If you have > >> > them in documentation the it is acceptable. > >> > >> I think we are going to have to disagree on this one. I actually used > >> the qemu one in testing/development recently. We have to have a way to > >> develop in-tree with U-Boot. It does not impinge on any of your use > >> cases, so far as I know. > > > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu > > saying the same thing. > > I understand the advanced debug/development scenario you mention. > > But locating the DT files in the dts directory is mis-leading the > > contributors to think that they need to compile the DT for the targeted > > platforms. > > For your advanced scenario, you can still have the dts in the documentation > > area, or whatever directory (except dts). compile it and supply to U-Boot. > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > has noticed. U-Boot handles the build automatically. If you turn off > OF_BOARD, it will use the U-Boot devicetree always so you know what is > going on. That we have to have so many separate rpi build targets, and can't just use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi configs that use CONFIG_OF_EMBED are on your list of things that need to be cleaned up, yes? > We can add a message to U-Boot indicating where the devicetree came > from, perhaps? That might be useful given everything that is going on. > > As in this case, quite often in these discussions I struggle to > understand what is behind the objection. Is it that your customers are > demanding that devicetrees become private, secret data, not included > in open-source projects? Or is it just the strange case of QEMU that > is informing your thinking? I know of at least one project where the > first-stage bootloader produces a devicetree and no one has the source > for it. I believe TF-A was created for licensing reasons...so can you > be a bit clearer about what the problem actually is? If a board is > in-tree in U-Boot I would like it to have a devicetree there, at least > until we have a better option. At the very least, it MUST be > discoverable and it must be possible to undertake U-Boot development > easily without a lot of messing around. What I don't understand here is why or how U-Boot is supposed to become the source of truth for device trees. The general goal is that the device tree be something that actually comes along on the hardware, because it's stable enough and correct enough that it's not going to be changed from one OS kernel release to the next. That should be where the correct and true tree comes from, the device itself. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Thu, Oct 28, 2021 at 12:00:44AM +0200, François Ozog wrote: > Hi Tom > > Le mer. 27 oct. 2021 à 21:06, Tom Rini a écrit : > > > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > > > Hi Mark, > > > > > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis > > wrote: > > > > > > > > From: François Ozog > > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > > > Hi, > > > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini > > wrote: > > > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > > wrote: > > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > > > s...@chromium.org> > > > > > > a écrit : > > > > > > > > > > > >> > > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > > >> > > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > > > tr...@konsulko.com> > > > > > > wrote: > > > > > > > > > > > >> > > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > > > wrote: > > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > > > s...@chromium.org> wrote: > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped > > OF_PRIOR_STAGE > > > > and > > > > > > OF_HOSTFILE so > > > > > > > > > > > >> > > > there are only three ways to obtain a > > devicetree: > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the > > > > devicetree > > > > > > is built and > > > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > > > >> > > >- OF_EMBED - for development purposes, the > > > > > > devicetree is embedded in > > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > > >> > > >- OF_BOARD - the board figures it out on its > > own > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > The last one is currently set up so that no > > > > devicetree > > > > > > is needed at all > > > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > > but > > > > > > some don't. Some > > > > > > > > > > > >> > > > don't even provide instructions on how to boot > > on > > > > the > > > > > > board. > > &
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > Hi Simon, > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > >- OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > >- OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > caller may have a better idea about the hardware available in the machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > Adding device trees that are never used sounds like a hack to me. > > For QEMU, device tree is dynamically generated on the fly based on > command line parameters, and the device tree you put in this series > has various hardcoded values which normally do not show up > in hand-written dts files. > > I am not sure I understand the whole point of this. I am also confused and do not like the idea of adding device trees for platforms that are capable of and can / do have a device tree to give us at run time. -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
On Wed, Oct 13, 2021 at 10:58:31AM -0600, Simon Glass wrote: > Hi François, > > On Tue, 12 Oct 2021 at 19:20, François Ozog wrote: > > > > > > > > Le mer. 13 oct. 2021 à 03:02, Simon Glass a écrit : > >> > >> QEMU currently generates a devicetree for use with U-Boot. Explain how to > >> obtain it. > >> > >> Signed-off-by: Simon Glass > >> --- > >> > >> doc/board/emulation/qemu-arm.rst | 12 > >> 1 file changed, 12 insertions(+) > >> > >> diff --git a/doc/board/emulation/qemu-arm.rst > >> b/doc/board/emulation/qemu-arm.rst > >> index 97b6ec64905..b458a398c69 100644 > >> --- a/doc/board/emulation/qemu-arm.rst > >> +++ b/doc/board/emulation/qemu-arm.rst > >> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these > >> settings:: > >> CONFIG_DEBUG_UART_PL010=y > >> CONFIG_DEBUG_UART_BASE=0x900 > >> CONFIG_DEBUG_UART_CLOCK=0 > >> + > >> +Obtaining the QEMU devicetree > >> +- > >> + > >> +QEMU generates its own devicetree to pass to U-Boot and does this by > >> default. > >> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree > >> version. > > > > this is for either Qemu experts or u-boot for Qemu maintainers. Not for the > > kernel développer as it is recipe for problems: could you add this warning ? > > Yes I can do that...or would it be better to hide this in doc/develop > somewhere with a link here? Somewhere under doc/develop and an external link to the QEMU documentation on dumpdtb would be good, as it's (as you demonstrate throughout this series) a generic feature. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > Hi François, > > On Wed, 13 Oct 2021 at 11:35, François Ozog wrote: > > > > Hi Simon > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit : > >> > >> Hi Tom, Bin,François, > >> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > >> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > >> > > Hi Simon, > >> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > >> > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> > > > there are only three ways to obtain a devicetree: > >> > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree is built and > >> > > > appended to U-Boot > >> > > >- OF_EMBED - for development purposes, the devicetree is embedded > >> > > > in > >> > > > the ELF file (also used for EFI) > >> > > >- OF_BOARD - the board figures it out on its own > >> > > > > >> > > > The last one is currently set up so that no devicetree is needed at > >> > > > all > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > >> > > > don't even provide instructions on how to boot on the board. > >> > > > > >> > > > The problems with this approach are documented at [1]. > >> > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > >> > > > board > >> > > > can obtain its devicetree at runtime, even it is has a devicetree > >> > > > built > >> > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > >> > > > and its > >> > > > caller may have a better idea about the hardware available in the > >> > > > machine. > >> > > > This is the case with a few QEMU boards, for example. > >> > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > >> > > > > >> > > > This series makes this change, adding various missing devicetree > >> > > > files > >> > > > (and placeholders) to make the build work. > >> > > > >> > > Adding device trees that are never used sounds like a hack to me. > >> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > >> > > command line parameters, and the device tree you put in this series > >> > > has various hardcoded values which normally do not show up > >> > > in hand-written dts files. > >> > > > >> > > I am not sure I understand the whole point of this. > >> > > >> > I am also confused and do not like the idea of adding device trees for > >> > platforms that are capable of and can / do have a device tree to give us > >> > at run time. > >> > >> (I'll just reply to this one email, since the same points applies to > >> all replies I think) > >> > >> I have been thinking about this and discussing it with people for a > >> few months now. I've been signalling a change like this for over a > >> month now, on U-Boot contributor calls and in discussions with Linaro > >> people. I sent a patch (below) to try to explain things. I hope it is > >> not a surprise! > >> > >> The issue here is that we need a devicetree in-tree in U-Boot, to > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > >> Ilias' series and this one we can get ourselves on a stronger footing. > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > >> For more context: > >> > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> BTW I did suggest to QEMU ARM that they support a way of adding the > >> u-boot.dtsi but there was not much interest there (in fact the > >> maintainer would prefer there was no special support even for booting > >> Linux
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > Hi François, > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog > > > wrote: > > > > > > > > Hi Simon > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit : > > > >> > > > >> Hi Tom, Bin,François, > > > >> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > > > >> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > >> > > Hi Simon, > > > >> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > > > >> > > wrote: > > > >> > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > >> > > > OF_HOSTFILE so > > > >> > > > there are only three ways to obtain a devicetree: > > > >> > > > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree is built > > > >> > > > and > > > >> > > > appended to U-Boot > > > >> > > >- OF_EMBED - for development purposes, the devicetree is > > > >> > > > embedded in > > > >> > > > the ELF file (also used for EFI) > > > >> > > >- OF_BOARD - the board figures it out on its own > > > >> > > > > > > >> > > > The last one is currently set up so that no devicetree is needed > > > >> > > > at all > > > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. > > > >> > > > Some > > > >> > > > don't even provide instructions on how to boot on the board. > > > >> > > > > > > >> > > > The problems with this approach are documented at [1]. > > > >> > > > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > > > >> > > > Any board > > > >> > > > can obtain its devicetree at runtime, even it is has a > > > >> > > > devicetree built > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > > > >> > > > bootloader and its > > > >> > > > caller may have a better idea about the hardware available in > > > >> > > > the machine. > > > >> > > > This is the case with a few QEMU boards, for example. > > > >> > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > > > >> > > > be an > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > >> > > > > > > >> > > > This series makes this change, adding various missing devicetree > > > >> > > > files > > > >> > > > (and placeholders) to make the build work. > > > >> > > > > > >> > > Adding device trees that are never used sounds like a hack to me. > > > >> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > > > >> > > command line parameters, and the device tree you put in this series > > > >> > > has various hardcoded values which normally do not show > > > >> > > up > > > >> > > in hand-written dts files. > > > >> > > > > > >> > > I am not sure I understand the whole point of this. > > > >> > > > > >> > I am also confused and do not like the idea of adding device trees > > > >> > for > > > >> > platforms that are capable of and can / do have a device tree to > > > >> > give us > > > >> > at run time. > > > >> > > > >> (I'll just reply to this one email, since the same points applies to > > > >> all replies I think) > > > >> > > > >> I have been thinking about this and discussing it with people for a
[Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior
Hey all, I'm trying to make use of the r2d platform for U-Boot testing via QEMU. After applying a series[1] I can use the kernel.org sh4 toolchain to get a u-boot.bin that runs, mostly. I say mostly as first of all I have to pass "-monitor null -serial null -serial stdio -nographic" to qemu-system-sh4 and in that order for me to get output from U-Boot on the prompt. On other platforms such as arm and vexpress or i386 and the 'pc' machine I do not need to do this. Does anyone have any idea why this might be and where to start poking in the code to fix this? I see this on v2.8.0-rc1 along with various older releases, thanks! [1]: https://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ -- Tom signature.asc Description: Digital signature
Re: [Qemu-devel] qemu-system-sh4 vs qemu-system-arm/i386 default behavior
On Wed, Nov 30, 2016 at 10:12:09AM +0100, Thomas Huth wrote: > On 30.11.2016 09:02, Aurelien Jarno wrote: > > On 2016-11-30 08:33, Thomas Huth wrote: > >> On 30.11.2016 02:01, Tom Rini wrote: > >>> Hey all, > >>> > >>> I'm trying to make use of the r2d platform for U-Boot testing via QEMU. > >>> After applying a series[1] I can use the kernel.org sh4 toolchain to get > >>> a u-boot.bin that runs, mostly. I say mostly as first of all I have to > >>> pass "-monitor null -serial null -serial stdio -nographic" to > >>> qemu-system-sh4 and in that order for me to get output from U-Boot on > >>> the prompt. On other platforms such as arm and vexpress or i386 and the > >>> 'pc' machine I do not need to do this. Does anyone have any idea why > >>> this might be and where to start poking in the code to fix this? > > > > The reason is that u-boot and the linux kernel do not have the same way > > to number the serial port than the physical hardware. Therefore u-boot > > and the Linux kernel use the second physical serial port .The question is > > whether we should number our ports from the software (or part of the > > sofrware) or hardware point of view. > > OK, thanks for the explanation, that makes sense now. ... maybe we > should put this information on a SH4 machine page under > http://qemu-project.org/Documentation/Platforms so that users have a > possibility to understand this serial port numbering? I'm still a bit confused, sorry. Digging around a bit I guess what is happening is that serial_hds[0] is being used, but Linux and U-Boot expect to use serial_hds[1] and that's what the above combination of arguments is getting me? How would I go about saying in a more simple form perhaps, to use the second described port not the first described port? Thanks! -- Tom signature.asc Description: Digital signature
Re: [PATCH v2 00/28] x86: Improve operation under QEMU
On Sun, Feb 16, 2025 at 01:43:45PM -0700, Simon Glass wrote: > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > is not perfect. > > With both builds, executing the VESA ROM causes an intermittent hang, at > least on some AMD CPUs. > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > is done in a way that works on real hardware but not with QEMU. This > means that performance is 4-5x slower than it could be, at least on my > CPU. > > We can work around the first problem by using Bochs, which is anyway a > better choice than VESA for QEMU. The second can be addressed by using > the same descriptor across the jump to long mode. > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 This seems needlessly not against mainline. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 00/47] x86: Improve operation under QEMU
On Sat, Mar 15, 2025 at 12:54:25PM +, Simon Glass wrote: > Hi Tom, > > On Fri, 14 Mar 2025 at 16:06, Tom Rini wrote: > > > > On Fri, Mar 14, 2025 at 02:44:35PM +, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 7 Mar 2025 at 14:23, Tom Rini wrote: > > > > > > > > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote: > > > > > > > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but > > > > > it > > > > > is not perfect. > > > > > > > > > > With both builds, executing the VESA ROM causes an intermittent hang, > > > > > at > > > > > least on some AMD CPUs. > > > > > > > > > > With qemu-x86_64 kvm cannot be used since the move to long mode > > > > > (64-bit) > > > > > is done in a way that works on real hardware but not with QEMU. This > > > > > means that performance is 4-5x slower than it could be, at least on my > > > > > CPU. > > > > > > > > > > We can work around the first problem by using Bochs, which is anyway a > > > > > better choice than VESA for QEMU. The second can be addressed by using > > > > > the same descriptor across the jump to long mode. > > > > > > > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > > > > > > > > > In v3 some e820 patches are included to make booting reliable and > > > > > avoid > > > > > ACPI tables being dropped. Also, several MTTR problems are addressed, > > > > > to > > > > > support memory sizes above 4GB reliably. > > > > > > > > Do you plan to rebase the prerequisite series' this requires so that it > > > > can be merged? > > > > > > Here's my understanding of where things are: > > > > > > 1. You rejected the membuf series and my replies to try to resolve > > > that haven't gone anywhere yet. So your tree doesn't have any tests > > > for that code and still has the old naming. > > > > https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not > > gratuitous summary of why the series as it stands is a step in the wrong > > direction. Tests are good. They're not a reason to pull an otherwise bad > > series. This series should be rebased to not depend on that series. The > > tests from the other series should be split out. > > It's not a bad series, unfortunately. I replied with my own comments > and I stand by them. > > I don't mind if you want to drop the #ifdef (which shows how a flag > could be used and the code-size impact). But other than that, I am > firm on this for now. I've already applied it to my tree and a membuf > implementation with tests and without a power-of-two limitation is > important for my current work on distros and expo. Well, you need to rebase this series without that then as I'm not going to take something another long time project contributor said was wrong and offered lots of constructive feedback on. > > > 2. I sent the first part of the PXE series so you could apply that. > > > > Yes, I should be applying that next week. > > > > > 3. You rejected the second part of this series because it didn't > > > include support for lwip without cmdline. I offered to handle that > > > case later but I'm pretty sure you rejected that too. > > > > That's not how I would characterize it, no. I said you should probably > > focus on sandbox + lwip, since you're the sandbox guru and ask Jerome to > > do the net_loop-alike thing, since he's one of the network custodians > > and the lwip person. I was trying to direct you to where your efforts > > might be most useful but if you insist on instead doing the > > net_loop-alike part and Jerome ack's it, that's fine. > > As you know there have been many arguments from the EFI guys about > sandbox and you have already rejected my sandbox-focussed EFI-memory > series for your tree. If I were actually a guru, that wouldn't have > happened. > > I see that Jerome has created some tests, which is good. > > So really, you should consider applying the full PXE series so that > Jerome can build on that and add support for non-CMDLINE PXE in lwip > in a way that you would like. I saw that Jerome posted sandbox for lwip as well and was pleased. You can pickup whatever is left and move forward once both your current
Re: [PATCH v5 00/46] x86: Improve operation under QEMU
On Sat, Mar 15, 2025 at 02:25:20PM +, Simon Glass wrote: > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > is not perfect. > > With both builds, executing the VESA ROM causes an intermittent hang, at > least on some AMD CPUs. > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > is done in a way that works on real hardware but not with QEMU. This > means that performance is 4-5x slower than it could be, at least on my > CPU. > > We can work around the first problem by using Bochs, which is anyway a > better choice than VESA for QEMU. The second can be addressed by using > the same descriptor across the jump to long mode. > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > In v3 some e820 patches are included to make booting reliable and avoid > ACPI tables being dropped. Also, several MTTR problems are addressed, to > support memory sizes above 4GB reliably. For the series, applied to u-boot/next, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 00/47] x86: Improve operation under QEMU
On Fri, Mar 14, 2025 at 02:44:35PM +, Simon Glass wrote: > Hi Tom, > > On Fri, 7 Mar 2025 at 14:23, Tom Rini wrote: > > > > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote: > > > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > > > is not perfect. > > > > > > With both builds, executing the VESA ROM causes an intermittent hang, at > > > least on some AMD CPUs. > > > > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > > > is done in a way that works on real hardware but not with QEMU. This > > > means that performance is 4-5x slower than it could be, at least on my > > > CPU. > > > > > > We can work around the first problem by using Bochs, which is anyway a > > > better choice than VESA for QEMU. The second can be addressed by using > > > the same descriptor across the jump to long mode. > > > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > > > > > In v3 some e820 patches are included to make booting reliable and avoid > > > ACPI tables being dropped. Also, several MTTR problems are addressed, to > > > support memory sizes above 4GB reliably. > > > > Do you plan to rebase the prerequisite series' this requires so that it > > can be merged? > > Here's my understanding of where things are: > > 1. You rejected the membuf series and my replies to try to resolve > that haven't gone anywhere yet. So your tree doesn't have any tests > for that code and still has the old naming. https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not gratuitous summary of why the series as it stands is a step in the wrong direction. Tests are good. They're not a reason to pull an otherwise bad series. This series should be rebased to not depend on that series. The tests from the other series should be split out. > 2. I sent the first part of the PXE series so you could apply that. Yes, I should be applying that next week. > 3. You rejected the second part of this series because it didn't > include support for lwip without cmdline. I offered to handle that > case later but I'm pretty sure you rejected that too. That's not how I would characterize it, no. I said you should probably focus on sandbox + lwip, since you're the sandbox guru and ask Jerome to do the net_loop-alike thing, since he's one of the network custodians and the lwip person. I was trying to direct you to where your efforts might be most useful but if you insist on instead doing the net_loop-alike part and Jerome ack's it, that's fine. > 4. This series is now marked 'changes requested' but the only feedback > I see is in the RFC patch. Yes, rebase to something that can be applied is a change I've requested. Because my feedback was "Do you plan to rebase the prerequisite series' this requires so that it can be merged?". I would have otherwise merged it by now. Patchwork reflects mainline status. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/28] x86: Improve operation under QEMU
On Mon, Feb 17, 2025 at 06:14:12AM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 16 Feb 2025 at 14:57, Tom Rini wrote: > > > > On Sun, Feb 16, 2025 at 01:43:45PM -0700, Simon Glass wrote: > > > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > > > is not perfect. > > > > > > With both builds, executing the VESA ROM causes an intermittent hang, at > > > least on some AMD CPUs. > > > > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > > > is done in a way that works on real hardware but not with QEMU. This > > > means that performance is 4-5x slower than it could be, at least on my > > > CPU. > > > > > > We can work around the first problem by using Bochs, which is anyway a > > > better choice than VESA for QEMU. The second can be addressed by using > > > the same descriptor across the jump to long mode. > > > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > > > This seems needlessly not against mainline. > > I just tried it and yes there is a very small delta. I can resend it > rebased to -next if you like. I'd really like to get some OS-booting > tests into CI. Sure, and please start pushing scripts to u-boot-extras. Having these scripts in u-boot itself explicitly makes it harder to use them for debug as you now rely on them being within the tree with the changes you want on whatever older commit you want. And since you want to move these to Python too you that also means language updates need to be in there as well. Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 00/47] x86: Improve operation under QEMU
On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote: > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > is not perfect. > > With both builds, executing the VESA ROM causes an intermittent hang, at > least on some AMD CPUs. > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > is done in a way that works on real hardware but not with QEMU. This > means that performance is 4-5x slower than it could be, at least on my > CPU. > > We can work around the first problem by using Bochs, which is anyway a > better choice than VESA for QEMU. The second can be addressed by using > the same descriptor across the jump to long mode. > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > In v3 some e820 patches are included to make booting reliable and avoid > ACPI tables being dropped. Also, several MTTR problems are addressed, to > support memory sizes above 4GB reliably. Do you plan to rebase the prerequisite series' this requires so that it can be merged? -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 00/44] x86: Improve operation under QEMU
On Mon, Feb 24, 2025 at 04:05:49PM -0700, Simon Glass wrote: > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it > is not perfect. > > With both builds, executing the VESA ROM causes an intermittent hang, at > least on some AMD CPUs. > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit) > is done in a way that works on real hardware but not with QEMU. This > means that performance is 4-5x slower than it could be, at least on my > CPU. > > We can work around the first problem by using Bochs, which is anyway a > better choice than VESA for QEMU. The second can be addressed by using > the same descriptor across the jump to long mode. > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > In v3 some e820 patches are included to make booting reliable and avoid > ACPI tables being dropped. Also, several MTTR problems are addressed, to > support memory sizes above 4GB reliably. This is based on your tree I guess and not next, because you've not rebased at least the prerequisite test/py series and I didn't try farther than that with applying this. -- Tom signature.asc Description: PGP signature
Re: (subset) [PATCH v5 00/25] passage: Define a standard for firmware data flow
On Wed, 28 May 2025 06:32:02 -0600, Simon Glass wrote: > This series adds a standard way of passing information between different > firmware phases. This already exists in U-Boot at a very basic level, in > the form of a bloblist containing an spl_handoff structure, but the intent > here is to define something useful across projects. > > The need for this is growing as firmware fragments into multiple binaries > each with its own purpose. Without any run-time connection, we must rely > on build-time settings which are brittle and painful to keep in sync. > > [...] Applied to u-boot/next, thanks! [06/25] spl: Rename jump_to_image_no_args() commit: f73450918d66565c5efacf2bb57227ba94bdaa40 -- Tom
Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
On Wed, May 28, 2025 at 05:08:38PM +0100, Simon Glass wrote: > Hi Tom, > > On Wed, 28 May 2025 at 16:19, Tom Rini wrote: > > > > On Wed, May 28, 2025 at 03:32:12PM +0100, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 28 May 2025 at 15:25, Tom Rini wrote: > > > > > > > > On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote: > > > > > > > > > > This series adds a standard way of passing information between > > > > > different > > > > > firmware phases. This already exists in U-Boot at a very basic level, > > > > > in > > > > > the form of a bloblist containing an spl_handoff structure, but the > > > > > intent > > > > > here is to define something useful across projects. > > > > > > > > > > The need for this is growing as firmware fragments into multiple > > > > > binaries > > > > > each with its own purpose. Without any run-time connection, we must > > > > > rely > > > > > on build-time settings which are brittle and painful to keep in sync. > > > > > > > > > > This feature is named 'standard passage' since the name is more unique > > > > > than many others that could be chosen, it is a passage in the sense > > > > > that > > > > > information is flowing from one place to another and it is standard, > > > > > because that is what we want to create. > > > > > > > > > > The implementation is mostly a pointer to a bloblist in a register, > > > > > with > > > > > an extra register to point to a devicetree, for more complex data. > > > > > This > > > > > should cover all cases (small memory footprint as well as complex data > > > > > flow) and be easy enough to implement on all architectures. > > > > > > > > > > The emphasis is on enabling open communcation between binaries, not > > > > > enabling passage of secret, undocumented data, although this is > > > > > possible > > > > > in a private environment. > > > > > > > > > > To try this out: > > > > > > > > > > $ ./scripts/build-qemu -a arm -rsx > > > > > > > > > > This will build and run QEMU for arm64 and you should see the > > > > > standdard > > > > > passage working: > > > > > > > > > >Core: 49 devices, 13 uclasses, devicetree: passage > > > > > > > > > > This series is available at u-boot-dm/pass-working > > > > > > > > > > Changes in v5: > > > > > - Add RFC for test script > > > > > > > > And this is why I question if you are working in good faith. I've > > > > rejected this countless times. I'm still rejecting it. Stop including > > > > it. Point at the version you could easily be maintaining in the contrib > > > > repository where you have write access and no one will be telling you to > > > > not do something. People would even review the patches since it would be > > > > against mainline. > > > > > > I fully understand that you don't want the script and I'm only > > > including (as an RFC) so people can actually try this series out. I > > > didn't want to point to my tree as I thought that would annoy you. I > > > already went through why the contrib tree is not suitable for me. > > > > So I have to take changes that I disagree with, but you can't work with > > a tree for your tooling where the community would be happy to provide > > feedback? That does not sound like compromise. Again, I have trouble > > believing that you are working in good faith to resolve the differences > > here. > > Yes, as mentioned before I would like you to take changes you disagree > with, at least once we have discussed alternatives and I'm sure that's > the way I want to go. It would save a lot of grief if you could do > that. > > I could use your contrib/ repo but there isn't a lot of point, since I > have to have my own tree anyway, due to rejected / changes-requested > patches. It's just lots of fiddling around for no gain. I'm fine with > your not having the scripts in your tree and I'm fine with maintaining > the Python tools in my tree. Basically it seems my tree is the dumping > ground for the stuff yo
Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
On Wed, May 28, 2025 at 03:32:12PM +0100, Simon Glass wrote: > Hi Tom, > > On Wed, 28 May 2025 at 15:25, Tom Rini wrote: > > > > On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote: > > > > > > This series adds a standard way of passing information between different > > > firmware phases. This already exists in U-Boot at a very basic level, in > > > the form of a bloblist containing an spl_handoff structure, but the intent > > > here is to define something useful across projects. > > > > > > The need for this is growing as firmware fragments into multiple binaries > > > each with its own purpose. Without any run-time connection, we must rely > > > on build-time settings which are brittle and painful to keep in sync. > > > > > > This feature is named 'standard passage' since the name is more unique > > > than many others that could be chosen, it is a passage in the sense that > > > information is flowing from one place to another and it is standard, > > > because that is what we want to create. > > > > > > The implementation is mostly a pointer to a bloblist in a register, with > > > an extra register to point to a devicetree, for more complex data. This > > > should cover all cases (small memory footprint as well as complex data > > > flow) and be easy enough to implement on all architectures. > > > > > > The emphasis is on enabling open communcation between binaries, not > > > enabling passage of secret, undocumented data, although this is possible > > > in a private environment. > > > > > > To try this out: > > > > > > $ ./scripts/build-qemu -a arm -rsx > > > > > > This will build and run QEMU for arm64 and you should see the standdard > > > passage working: > > > > > >Core: 49 devices, 13 uclasses, devicetree: passage > > > > > > This series is available at u-boot-dm/pass-working > > > > > > Changes in v5: > > > - Add RFC for test script > > > > And this is why I question if you are working in good faith. I've > > rejected this countless times. I'm still rejecting it. Stop including > > it. Point at the version you could easily be maintaining in the contrib > > repository where you have write access and no one will be telling you to > > not do something. People would even review the patches since it would be > > against mainline. > > I fully understand that you don't want the script and I'm only > including (as an RFC) so people can actually try this series out. I > didn't want to point to my tree as I thought that would annoy you. I > already went through why the contrib tree is not suitable for me. So I have to take changes that I disagree with, but you can't work with a tree for your tooling where the community would be happy to provide feedback? That does not sound like compromise. Again, I have trouble believing that you are working in good faith to resolve the differences here. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote: > > This series adds a standard way of passing information between different > firmware phases. This already exists in U-Boot at a very basic level, in > the form of a bloblist containing an spl_handoff structure, but the intent > here is to define something useful across projects. > > The need for this is growing as firmware fragments into multiple binaries > each with its own purpose. Without any run-time connection, we must rely > on build-time settings which are brittle and painful to keep in sync. > > This feature is named 'standard passage' since the name is more unique > than many others that could be chosen, it is a passage in the sense that > information is flowing from one place to another and it is standard, > because that is what we want to create. > > The implementation is mostly a pointer to a bloblist in a register, with > an extra register to point to a devicetree, for more complex data. This > should cover all cases (small memory footprint as well as complex data > flow) and be easy enough to implement on all architectures. > > The emphasis is on enabling open communcation between binaries, not > enabling passage of secret, undocumented data, although this is possible > in a private environment. > > To try this out: > > $ ./scripts/build-qemu -a arm -rsx > > This will build and run QEMU for arm64 and you should see the standdard > passage working: > >Core: 49 devices, 13 uclasses, devicetree: passage > > This series is available at u-boot-dm/pass-working > > Changes in v5: > - Add RFC for test script And this is why I question if you are working in good faith. I've rejected this countless times. I'm still rejecting it. Stop including it. Point at the version you could easily be maintaining in the contrib repository where you have write access and no one will be telling you to not do something. People would even review the patches since it would be against mainline. -- Tom signature.asc Description: PGP signature
