On Sat, Sep 18, 2021 at 03:27:40AM -0600, Simon Glass wrote: > Hi Tom, > > On Fri, 17 Sept 2021 at 11:42, Tom Rini <tr...@konsulko.com> wrote: > > > > On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 15 Sept 2021 at 07:35, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote: > > > > > > From: Simon Glass <s...@chromium.org> > > > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600 > > > > > > > > > > Hi Simon, > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis > > > > > > <mark.kette...@xs4all.nl> wrote: > > > > > > > > > > > > > > > From: Moiz Imtiaz <moizimti...@gmail.com> > > > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > Thanks for the reply. I already followed the steps mentioned in > > > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > > > > > > > > > > > > > >I wonder if rpi is not using the devicetree compiled with > > > > > > > > >U-Boot, but > > > > > > > > instead one provided by the earlier-stage firmware? > > > > > > > > > > > > > > > > Not sure, but seems like this is the case. I checked and there > > > > > > > > isn't any > > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. > > > > > > > > I tried to > > > > > > > > add the dtb and other dts dtsi > > > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files > > > > > > > > from the raspberry pi Linux and compile them with > > > > > > > > CONFIG_OF_SEPARATE and > > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the > > > > > > > > U-Boot and > > > > > > > > it would just give a blank screen*. I wonder why there isn't > > > > > > > > any device > > > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not > > > > > > > > supported by > > > > > > > > RPI4? > > > > > > > > > > > > > > The issue with the rpi4 is that the addresses of devices move > > > > > > > around > > > > > > > based on the version of the Raspberry Pi firmware you're using. > > > > > > > And > > > > > > > possibly on the amount of memory on the board as well. So U-Boot > > > > > > > pretty much has to use the device tree passed by the firmware > > > > > > > since > > > > > > > the device tree in the U-Boot tree would be wrong for many > > > > > > > combinations of firmware and hardware. > > > > > > > > > > > > > > Simon, this sort of thing is exactly the reason why I think the > > > > > > > idea > > > > > > > of having all U-Boot configuration information in a single device > > > > > > > tree > > > > > > > with the hardware description doesn't work everywhere. > > > > > > > > > > > > >From my reading of this thread, it rather reinforces the need to > > > > > > provide a way to give U-Boot the config it needs, in the devicetree. > > > > > > > > > > As long as that configuration is optional, yes, maybe. > > > > > > > > Lets be a little careful. We don't want to have two ways to provide the > > > > information for a given feature. But some configuration properties are > > > > certainly optional. > > > > > > > > > > It seems that rpi is actually OK in this regard. If you think about > > > > > > it, it would be pretty hopeless if first-stage firmware assumed that > > > > > > it could provide a devicetree to whatever is next. > > > > > > > > > > Not hopeless. If that device tree provides a hardware description > > > > > that is complete enough to boot Linux, it should be good enough to run > > > > > U-Boot. > > > > > > > > And keep in mind that one of those long stated goals is that the device > > > > tree for a platform lives physically on the platform and doesn't require > > > > being replaced entirely at run-time with a new/different device tree. > > > > > > > > > And yes, the Raspberry Pi has a nice way to load overlays to do > > > > > additional hardware configuration and support add-on hardware that > > > > > connects to the GPIO header on the Pi. Replicating all this in U-Boot > > > > > would make very little sense. > > > > > > > > Note that in U-Boot we do have functionality to figure out and apply DT > > > > overlays for a platform, and it's generic enough that platforms can > > > > plugin their logic to detect what overlays are appropriate. This is > > > > under CMD_EXTENSION. It's not appropriate for Pi as they did all of > > > > this in their in-house firmware instead of using U-Boot. > > > > > > > > > > For example, if U-Boot evolves to support more devices, they could > > > > > > not be supported. > > > > > > > > > > Unless the device in question has a mechanism to load device tree > > > > > overlays like the Pi, this would require a firmware update. > > > > > > > > In that CMD_EXTENSION is about updating the tree for the next stage, and > > > > not ourself, yes. But this is also the same problem that OSes have that > > > > lead to overlays, at least in part. But also why it's so hard to > > > > support a static device tree on hardware, and have an evolving kernel. > > > > I'm not sure there's many / any good examples of wholly static and also > > > > feature complete device trees and OSes today, on a recent / semi-recent > > > > piece of hardware. > > > > > > > > > In practice, the device tree provided by the firmware will have more > > > > > stuff than U-Boot will ever need though. Unless you're advocating > > > > > that U-Boot evolves into a full-fledged OS ;). > > > > > > > > > > > If UEFI is used, the devicetree would have no effect, since it > > > > > > doesn't > > > > > > support devicetree. > > > > > > > > > > That is not true. UEFI supports device trees just fine. All the > > > > > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER > > > > > support use device trees. The idea that UEFI implies ACPI is a > > > > > misconception. > > > > > > > > > > > So perhaps the only remaining issue is with qemu on ARM / Risc-V? > > > > > > > > > > Maybe somebody can add device tree overlay support to QEMU? > > > > > > > > Having gone through this thread, I wonder if U-Boot generating a device > > > > tree overlay (and also the keeping the source of it, before > > > > preprocessing if we can) isn't part of the solution here. Heinrich had > > > > suggested in another thread, and Simon had strongly disagreed with > > > > overlays being how we perhaps solve some portions of the overall "what > > > > should U-Boot require of the DT?" problem. I'm thinking that might be > > > > the right answer, in some cases. > > > > > > Note that my objection here is adding runtime to U-Boot. If the prior > > > stage wants to arrange things that way, it seems OK to me. In > > > particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot > > > tree to merge with what it generates. > > > > Right. I am talking about U-Boot applying an overlay to a provided by > > prior stage device tree. In the above example of Pi, the prior stage > > has an option already to apply an overlay before-hand, yes. But that's > > not going to be the case for all platforms. > > There is no need for the prior stage to apply an overlay though. It > just needs to provide the correct devicetree with the U-Boot > properties.
Well, it depends on what upstream is and how it handles things. The case where U-Boot is optional in the boot chain, like Pi, is perhaps more common than we would like to admit, and at least Pi, and possibly other cases also have a mechanism for applying overlays to the generated device tree, in order to pass it to the kernel (or, U-Boot). I'd almost say that if for no reason other than to make examples for vboot, and other things too, available on Pi (as nearly everyone has one in/on their desk), it's important to do so. It's the most common reference platform. > I'm going to send a binding for the config node upstream and see what happens. OK, please make sure to CC me, thanks! -- Tom
signature.asc
Description: PGP signature
