On Fri, Jan 1, 2010 at 7:12 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Grant, > > In message <fa686aa40912301601s6cd0ec4y85b88976159a3...@mail.gmail.com> you > wrote: >> >> Thinking further, I do actually have another concern, at least with >> regard to the way the current patch set implements things. Is it >> expected or even "recommended" that fit images will *always* contain a >> .dtb image? The current patch only handles the case of a .dtb >> embedded inside the fit image. > > I think this can be expected. > > Historically, the need to pass the dtb image to the Linux kernel, > too, was what actually triggered the development of the FIT image > format, as it turned out that the old image format with it's fixed > binary header was too inflexible. So bundling the kernel image and > the device tree blob into one image file is the specific use case > this image format was created for (which does not mean that other > usage would be impossible). > >> Personally, I don't get any benefit out of the new image format, so I >> haven't spent any time looking at it. However, I'm concerned about > > Assume you want to boot over DHCP or similar, where you can provide > just a single image file for download. Here it is definitely nice if > you can bundle the kernel image and the DTB into one image file. We > were able to extend the old so-called "multi-file" uImage format to > handle this situation, too, but it was clear that further extensions > were not really possible. > > We consider the old legace uImage format as something we want to move > away from, and the new FIT image format shall be the new default. > >> the drift back towards a different image per target when the move over >> the last 4 years has been towards multiplatform kernel images. I >> certainly don't want to encourage embedding the device tree blob into >> the kernel image, and I'm not very interested in merging code to do >> that into the kernel tree. If someone really needs to do that for >> their particular target, it is certainly easy enough for them to weld >> in the .dtb after the fact before transferring the image to the >> target, but I want that mode to be the exception, not the rule. > > This is specific for particular targets, but for specific modes of > operation, like booting over the network or other szenarios where > transferring a single image file is essential - another example where > we often see this request is upgrade procedures for devics, where the > vendor wants to be able to distribute a single file for his target > systems to avoid customers bricking their devices by chosing > incompatible combinations.
As I said in a previous email; I understand the need for certain scenarios, but in the general case it is not the mode that I think should be encouraged. I don't want to merge additional targets for .dtb embedded in the kernel image unless absolutely necessary, and I want developers to have the mindset that .dtbs should be separate from the kernel; and should be quasi-stable (or at least more stable than the kernel itself) because I think that multiplatform is important, and is going to become more important in the future. So I don't want to support it by default; but OTOH, I'm not going to actively prevent embedded .dtb blobs either. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
