On Fri, Jan 10, 2025 at 01:25:43PM +0530, Ayush Singh wrote: > > > On 10/01/25 09:56, David Gibson wrote: > > On Wed, Jan 08, 2025 at 10:47:19AM +0100, Herve Codina wrote: > > > Hi Ayush, > > > > > > On Wed, 8 Jan 2025 13:58:04 +0530 > > > Ayush Singh <ayush@xxxxxxxxxxxxxxx> wrote: > > > > > > ... > > > > > > > > I will experiment with adding support to dtc and see how things look. > > > > Hopefully, 2025 is the year of addon board support. > > > > > > > > > > Also one point different between fdtoverlay an runtime loading is > > > that runtime loading allows to set the target node of the overlay > > > at runtime. > > > > I'm not really sure what you mean by "runtime loading". Do you mean > > the kernel's implementation of loading dtbo overlays? > > > > While that is a different implementation from the one in fdtoverlay > > (AIUI), they're both working from the same dtb format. As we > > discovered attempting Ayush's proposal, it turns out that the dtbo > > simply doesn't have the information we need to correctly path > > substitutions; and it's not at all easy to add it. > > Ahh, I think there is a misunderstanding. `export-symbols` only seems to > support phandles, not paths. So no resizing involved. Oh, sorry, I was mixing this up with a different feature Ayush was working on. > It's closer to the phandle support in `__symbols__`, just local in scope. > > > > > So, the problem of the encoding format needs to be solved regardless > > of which implementation is actually processing the overlays. > > > > So there is no problem with the encoding format. > > The questions I have are more regarding weather `export-symbols` or > something close to it can be made part of spec instead of the custom linux > thing. > > > Ayush Singh > -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
