On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote: > On Thu, 21 Feb 2013, Jason Gunthorpe wrote: > > > On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote: > > > > > So let's stop kidding ourselves and be coherent please: either we move > > > device specifics away from the kernel, or we keep them together. In > > > other words, the DT should ideally come preinstalled with the bootloader > > > on a given board/device for distros to not even have to care about it, > > > or we put that data back inside the kernel and dispense ourselves from > > > all the added DT overhead entirely. But an hybrid mixed solution like > > > FIT is IMHO the worst of both worlds and sending a wrong message. > > > > Just to thread jack a bit here.. > > > > We've been using DT on production embedded stuff sice about 2.6.20ish > > on PPC and now ARM. We treat the dtb as a kernel version specific > > file, much like an initrd and ensure that the kernel only ever boots > > with its proper dtb. This is based on experience that the dtbs change > > depending on the state of the drivers in the kernel, what gets > > mainlined and when, etc. > > For embedded appliance product you may do as you wish. Nobody will > interfere in the way you develop and support your own products (as long > as you honor the applicable licenses of course). I was specifically responding to your statement that 'a hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message.' We have been making good use of such an arrangement, and it is defintely not 'the wrong message' for certain applications. In fact, as I said, it is probably the *right* message for embedded users. Even if I was a distro user, the idea that my dt and kernel would be decoupled is very scary. Realize that today, my Kirkwood systems require a different DT for at least 3.7 and 3.8 kernels, and quite possibly different again for 3.9!! This will eventually settle on kirkwood, but I bet the same pattern will repeat on the next new SOC. I would have thought keeping the device tree data and kernel together is preferred for most cases as it is more inline with Documentation/stable_api_nonsense.txt. Making the DT a strong stable API boundary sounds really hard to me, and if the churn on ARM so far is indication, it may not be realistic.. > But here we're discussing ARM Linux distributions having to deal with > different hardware devices. It simply doesn't make sense to bundle > every hardware specific data with the kernel in that context. Distros already ship huge kernels with modules for every hardware out there. Shipping all the DTs as well doesn't seem like a problem. I am thinking something like /lib/device-tree/`uname -r`/... Where (taking a PC analog) the bootloader is told to grab: /boot/vmlinuz-3.9 /boot/initrd.img-3.9 /lib/device-tree/3.9/ti/omap/foo-bar-board The kernel build can be nice and uniform, while the distro can provide scripts/tools to bundle the kernel zimage, kernel modules, initramfs stuff and dtb into something bootable - be it FIT, uimage, bootz script, grub script or whatever. > > Embedding this stuff into the bootloader is *not* desirable for my > > embedded scenarios. We don't use FIT (or uboot) but we do the same > > thing: a single image is constructed with the proper dtb, kernel and > > initrd, and that is what the bootloader boots. > > No one is advocating to embed the DT stuff in the bootloader. The DTB > may be buggy and/or incomplete and being able to update it safely i.e. > independently from the bootloader is necessary. Sorry, what did you mean by: 'the DT should ideally come preinstalled with the bootloader on a given board/device' ? My point was simply that any scenario where the bootloader grabs a DTB that is not strongly associated with the kernel it is going to boot is not desirable. > > People making dev boards and distros for them certainly have different > > requirements, but we've decided that the single image approach is the > > best for appliance style products. > > Absolutely. And in your case, DT is not bringing any benefit over the > previous situation where everything was compiled into the kernel. I Strongly disagree, see my prior email to Russell. DT is a very big improvement over the old way of C coding the same data. Jason -- 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
