Steve Capper <steve.cap...@arm.com> writes: > Hi folks, > Adding Rob Herring to the thread, as he covers the DTB side in the Linux > kernel. > > From the distros side, I am terrified at the prospect of requiring > that dtbs be embedded into the distros as a pre-requisite for a board > to function. It would represent a combinatorial mess (many platforms, > many distros, many versions) that would just hurt everyone in the > long-term. Have I misunderstood the intent of this proposal?
In this proposal, I'm not requiring it. Now a more extreme version of the proposal would require that the OS provide the DT. The argument for this is that if EBBR doesn't require it, an OS may not provide it, and thus breakages may be experienced by the user. This is bad for 'just works', so force it. But my proposal is taking the middle ground of requiring the firmware to provide a DT, but also specifying a standard mechanism whereby an OS can provide a more up to date / matching DT. > > Cheers, > -- > Steve Capper > > From: Heinrich Schuchardt <heinrich.schucha...@canonical.com> > Date: Thursday, 2 May 2024 at 10:07 > To: Pere Garcia <pere.gar...@arm.com> > Cc: Humphreys, Jonathan <j-humphr...@ti.com>, > boot-architecture@lists.linaro.org <boot-architecture@lists.linaro.org>, > Vincent Stehle <vincent.ste...@arm.com> > Subject: Re: OS provided DT proposal > On 02.05.24 09:18, Pere Garcia wrote: >> Hi Jon, >> SystemReady IR owner here at ATG. May I ask, what would be the purpose >> of DTB provided by the OS? The primary function (not only one) of DTB >> from a SystemReady perspective is for the Platform (fw) advertise to the >> OS what's in there, there are other secondary functions and some >> vendors use DTB to store FW-only information or proprietary data >> structures that do not break the interoperability to OSes. >> Is such OS DTB containing platform information, or is this DTB >> containing data useful for the OS or meaningful to be originated from >> the OS ? can you please elaborate a bit? >> >> Thanks in advance, >> Pere > > Device-trees are a mixture of hardware description and operating > instructions for the kernel (e.g. baudrate of the UART, driver or host > operating mode of a USB port). > > Device-tree overlays may be needed for optional hardware (e.g. Raspberry > hats). > > Linux device-trees evolve over time. Full board support cannot be > expected with an outdated device-tree provided by firmware. Furthermore > both backward and forward incompatibilities occur from time to time. > > Using the device-tree matching the booted kernel typically provides the > best user experience. > > Best regards > > Heinrich > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
