Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Mon, Dec 06, 2021 at 08:24:56AM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 5 Dec 2021 at 06:32, Tom Rini wrote: > > > > On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sat, 4 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > > > > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > > > > > > > [huge snip] > > > > > > > > There's things that need to be cleaned up because we have some > > > > > > > > small > > > > > > > > number of platforms that went off and did their own thing. But > > > > > > > > largely > > > > > > > > yes, things make sense to me. We have: > > > > > > > > - We embedded the device tree that will configure U-Boot, > > > > > > > > because there > > > > > > > > is no way for the hardware to have provided us one. > > > > > > > > - We do not embed the device tree that will configure U-Boot, > > > > > > > > because > > > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > > > > > Then we have the developer option of: > > > > > > > > - We embedded the device tree that will configure U-Boot, > > > > > > > > because we're > > > > > > > > developing something. > > > > > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a > > > > > > > run-time choice. > > > > > > > > > > > > But it's not possible. That's the problem we keep going around and > > > > > > around about. People keep raising real life examples where you > > > > > > cannot > > > > > > make a run time choice between "device tree we're passed at run > > > > > > time" > > > > > > and "device tree we're compiled with". > > > > > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > > > even added a test with it. What am I missing? > > > > > > > > QEMU and Xen should both never have an in-source-tree dts as they are > > > > dynamic. I think you missed the explanation about how U-Boot + Xen > > > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > > > > (with required features...) system. For QEMU virtual machines you're > > > > not supposed to do what you're doing, for production. > > > > > > > > > > And it's not helpful. It is ALWAYS the case that we know that we > > > > > > want > > > > > > to override the run time device tree with our own, because it's a > > > > > > developer developing things or it's a user / production case where > > > > > > we > > > > > > must use the provided tree. NOT doing that is what leads to madness > > > > > > like we see for example on Pi where if we don't use the passed tree > > > > > > we > > > > > > still need to copy X/Y/Z out of it. > > > > > > > > > > Aren't you talking about the distro DT there, rather than the the one > > > > > on the boot disk? That is my reading of that patch. If we need to do > > > > > that sort of thing, it doesn't matter where the the cointrol DT comes > > > > > from. You are still going to have to do that sort of thing. > > > > > > > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > > > > OF_BOARD and still boot / iterate. > > > > > > > > The DT we're passed in is the DT to pass to the OS. That's the hook for > > > > putting a DTB on the device as it ships, the OS will just work. The > > > > production case of needing to update that stored DTB is handled. It's > > > > always what should be used, again outside of developer doing > > > > development. > > > > > > > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > > > > the DTB the OS will consume too, in the passed at run time case. Unless > > > > we're instead going to save that DTB aside? Which leaves me with a > > > > different set of design questions... > > > > > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > > > > > > > > > should > > > > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > > > > > > > I'm looking for ways to convince you that we do not need to > > > > > > > > include a > > > > > > > > device tree in the binary. There's a growing set of devices > > > > > > > > where the > > > > > > > > device tree exists with the device. If it's missing, that's a > > > > > > > > huge > > > > > > > > fatal error we can't do all that much about. If we need to do > > > > > > > > something > > > > > > > > to that device tree for U-Boot, yes, fine, we should make it > > > > > > > > straight > > > > > > > > forward for the developer to do that. But that's not the > > > > > > > > common case! > > > > > > > > > > > > > > Well we could add another Kconfig which tells U-Boot not to > > > > > > > include a > > > > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > > > > > > > I just want to make sure
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Sun, 5 Dec 2021 at 06:32, Tom Rini wrote: > > On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 4 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > > > > > [huge snip] > > > > > > > There's things that need to be cleaned up because we have some > > > > > > > small > > > > > > > number of platforms that went off and did their own thing. But > > > > > > > largely > > > > > > > yes, things make sense to me. We have: > > > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > > > there > > > > > > > is no way for the hardware to have provided us one. > > > > > > > - We do not embed the device tree that will configure U-Boot, > > > > > > > because > > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > > > Then we have the developer option of: > > > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > > > we're > > > > > > > developing something. > > > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > > > > > > choice. > > > > > > > > > > But it's not possible. That's the problem we keep going around and > > > > > around about. People keep raising real life examples where you cannot > > > > > make a run time choice between "device tree we're passed at run time" > > > > > and "device tree we're compiled with". > > > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > > even added a test with it. What am I missing? > > > > > > QEMU and Xen should both never have an in-source-tree dts as they are > > > dynamic. I think you missed the explanation about how U-Boot + Xen > > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > > > (with required features...) system. For QEMU virtual machines you're > > > not supposed to do what you're doing, for production. > > > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > > > to override the run time device tree with our own, because it's a > > > > > developer developing things or it's a user / production case where we > > > > > must use the provided tree. NOT doing that is what leads to madness > > > > > like we see for example on Pi where if we don't use the passed tree we > > > > > still need to copy X/Y/Z out of it. > > > > > > > > Aren't you talking about the distro DT there, rather than the the one > > > > on the boot disk? That is my reading of that patch. If we need to do > > > > that sort of thing, it doesn't matter where the the cointrol DT comes > > > > from. You are still going to have to do that sort of thing. > > > > > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > > > OF_BOARD and still boot / iterate. > > > > > > The DT we're passed in is the DT to pass to the OS. That's the hook for > > > putting a DTB on the device as it ships, the OS will just work. The > > > production case of needing to update that stored DTB is handled. It's > > > always what should be used, again outside of developer doing > > > development. > > > > > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > > > the DTB the OS will consume too, in the passed at run time case. Unless > > > we're instead going to save that DTB aside? Which leaves me with a > > > different set of design questions... > > > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > > > > > > > > should > > > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > > > > > I'm looking for ways to convince you that we do not need to > > > > > > > include a > > > > > > > device tree in the binary. There's a growing set of devices > > > > > > > where the > > > > > > > device tree exists with the device. If it's missing, that's a > > > > > > > huge > > > > > > > fatal error we can't do all that much about. If we need to do > > > > > > > something > > > > > > > to that device tree for U-Boot, yes, fine, we should make it > > > > > > > straight > > > > > > > forward for the developer to do that. But that's not the common > > > > > > > case! > > > > > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include > > > > > > a > > > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > > > > > I just want to make sure that we always build the devicetrees and > > > > > > that > > > > > > it is easy for a knowledgeable dev to switch over to use them, > > > > > > without > > > > > > spelunking through dozens of other projects to discover the secret > > > > > > DT > > > > > > that no one will tell us about. > > > > > > > > > > Should we
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Heinrich, On Fri, 3 Dec 2021 at 03:04, Heinrich Schuchardt wrote: > > On 12/2/21 17:50, Simon Glass wrote: > > Hi Heinrich, > > > > On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt > > wrote: > >> > >> On 12/2/21 16:58, 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 in another patch in this > >>> series: "doc: Add documentation about devicetree usage" > >>> > >>> 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. > >>> > >>> Note: If board maintainers are able to add their own patch to add the > >>> files, some patches in this series can be dropped. > >>> > >>> It also provides a few qemu clean-ups discovered along the way. The > >>> qemu-riscv64_spl problem is fixed. > >> > >> Distros like Ubuntu are provided as preinstalled images using U-Boot to > >> launch Linux for usage with QEMU. A single image must be able to be > >> usable in the future irrespective of the QEMU command line device > >> configuration. > >> > >> This means that the devicetree coming from QEMU must be accurately > >> parsed in U-Boot to setup the UEFI memory map. The number and type of > >> CPUs and the NUMA configuration must be accurate. All devices enabled > >> via the QEMU command line must be visible in the device-tree of Linux. > >> > >> Please, observe that information like number of CPU cores, number and > >> type of block devices, namespace IDs used for NVMe drives, etc. cannot > >> be available at build time. > >> > >> It this all guaranteed with this series? If not, this would > >> unfortunately imply a NAK. > > > > Yes, it is guaranteed and there is no change there. > > Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump > the devicetree exposed to UEFI binaries. The number of CPUs and the > memory size matches the call parameters of QEMU. Emulated devices like > SCSI and NVMe drives and TPMv2 work inside U-Boot. > > I also tested: > > * qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI > * qemu-riscv64_spl_defconfig > > and found no issues. > > Tested-by: Heinrich Schuchardt Thank you for testing it. I have added your tag to the three patches for QEMU devicetree (arm/riscv) since I don't have a way to add to the whole series and I'm not sure it applies in any case. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Sat, Dec 04, 2021 at 07:52:46PM +0100, François Ozog wrote: > Hi Simon > > Le sam. 4 déc. 2021 à 18:35, Simon Glass a écrit : > > > Hi François, > > > > On Sat, 4 Dec 2021 at 09:55, François Ozog > > wrote: > > > > > > Hi Simon > > > > > > Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit : > > >> > > >> Hi Tom, > > >> > > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > >> > > > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > >> > > > >> > [huge snip] > > >> > > > There's things that need to be cleaned up because we have some > > small > > >> > > > number of platforms that went off and did their own thing. But > > largely > > >> > > > yes, things make sense to me. We have: > > >> > > > - We embedded the device tree that will configure U-Boot, because > > there > > >> > > > is no way for the hardware to have provided us one. > > >> > > > - We do not embed the device tree that will configure U-Boot, > > because > > >> > > > there is already one present in memory for us to use. > > >> > > > > > >> > > > Then we have the developer option of: > > >> > > > - We embedded the device tree that will configure U-Boot, because > > we're > > >> > > > developing something. > > >> > > > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time > > choice. > > >> > > > >> > But it's not possible. That's the problem we keep going around and > > >> > around about. People keep raising real life examples where you cannot > > >> > make a run time choice between "device tree we're passed at run time" > > >> > and "device tree we're compiled with". > > >> > > >> I haven't seen one. The most extreme case is QEMU and it works fine. I > > >> even added a test with it. What am I missing? > > >> > > >> > > > >> > And it's not helpful. It is ALWAYS the case that we know that we want > > >> > to override the run time device tree with our own, because it's a > > >> > developer developing things or it's a user / production case where we > > >> > must use the provided tree. NOT doing that is what leads to madness > > >> > like we see for example on Pi where if we don't use the passed tree we > > >> > still need to copy X/Y/Z out of it. > > >> > > >> Aren't you talking about the distro DT there, rather than the the one > > >> on the boot disk? That is my reading of that patch. If we need to do > > >> that sort of thing, it doesn't matter where the the cointrol DT comes > > >> from. You are still going to have to do that sort of thing. > > >> > > >> It is not ALWAYS the case. I've shown you how easy it is to disable > > >> OF_BOARD and still boot / iterate. > > >> > > >> > > > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > > should > > >> > > > > provide a way to do that? But what is driving that desire? > > >> > > > > > >> > > > I'm looking for ways to convince you that we do not need to > > include a > > >> > > > device tree in the binary. There's a growing set of devices > > where the > > >> > > > device tree exists with the device. If it's missing, that's a > > huge > > >> > > > fatal error we can't do all that much about. If we need to do > > something > > >> > > > to that device tree for U-Boot, yes, fine, we should make it > > straight > > >> > > > forward for the developer to do that. But that's not the common > > case! > > >> > > > > >> > > Well we could add another Kconfig which tells U-Boot not to include > > a > > >> > > devicetree in u-boot.bin, if that would resolve this? > > >> > > > > >> > > I just want to make sure that we always build the devicetrees and > > that > > >> > > it is easy for a knowledgeable dev to switch over to use them, > > without > > >> > > spelunking through dozens of other projects to discover the secret > > DT > > >> > > that no one will tell us about. > > >> > > > >> > Should we demand better documentation for boards? Yes. But it's > > still > > >> > a valid case to have zero device trees for a given platform in-tree. > > >> > Xen is an example of this. QEMU is an example of this. Platforms > > need > > >> > to work without adding special tweaks for us. Maybe that means some > > >> > features can't be tested in QEMU-as-virtual-platform and only in > > >> > QEMU-faithfully-emulating-specific-physical-platforms. > > >> > > >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > >> case, I think. How about we create a special Kconfig for that case? We > > >> need to make some progress here. > > >> > > >> > > > >> > > > I guess another part of the problem is that historically almost > > all > > >> > > > platforms were in the first case I list above, no run time > > provided > > >> > > > device tree, so we took the kernel one and added our bindings to > > it. > > >> > > > Now we're being bit by the growing number of platforms that are > > the > > >> > > > second case, and how do we get our properties in there, and which > > ones > > >> > > > even make sense to do that for. > > >> > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Sat, Dec 04, 2021 at 03:09:59PM -0700, Simon Glass wrote: > Hi Tom, > > On Sat, 4 Dec 2021 at 11:03, Tom Rini wrote: > > > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > > > [huge snip] > > > > > > There's things that need to be cleaned up because we have some small > > > > > > number of platforms that went off and did their own thing. But > > > > > > largely > > > > > > yes, things make sense to me. We have: > > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > > there > > > > > > is no way for the hardware to have provided us one. > > > > > > - We do not embed the device tree that will configure U-Boot, > > > > > > because > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > Then we have the developer option of: > > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > > we're > > > > > > developing something. > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > > > > > choice. > > > > > > > > But it's not possible. That's the problem we keep going around and > > > > around about. People keep raising real life examples where you cannot > > > > make a run time choice between "device tree we're passed at run time" > > > > and "device tree we're compiled with". > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > even added a test with it. What am I missing? > > > > QEMU and Xen should both never have an in-source-tree dts as they are > > dynamic. I think you missed the explanation about how U-Boot + Xen > > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > > (with required features...) system. For QEMU virtual machines you're > > not supposed to do what you're doing, for production. > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > > to override the run time device tree with our own, because it's a > > > > developer developing things or it's a user / production case where we > > > > must use the provided tree. NOT doing that is what leads to madness > > > > like we see for example on Pi where if we don't use the passed tree we > > > > still need to copy X/Y/Z out of it. > > > > > > Aren't you talking about the distro DT there, rather than the the one > > > on the boot disk? That is my reading of that patch. If we need to do > > > that sort of thing, it doesn't matter where the the cointrol DT comes > > > from. You are still going to have to do that sort of thing. > > > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > > OF_BOARD and still boot / iterate. > > > > The DT we're passed in is the DT to pass to the OS. That's the hook for > > putting a DTB on the device as it ships, the OS will just work. The > > production case of needing to update that stored DTB is handled. It's > > always what should be used, again outside of developer doing > > development. > > > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > > the DTB the OS will consume too, in the passed at run time case. Unless > > we're instead going to save that DTB aside? Which leaves me with a > > different set of design questions... > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > > > > > > > should > > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > > > I'm looking for ways to convince you that we do not need to include > > > > > > a > > > > > > device tree in the binary. There's a growing set of devices where > > > > > > the > > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > > fatal error we can't do all that much about. If we need to do > > > > > > something > > > > > > to that device tree for U-Boot, yes, fine, we should make it > > > > > > straight > > > > > > forward for the developer to do that. But that's not the common > > > > > > case! > > > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > > spelunking through dozens of other projects to discover the secret DT > > > > > that no one will tell us about. > > > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > > a valid case to have zero device trees for a given platform in-tree. > > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > > to work without adding special tweaks for us. Maybe that means some > > > > features can't be tested in
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le sam. 4 déc. 2021 à 18:35, Simon Glass a écrit : > Hi François, > > On Sat, 4 Dec 2021 at 09:55, François Ozog > wrote: > > > > Hi Simon > > > > Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit : > >> > >> Hi Tom, > >> > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > >> > > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > >> > > >> > [huge snip] > >> > > > There's things that need to be cleaned up because we have some > small > >> > > > number of platforms that went off and did their own thing. But > largely > >> > > > yes, things make sense to me. We have: > >> > > > - We embedded the device tree that will configure U-Boot, because > there > >> > > > is no way for the hardware to have provided us one. > >> > > > - We do not embed the device tree that will configure U-Boot, > because > >> > > > there is already one present in memory for us to use. > >> > > > > >> > > > Then we have the developer option of: > >> > > > - We embedded the device tree that will configure U-Boot, because > we're > >> > > > developing something. > >> > > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time > choice. > >> > > >> > But it's not possible. That's the problem we keep going around and > >> > around about. People keep raising real life examples where you cannot > >> > make a run time choice between "device tree we're passed at run time" > >> > and "device tree we're compiled with". > >> > >> I haven't seen one. The most extreme case is QEMU and it works fine. I > >> even added a test with it. What am I missing? > >> > >> > > >> > And it's not helpful. It is ALWAYS the case that we know that we want > >> > to override the run time device tree with our own, because it's a > >> > developer developing things or it's a user / production case where we > >> > must use the provided tree. NOT doing that is what leads to madness > >> > like we see for example on Pi where if we don't use the passed tree we > >> > still need to copy X/Y/Z out of it. > >> > >> Aren't you talking about the distro DT there, rather than the the one > >> on the boot disk? That is my reading of that patch. If we need to do > >> that sort of thing, it doesn't matter where the the cointrol DT comes > >> from. You are still going to have to do that sort of thing. > >> > >> It is not ALWAYS the case. I've shown you how easy it is to disable > >> OF_BOARD and still boot / iterate. > >> > >> > > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > should > >> > > > > provide a way to do that? But what is driving that desire? > >> > > > > >> > > > I'm looking for ways to convince you that we do not need to > include a > >> > > > device tree in the binary. There's a growing set of devices > where the > >> > > > device tree exists with the device. If it's missing, that's a > huge > >> > > > fatal error we can't do all that much about. If we need to do > something > >> > > > to that device tree for U-Boot, yes, fine, we should make it > straight > >> > > > forward for the developer to do that. But that's not the common > case! > >> > > > >> > > Well we could add another Kconfig which tells U-Boot not to include > a > >> > > devicetree in u-boot.bin, if that would resolve this? > >> > > > >> > > I just want to make sure that we always build the devicetrees and > that > >> > > it is easy for a knowledgeable dev to switch over to use them, > without > >> > > spelunking through dozens of other projects to discover the secret > DT > >> > > that no one will tell us about. > >> > > >> > Should we demand better documentation for boards? Yes. But it's > still > >> > a valid case to have zero device trees for a given platform in-tree. > >> > Xen is an example of this. QEMU is an example of this. Platforms > need > >> > to work without adding special tweaks for us. Maybe that means some > >> > features can't be tested in QEMU-as-virtual-platform and only in > >> > QEMU-faithfully-emulating-specific-physical-platforms. > >> > >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > >> case, I think. How about we create a special Kconfig for that case? We > >> need to make some progress here. > >> > >> > > >> > > > I guess another part of the problem is that historically almost > all > >> > > > platforms were in the first case I list above, no run time > provided > >> > > > device tree, so we took the kernel one and added our bindings to > it. > >> > > > Now we're being bit by the growing number of platforms that are > the > >> > > > second case, and how do we get our properties in there, and which > ones > >> > > > even make sense to do that for. > >> > > > >> > > I think upstreaming the bindings is the solution there. I've made a > >> > > start, but we need to make progress with this series and all the > other > >> > > things in flight. I think a lot of people want U-Boot to not have a > >> > > devicetree source files in it for ARMv8 platforms. I am
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Sat, 4 Dec 2021 at 11:03, Tom Rini wrote: > > On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > [huge snip] > > > > > There's things that need to be cleaned up because we have some small > > > > > number of platforms that went off and did their own thing. But > > > > > largely > > > > > yes, things make sense to me. We have: > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > there > > > > > is no way for the hardware to have provided us one. > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > there is already one present in memory for us to use. > > > > > > > > > > Then we have the developer option of: > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > we're > > > > > developing something. > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > > > > choice. > > > > > > But it's not possible. That's the problem we keep going around and > > > around about. People keep raising real life examples where you cannot > > > make a run time choice between "device tree we're passed at run time" > > > and "device tree we're compiled with". > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > even added a test with it. What am I missing? > > QEMU and Xen should both never have an in-source-tree dts as they are > dynamic. I think you missed the explanation about how U-Boot + Xen > works? You're running the same U-Boot under Xen on any arbitrary ARMv8 > (with required features...) system. For QEMU virtual machines you're > not supposed to do what you're doing, for production. > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > to override the run time device tree with our own, because it's a > > > developer developing things or it's a user / production case where we > > > must use the provided tree. NOT doing that is what leads to madness > > > like we see for example on Pi where if we don't use the passed tree we > > > still need to copy X/Y/Z out of it. > > > > Aren't you talking about the distro DT there, rather than the the one > > on the boot disk? That is my reading of that patch. If we need to do > > that sort of thing, it doesn't matter where the the cointrol DT comes > > from. You are still going to have to do that sort of thing. > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > OF_BOARD and still boot / iterate. > > The DT we're passed in is the DT to pass to the OS. That's the hook for > putting a DTB on the device as it ships, the OS will just work. The > production case of needing to update that stored DTB is handled. It's > always what should be used, again outside of developer doing > development. > > Maybe that's part of the confusion here too. The DTB U-Boot is using is > the DTB the OS will consume too, in the passed at run time case. Unless > we're instead going to save that DTB aside? Which leaves me with a > different set of design questions... > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > device tree in the binary. There's a growing set of devices where the > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > fatal error we can't do all that much about. If we need to do > > > > > something > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > spelunking through dozens of other projects to discover the secret DT > > > > that no one will tell us about. > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > a valid case to have zero device trees for a given platform in-tree. > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > to work without adding special tweaks for us. Maybe that means some > > > features can't be tested in QEMU-as-virtual-platform and only in > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > case, I think. How about we create a special Kconfig for that case? We > > need to make some progress here. > > Yes, because there's a small number of
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon, On Sat, Dec 04, 2021 at 10:25:29AM -0700, Simon Glass wrote: > Hi Ilias, > > On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > [...] > > > > [huge snip] > > > > > > There's things that need to be cleaned up because we have some small > > > > > > number of platforms that went off and did their own thing. But > > > > > > largely > > > > > > yes, things make sense to me. We have: > > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > > there > > > > > > is no way for the hardware to have provided us one. > > > > > > - We do not embed the device tree that will configure U-Boot, > > > > > > because > > > > > > there is already one present in memory for us to use. > > > > > > > > > > > > Then we have the developer option of: > > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > > we're > > > > > > developing something. > > > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > > > > > choice. > > > > > > > > I am not convinced the case is "we are developing something". The > > arguments for this are something along the lines of: > > 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide > > no DT so we need to include it. With which I disagree. The config option > > says "You must provide an external device tree" for a reason. > > Where are you reading that? I'm lost. In the XEN patch commit message [1] > > OF_SEPARATE means it is not embedded in U-Boot but is attached to the end of > it. > > > 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact > > committed in the kernel. I am not sure about the rest, but honestly this > > isn't a convincing argument for me. > > Great, so you've solved that one but even that was confusing for me, > as my patch should make clear. Every single board would be its own > special snowflake if we went that way. > > So if they are in the kernel, we just need to put them in U-Boot too, > so problem solved. The auto-sync thing that I believe Rob is working > on will make things easy. My problem is not usable DTs like the PRI4. My problem is the OF_BOARD being a runtime option and always building that DT, while at the same time introduce a third option to not include it in the binary. Another problem is 'empty' DTs. > > > > > What else are we gaining with it being a run time choice? One of the > > We are requiring a DT to be present in the U-Boot tree for > development, documentation and discoverability purposes. Devs can turn > OF_BOARD on and off as it suits them when iterating on a platform. They can also do the same thing without tangling the 2 options. The *real* problem is that in a month from now we'll get a patch saying "I need to change X on RPI4 DTB because I have this special reason and I want a specific u-boot binding" and then we are back at the start. We also have OF_EMBED for the 'developer' option which is also mentioned explicitly in the Kconfig. > > > things this approach does address, but we keep conveniently ignoring, is > > that it tries to preserve the current status quo. You can go and add the > > special missing U-Boot nodes in those DT's. So that would bypass problems > > if the bindings get NAK'ed. But this is going to work against the > > fragmentation we are trying to resolve. > > Well that's another reason why we need in-tree DTs at the moment. That > reason goes away once we have our bindings upstream and are able to do > what we need with DT there. > Again, that's a huge if. I am honestly not saying this in bad faith, but I have my concerns on if and what gets upstreamed. So what this really does in my head is preserve the current functionality. So what I am trying to avoid here is, in case the bindings get NAK'ed, we go back and say "that's fine we got this covered, look it's in docs and commit messages!" > > > > > > But it's not possible. That's the problem we keep going around and > > > > around about. People keep raising real life examples where you cannot > > > > make a run time choice between "device tree we're passed at run time" > > > > and "device tree we're compiled with". > > > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > > even added a test with it. What am I missing? > > (I think my point there is made) > > > > > IMHO 3b595da441cf is the commit that started the problem and tangled those > > 2 options. Note that this support has been removed from the dragonboard > > later in 0204d1b56b2f > > Yes it is one of them. There may be cases where we want to patch up > the DT that U-Boot builds. In fact OF_BOARD does not mean it came from > a prior stage. All sorts of things could be going on. We should not > conflate building a DT with OF_BOARD. It says 'board specific way'. To means that means we either create it on the fly or inherit it. In the case you want to fixup the DTB
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Sat, Dec 04, 2021 at 08:20:55AM -0700, Simon Glass wrote: > Hi Tom, > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? QEMU and Xen should both never have an in-source-tree dts as they are dynamic. I think you missed the explanation about how U-Boot + Xen works? You're running the same U-Boot under Xen on any arbitrary ARMv8 (with required features...) system. For QEMU virtual machines you're not supposed to do what you're doing, for production. > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. The DT we're passed in is the DT to pass to the OS. That's the hook for putting a DTB on the device as it ships, the OS will just work. The production case of needing to update that stored DTB is handled. It's always what should be used, again outside of developer doing development. Maybe that's part of the confusion here too. The DTB U-Boot is using is the DTB the OS will consume too, in the passed at run time case. Unless we're instead going to save that DTB aside? Which leaves me with a different set of design questions... > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. Yes, because there's a small number of OF_BOARD=y configs in tree right now, most of which are QEMU virtual machines, others of which are Pi (which we've talked to death), highbank (which Andre has explained), and then the octeontx stuff I don't know how works. I keep pushing to say that OF_BOARD=y is the special case
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi François, On Sat, 4 Dec 2021 at 09:55, François Ozog wrote: > > Hi Simon > > Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit : >> >> Hi Tom, >> >> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: >> > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: >> > >> > [huge snip] >> > > > There's things that need to be cleaned up because we have some small >> > > > number of platforms that went off and did their own thing. But largely >> > > > yes, things make sense to me. We have: >> > > > - We embedded the device tree that will configure U-Boot, because there >> > > > is no way for the hardware to have provided us one. >> > > > - We do not embed the device tree that will configure U-Boot, because >> > > > there is already one present in memory for us to use. >> > > > >> > > > Then we have the developer option of: >> > > > - We embedded the device tree that will configure U-Boot, because we're >> > > > developing something. >> > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time >> > > choice. >> > >> > But it's not possible. That's the problem we keep going around and >> > around about. People keep raising real life examples where you cannot >> > make a run time choice between "device tree we're passed at run time" >> > and "device tree we're compiled with". >> >> I haven't seen one. The most extreme case is QEMU and it works fine. I >> even added a test with it. What am I missing? >> >> > >> > And it's not helpful. It is ALWAYS the case that we know that we want >> > to override the run time device tree with our own, because it's a >> > developer developing things or it's a user / production case where we >> > must use the provided tree. NOT doing that is what leads to madness >> > like we see for example on Pi where if we don't use the passed tree we >> > still need to copy X/Y/Z out of it. >> >> Aren't you talking about the distro DT there, rather than the the one >> on the boot disk? That is my reading of that patch. If we need to do >> that sort of thing, it doesn't matter where the the cointrol DT comes >> from. You are still going to have to do that sort of thing. >> >> It is not ALWAYS the case. I've shown you how easy it is to disable >> OF_BOARD and still boot / iterate. >> >> > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should >> > > > > provide a way to do that? But what is driving that desire? >> > > > >> > > > I'm looking for ways to convince you that we do not need to include a >> > > > device tree in the binary. There's a growing set of devices where the >> > > > device tree exists with the device. If it's missing, that's a huge >> > > > fatal error we can't do all that much about. If we need to do >> > > > something >> > > > to that device tree for U-Boot, yes, fine, we should make it straight >> > > > forward for the developer to do that. But that's not the common case! >> > > >> > > Well we could add another Kconfig which tells U-Boot not to include a >> > > devicetree in u-boot.bin, if that would resolve this? >> > > >> > > I just want to make sure that we always build the devicetrees and that >> > > it is easy for a knowledgeable dev to switch over to use them, without >> > > spelunking through dozens of other projects to discover the secret DT >> > > that no one will tell us about. >> > >> > Should we demand better documentation for boards? Yes. But it's still >> > a valid case to have zero device trees for a given platform in-tree. >> > Xen is an example of this. QEMU is an example of this. Platforms need >> > to work without adding special tweaks for us. Maybe that means some >> > features can't be tested in QEMU-as-virtual-platform and only in >> > QEMU-faithfully-emulating-specific-physical-platforms. >> >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special >> case, I think. How about we create a special Kconfig for that case? We >> need to make some progress here. >> >> > >> > > > I guess another part of the problem is that historically almost all >> > > > platforms were in the first case I list above, no run time provided >> > > > device tree, so we took the kernel one and added our bindings to it. >> > > > Now we're being bit by the growing number of platforms that are the >> > > > second case, and how do we get our properties in there, and which ones >> > > > even make sense to do that for. >> > > >> > > I think upstreaming the bindings is the solution there. I've made a >> > > start, but we need to make progress with this series and all the other >> > > things in flight. I think a lot of people want U-Boot to not have a >> > > devicetree source files in it for ARMv8 platforms. I am strongly >> > > opposed to that. I've laid out my reasons very clearly in the past. I >> > > think this is a good summary: >> > > >> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html >> > >> > Yes, there are some ARMv8 platforms we will have to have the source >> >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Sat, 4 Dec 2021 at 09:09, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Sat, 4 Dec 2021 08:20:55 -0700 > > > > Hi Tom, > > > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > > > [huge snip] > > > > > There's things that need to be cleaned up because we have some small > > > > > number of platforms that went off and did their own thing. But > > > > > largely > > > > > yes, things make sense to me. We have: > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > there > > > > > is no way for the hardware to have provided us one. > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > there is already one present in memory for us to use. > > > > > > > > > > Then we have the developer option of: > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > we're > > > > > developing something. > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > > > > choice. > > > > > > But it's not possible. That's the problem we keep going around and > > > around about. People keep raising real life examples where you cannot > > > make a run time choice between "device tree we're passed at run time" > > > and "device tree we're compiled with". > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > even added a test with it. What am I missing? > > Try it on your M1 Mac. I have tested this series on a Mac Mini and it works fine. You cannot run U-Boot by itself, of course, since it needs m1n1. Also m1n1 fixes up the DT. I'm not sure exactly what changes it makes, as I don't even have a serial console on the machine at present. But in any case, I can easily iterate on U-Boot on this platform with U-Boot building the DTs. It certainly meets my requirements at present. > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > to override the run time device tree with our own, because it's a > > > developer developing things or it's a user / production case where we > > > must use the provided tree. NOT doing that is what leads to madness > > > like we see for example on Pi where if we don't use the passed tree we > > > still need to copy X/Y/Z out of it. > > > > Aren't you talking about the distro DT there, rather than the the one > > on the boot disk? That is my reading of that patch. If we need to do > > that sort of thing, it doesn't matter where the the cointrol DT comes > > from. You are still going to have to do that sort of thing. > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > OF_BOARD and still boot / iterate. > > You are cheating. If you dump the device tree passed to U-Boot (or > the OS) and don't change anything in the configuration of whatever is > passing U-Boot that device tree this is likely to work fine. But it > won't work in general. I didn't say it would. What are you getting at? Can you please try to test my series so you get the hang of what it is actually doing? > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > device tree in the binary. There's a growing set of devices where the > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > fatal error we can't do all that much about. If we need to do > > > > > something > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > > forward for the developer to do that. But that's not the common case! > > > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > > > I just want to make sure that we always build the devicetrees and that > > > > it is easy for a knowledgeable dev to switch over to use them, without > > > > spelunking through dozens of other projects to discover the secret DT > > > > that no one will tell us about. > > > > > > Should we demand better documentation for boards? Yes. But it's still > > > a valid case to have zero device trees for a given platform in-tree. > > > Xen is an example of this. QEMU is an example of this. Platforms need > > > to work without adding special tweaks for us. Maybe that means some > > > features can't be tested in QEMU-as-virtual-platform and only in > > > QEMU-faithfully-emulating-specific-physical-platforms. > > > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > > case, I think. How about we create a special Kconfig for that case? We > > need to make some progress here. > > No, Apple M1 and Raspberry Pi 4 also fall into that case. And I > suspect at least some of the other boards that currently
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Ilias, On Sat, 4 Dec 2021 at 08:58, Ilias Apalodimas wrote: > > Hi Simon, > > [...] > > > [huge snip] > > > > > There's things that need to be cleaned up because we have some small > > > > > number of platforms that went off and did their own thing. But > > > > > largely > > > > > yes, things make sense to me. We have: > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > there > > > > > is no way for the hardware to have provided us one. > > > > > - We do not embed the device tree that will configure U-Boot, because > > > > > there is already one present in memory for us to use. > > > > > > > > > > Then we have the developer option of: > > > > > - We embedded the device tree that will configure U-Boot, because > > > > > we're > > > > > developing something. > > > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > > > > choice. > > > > > I am not convinced the case is "we are developing something". The > arguments for this are something along the lines of: > 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide > no DT so we need to include it. With which I disagree. The config option > says "You must provide an external device tree" for a reason. Where are you reading that? I'm lost. OF_SEPARATE means it is not embedded in U-Boot but is attached to the end of it. > 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact > committed in the kernel. I am not sure about the rest, but honestly this > isn't a convincing argument for me. Great, so you've solved that one but even that was confusing for me, as my patch should make clear. Every single board would be its own special snowflake if we went that way. So if they are in the kernel, we just need to put them in U-Boot too, so problem solved. The auto-sync thing that I believe Rob is working on will make things easy. > > What else are we gaining with it being a run time choice? One of the We are requiring a DT to be present in the U-Boot tree for development, documentation and discoverability purposes. Devs can turn OF_BOARD on and off as it suits them when iterating on a platform. > things this approach does address, but we keep conveniently ignoring, is > that it tries to preserve the current status quo. You can go and add the > special missing U-Boot nodes in those DT's. So that would bypass problems > if the bindings get NAK'ed. But this is going to work against the > fragmentation we are trying to resolve. Well that's another reason why we need in-tree DTs at the moment. That reason goes away once we have our bindings upstream and are able to do what we need with DT there. > > > > But it's not possible. That's the problem we keep going around and > > > around about. People keep raising real life examples where you cannot > > > make a run time choice between "device tree we're passed at run time" > > > and "device tree we're compiled with". > > > > I haven't seen one. The most extreme case is QEMU and it works fine. I > > even added a test with it. What am I missing? (I think my point there is made) > > IMHO 3b595da441cf is the commit that started the problem and tangled those > 2 options. Note that this support has been removed from the dragonboard > later in 0204d1b56b2f Yes it is one of them. There may be cases where we want to patch up the DT that U-Boot builds. In fact OF_BOARD does not mean it came from a prior stage. All sorts of things could be going on. We should not conflate building a DT with OF_BOARD. > > > > > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > > to override the run time device tree with our own, because it's a > > > developer developing things or it's a user / production case where we > > > must use the provided tree. NOT doing that is what leads to madness > > > like we see for example on Pi where if we don't use the passed tree we > > > still need to copy X/Y/Z out of it. > > > > Aren't you talking about the distro DT there, rather than the the one > > on the boot disk? That is my reading of that patch. If we need to do > > that sort of thing, it doesn't matter where the the cointrol DT comes > > from. You are still going to have to do that sort of thing. > > > > It is not ALWAYS the case. I've shown you how easy it is to disable > > OF_BOARD and still boot / iterate. > > > > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > > device tree in the binary. There's a growing set of devices where the > > > > > device tree exists with the device. If it's missing, that's a huge > > > > > fatal error we can't do all that much about. If we need to do > > > > > something > > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit : > Hi Tom, > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But > largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because > there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because > we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > choice. > > > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where > the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do > something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common > case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. > > > > > > > I guess another part of the problem is that historically almost all > > > > platforms were in the first case I list above, no run time provided > > > > device tree, so we took the kernel one and added our bindings to it. > > > > Now we're being bit by the growing number of platforms that are the > > > > second case, and how do we get our properties in there, and which > ones > > > > even make sense to do that for. > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > start, but we need to make progress with this series and all the other > > > things in flight. I think a lot of people want U-Boot to not have a > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > think this is a good summary: > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > Yes, there are some ARMv8 platforms we will have to have the source > > files to, in tree, because they won't come to us at run time. But > > others we won't for practical reasons, namely that we can't statically > > provide something that
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Simon Glass > Date: Sat, 4 Dec 2021 08:20:55 -0700 > > Hi Tom, > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? Try it on your M1 Mac. > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. You are cheating. If you dump the device tree passed to U-Boot (or the OS) and don't change anything in the configuration of whatever is passing U-Boot that device tree this is likely to work fine. But it won't work in general. > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. No, Apple M1 and Raspberry Pi 4 also fall into that case. And I suspect at least some of the other boards that currently defined OF_BOARD fall into this category. So rather than changing the meaning of OF_BOARD, how about introducing another Kconfig option that indicates that switching to a device tree built into U-Boot is ok? You could use that to implement the runtime switching that you desire. This would prevent confusing users with options that result in making their systems unusable. > > > > I guess another part of the problem is that historically almost all > > > > platforms were in the first case I list above, no run time provided > > > > device tree, so we took the kernel one and added our bindings to it. > > > > Now we're being bit by the growing number of platforms that are the > > > > second case, and how do we get our properties in there, and which ones > > > > even make sense to do that for. > > > > > > I think
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon, [...] > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > I am not convinced the case is "we are developing something". The arguments for this are something along the lines of: 1. U-Boot will fail to compile if OF_SEPARATE is selected and you provide no DT so we need to include it. With which I disagree. The config option says "You must provide an external device tree" for a reason. 2. The DT's are hard to find. The 'hard to find' RPI DTs are in fact committed in the kernel. I am not sure about the rest, but honestly this isn't a convincing argument for me. What else are we gaining with it being a run time choice? One of the things this approach does address, but we keep conveniently ignoring, is that it tries to preserve the current status quo. You can go and add the special missing U-Boot nodes in those DT's. So that would bypass problems if the bindings get NAK'ed. But this is going to work against the fragmentation we are trying to resolve. > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? IMHO 3b595da441cf is the commit that started the problem and tangled those 2 options. Note that this support has been removed from the dragonboard later in 0204d1b56b2f > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. So the translation of this for me is: We have 2 discrete options (that can be cleaned up further) which choose either to embed or receive the DTB. Let's tangle them and introduce a *new* third option to separate them if someone needs to. Which makes no sense to me. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > [huge snip] > > > There's things that need to be cleaned up because we have some small > > > number of platforms that went off and did their own thing. But largely > > > yes, things make sense to me. We have: > > > - We embedded the device tree that will configure U-Boot, because there > > > is no way for the hardware to have provided us one. > > > - We do not embed the device tree that will configure U-Boot, because > > > there is already one present in memory for us to use. > > > > > > Then we have the developer option of: > > > - We embedded the device tree that will configure U-Boot, because we're > > > developing something. > > > > Yes, agreed those are the cases. To me this needs to be a run-time choice. > > But it's not possible. That's the problem we keep going around and > around about. People keep raising real life examples where you cannot > make a run time choice between "device tree we're passed at run time" > and "device tree we're compiled with". I haven't seen one. The most extreme case is QEMU and it works fine. I even added a test with it. What am I missing? > > And it's not helpful. It is ALWAYS the case that we know that we want > to override the run time device tree with our own, because it's a > developer developing things or it's a user / production case where we > must use the provided tree. NOT doing that is what leads to madness > like we see for example on Pi where if we don't use the passed tree we > still need to copy X/Y/Z out of it. Aren't you talking about the distro DT there, rather than the the one on the boot disk? That is my reading of that patch. If we need to do that sort of thing, it doesn't matter where the the cointrol DT comes from. You are still going to have to do that sort of thing. It is not ALWAYS the case. I've shown you how easy it is to disable OF_BOARD and still boot / iterate. > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > > provide a way to do that? But what is driving that desire? > > > > > > I'm looking for ways to convince you that we do not need to include a > > > device tree in the binary. There's a growing set of devices where the > > > device tree exists with the device. If it's missing, that's a huge > > > fatal error we can't do all that much about. If we need to do something > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > forward for the developer to do that. But that's not the common case! > > > > Well we could add another Kconfig which tells U-Boot not to include a > > devicetree in u-boot.bin, if that would resolve this? > > > > I just want to make sure that we always build the devicetrees and that > > it is easy for a knowledgeable dev to switch over to use them, without > > spelunking through dozens of other projects to discover the secret DT > > that no one will tell us about. > > Should we demand better documentation for boards? Yes. But it's still > a valid case to have zero device trees for a given platform in-tree. > Xen is an example of this. QEMU is an example of this. Platforms need > to work without adding special tweaks for us. Maybe that means some > features can't be tested in QEMU-as-virtual-platform and only in > QEMU-faithfully-emulating-specific-physical-platforms. You mention QEMU (for ARM and RISC-V) and now XEN. They are a special case, I think. How about we create a special Kconfig for that case? We need to make some progress here. > > > > I guess another part of the problem is that historically almost all > > > platforms were in the first case I list above, no run time provided > > > device tree, so we took the kernel one and added our bindings to it. > > > Now we're being bit by the growing number of platforms that are the > > > second case, and how do we get our properties in there, and which ones > > > even make sense to do that for. > > > > I think upstreaming the bindings is the solution there. I've made a > > start, but we need to make progress with this series and all the other > > things in flight. I think a lot of people want U-Boot to not have a > > devicetree source files in it for ARMv8 platforms. I am strongly > > opposed to that. I've laid out my reasons very clearly in the past. I > > think this is a good summary: > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > Yes, there are some ARMv8 platforms we will have to have the source > files to, in tree, because they won't come to us at run time. But > others we won't for practical reasons, namely that we can't statically > provide something that exists dynamically without massive duplication of > code or just taking things from that passed to us tree. So let's require that the static ones have the Linux DT in our tree for now. The dynamic ones are just QEMU for ARM and Xen, I think. If that's it then I
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: [huge snip] > > There's things that need to be cleaned up because we have some small > > number of platforms that went off and did their own thing. But largely > > yes, things make sense to me. We have: > > - We embedded the device tree that will configure U-Boot, because there > > is no way for the hardware to have provided us one. > > - We do not embed the device tree that will configure U-Boot, because > > there is already one present in memory for us to use. > > > > Then we have the developer option of: > > - We embedded the device tree that will configure U-Boot, because we're > > developing something. > > Yes, agreed those are the cases. To me this needs to be a run-time choice. But it's not possible. That's the problem we keep going around and around about. People keep raising real life examples where you cannot make a run time choice between "device tree we're passed at run time" and "device tree we're compiled with". And it's not helpful. It is ALWAYS the case that we know that we want to override the run time device tree with our own, because it's a developer developing things or it's a user / production case where we must use the provided tree. NOT doing that is what leads to madness like we see for example on Pi where if we don't use the passed tree we still need to copy X/Y/Z out of it. > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we should > > > provide a way to do that? But what is driving that desire? > > > > I'm looking for ways to convince you that we do not need to include a > > device tree in the binary. There's a growing set of devices where the > > device tree exists with the device. If it's missing, that's a huge > > fatal error we can't do all that much about. If we need to do something > > to that device tree for U-Boot, yes, fine, we should make it straight > > forward for the developer to do that. But that's not the common case! > > Well we could add another Kconfig which tells U-Boot not to include a > devicetree in u-boot.bin, if that would resolve this? > > I just want to make sure that we always build the devicetrees and that > it is easy for a knowledgeable dev to switch over to use them, without > spelunking through dozens of other projects to discover the secret DT > that no one will tell us about. Should we demand better documentation for boards? Yes. But it's still a valid case to have zero device trees for a given platform in-tree. Xen is an example of this. QEMU is an example of this. Platforms need to work without adding special tweaks for us. Maybe that means some features can't be tested in QEMU-as-virtual-platform and only in QEMU-faithfully-emulating-specific-physical-platforms. > > I guess another part of the problem is that historically almost all > > platforms were in the first case I list above, no run time provided > > device tree, so we took the kernel one and added our bindings to it. > > Now we're being bit by the growing number of platforms that are the > > second case, and how do we get our properties in there, and which ones > > even make sense to do that for. > > I think upstreaming the bindings is the solution there. I've made a > start, but we need to make progress with this series and all the other > things in flight. I think a lot of people want U-Boot to not have a > devicetree source files in it for ARMv8 platforms. I am strongly > opposed to that. I've laid out my reasons very clearly in the past. I > think this is a good summary: > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html Yes, there are some ARMv8 platforms we will have to have the source files to, in tree, because they won't come to us at run time. But others we won't for practical reasons, namely that we can't statically provide something that exists dynamically without massive duplication of code or just taking things from that passed to us tree. > I believe I have been consistent in this although with all the > discussion I'm really not sure anymore. Yes, everyone has been consistent in these discussions. > The problem is that various people have various views about how U-Boot > should work with devicetree. I strongly believe that until we have > bindings upstream, a central repo for DTs with easy downloading for > builds, automated validation, among other things, we must maintain the > devicetree in U-Boot. Just from the POV of energy expended, I do not > want to be arguing with the Linaro folks about what U-Boot is allowed > to do every month for the next two years. I'd rather set out the stall > now and then deal with the problems it causes from that perspective. The problems of the last going on 12 years won't be solved instantly. The conflict as I see it is that you're insisting that all platforms must have statically usable device trees, and I (and I believe others) are saying that's unreasonable in cases where the trees are dynamic at
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Fri, 3 Dec 2021 at 13:43, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote: > > Hi Andre, > > > > On Thu, 2 Dec 2021 at 18:59, Andre Przywara wrote: > > > > > > On Thu, 2 Dec 2021 13:34:07 -0500 > > > Tom Rini wrote: > > > > > > Hi, > > > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog > > > > > > > > > > wrote: > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > > > 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 in > > > > > > > > > > > > another patch in this > > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own > > > > > > > > > > > > patch to add the > > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along > > > > > > > > > > > > the way. The > > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > > > current state > > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > > > *control* devicetrees > > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the > > > > > > > > > > > mailing list.so I am > > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > > If you make a version without « fake DTs » as you name > > > > > > > > > > > them, there are good > > > > > > > > > > > advances in the documentation and other areas that would > > > > > > > > > > > be better in > > > > > > > > > > > mainline…. > > > > > > > > > > > If I am the only one thinking this way and the patch can > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom,
On Fri, 3 Dec 2021 at 12:25, Tom Rini wrote:
>
> On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote:
> > is generallyHi Tom,
> >
> > On Fri, 3 Dec 2021 at 09:31, Tom Rini wrote:
> > >
> > > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> > > > >
> > > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch
> > > > > > > > in this
> > > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > Note: If board maintainers are able to add their own patch to
> > > > > > > > add the
> > > > > > > > files, some patches in this series can be dropped.
> > > > > > > >
> > > > > > > > It also provides a few qemu clean-ups discovered along the way.
> > > > > > > > The
> > > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > > >
> > > > > > > Note that I can't run-time test this as the last patch fails to
> > > > > > > apply
> > > > > > > and is dependent on non-trivial missing changes ("/* The
> > > > > > > devicetree is
> > > > > > > typically appended to U-Boot */" doesn't exist at all in
> > > > > > > lib/fdtdec.c
> > > > > > > and that's part of the unchanging context where things fail to
> > > > > > > apply).
> > > > > >
> > > > > > That code is the penultimate patch ("fdt: Drop remaining
> > > > > > preprocessor
> > > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > > > -next and is at dm/ofb-working if you want to compare.
> > > > >
> > > > > I just fetch'd and built that instead, thanks.
> > > > >
> > > > > > > So, here's my first bit of confusion. Today, I build for
> > > > > > > rpi_arm64 and
> > > > > > > no dtb files are built. I run this on my Pi 3 and everything
> > > > > > > works.
> > > > > > > With your series, I see all the dtbs have been built, and
> > > > > > > dts/dt.dtb and
> > > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > > > >
> > > > > > Yes, so long as OF_BOARD is enabled, which it is in this series.
> > > > > > This
> > > > > > is basically the same as the situation with rpi3, except it uses
> > > > > > OF_EMBED (need to fix...)
> > > > >
> > > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > > > .config, so I'm telling it to use the run-time device tree. It will
> > > > > never ever use this dtb, under any circumstance, right?
> > > >
> > > > That's right, unless you disable OF_BOARD and build U-Boot again.
> > >
> > > And then it would fail to boot, because I'm on a 3, not a 4.
> >
> > Yes, but that's because the DT is wrong, right? The build builds all
> > the different DTs but just selects one (the default) to put into
> > u-boot.dtb and u-boot.bin
> >
> > We could make it generate images for all of them. I have thought about
> > that as it stops us
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote: > Hi Andre, > > On Thu, 2 Dec 2021 at 18:59, Andre Przywara wrote: > > > > On Thu, 2 Dec 2021 13:34:07 -0500 > > Tom Rini wrote: > > > > Hi, > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own > > > > > > > > > > > patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along > > > > > > > > > > > the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name > > > > > > > > > > them, there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the > > > > > > > > > > possible outcomes of > > > > > > > > > > not
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote:
> is generallyHi Tom,
>
> On Fri, 3 Dec 2021 at 09:31, Tom Rini wrote:
> >
> > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> > > >
> > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch
> > > > > > > in this
> > > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > Note: If board maintainers are able to add their own patch to add
> > > > > > > the
> > > > > > > files, some patches in this series can be dropped.
> > > > > > >
> > > > > > > It also provides a few qemu clean-ups discovered along the way.
> > > > > > > The
> > > > > > > qemu-riscv64_spl problem is fixed.
> > > > > >
> > > > > > Note that I can't run-time test this as the last patch fails to
> > > > > > apply
> > > > > > and is dependent on non-trivial missing changes ("/* The devicetree
> > > > > > is
> > > > > > typically appended to U-Boot */" doesn't exist at all in
> > > > > > lib/fdtdec.c
> > > > > > and that's part of the unchanging context where things fail to
> > > > > > apply).
> > > > >
> > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > > -next and is at dm/ofb-working if you want to compare.
> > > >
> > > > I just fetch'd and built that instead, thanks.
> > > >
> > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64
> > > > > > and
> > > > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > > > With your series, I see all the dtbs have been built, and
> > > > > > dts/dt.dtb and
> > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > > >
> > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > > > is basically the same as the situation with rpi3, except it uses
> > > > > OF_EMBED (need to fix...)
> > > >
> > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > > .config, so I'm telling it to use the run-time device tree. It will
> > > > never ever use this dtb, under any circumstance, right?
> > >
> > > That's right, unless you disable OF_BOARD and build U-Boot again.
> >
> > And then it would fail to boot, because I'm on a 3, not a 4.
>
> Yes, but that's because the DT is wrong, right? The build builds all
> the different DTs but just selects one (the default) to put into
> u-boot.dtb and u-boot.bin
>
> We could make it generate images for all of them. I have thought about
> that as it stops us needing different boards just to handle having
> multiple DT options. But I haven't really looked at it.
It would be wrong because it's the wrong device tree for the hardware,
yes. And we don't want to build N different binaries, the point of the
target is that everything works like a good data-driven
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
is generallyHi Tom,
On Fri, 3 Dec 2021 at 09:31, Tom Rini wrote:
>
> On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> > >
> > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in
> > > > > > this
> > > > > > series: "doc: Add documentation about devicetree usage"
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Note: If board maintainers are able to add their own patch to add
> > > > > > the
> > > > > > files, some patches in this series can be dropped.
> > > > > >
> > > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > > qemu-riscv64_spl problem is fixed.
> > > > >
> > > > > Note that I can't run-time test this as the last patch fails to apply
> > > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > > and that's part of the unchanging context where things fail to apply).
> > > >
> > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > -next and is at dm/ofb-working if you want to compare.
> > >
> > > I just fetch'd and built that instead, thanks.
> > >
> > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64
> > > > > and
> > > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb
> > > > > and
> > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > >
> > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > > is basically the same as the situation with rpi3, except it uses
> > > > OF_EMBED (need to fix...)
> > >
> > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > .config, so I'm telling it to use the run-time device tree. It will
> > > never ever use this dtb, under any circumstance, right?
> >
> > That's right, unless you disable OF_BOARD and build U-Boot again.
>
> And then it would fail to boot, because I'm on a 3, not a 4.
Yes, but that's because the DT is wrong, right? The build builds all
the different DTs but just selects one (the default) to put into
u-boot.dtb and u-boot.bin
We could make it generate images for all of them. I have thought about
that as it stops us needing different boards just to handle having
multiple DT options. But I haven't really looked at it.
>
> > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> > I didn't even know that...yet another example of the confusion of the
> > current state.
>
> So, I'm trying to use this example here to lead to what I think is a
> reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
> built trees, and the embedded tree, will not ever be used. But it makes
(except during development and for build testing)
> the make logic a tiny bit easier to have some tree, not no tree. Why
> can't we:
> - When CONFIG_OF_BOARD=y not build those
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> >
> > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in
> > > > > this
> > > > > series: "doc: Add documentation about devicetree usage"
> > > > >
> > > > > 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.
> > > > >
> > > > > Note: If board maintainers are able to add their own patch to add the
> > > > > files, some patches in this series can be dropped.
> > > > >
> > > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > > qemu-riscv64_spl problem is fixed.
> > > >
> > > > Note that I can't run-time test this as the last patch fails to apply
> > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > and that's part of the unchanging context where things fail to apply).
> > >
> > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > -next and is at dm/ofb-working if you want to compare.
> >
> > I just fetch'd and built that instead, thanks.
> >
> > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > >
> > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > is basically the same as the situation with rpi3, except it uses
> > > OF_EMBED (need to fix...)
> >
> > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > .config, so I'm telling it to use the run-time device tree. It will
> > never ever use this dtb, under any circumstance, right?
>
> That's right, unless you disable OF_BOARD and build U-Boot again.
And then it would fail to boot, because I'm on a 3, not a 4.
> Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> I didn't even know that...yet another example of the confusion of the
> current state.
So, I'm trying to use this example here to lead to what I think is a
reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
built trees, and the embedded tree, will not ever be used. But it makes
the make logic a tiny bit easier to have some tree, not no tree. Why
can't we:
- When CONFIG_OF_BOARD=y not build those trees as part of "all"
(individual rules should still work).
- For linking, use an empty minimal valid dts.
Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration
to know what device tree you want it to even use if you disable
CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is
correct, which is why it's unset currently.
Does this make sense? If not, why not? And I have thoughts about other
platforms too, but I want to stick with a fairly concrete example first.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom,
On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
>
> On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > >
> > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this
> > > > series: "doc: Add documentation about devicetree usage"
> > > >
> > > > 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.
> > > >
> > > > Note: If board maintainers are able to add their own patch to add the
> > > > files, some patches in this series can be dropped.
> > > >
> > > > It also provides a few qemu clean-ups discovered along the way. The
> > > > qemu-riscv64_spl problem is fixed.
> > >
> > > Note that I can't run-time test this as the last patch fails to apply
> > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > and that's part of the unchanging context where things fail to apply).
> >
> > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > -next and is at dm/ofb-working if you want to compare.
>
> I just fetch'd and built that instead, thanks.
>
> > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> >
> > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > is basically the same as the situation with rpi3, except it uses
> > OF_EMBED (need to fix...)
>
> OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> .config, so I'm telling it to use the run-time device tree. It will
> never ever use this dtb, under any circumstance, right?
That's right, unless you disable OF_BOARD and build U-Boot again.
Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
I didn't even know that...yet another example of the confusion of the
current state.
Regards,
Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> >
> > On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this
> > > series: "doc: Add documentation about devicetree usage"
> > >
> > > 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.
> > >
> > > Note: If board maintainers are able to add their own patch to add the
> > > files, some patches in this series can be dropped.
> > >
> > > It also provides a few qemu clean-ups discovered along the way. The
> > > qemu-riscv64_spl problem is fixed.
> >
> > Note that I can't run-time test this as the last patch fails to apply
> > and is dependent on non-trivial missing changes ("/* The devicetree is
> > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > and that's part of the unchanging context where things fail to apply).
>
> That code is the penultimate patch ("fdt: Drop remaining preprocessor
> macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> -next and is at dm/ofb-working if you want to compare.
I just fetch'd and built that instead, thanks.
> > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > no dtb files are built. I run this on my Pi 3 and everything works.
> > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
>
> Yes, so long as OF_BOARD is enabled, which it is in this series. This
> is basically the same as the situation with rpi3, except it uses
> OF_EMBED (need to fix...)
OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
.config, so I'm telling it to use the run-time device tree. It will
never ever use this dtb, under any circumstance, right?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Fri, 3 Dec 2021 at 08:14, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote: > > [snip] > > So now we find out the full horror of the fragmented mess that things > > are to become. No way does this make sense. > > > > It is already too hard to build things. Just look at the meson/binman > > series I sent last week. We need to make things easier for people, not > > harder. > > I think this gets at one of my points. It seems exceedingly unlikely to > me that every semi vendor is going to stop making their own tooling and > per SoC requirements here and instead converge on a common one. I feel > like that's not even true in x86, but it's largely just Intel or AMD > rather than a handful of vendors. I see places we can make change > happen and places we're going to have to use what we're given. Unless > Arm Ltd pushes something, every semi gets to "innovate" in this area up > until the point where SystemReady (well, the underlying specifications) > say you MUST do X. Yes, I think you are right. So I think the best we can do for now is describe the image and the tools needed to make it, leaving the user to collect the required binaries and tools that are needed, repeating until binman stops saying 'missing external blobs'. BTW binman does have a way to show help for how to get each blob (tools/binman/missing-blob-help) and I plan to do the same for tools when I respin the meson series. For x86, Intel tools have ended up open source over time, e.g. under the influence of Chrome OS. I am less sure on the AMD side though, but will check that and push there if needed. I'd suggest that Arm should require the tools to be open-source. I will make that point next time I have a chance. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom,
On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
>
> On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this
> > series: "doc: Add documentation about devicetree usage"
> >
> > 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.
> >
> > Note: If board maintainers are able to add their own patch to add the
> > files, some patches in this series can be dropped.
> >
> > It also provides a few qemu clean-ups discovered along the way. The
> > qemu-riscv64_spl problem is fixed.
>
> Note that I can't run-time test this as the last patch fails to apply
> and is dependent on non-trivial missing changes ("/* The devicetree is
> typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> and that's part of the unchanging context where things fail to apply).
That code is the penultimate patch ("fdt: Drop remaining preprocessor
macros in fdtdec_setup()"). Did that patch apply OK? It is based on
-next and is at dm/ofb-working if you want to compare.
>
> So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> no dtb files are built. I run this on my Pi 3 and everything works.
> With your series, I see all the dtbs have been built, and dts/dt.dtb and
> u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
Yes, so long as OF_BOARD is enabled, which it is in this series. This
is basically the same as the situation with rpi3, except it uses
OF_EMBED (need to fix...)
If we get as far as the std passage stuff then it will print out the
source of the DT when it starts. If you like I could move three
patches into this series:
f88bd6a431a (HEAD -> ofb6) dm: core: Allow getting some basic stats
8121102a004 passage: Report the devicetree source
c9c791ddedf passage: Record where the devicetree came from
5a0b7505498 (dm/ofb-working, dm-public/ofb-working) fdt: Don't call
board_fdt_blob_setup() without OF_BOARD
Booting with rpi3 and rpi4 I get (see the "devicetree:" bit):
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:32:41 -0700)
DRAM: 992 MiB
RPI 3 Model B (0xa02082)
Core: 61 devices, 11 uclasses, devicetree: embed
MMC: mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In:serial
Out: vidconsole
Err: vidconsole
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:33:43 -0700)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03111)
Core: 197 devices, 13 uclasses, devicetree: board
MMC: mmcnr@7e30: 1, mmc@7e34: 0
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In:serial
Out: vidconsole
Regards,
Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote: [snip] > So now we find out the full horror of the fragmented mess that things > are to become. No way does this make sense. > > It is already too hard to build things. Just look at the meson/binman > series I sent last week. We need to make things easier for people, not > harder. I think this gets at one of my points. It seems exceedingly unlikely to me that every semi vendor is going to stop making their own tooling and per SoC requirements here and instead converge on a common one. I feel like that's not even true in x86, but it's largely just Intel or AMD rather than a handful of vendors. I see places we can make change happen and places we're going to have to use what we're given. Unless Arm Ltd pushes something, every semi gets to "innovate" in this area up until the point where SystemReady (well, the underlying specifications) say you MUST do X. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > > tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > > required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > > adding > > > > > > > > more. > > > > > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > > > with this approach. This proposal is working in the *exact* > > > > > > > opposite > > > > > > > direction and we'll never be able to get rid of device trees from > > > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > > > Personally I'd be way happier if we could figure out were the > > > > > > > specific > > > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > > > what we figure out we could, pick up the device tree from a > > > > > > > previous > > > > > > > state bootloader and fix it up with our special nodes before we > > > > > > > start > > > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > > > that indeed belong in the u-boot tree. > > > > > > > > Applying a devicetree overlay can be implemented in common/board_f.c > > > before the first usage of the devicetree to initialize devices (there > > > are some that are initialized before relocation). > > > > Thanks for digging this up. Tbh I misunderstood the original mail from > > Mark. When I read pre-reloc I assumed no C environment was up yet. > > However this raises a few questions. > > 1. The .dtbos will need to be embedded in the u-boot binary since > > there's no FS access (or in some cases storage access to begin with) > > 2. The RAM we have is going to be limited if we want to apply the overlays > > before consoles etc are up, since it basically has to happen at some point > > near 'fdtdec_setup' > > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think > > of > > the same hardware with different configuration. You'll be able to use the > > same binary, if you can somehow configure which overlays you want to apply. > > This has come up before and the answer has been "doing it this early > will be too large" where large can mean either of .text space (we have > many constrained platforms) or memory usage (this is before DRAM > potentially). It's also on the flip side one of those places where > maybe it's less of a problem on arm64 (where prior stages will have > initialized much already) than arm32 (where we are very early) and other > platforms. And we need solutions that work for both cases. So I have an answer on my (3).a We can use the bloblist for that. We could do something along the lines of 1. Include .dtbos in u-boot source 2. Standardize the bloblist handover discussion we had across bootloaders, so that the bloblist contains information of what .dtbos to apply. We can even take it a step further and request specific .dtbos to be applied before/after DRAM init to save some boards from the DRAM issue. 3. U-Boot applies the .dtbos on the fly. What's more interesting is that looking around what we currently have, the renesas RCAR platform is already doing something *very* similar [1]. [1] board/renesas/rcar-common/common.c -> fdtdec_board_setup Cheers /Ilias > > -- > Tom
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 08:58:54AM -0700, 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 in another patch in this
> series: "doc: Add documentation about devicetree usage"
>
> 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.
>
> Note: If board maintainers are able to add their own patch to add the
> files, some patches in this series can be dropped.
>
> It also provides a few qemu clean-ups discovered along the way. The
> qemu-riscv64_spl problem is fixed.
Note that I can't run-time test this as the last patch fails to apply
and is dependent on non-trivial missing changes ("/* The devicetree is
typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
and that's part of the unchanging context where things fail to apply).
So, here's my first bit of confusion. Today, I build for rpi_arm64 and
no dtb files are built. I run this on my Pi 3 and everything works.
With your series, I see all the dtbs have been built, and dts/dt.dtb and
u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 04:30:40PM +0200, Ilias Apalodimas wrote: > Hi Heinrich, > > On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote: > > On 12/3/21 11:27, Mark Kettenis wrote: > > > > Date: Fri, 3 Dec 2021 09:50:44 +0200 > > > > From: Ilias Apalodimas > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more. > > > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > > with this approach. This proposal is working in the *exact* > > > > > > opposite > > > > > > direction and we'll never be able to get rid of device trees from > > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > > Personally I'd be way happier if we could figure out were the > > > > > > specific > > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > > what we figure out we could, pick up the device tree from a previous > > > > > > state bootloader and fix it up with our special nodes before we > > > > > > start > > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > > that indeed belong in the u-boot tree. > > > > > Applying a devicetree overlay can be implemented in common/board_f.c > > before the first usage of the devicetree to initialize devices (there > > are some that are initialized before relocation). > > Thanks for digging this up. Tbh I misunderstood the original mail from > Mark. When I read pre-reloc I assumed no C environment was up yet. > However this raises a few questions. > 1. The .dtbos will need to be embedded in the u-boot binary since > there's no FS access (or in some cases storage access to begin with) > 2. The RAM we have is going to be limited if we want to apply the overlays > before consoles etc are up, since it basically has to happen at some point > near 'fdtdec_setup' > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of > the same hardware with different configuration. You'll be able to use the > same binary, if you can somehow configure which overlays you want to apply. This has come up before and the answer has been "doing it this early will be too large" where large can mean either of .text space (we have many constrained platforms) or memory usage (this is before DRAM potentially). It's also on the flip side one of those places where maybe it's less of a problem on arm64 (where prior stages will have initialized much already) than arm32 (where we are very early) and other platforms. And we need solutions that work for both cases. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Heinrich, On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote: > On 12/3/21 11:27, Mark Kettenis wrote: > > > Date: Fri, 3 Dec 2021 09:50:44 +0200 > > > From: Ilias Apalodimas > > > > > > Hi Mark, > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > > state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > direction and we'll never be able to get rid of device trees from > > > > > U-Boot, even if at some point they move out of the kernel to a > > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > > Personally I'd be way happier if we could figure out were the specific > > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > > what we figure out we could, pick up the device tree from a previous > > > > > state bootloader and fix it up with our special nodes before we start > > > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > > > that indeed belong in the u-boot tree. > > Applying a devicetree overlay can be implemented in common/board_f.c > before the first usage of the devicetree to initialize devices (there > are some that are initialized before relocation). Thanks for digging this up. Tbh I misunderstood the original mail from Mark. When I read pre-reloc I assumed no C environment was up yet. However this raises a few questions. 1. The .dtbos will need to be embedded in the u-boot binary since there's no FS access (or in some cases storage access to begin with) 2. The RAM we have is going to be limited if we want to apply the overlays before consoles etc are up, since it basically has to happen at some point near 'fdtdec_setup' 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of the same hardware with different configuration. You'll be able to use the same binary, if you can somehow configure which overlays you want to apply. Thanks /Ilias > > > > > > > > > I don't think it makes sense to put stuff in the DT that is specific > > > > for U-Boot only to pull it out moments later. Maybe it does make some > > > > sense to do this to pass information between TPL/SPL and U-Boot > > > > proper. But otherwise you can just use global variables... > > Linux will silently ignore any node for which it does not have a > compatible string. So application of an overlay once in U-Boot is > sufficient. > > Best regards > > Heinrich > > > > > > > Last time we said we don't really have to remove them, but I get the > > > point. > > > > Ah, when I said "pull it out" I meant "read it back"; not "delete it". > > > > > > Now I just ran into an issue on Apple M1 that may have some relevance > > > > here. I'm adding support for power domains and the serial port > > > > requires certain power domains to be on. Since the serial port is > > > > initialized in the pre-relocation phase this means that the device > > > > tree nodes for the power domain controllers need to have the > > > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > > > be able to bind the power domain controller driver in this phase and > > > > binding the serial port driver itself will fail. Which makes U-Boot > > > > hang without any visible output on the serial console. > > > > > > Very relevant
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On 12/3/21 11:27, Mark Kettenis wrote: Date: Fri, 3 Dec 2021 09:50:44 +0200 From: Ilias Apalodimas Hi Mark, [...] Changes in v6: - Fix description of OF_BOARD so it refers just to the current state - Explain that the 'two devicetrees' refers to two *control* devicetrees - Expand the commit message based on comments - Expand the commit message based on comments You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either. If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline…. If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform. This is the part that I too am still unhappy about. I do not want reference or fake or whatever device trees in the U-Boot source tree. We should be able to _remove_ the ones we have, that are not required, with doc/board/...rst explaining how to get / view one. Not adding more. So this is a key point for me and the reason I completely disagree with this approach. This proposal is working in the *exact* opposite direction and we'll never be able to get rid of device trees from U-Boot, even if at some point they move out of the kernel to a 'common' repo'. I'll just repeat what I've been saying since v1. Personally I'd be way happier if we could figure out were the specific U-Boot config nodes are needed and when are they needed. Based on what we figure out we could, pick up the device tree from a previous state bootloader and fix it up with our special nodes before we start using it, using internal DTS files (compiled to .dtbos or similar) that indeed belong in the u-boot tree. Applying a devicetree overlay can be implemented in common/board_f.c before the first usage of the devicetree to initialize devices (there are some that are initialized before relocation). I don't think it makes sense to put stuff in the DT that is specific for U-Boot only to pull it out moments later. Maybe it does make some sense to do this to pass information between TPL/SPL and U-Boot proper. But otherwise you can just use global variables... Linux will silently ignore any node for which it does not have a compatible string. So application of an overlay once in U-Boot is sufficient. Best regards Heinrich Last time we said we don't really have to remove them, but I get the point. Ah, when I said "pull it out" I meant "read it back"; not "delete it". Now I just ran into an issue on Apple M1 that may have some relevance here. I'm adding support for power domains and the serial port requires certain power domains to be on. Since the serial port is initialized in the pre-relocation phase this means that the device tree nodes for the power domain controllers need to have the "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't be able to bind the power domain controller driver in this phase and binding the serial port driver itself will fail. Which makes U-Boot hang without any visible output on the serial console. Very relevant indeed. That's close to what I was afraid of when I said "if we could figure out were the specific U-Boot config nodes are needed and *when* are they needed". Obviously this is a clear no go, since more boards will have similar requirements in the future. Within the Asahi Linux group we're currently discussing how to solve this. We could just add the "u-boot,dm-pre-reloc" properties in the device trees that we're going to distribute as part of m1n1 (the "bootloader" than embeds U-Boot). Or we can write some code that adds those properties to the device tree nodes that are dependencies for the serial port. That might make sense for a project like m1n1 were you are dealing with a handful of devices, but I think it's going to be a pain on a larger scale, unless of course the bindings are documented in upstream. In that case we could ask previous bootloaders to add them etc. I don't think the suggestion of applying an overlay embedded in U-Boot would work here. The code applying the overlay would need to run very early on in the pre-relocation phase. Yep it wouldn't We'd also have to include overlays for all the models that Apple offers and pick the right one. And if a new model appears we can no longer just add a new device tree to m1n1. But maybe there is a case where the overlay approach would make sense... I think there is, for example I was thinking of TF-A doing all the hardware init and then handover a DTB into u-boot on a register. In that case U-boot could fixup the DTB before initialing the rest of the subsystems and make DM happy. However as you pointed out that's not the case for
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> Date: Fri, 3 Dec 2021 09:50:44 +0200 > From: Ilias Apalodimas > > Hi Mark, > > > > > > > > > [...] > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sense to do this to pass information between TPL/SPL and U-Boot > > proper. But otherwise you can just use global variables... > > Last time we said we don't really have to remove them, but I get the > point. Ah, when I said "pull it out" I meant "read it back"; not "delete it". > > Now I just ran into an issue on Apple M1 that may have some relevance > > here. I'm adding support for power domains and the serial port > > requires certain power domains to be on. Since the serial port is > > initialized in the pre-relocation phase this means that the device > > tree nodes for the power domain controllers need to have the > > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > > be able to bind the power domain controller driver in this phase and > > binding the serial port driver itself will fail. Which makes U-Boot > > hang without any visible output on the serial console. > > Very relevant indeed. That's close to what I was afraid of when I said > "if we could figure out were the specific U-Boot config nodes are needed > and *when* are they needed". Obviously this is a clear no go, since more > boards will have similar requirements in the future. > > > > > Within the Asahi Linux group we're currently discussing how to solve > > this. We could just add the "u-boot,dm-pre-reloc" properties in the > > device trees that we're going to distribute as part of m1n1 (the > > "bootloader" than embeds U-Boot). Or we can write some code that adds > > those properties to the device tree nodes that are dependencies for > > the serial port. > > That might make sense for a project like m1n1 were you are dealing with a > handful of devices, but I think it's going to be a pain on a larger scale, > unless of course the bindings are documented in upstream. In that case we > could ask previous bootloaders to add them etc. > > > > > I don't think the suggestion of applying an overlay embedded in U-Boot > > would work here. The code applying the overlay would need to run very > > early on in the pre-relocation phase. > > Yep it wouldn't > > > We'd also have to include > > overlays for all the models that Apple offers and pick the right one. > > And if a new model appears we can no longer just add a new device tree > > to m1n1. > > > > But maybe there is a case where the overlay approach would make sense... > > I think there is, for example I was thinking of TF-A doing all the hardware > init > and then handover a DTB into u-boot on a register. In that case
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On 12/2/21 17:50, Simon Glass wrote: Hi Heinrich, On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt wrote: On 12/2/21 16:58, 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 in another patch in this series: "doc: Add documentation about devicetree usage" 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. Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped. It also provides a few qemu clean-ups discovered along the way. The qemu-riscv64_spl problem is fixed. Distros like Ubuntu are provided as preinstalled images using U-Boot to launch Linux for usage with QEMU. A single image must be able to be usable in the future irrespective of the QEMU command line device configuration. This means that the devicetree coming from QEMU must be accurately parsed in U-Boot to setup the UEFI memory map. The number and type of CPUs and the NUMA configuration must be accurate. All devices enabled via the QEMU command line must be visible in the device-tree of Linux. Please, observe that information like number of CPU cores, number and type of block devices, namespace IDs used for NVMe drives, etc. cannot be available at build time. It this all guaranteed with this series? If not, this would unfortunately imply a NAK. Yes, it is guaranteed and there is no change there. Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump the devicetree exposed to UEFI binaries. The number of CPUs and the memory size matches the call parameters of QEMU. Emulated devices like SCSI and NVMe drives and TPMv2 work inside U-Boot. I also tested: * qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI * qemu-riscv64_spl_defconfig and found no issues. Tested-by: Heinrich Schuchardt
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon, > > > > > [...] > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > Eh? If the device tree files are actually common then there should be > a single source. If U-Boot has a copy then it should be identical. > > The special node thing makes no sense for U-Boot. We just need to > upstream our bindings and I am working on that. Yea we discussed this on v5. If the device bindings are upstreamed things gets substantially easier. But that's a big if. > > Are the device tree files moving out of Linux? There was an effort from Linaro and iirc we tried to move a few and see how things would work out, but there's nothing official. Regards /Ilias
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, > > > > > [...] > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... Last time we said we don't really have to remove them, but I get the point. > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes for the power domain controllers need to have the > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > be able to bind the power domain controller driver in this phase and > binding the serial port driver itself will fail. Which makes U-Boot > hang without any visible output on the serial console. Very relevant indeed. That's close to what I was afraid of when I said "if we could figure out were the specific U-Boot config nodes are needed and *when* are they needed". Obviously this is a clear no go, since more boards will have similar requirements in the future. > > Within the Asahi Linux group we're currently discussing how to solve > this. We could just add the "u-boot,dm-pre-reloc" properties in the > device trees that we're going to distribute as part of m1n1 (the > "bootloader" than embeds U-Boot). Or we can write some code that adds > those properties to the device tree nodes that are dependencies for > the serial port. That might make sense for a project like m1n1 were you are dealing with a handful of devices, but I think it's going to be a pain on a larger scale, unless of course the bindings are documented in upstream. In that case we could ask previous bootloaders to add them etc. > > I don't think the suggestion of applying an overlay embedded in U-Boot > would work here. The code applying the overlay would need to run very > early on in the pre-relocation phase. Yep it wouldn't > We'd also have to include > overlays for all the models that Apple offers and pick the right one. > And if a new model appears we can no longer just add a new device tree > to m1n1. > > But maybe there is a case where the overlay approach would make sense... I think there is, for example I was thinking of TF-A doing all the hardware init and then handover a DTB into u-boot on a register. In that case U-boot could fixup the DTB before initialing the rest of the subsystems and make DM happy. However as you pointed out that's not the case for all boards and dealing with this in the early pre-relocation stage is close to impossible, so let's drop that. Thanks! /Ilias
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Andre, On Thu, 2 Dec 2021 at 18:59, Andre Przywara wrote: > > On Thu, 2 Dec 2021 13:34:07 -0500 > Tom Rini wrote: > > Hi, > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > > > > > > > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > > > reference or fake or whatever device trees in the
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 13:34:07 -0500 Tom Rini wrote: Hi, > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more. > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Andre, On Thu, 2 Dec 2021 at 18:31, Andre Przywara wrote: > > On Thu, 2 Dec 2021 11:17:38 -0700 > Simon Glass wrote: > > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more. > > > > > > > > > > > > I
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 11:17:38 -0700 Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > écrit : > > > > > > > > > > > > > > > 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 in another patch > > > > > > > > in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > > The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > > state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > it had not come to this. > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > have a devicetree anywhere I can find. > > > > > > > > > > I think on balance
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 19:03:46 +0200 Ilias Apalodimas wrote: Hi, > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > 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 in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > 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. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. I agree on that, I always felt like U-Boot is abusing the DT here for its own purposes. If it needs to convey some configuration information, it should do it separately. It can use the DTB *format* (hierarchically organised key/value pairs), but this should not really be mingled with the hardware information. Trusted-Firmware is using this idea: they use the already included libfdt for parsing, but load the various config "DTB"s separately. The "hw_config" DTB (as they call the actual DTB) is treated separately. Cheers, Andre
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 09:39:52 -0700 Simon Glass wrote: Hi, wow, this thread quickly exploded, jumping in here randomly to add my thoughts: > Hi François, > > On Thu, 2 Dec 2021 at 09:34, François Ozog wrote: > > > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > >> > >> 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 in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> 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. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. The > >> qemu-riscv64_spl problem is fixed. > >> > >> [1] > >> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> Changes in v6: > >> - Fix description of OF_BOARD so it refers just to the current state > >> - Explain that the 'two devicetrees' refers to two *control* devicetrees > >> - Expand the commit message based on comments > >> - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > Please see the change log. I have addressed everything except the > fundamental disagreement we have. > > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! But why? Actually it's the exact opposite, Highbank is somewhat of a (sadly abandoned) poster book child of DT usage: Before the Cortex-A cores boot, the DTB gets loaded by the management processor (ECME) from NOR flash into DRAM. There the memory node gets populated, based on what the ECME detected (it has a DIMM slot!). Then this DTB gets used by U-Boot, which adds the command line and initrd information, based on user choices. And this is eventually consumed by a kernel. So the base DTB here is provided by the system, and software just reacts to it - how it should be. The (arm64) Linux kernel works on this idea: exactly *one* binary image, and the drivers that are needed by the hardware get loaded based on DT information. The fact the .dts files live in the kernel tree is more for practical reasons, because it started there, we enhance DTs and should have a repo holding them, plus all the review knowledge is in the kernel community. Cheers, Andre P.S. I started writing some documentation for Highbank, to be posted soonish. > > Anyway yes I can add a comment to all the files, but please try to ask > for everything at once as there is a cost to continually reworking > this series. > > Regards, > Simon > > >> > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 15:47, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:34, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own > > > > > > > > > > > patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along > > > > > > > > > > > the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name > > > > > > > > > > them, there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the > > > > > > > > > > possible outcomes of > > > > > > > > > > not using the one
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 15:53, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > > Hi Simon,Tom > > > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > a écrit : > > > > > > > > > > > > > > > > > > > > > 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 in another > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the possible > > > outcomes of > > > > > > > > > > not using the one provided by the platform and the right way > > > of dealing > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > want > > > > > > > > > reference or fake or whatever device trees in the U-Boot > > > source tree. > > > > > > > > > We should be able to _remove_ the ones we have, that are not > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > Hi Simon,Tom > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > a écrit : > > > > > > > > > > > > > > > > > > > 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 in another > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > want > > > > > > > > reference or fake or whatever device trees in the U-Boot > > source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not > > required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > adding > > > > > > > > more. > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > > wish > > > > > > > it had not come to this. > > > > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:34, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > > > > > > > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > > > reference or fake or whatever device trees in the
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 14:53, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Simon Glass > > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > > > wrote: > > > > > > > > > > > > > > > From: Ilias Apalodimas > > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own > > > > > > > > > > > patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along > > > > > > > > > > > the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name > > > > > > > > > > them, there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the > > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon,Tom Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > a écrit : > > > > > > > > > > > > > > > > > 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 in another > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two > *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > there are good > > > > > > > > advances in the documentation and other areas that would be > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > > > > > would love there is a warning in capital letters at the top > of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > > > > > not using the one provided by the platform and the right way > of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > want > > > > > > > reference or fake or whatever device trees in the U-Boot > source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > adding > > > > > > > more. > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > wish > > > > > > it had not come to this. > > > > > > > > > > > > However we are only talking about 10 boards, three of which > don't even > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to > add > > > > > > whatever caveats and documentation people want to clarify what is
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis > > > wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > Hi Mark, > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > > wrote: > > > > > > > > > > > > > From: Ilias Apalodimas > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > > > > > > > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Ilias Apalodimas > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Simon Glass > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > wrote: > > > > > > > > > From: Ilias Apalodimas > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > écrit : > > > > > > > > > > > > > > > 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 in another patch > > > > > > > > in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > > The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > > state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > direction and we'll never be able to get rid of device trees from > > > > > U-Boot, even if at some point they move
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 11:34, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > 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 in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more. > > > > > > > > > > > > I understand
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: François Ozog > Date: Thu, 2 Dec 2021 19:32:17 +0100 > > On Thu, 2 Dec 2021 at 19:15, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > écrit : > > > > > > > > > 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 in another patch > in this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > 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. > > > > > > > > > > Note: If board maintainers are able to add their own patch to > add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current > state > > > > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better > in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source > tree. > > > We should be able to _remove_ the ones we have, that are not > required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > > > From: Ilias Apalodimas > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > écrit : > > > > > > > > > > > > > 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 in another patch > > > > > > > in this > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > > the > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > The > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > Changes in v6: > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > state > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > devicetrees > > > > > > > - Expand the commit message based on comments > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > > > > > > I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there > > > > > > are good > > > > > > advances in the documentation and other areas that would be better > > > > > > in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be > > > > > > accepted, I > > > > > > would love there is a warning in capital letters at the top of the > > > > > > DTS fake > > > > > > files that explains the intent of this fake DT, the possible > > > > > > outcomes of > > > > > > not using the one provided by the platform and the right way of > > > > > > dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > with this approach. This proposal is working in the *exact* opposite > > > > direction and we'll never be able to get rid of device trees from > > > > U-Boot, even if at some point they move out of the kernel to a > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > Personally I'd be way happier if we could figure out were the specific > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > what we figure out we could, pick up the device tree
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Simon Glass > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > From: Ilias Apalodimas > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > 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 in another patch in > > > > > > this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > 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. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:21:22AM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > From: Ilias Apalodimas > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > 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 in another patch in > > > > > > this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > 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. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sense
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > écrit : > > > > > > > > > > > > > > > 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 in another patch > > > > > > > > in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > > The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > > state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > it had not come to this. > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > have a devicetree anywhere I can find. > > > > > > > > > > I think on balance this is a
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 19:15, Mark Kettenis wrote: > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit > : > > > > > > > > > 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 in another patch in > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > 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. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current > state > > > > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > 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 in another patch in > > > > > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > 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. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > écrit : > > > > > > > > > > > > > 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 in another patch > > > > > > > in this > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > > the > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > The > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > Changes in v6: > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > state > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > devicetrees > > > > > > > - Expand the commit message based on comments > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > > > > > > I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there > > > > > > are good > > > > > > advances in the documentation and other areas that would be better > > > > > > in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be > > > > > > accepted, I > > > > > > would love there is a warning in capital letters at the top of the > > > > > > DTS fake > > > > > > files that explains the intent of this fake DT, the possible > > > > > > outcomes of > > > > > > not using the one provided by the platform and the right way of > > > > > > dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > it had not come to this. > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > have a devicetree anywhere I can find. > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > whatever caveats and documentation people want to clarify what is > > > > going on here. I'm happy to look at future options where the > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > within U-Boot for development purposes. > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Ilias Apalodimas > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > 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 in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > 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. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. I don't think it makes sense to put stuff in the DT that is specific for U-Boot only to pull it out moments later. Maybe it does make some sense to do this to pass information between TPL/SPL and U-Boot proper. But otherwise you can just use global variables... Now I just ran into an issue on Apple M1 that may have some relevance here. I'm adding support for power domains and the serial port requires certain power domains to be on. Since the serial port is initialized in the pre-relocation phase this means that the device tree nodes for the power domain controllers need to have the "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't be able to bind the power domain controller driver in this phase and binding the serial port driver itself will fail. Which
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > 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 in another patch in > > > > > > this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > 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. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > I understand you don't like it and that others don't as well. I wish > > > it had not come to this. > > > > > > However we are only talking about 10 boards, three of which don't even > > > have a devicetree anywhere I can find. > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > whatever caveats and documentation people want to clarify what is > > > going on here. I'm happy to look at future options where the > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > within U-Boot for development purposes. > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > But for now, I still feel this is the best path forward. > > > > I'm not sure how to proceed here. The reviews are rather strongly > > against the "include a device tree that won't be used". The use case of > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Ilias, On Thu, 2 Dec 2021 at 10:04, Ilias Apalodimas wrote: > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > 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 in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > 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. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. Eh? If the device tree files are actually common then there should be a single source. If U-Boot has a copy then it should be identical. The special node thing makes no sense for U-Boot. We just need to upstream our bindings and I am working on that. Are the device tree files moving out of Linux? Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > 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 in another patch in > > > > > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > 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. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > I understand you don't like it and that others don't as well. I wish > > it had not come to this. > > > > However we are only talking about 10 boards, three of which don't even > > have a devicetree anywhere I can find. > > > > I think on balance this is a substantial clean-up. I am happy to add > > whatever caveats and documentation people want to clarify what is > > going on here. I'm happy to look at future options where the > > devicetree is hosted elsewhere, so long as it is trivial to build it > > within U-Boot for development purposes. > > > > I'll also note that the bootstd series shows the devicetree source: > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > But for now, I still feel this is the best path forward. > > I'm not sure how to proceed here. The reviews are rather strongly > against the "include a device tree that won't be used". The use case of > "but for development someone might need to modify the device tree" is > handled by platforms documenting where / how to get the real one. We > should even update the Kconfig help to note that if you enable this your > board docs MUST explain where the device tree can be seen (or have some > legal reason you think it's OK to not...). Right, we can do
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > 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 in another patch in this > > > series: "doc: Add documentation about devicetree usage" > > > > > > 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. > > > > > > Note: If board maintainers are able to add their own patch to add the > > > files, some patches in this series can be dropped. > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > qemu-riscv64_spl problem is fixed. > > > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > Changes in v6: > > > - Fix description of OF_BOARD so it refers just to the current state > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > - Expand the commit message based on comments > > > - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > This is the part that I too am still unhappy about. I do not want > reference or fake or whatever device trees in the U-Boot source tree. > We should be able to _remove_ the ones we have, that are not required, > with doc/board/...rst explaining how to get / view one. Not adding > more. So this is a key point for me and the reason I completely disagree with this approach. This proposal is working in the *exact* opposite direction and we'll never be able to get rid of device trees from U-Boot, even if at some point they move out of the kernel to a 'common' repo'. I'll just repeat what I've been saying since v1. Personally I'd be way happier if we could figure out were the specific U-Boot config nodes are needed and when are they needed. Based on what we figure out we could, pick up the device tree from a previous state bootloader and fix it up with our special nodes before we start using it, using internal DTS files (compiled to .dtbos or similar) that indeed belong in the u-boot tree. Regards /Ilias > > -- > Tom
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > 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 in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > 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. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > I understand you don't like it and that others don't as well. I wish > it had not come to this. > > However we are only talking about 10 boards, three of which don't even > have a devicetree anywhere I can find. > > I think on balance this is a substantial clean-up. I am happy to add > whatever caveats and documentation people want to clarify what is > going on here. I'm happy to look at future options where the > devicetree is hosted elsewhere, so long as it is trivial to build it > within U-Boot for development purposes. > > I'll also note that the bootstd series shows the devicetree source: > > Core: 246 devices, 88 uclasses, devicetree: board > > But for now, I still feel this is the best path forward. I'm not sure how to proceed here. The reviews are rather strongly against the "include a device tree that won't be used". The use case of "but for development someone might need to modify the device tree" is handled by platforms documenting where / how to get the real one. We should even update the Kconfig help to note that if you enable this your board docs MUST explain where the device tree can be seen (or have some legal reason you think it's OK to not...). And yes, we're "only" talking about 10 platforms, which include things like the "everyone" has one Pi family, the extraordinarily flexible (and so easy for the reference device tree to be very wrong) QEMU families and then platforms that are including a dts in-tree now because they were told that was required. How about
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le jeu. 2 déc. 2021 à 17:40, Simon Glass a écrit : > Hi François, > > On Thu, 2 Dec 2021 at 09:34, François Ozog > wrote: > > > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > >> > >> 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 in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> 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. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. The > >> qemu-riscv64_spl problem is fixed. > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> Changes in v6: > >> - Fix description of OF_BOARD so it refers just to the current state > >> - Explain that the 'two devicetrees' refers to two *control* devicetrees > >> - Expand the commit message based on comments > >> - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > not in favor of this new version either. > > Please see the change log. I have addressed everything except the > fundamental disagreement we have. > > > If you make a version without « fake DTs » as you name them, there are > good advances in the documentation and other areas that would be better in > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > would love there is a warning in capital letters at the top of the DTS fake > files that explains the intent of this fake DT, the possible outcomes of > not using the one provided by the platform and the right way of dealing > with DTs for the platform. > > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), Qemu is another one, and then you will have all SystemReady compliant boards. > where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! > > Anyway yes I can add a comment to all the files, but please try to ask > for everything at once as there is a cost to continually reworking > this series. I proposed this as a last resort if I was the only one with concerns. But sounds like I am not the only one strongly opinionated here. Another trick would be to use a “.dts.doc” extension so that it is not compiled unless someone is knowingly deciding to use the fake DT for debug purposes (the warning message is still valid). (This is an effort to advance on the good things of the patch) > > > Regards, > Simon > > >> > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 16:40, Simon Glass wrote: > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! Isn't highbank https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/highbank.dts ? -- PMM
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Heinrich, On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt wrote: > > On 12/2/21 16:58, 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 in another patch in this > > series: "doc: Add documentation about devicetree usage" > > > > 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. > > > > Note: If board maintainers are able to add their own patch to add the > > files, some patches in this series can be dropped. > > > > It also provides a few qemu clean-ups discovered along the way. The > > qemu-riscv64_spl problem is fixed. > > Distros like Ubuntu are provided as preinstalled images using U-Boot to > launch Linux for usage with QEMU. A single image must be able to be > usable in the future irrespective of the QEMU command line device > configuration. > > This means that the devicetree coming from QEMU must be accurately > parsed in U-Boot to setup the UEFI memory map. The number and type of > CPUs and the NUMA configuration must be accurate. All devices enabled > via the QEMU command line must be visible in the device-tree of Linux. > > Please, observe that information like number of CPU cores, number and > type of block devices, namespace IDs used for NVMe drives, etc. cannot > be available at build time. > > It this all guaranteed with this series? If not, this would > unfortunately imply a NAK. Yes, it is guaranteed and there is no change there. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > 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 in another patch in this > > > series: "doc: Add documentation about devicetree usage" > > > > > > 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. > > > > > > Note: If board maintainers are able to add their own patch to add the > > > files, some patches in this series can be dropped. > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > qemu-riscv64_spl problem is fixed. > > > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > Changes in v6: > > > - Fix description of OF_BOARD so it refers just to the current state > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > - Expand the commit message based on comments > > > - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > This is the part that I too am still unhappy about. I do not want > reference or fake or whatever device trees in the U-Boot source tree. > We should be able to _remove_ the ones we have, that are not required, > with doc/board/...rst explaining how to get / view one. Not adding > more. I understand you don't like it and that others don't as well. I wish it had not come to this. However we are only talking about 10 boards, three of which don't even have a devicetree anywhere I can find. I think on balance this is a substantial clean-up. I am happy to add whatever caveats and documentation people want to clarify what is going on here. I'm happy to look at future options where the devicetree is hosted elsewhere, so long as it is trivial to build it within U-Boot for development purposes. I'll also note that the bootstd series shows the devicetree source: Core: 246 devices, 88 uclasses, devicetree: board But for now, I still feel this is the best path forward. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On 12/2/21 16:58, 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 in another patch in this series: "doc: Add documentation about devicetree usage" 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. Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped. It also provides a few qemu clean-ups discovered along the way. The qemu-riscv64_spl problem is fixed. Distros like Ubuntu are provided as preinstalled images using U-Boot to launch Linux for usage with QEMU. A single image must be able to be usable in the future irrespective of the QEMU command line device configuration. This means that the devicetree coming from QEMU must be accurately parsed in U-Boot to setup the UEFI memory map. The number and type of CPUs and the NUMA configuration must be accurate. All devices enabled via the QEMU command line must be visible in the device-tree of Linux. Please, observe that information like number of CPU cores, number and type of block devices, namespace IDs used for NVMe drives, etc. cannot be available at build time. It this all guaranteed with this series? If not, this would unfortunately imply a NAK. Best regards Heinrich [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ Changes in v6: - Fix description of OF_BOARD so it refers just to the current state - Explain that the 'two devicetrees' refers to two *control* devicetrees - Expand the commit message based on comments - Expand the commit message based on comments Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu - Merge RISC-V and ARM patches since they are similar - Add new patches to clean up fdtdec_setup() and surrounds Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi François, On Thu, 2 Dec 2021 at 09:34, François Ozog wrote: > > Hi Simon > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : >> >> 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 in another patch in this >> series: "doc: Add documentation about devicetree usage" >> >> 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. >> >> Note: If board maintainers are able to add their own patch to add the >> files, some patches in this series can be dropped. >> >> It also provides a few qemu clean-ups discovered along the way. The >> qemu-riscv64_spl problem is fixed. >> >> [1] >> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ >> >> Changes in v6: >> - Fix description of OF_BOARD so it refers just to the current state >> - Explain that the 'two devicetrees' refers to two *control* devicetrees >> - Expand the commit message based on comments >> - Expand the commit message based on comments > > You haven’t addressed any concerns expressed on the mailing list.so I am not > in favor of this new version either. Please see the change log. I have addressed everything except the fundamental disagreement we have. > If you make a version without « fake DTs » as you name them, there are good > advances in the documentation and other areas that would be better in > mainline…. > If I am the only one thinking this way and the patch can be accepted, I would > love there is a warning in capital letters at the top of the DTS fake files > that explains the intent of this fake DT, the possible outcomes of not using > the one provided by the platform and the right way of dealing with DTs for > the platform. The word 'fake' applies to only three of the boards (highbank, bcm7xxx and octeontx), where I could not even figure out where to get a devicetree. One might think this would be a significant problem! Anyway yes I can add a comment to all the files, but please try to ask for everything at once as there is a cost to continually reworking this series. Regards, Simon >> >> >> Changes in v5: >> - Bring into the OF_BOARD series >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> - Refer to the 'control' DTB in the first paragraph >> - Use QEMU instead of qemu >> - Merge RISC-V and ARM patches since they are similar >> - Add new patches to clean up fdtdec_setup() and surrounds >> >> Changes in v3: >> - Clarify the 'bug' refered to at the top >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> Changes in v2: >> - Fix typos per Sean (thank you!) and a few others >> - Add a 'Use of U-Boot /config node' section >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> - Explain that OF_BOARD will still work after these changes (in >> 'Once this bug is fixed...' paragraph) >> - Expand a bit on the reason why the 'Current situation' is bad >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> in 'To be clear, while U-Boot...' >> - Expand on why we should have rules for other projects in >> 'Devicetree in another project' >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> points raised on v1 >> - Add 'Why does U-Boot have its nodes and properties?' >> - Add 'Why not have two devicetrees?' >> >> Simon Glass (25): >> doc: Add documentation about devicetree usage >> arm: qemu: Mention -nographic in the docs >> arm: riscv: qemu: Explain how to extract the generated dt >> arm: qemu: Add a devicetree file for qemu_arm >> arm: qemu: Add a devicetree file for qemu_arm64 >>
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > Hi Simon > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > 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 in another patch in this > > series: "doc: Add documentation about devicetree usage" > > > > 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. > > > > Note: If board maintainers are able to add their own patch to add the > > files, some patches in this series can be dropped. > > > > It also provides a few qemu clean-ups discovered along the way. The > > qemu-riscv64_spl problem is fixed. > > > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > Changes in v6: > > - Fix description of OF_BOARD so it refers just to the current state > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > - Expand the commit message based on comments > > - Expand the commit message based on comments > > You haven’t addressed any concerns expressed on the mailing list.so I am > not in favor of this new version either. > If you make a version without « fake DTs » as you name them, there are good > advances in the documentation and other areas that would be better in > mainline…. > If I am the only one thinking this way and the patch can be accepted, I > would love there is a warning in capital letters at the top of the DTS fake > files that explains the intent of this fake DT, the possible outcomes of > not using the one provided by the platform and the right way of dealing > with DTs for the platform. This is the part that I too am still unhappy about. I do not want reference or fake or whatever device trees in the U-Boot source tree. We should be able to _remove_ the ones we have, that are not required, with doc/board/...rst explaining how to get / view one. Not adding more. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > 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 in another patch in this > series: "doc: Add documentation about devicetree usage" > > 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. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. The > qemu-riscv64_spl problem is fixed. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > Changes in v6: > - Fix description of OF_BOARD so it refers just to the current state > - Explain that the 'two devicetrees' refers to two *control* devicetrees > - Expand the commit message based on comments > - Expand the commit message based on comments You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either. If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline…. If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform. > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt:
[PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
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 in another patch in this series: "doc: Add documentation about devicetree usage" 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. Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped. It also provides a few qemu clean-ups discovered along the way. The qemu-riscv64_spl problem is fixed. [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ Changes in v6: - Fix description of OF_BOARD so it refers just to the current state - Explain that the 'two devicetrees' refers to two *control* devicetrees - Expand the commit message based on comments - Expand the commit message based on comments Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu - Merge RISC-V and ARM patches since they are similar - Add new patches to clean up fdtdec_setup() and surrounds Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD Makefile |3 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 + arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 + arch/arm/dts/qemu-arm64.dts| 381 + arch/arm/dts/xenguest-arm64.dts|
