Hi, Conor, On Fri, Aug 25, 2023 at 8:01 PM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote: > > On Thu, Aug 24, 2023 at 11:20:34AM +0800, Binbin Zhou wrote: > > Hi Rob: > > > > On Thu, Aug 24, 2023 at 3:42 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > > On Wed, Aug 23, 2023 at 05:54:51PM +0800, Binbin Zhou wrote: > > > > Some systems do not provide a useful device tree to the kernel at boot > > > > time. Let's keep a device tree table in the kernel, keyed by the dts > > > > filename, containing the relevant DTBs. > > > > > > Support for this in other arches was added to support legacy bootloaders > > > with no DT support. You should not need this for a new architecture. Fix > > > the bootloader to provide a useful DT. > > > > > Yes, our bootloader already supports DT. > > > > Our original intention of providing kernel built-in DTS is to describe > > all possible device information of that SoC, so that everyone can use > > it as a reference during development; we will unlikely to add more > > .dts files to the kernel besides the reference ones. > > > > And as a reference, our built-in DTS provides the most basic bootable > > combinations (so it is generic enough) as an alternative in case the > > DTS in the bootloader is unexpected. > > > > Does this make any sense? > > I don't see how this answers the question - as far as I can tell Rob was > asking specifically about the building the dtb into the kernel, whereas > your response seems to talk about havint the dts files in the kernel > tree. I'm sorry, but from my point of view, giving users a chance to build the reference dts file into the kernel is not a bad idea. Of course the commit message can be improved. Huacai
