On Thu, 21 Feb 2013, Jason Gunthorpe wrote: > On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote: > > 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. No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that for your embedded system. The "wrong message" here is to distribute multiple DTBs around, whether it is with FIT or on a distro install media. > Even if I was a distro user, the idea that my dt and kernel would be > decoupled is very scary. That was still the design goal for DT. > 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!! Understandable, given that Kirkwood is being ported to DT right now. But if DT had been used from the start when we introduced Kirkwood support to Linux back in 2008 you most likely wouldn't have to change the DTB on your board at all today. > This will eventually settle on kirkwood, but I bet the same pattern > will repeat on the next new SOC. Possible, although new SOCs do start with DT from the start which is much easier than trying to retrofit it to existing code without breaking things. And given that patterns emerge, there is no need to redesign new bindings for every 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.. The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). > Distros already ship huge kernels with modules for every hardware out > there. Shipping all the DTs as well doesn't seem like a problem. But it is! Even shipping multiple kernels _is_ a problem for them. Hence this multi-platform kernel effort. Otherwise why would we bother? According to your logic, distros could package and distribute BIOS updates for all the X86 systems out there. After all, if they did, they would guarantee even better support on the hardware they target and not have to carry those ACPI quirks in the kernel, no? Ask them if they find this idea rejoicing. You might be surprised. > 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 And what is the advantage over not having to carry all those files at all on your filesystem? > 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. Or they may simply not bother if the bootloader that comes with the hardware already does the right thing which is even better. > > > 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' > > ? When you acquire some hardware, it should come with a DTB and bootloader pre-installed, ready to boot any distribution (as long as its kernel supports the SoC of course). Your hardware vendor should offer DTB updates on its website. The DTB should not be compiled into the bootloader so DTB updates can be done independently from risky bootloader updates. Nicolas -- 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
