Re: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages
Hi Grant, I put U-Boot ML on CC.
On Wed, 2009-12-30 at 16:02 -0700, Grant Likely wrote:
On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser ptyser@xes-inc.com wrote:
The PowerPC architecture has the ability to embed the ramdisk located at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image. If the bootable kernel is in the Flattened Image Tree (FIT) format, the ramdisk should be a node in the tree instead of being embedded directly in the kernel executable.
A FIT uImage with a ram filesystem can be generated using the command: "make uImage.fit.initrd.<boardname>" where <boardname> is one of arch/powerpc/boot/dts/<boardname>.dts. The command will generate a FIT uImage at arch/powerpc/boot/uImage.fit.initrd.<boardname> that contains a kernel image, device tree blob, and a ram filesystem.
The ramdisk at arch/powerpc/boot/ramdisk.image.gz can either be an older style "ramdisk" or a newer "ramfs" gzipped cpio archive.
Signed-off-by: Peter Tyser ptyser@xes-inc.com
Changes since v1:
- Don't strip leading 0x from dts ramdisk address
arch/powerpc/boot/Makefile | 3 +++ arch/powerpc/boot/wrapper | 20 ++++++++++++++++---- scripts/mkits.sh | 34 ++++++++++++++++++++++++++++++++-- 3 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index e56ec21..c2a6591 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -313,6 +313,9 @@ $(obj)/uImage: vmlinux $(wrapperbits) $(obj)/uImage.fit.%: vmlinux $(obj)/%.dtb $(wrapperbits) $(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb)
+$(obj)/uImage.fit.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,uboot.fit,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the Makefile so that make behaves more consistently.
Makes sense.
Speaking of which, the number of '.' in the name is getting rather large. Would you consider using 'fitImage' instead of 'uImage.fit'?
Sure, I don't have a strong opinion about the name. I settled on uImage.fit because all the U-Boot documentation describes the FIT images as type of uImage. Eg the readme is located in doc/uImage.fit, its referred to as the "new uImage" format, etc. So using the "uimage.fit.*" name goes along with the concept that a FIT image is a type of uImage. A target like fitImage loses the uImage<->FIT connection.
But I do agree that "."s are a bit overwhelming. I could rework these patches with your suggested fitImage target name and follow-up with U-Boot patches to clear up its documentation. In my opinion, there's not much reason to keep the uImage<->FIT connection that currently exists in U-Boot. Right now U-Boot documents the "Legacy uImage" and "FIT uImage" format when logically it would make sense to rename the formats to "uImage" and "FIT" as there isn't much in common between the 2 formats. The FIT image is just a blob generated by the device tree compiler, its not tied to U-Boot in any way.
Does anyone in the U-Boot community have an opinion about this? I'm fine with keeping the uImage.fit naming or using fitImage for this patch, but I think U-Boot's documentation should be on the same page either way.
Thanks for the review, Peter
On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser ptyser@xes-inc.com wrote:
Hi Grant, I put U-Boot ML on CC.
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.
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 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.
g.
On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser ptyser@xes-inc.com wrote:
Hi Grant, I put U-Boot ML on CC.
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'm not aware of any recommendations as far as what FIT images should contain and there isn't a requirement that it should contain a .dtb image - its just a flexible image format.
I believe in the most common FIT usage scenario the image would contain both a kernel image and .dtb file though. For example, most people I deal with just have boardX and boardY that they want to boot Linux on.
Currently they have to make a "legacy" uImage, manually run the device tree compiler with the proper flags to generate a board-specific .dtb file, transfer the uImage to to boardX, transfer the .dtb file to boardX, set some U-Boot variables, then boot to Linux. For boardY they would have to redo the steps with the exception of recreating the legacy uImage. (To add to the confusion, the format of device trees is a somewhat moving target, so .dtb files aren't always compatible with different kernel versions.)
The FIT+.dtb patches I sent make it so the same process is shortened to: make a FIT image for boardX which contains a .dtb, download it to boardX, and boot it. Then repeat the same steps for boardY.
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 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.
I see your point. The main goal of the patch was to introduce FIT image support as its the new, more flexible, "better", standard image format for U-Boot going forward. Also, lots people aren't aware of FIT images and the cool stuff they can do with them, so what better way to get the word out than getting support for FIT images included in the kernel proper:)
I think it would be nice to generate a FIT image that contained the kernel + .dtb as it significantly simplifies the process of booting Linux for the common case for lots of U-Boot users and showcases one of the benefits of the FIT format. If you'd prefer not to have this portion of the patch included, I can respin so that the FIT image created only contains a kernel image, not a .dtb or initramfs. Or I could make targets of fitImage (no dtb included), fitImage.<board> (dtb included), and fitImage.initrd.<board> (dtb and initramfs included). Either way is fine with me, it'd just be nice to see FIT support get in in some form.
Thanks, Peter
Hi Peter,
On Wed, Dec 30, 2009 at 6:10 PM, Peter Tyser ptyser@xes-inc.com wrote:
On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser ptyser@xes-inc.com wrote:
Hi Grant, I put U-Boot ML on CC.
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'm not aware of any recommendations as far as what FIT images should contain and there isn't a requirement that it should contain a .dtb image - its just a flexible image format.
I believe in the most common FIT usage scenario the image would contain both a kernel image and .dtb file though. For example, most people I deal with just have boardX and boardY that they want to boot Linux on.
Currently they have to make a "legacy" uImage, manually run the device tree compiler with the proper flags to generate a board-specific .dtb file,
... or put the .dts files into arch/powerpc/boot/dts and use 'make <board>.dtb'
multiple <board>.dtb targets can also be added to CONFIG_EXTRA_TARGETS so that a plain 'make' will build all needed files.
transfer the uImage to to boardX, transfer the .dtb file to boardX, set some U-Boot variables, then boot to Linux. For boardY they would have to redo the steps with the exception of recreating the legacy uImage. (To add to the confusion, the format of device trees is a somewhat moving target, so .dtb files aren't always compatible with different kernel versions.)
The are no guarantees that new dtb files will work with old kernels, but old dtb files should continue to work with new kernels. There have been growing pains in this regard, and there are a number of examples where this hasn't been the case especially as we were learning how best to use the device tree. It is a lot more stable now than it had been and new cases can be considered a kernel bug.
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 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.
I see your point. The main goal of the patch was to introduce FIT image support as its the new, more flexible, "better", standard image format for U-Boot going forward. Also, lots people aren't aware of FIT images and the cool stuff they can do with them, so what better way to get the word out than getting support for FIT images included in the kernel proper:)
Define 'better'. :-)
I do understand your use-case and what problem fit images solve for you. However, from a "long term strategy" point of view it is a use case that I'm not interested in actively supporting for two reasons. The first is that I think it is in our best interest to encourage the mind set that the hardware description is separate from the operating system image, and so they should be stored and updated separately. I look at the unexpected ecosystem of distributions that has sprung up around wireless routers (ie OpenWRT and the like) and Linux cell phones (ie. Cyanogen Mod) where there is a huge range of hardware. The userspace can pretty much run on any of them excepting minor configuration changes. The embedded space is becoming more PCs in this regard, and I know that multiplatform is a big deal for some of the users. I'm not interested in encouraging any behaviour that will scuttle deployment of multiplatform kernels. (That being said, I'm not going to actively sabotage people who want to put dtb sections into the kernel images either. I understand that at times it is necessary, and there are numerous examples of this already in the kernel tree; specifically to support firmware that doesn't implement arch/powerpc's boot interface)
The second is that I no longer think it is a good idea to be building bootloader specific image fomats if we can help it. U-Boot is not the only game bootloaders, especially when talking about ARM or MIPS, and some folks are even using kexec to go from one kernel to the next. Having the same image format for all firmware and also kexec is far more interesting to me than the a new u-boot format. Some form of zImage seems to be a more likely format to standardize around than the FIT format, mostly because kexec and a lot of firmware already understand zImages, and it doesn't require firmware to link in libfdt.
I think it would be nice to generate a FIT image that contained the kernel + .dtb as it significantly simplifies the process of booting Linux for the common case for lots of U-Boot users and showcases one of the benefits of the FIT format. If you'd prefer not to have this portion of the patch included, I can respin so that the FIT image created only contains a kernel image, not a .dtb or initramfs. Or I could make targets of fitImage (no dtb included), fitImage.<board> (dtb included), and fitImage.initrd.<board> (dtb and initramfs included). Either way is fine with me, it'd just be nice to see FIT support get in in some form.
I'd be okay (perhaps not happy, but okay) with merging fitImage and fitImage.initrd targets (no dtb). I will resist merging fitImage.% and fitImage.initrd.% targets because I see that very much as a project specific deployment target and I'm not convinced yet that it the pattern is right or that it is even needed in the kernel at all.
Cheers, g.
Dear Grant Likely,
In message fa686aa41001022108i92596d6qdf2da0e24c34767e@mail.gmail.com you wrote:
Currently they have to make a "legacy" uImage, manually run the device tree compiler with the proper flags to generate a board-specific .dtb file,
... or put the .dts files into arch/powerpc/boot/dts and use 'make <board>.= dtb'
multiple <board>.dtb targets can also be added to CONFIG_EXTRA_TARGETS so that a plain 'make' will build all needed files.
Note that the FIT image can also be made to contain a number of DT blobs, and selection of a "board profile" then can be used to boot the very sane FIT image file on any of the supported boards - so FIT images inherently support multibooting.
I see your point. The main goal of the patch was to introduce FIT image support as its the new, more flexible, "better", standard image format for U-Boot going forward. Also, lots people aren't aware of FIT images and the cool stuff they can do with them, so what better way to get the word out than getting support for FIT images included in the kernel proper:)
Define 'better'. :-)
FIT images are better than the old uImage format because they:
- allow for strong checksum algorithms like MD5, SHA1, ... (the plain CRC32 method is not good enough if you for example want to run software in a slot machine in Las Vegas).
- can combine multiple kernel images, device tree blobs and root file system images in arbitrary combinations; this allows for example for multibooting the same image on different boards by selecting the right DTB, for software updates with automatic fall-back, etc.
- can be extended to add new features, images types or whatever in a standard way, using a standard technology (device tree support) which is already present anyway, i. e. without additional code overhead.
I do understand your use-case and what problem fit images solve for you. However, from a "long term strategy" point of view it is a use case that I'm not interested in actively supporting for two reasons. The first is that I think it is in our best interest to encourage the mind set that the hardware description is separate from the operating system image, and so they should be stored and updated separately. I
How do you boot systems over network, then? Normally you always download only a single image file.
How do you explain this to system vendors? They have a very reasonable request to offer only one image file to their customers.
look at the unexpected ecosystem of distributions that has sprung up around wireless routers (ie OpenWRT and the like) and Linux cell phones (ie. Cyanogen Mod) where there is a huge range of hardware. The userspace can pretty much run on any of them excepting minor configuration changes. The embedded space is becoming more PCs in
Right. So let's be able to provide kernel images that fit intot he same pattern - that can be used on a range of platforms, for example by embedding multiple DTBs.
Requesting that we manage a kernel mage plus a collection of DTBs and that eveybody has to install the only working correctly combination seems to be a bad idea to me.
this regard, and I know that multiplatform is a big deal for some of the users. I'm not interested in encouraging any behaviour that will scuttle deployment of multiplatform kernels. (That being said, I'm
You misunderstand. FIT images do not scuttle multiplatform kernels. Instead they support this much better, as they allow to bundle the repsective DTBs into one image file.
not going to actively sabotage people who want to put dtb sections into the kernel images either. I understand that at times it is necessary, and there are numerous examples of this already in the kernel tree; specifically to support firmware that doesn't implement arch/powerpc's boot interface)
Even if the boot loader supports it, it is usually pretty benefical (especially during development) if you can do this.
I'd be okay (perhaps not happy, but okay) with merging fitImage and fitImage.initrd targets (no dtb). I will resist merging fitImage.% and fitImage.initrd.% targets because I see that very much as a project specific deployment target and I'm not convinced yet that it the pattern is right or that it is even needed in the kernel at all.
Is this just your personal opinion, or do you think that this is really what a majority of kernel developers and users are wanting?
Speaking for myself, I have to admit that I don't understand and don't share this attitude.
Best regards,
Wolfgang Denk
<snip>
Note that the FIT image can also be made to contain a number of DT blobs, and selection of a "board profile" then can be used to boot the very sane FIT image file on any of the supported boards - so FIT images inherently support multibooting.
I agree with Wolfgang. Additionally, if a FIT image does contain a .dtb file, firmware can ignore it and load a different .dtb file. So for the fitImage.<boardname> target you could think of it as including a "default/fallback" .dtb file, not a mandatory one. So the FIT image could still be used as a multiplatform image even if it contained dtbs.
I see your point. The main goal of the patch was to introduce FIT image support as its the new, more flexible, "better", standard image format for U-Boot going forward. Also, lots people aren't aware of FIT images and the cool stuff they can do with them, so what better way to get the word out than getting support for FIT images included in the kernel proper:)
Define 'better'. :-)
FIT images are better than the old uImage format because they:
allow for strong checksum algorithms like MD5, SHA1, ... (the plain CRC32 method is not good enough if you for example want to run software in a slot machine in Las Vegas).
can combine multiple kernel images, device tree blobs and root file system images in arbitrary combinations; this allows for example for multibooting the same image on different boards by selecting the right DTB, for software updates with automatic fall-back, etc.
can be extended to add new features, images types or whatever in a standard way, using a standard technology (device tree support) which is already present anyway, i. e. without additional code overhead.
Other advantages of FIT images that I see day-to-day include: - Adding meta-data such as timestamps and version information for each component of the FIT image. Its great to be able to easily display the contents of a FIT image to determine which kernel versions it contains, etc.
- Embed multiple OS/dtb images in one FIT image. As a board vendor its nice to give a customer 1 image that has example dtb(s) and Linux, VxWorks, QNX, diagnostic, etc kernels. They can boot a number of OSes on a number of different boards with 1 image.
- You can extract the images contained in a FIT image using 'dtc' to convert the FIT image to a ".dts" file that has the raw image contents. Other image formats are more difficult to extract contents from.
<snip>
I'd be okay (perhaps not happy, but okay) with merging fitImage and fitImage.initrd targets (no dtb). I will resist merging fitImage.% and fitImage.initrd.% targets because I see that very much as a project specific deployment target and I'm not convinced yet that it the pattern is right or that it is even needed in the kernel at all.
Is this just your personal opinion, or do you think that this is really what a majority of kernel developers and users are wanting?
Speaking for myself, I have to admit that I don't understand and don't share this attitude.
I agree with Wolfgang that many people would find the combined kernel/dtb/ramfs useful, but understand Grant's reservations. Assuming I rework the patch to include a "fitImage" (no dtb) target, for the users that basic multiplatform images are important to, they could build this kernel-only FIT image. For people such as Wolfgang, Peter, and myself who would like to bundle a kernel + dtb(s), we could use the fitImage.<boardname> target. Wouldn't both parties be happy then? I could make the FIT documentation explain the benefits of multiplatform images or warn about the combined kernel/dtb FIT images if that made a difference too.
Best, Peter
On Sun, Jan 3, 2010 at 3:10 AM, Wolfgang Denk wd@denx.de wrote:
Dear Grant Likely,
In message fa686aa41001022108i92596d6qdf2da0e24c34767e@mail.gmail.com you wrote:
Note that the FIT image can also be made to contain a number of DT blobs, and selection of a "board profile" then can be used to boot the very sane FIT image file on any of the supported boards - so FIT images inherently support multibooting.
I see your point. The main goal of the patch was to introduce FIT image support as its the new, more flexible, "better", standard image format for U-Boot going forward. Also, lots people aren't aware of FIT images and the cool stuff they can do with them, so what better way to get the word out than getting support for FIT images included in the kernel proper:)
Define 'better'. :-)
FIT images are better than the old uImage format because they:
- allow for strong checksum algorithms like MD5, SHA1, ... (the plain
CRC32 method is not good enough if you for example want to run software in a slot machine in Las Vegas).
- can combine multiple kernel images, device tree blobs and root file
system images in arbitrary combinations; this allows for example for multibooting the same image on different boards by selecting the right DTB, for software updates with automatic fall-back, etc.
- can be extended to add new features, images types or whatever in a
standard way, using a standard technology (device tree support) which is already present anyway, i. e. without additional code overhead.
That's a lot of variability. More on this at the end of my email...
this regard, and I know that multiplatform is a big deal for some of the users. I'm not interested in encouraging any behaviour that will scuttle deployment of multiplatform kernels. (That being said, I'm
You misunderstand. FIT images do not scuttle multiplatform kernels. Instead they support this much better, as they allow to bundle the repsective DTBs into one image file.
I believe I do understand. The problem with this model is that it makes the assumption that the kernel image builder has access to ahead of time the full set of bootable platforms. That assumption doesn't hold anymore for a lot of markets where many vendors use the same SoC in slightly different ways. I think hardware vendors should be encouraged to manage dtb blobs separately from the kernel so that we can get out of the current paradigm of only supporting boards we know about.
Practical example: Ubuntu on ARM netbooks. Ubuntu is really not interested in generating new kernel images every time a vendor releases a new or modified piece of hardware.
If a vendor still decides that they want a kernel+dtb image then fine; but I don't think it does the Linux ecosystem any favors to make it the default choice.
not going to actively sabotage people who want to put dtb sections into the kernel images either. I understand that at times it is necessary, and there are numerous examples of this already in the kernel tree; specifically to support firmware that doesn't implement arch/powerpc's boot interface)
Even if the boot loader supports it, it is usually pretty benefical (especially during development) if you can do this.
Nothing prevents using a custom install script to wrap up a custom fit image when copying it into the tftp directory (or wherever).
I'd be okay (perhaps not happy, but okay) with merging fitImage and fitImage.initrd targets (no dtb). I will resist merging fitImage.% and fitImage.initrd.% targets because I see that very much as a project specific deployment target and I'm not convinced yet that it the pattern is right or that it is even needed in the kernel at all.
Is this just your personal opinion, or do you think that this is really what a majority of kernel developers and users are wanting?
I've stated my opinion, my reasons for it, and what I'm willing to merge. However, I'm not the only PowerPC maintainer and the others may disagree. While I don't particularly like the fit image format, it won't stop me from merging fitImage and fitImage.initrd patches.
I will not merge fitImage.% and fitImage.initrd.% targets because of the variability I commented on above. As you mentioned, there is a huge amount of flexability in what sections are placed into a fit image, such as carrying multiple dtb blobs. However, a fitImage.% pattern can only express a very specific subset (one kernel image + one dtb image). I do not want to codify a particular pattern into the build system when it seems quite apparent that make targets are nowhere near expressive enough to do what you're talking about with fit images. As is, the targets with embedded .dtbs are already rife with special cases and other nastiness.
So, I choose to punt it out of the kernel. If you want to build fit images beyond just containing an kernel image, then use a custom install or postprocessing script to assemble the vmlinux, dtb and initrd building blocks into the image you need.
g.
"Grant" == Grant Likely grant.likely@secretlab.ca writes:
Hi,
Grant> Personally, I don't get any benefit out of the new image format, Grant> so I haven't spent any time looking at it. However, I'm Grant> concerned about the drift back towards a different image per Grant> target when the move over the last 4 years has been towards Grant> multiplatform kernel images. I certainly don't want to Grant> encourage embedding the device tree blob into the kernel image, Grant> and I'm not very interested in merging code to do that into the Grant> kernel tree. If someone really needs to do that for their Grant> particular target, it is certainly easy enough for them to weld Grant> in the .dtb after the fact before transferring the image to the Grant> target, but I want that mode to be the exception, not the rule.
I understand the advantages of being able to compile multiplatform kernels - But for the typical embedded device, having the device tree together with the kernel makes stuff a lot simpler when upgrading because of the version depencies of the dts.
That's also why I submitted the (nacked) multifile uimage support some time ago:
http://thread.gmane.org/gmane.linux.ports.ppc64.devel/46825/
The fitimage stuff is the logical continuation of that.
Dear Grant,
In message fa686aa40912301601s6cd0ec4y85b88976159a36af@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.
Best regards,
Wolfgang Denk
On Fri, Jan 1, 2010 at 7:12 AM, Wolfgang Denk wd@denx.de wrote:
Dear Grant,
In message fa686aa40912301601s6cd0ec4y85b88976159a36af@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.
Dear Grant Likely,
In message fa686aa41001022118w6b41765ld145c646bfca9423@mail.gmail.com you wrote:
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.
But by blocking the addition of such a make target you do actively prevent this, don;t you?
Best regards,
Wolfgang Denk
participants (4)
-
Grant Likely -
Peter Korsgaard -
Peter Tyser -
Wolfgang Denk