From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 5 Sep 2014 15:21:57 -0400 Subject: [U-Boot] Call for participation in the U-Boot Mini Summit 2014 In-Reply-To: References: <201409041701.55681.marex@denx.de> <1409932247.24184.200.camel@snotra.buserror.net> <201409051930.35133.marex@denx.de> <20140905175349.GK25506@bill-the-cat> Message-ID: <20140905192157.GL25506@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Sep 05, 2014 at 12:08:13PM -0600, Simon Glass wrote: > Hi Tom, > > On 5 September 2014 11:53, Tom Rini wrote: > > On Fri, Sep 05, 2014 at 07:30:35PM +0200, Marek Vasut wrote: > > > > [snip] > >> > It's easier to work with than fitImage. > >> > >> In which way? > > > > In most developer work flows at least zImage then uImage then fitImage > > are the easiest to work with, in that order, for ARM. For ARM64 Image > > in the next release will probably release uImage as the easiet to work > > with. > > > > fitImage seems useful in a lot of deployment scenarios. Having to craft > > up a good skeleton device tree in most cases is an annoying to overcome > > barrier for a development workflow. > > I wonder if we could easily address that by building in the > functionality to mkimage? For the common case of a kernel, FDT and > ramdisk I don't see why anyone needs to write a .its file. It's just > boilerplate. Maybe. Or at least add in an example that doesn't do any reloc to it AND make it clear that's what it does. Looking over my normally lost boilerplate its file, it's kernel_noload that doesn't relocate things around to the load/entry point so a generic example could be made. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: