On Fri, Nov 09, 2012 at 09:36:26PM -0600, Joel A Fernandes wrote: > Hi Pantelis, > > On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou > <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > >>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, > >>>> and passes the resolved tree to the kernel. > >>>> > >>> > >>> Could be made to work. Only really required if Joanne wants the > >>> cape interface to work for u-boot too. For example if the cape has some > >>> kind of network interface that u-boot will use to boot from. > >>> > >> > >> I love Grant's hashing idea a lot keeping the phandle problem for > >> compile time and not requiring fixups. > >> > >> IMO it is still a cleaner approach if u-boot does the tree merging for > >> all cases, and not the kernel. > >> > >> That way from a development standpoint, very little or nothing will > >> have to be changed in kernel (except for scripts/dtc) considering we > >> are moving forward with hashing. > >> > >> Also this discussed a while back but at some point is going to brought > >> up again- loading of dt fragment directly from EEPROM and merging at > >> run time. If we were to implement this in kernel, we would have to add > >> cape specific EEPROM reading code, merge the tree before it is > >> unflattened and parse. I think doing tree merging in kernel is messy > >> and we should do it in uboot. Ideally reading the fragment from the > >> EEPROM for all capes and merging without worrying about version > >> detection, Doing the merge and passing the merged blob to the kernel > >> which (kernel) works the same way it does today. > > > > Not going to work, for a lot of cases. Doing it in the kernel seems to be > > the cleaner option. There are valid use cases for doing in u-boot too. > > True, if dynamic runtime stuff from userspace is what we're talking > about, then yeah I see the important need for kernel to do the merge. > > >> Alternatively to hashing, reading david gibsons paper I followed, > >> phandle is supposed to 'uniquely' identity node. I wonder why the node > >> name itself is not sufficient to unquiely identify. The code that does > >> the tree walking can then just strcmp the node name while it walks the > >> tree instead of having to find a node with a phandle number. I guess > >> the reason is phandles are small to store as data values. Another > >> approach can be to arrange the string block in alphabetical order > >> (unless it already is), and store phandle as index of the node name > >> referenced relative to the starting of the strong block. This will not > >> affect nodes in dtb being moved around since they will still have the > >> same index value. the problem being adding or removing nodes Changes > >> the offsets of all other nodes in the string block as well.. Hmm. > >> > > > > This is pretty radical change to the DT format, no? > > Yes, true and the only way hypothetically to replace the phandle > tree-walking mechanism is to store node paths instead of phandle which > David pointed is too long to store, so I guess this wont work after > all. Anyway this was an interesting exercise, thanks. They're not too long to store, but changing to paths would break years of existing OF practice. -- David Gibson | 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
