From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Korsgaard Date: Thu, 31 Dec 2009 09:01:22 +0100 Subject: [U-Boot] [PATCH v2 3/3] powerpc: Add support for ram filesystems in FIT uImages In-Reply-To: (Grant Likely's message of "Wed, 30 Dec 2009 17:01:35 -0700") References: <1261446643-21714-1-git-send-email-ptyser@xes-inc.com> <1261446643-21714-4-git-send-email-ptyser@xes-inc.com> <1262216393.29396.41.camel@localhost.localdomain> Message-ID: <87skartvvx.fsf@macbook.be.48ers.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >>>>> "Grant" == Grant Likely 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. -- Bye, Peter Korsgaard