Date: Fri, 21 Sep 2007 12:02:23 +0100 From: Matt Sealey <matt@genesi-usa.com> To: Rafal Jaworowski <raj@semihalf.com> Cc: freebsd-ppc@freebsd.org, grehan@freebsd.org Subject: Re: Cell port Message-ID: <46F3A4BF.7000705@genesi-usa.com> In-Reply-To: <46F39815.6060507@semihalf.com> References: <E79BC169-E7E8-4CA2-95E8-FC806777714E@decpp.net> <46DCD1DA.5090301@freebsd.org> <42C14314-D3EC-460E-97D9-53830FB9CBF6@decpp.net> <46E03D3E.8060504@freebsd.org> <46F28001.2030205@videotron.ca> <46F39815.6060507@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Rafal Jaworowski wrote: > Stephane E. Potvin wrote: >> >> It might be worthwhile for anybody attempting to port to a new >> architecture to look into adding support for something similar instead >> of removing the OF dependency. > > Having the flat device tree is not cheap, as one has to provide the > whole infrastructure, which is currently non-existent: > > - the dtc 'compiler' to produce binary out of textual description of the > device tree (the existing GPL-licensed could be used for quick start) Well, it's not exactly non-existent then is it? :) There would be a worry about introducing a GPL dependency in BSD code (after the Atheros stuff last month, even moreso) but in the end, the flattened device tree and the tool that generates it are not required for operation of the Operating System - the FDT should be presented by the firmware, and not ingrained into the OS tools. Consider the FDT/DTC a U-Boot problem and not a FreeBSD problem. > - in-kernel library of routines processing the device tree blob (node, > properties etc.) Since parsing a device tree is the same thing, regardless, and the specs for the Linux FDT are purposefully derived from the Open Firmware ones, there isn't much change here other than to be able to parse a FDT blob rather than using the Open Firmware Client Interface. > - loader(8) would need to be involved too (at least to pass the blob as > part of metadata or so). A curious question, how is this metadata structured? Can a binary blob be easily passed with few changes? Is anything even passed on OF platforms considering all the metadata (apart from the loader flags which would be required) is in fact in the device tree? > Introducing this is quite a big project for its own, and requires > dealing with OpenFirmware internals, binding definitions etc. as FDT > essentially mimics some part of it. Like I said above, leeching off the Linux device tree project is not a bad idea if you consider it more of a firmware issue than a Linux issue. Just what IS the licensing on a binary blob passed by firmware? If you create a device tree from GPLv2 code in the Linux tree and put it into your GPL U-Boot, does passing that code to FreeBSD cause a problem? By implementing a "new device tree standard" you completely throw away the advantages of a firmware device tree. Linux already made that stupid mistake by reimplementing a device tree and making it dependant on the Linux kernel and tools.. -- Matt Sealey <matt@genesi-usa.com> Genesi, Manager, Developer Relations
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46F3A4BF.7000705>