On Thu, 2009-02-26 at 11:52 +1100, David Gibson wrote: > If you're working exclusively with the flattened tree, then please use > libfdt as your parsing library. It's not used in the powerpc kernel > proper, because that's based on an expanded tree, but it is used in > the powerpc bootwrapper, see arch/powerpc/boot/libfdt. That's just a > copy of the upstream version that's part of the dtc tree. If ARM > starts using this as well we can move it to lib/ or some other > non-arch-specific location. > > If you need to extend libfdt, that's fine - but talk to me about > getting your extensions upstream. The whole idea is that it gets > extended to be the flat tree parsing library of choice.
I fully agree with this, that's the reason why we currently work on our specific platform for now. Concerning the change in the interface, that shouldn't have a big influence on any eventual future merge as the ppc/libfdt main branch is also using external iterator and is endian-aware. We'll keep that in mind anyway. > I don't entirely follow what you're doing here, but it sounds like it > might not be quite correct. The device tree should always (well, > nearly always) describe the hardware, *not* Linux or driver specific > information. Generally drivers will use the "compatible" property to > determine if a device tree node is relevant to them. I think there is a bit of misunderstanding here. Our initial goal is not to port the device-tree framework to ARM, even if it would be nice to do so. We face a specific issue on our range of devices which is to personalize them with device-specific and model-specific information, not board-specific. We realized that the device-tree format was well-suited for what we wanted to do, so we plan to use the device-tree *format*, not *framework*. Taking this into account, this is an opportunity to also parametrize some platform-devices using the same system, but we didn't initially planned to make a whole redesign of ARM platform-device initialization like the one which is done on PPC. Anyhow, any feedback on porting device-tree on some other architecture is welcomed and somehow we need to start somewhere. So even if what we do won't be portable/ported to be the next ARM standard it could be useful to iron-out any arch-dependencies on the system and give some momentum on the device-tree usage. > > The platform-device initialization order is given by device-tree order. > > This is not usually a good idea. Flattened device trees do have an > order, but for real OF trees, the tree order is not well defined, so > it's generally best not to use the order to control initialization, > but instead to use explicit content to control order, if it's > important. Good point. but as I said above we'll probably not rely too much on this anyway. > > Also we noticed the lack of type information in device-tree binary > > format (could be needed for exporting values to user-land through > > something like sysfs, to have human-readable integer values in scripts - > > also big-endian integers have to be converted). > > Yes, the device tree structure treats property values as "bag of > bytes". It's assumed that you need to know the binding for a given > node/property - which describes the format of the content - in order > to correctly interpret it. OK, I consider this to be a "feature" then ;). But that rules out any automated human-readable export of device-tree properties through something like sysfs though. Laurent GREGOIRE Embedded Software Engineering | TomTom | www.tomtom.com _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
