From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marek.vasut@gmail.com>
Date: Sat, 5 Nov 2011 23:06:47 +0100
Subject: [U-Boot] [PATCH v2 1/3] image: Make image_get_fdt work like
	image_get_{ram_disk, kernel}
In-Reply-To: <20111105215302.789531893014@gemini.denx.de>
References: <1320164902-24190-1-git-send-email-swarren@nvidia.com>
	<CAPnjgZ0bbhvZ1VPwY=0y9YZJdf+EOBgyKKVPFuAkBqy2z4L3HA@mail.gmail.com>
	<20111105215302.789531893014@gemini.denx.de>
Message-ID: <201111052306.47844.marek.vasut@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

> Dear Simon Glass,
> 
> In message 
<CAPnjgZ0bbhvZ1VPwY=0y9YZJdf+EOBgyKKVPFuAkBqy2z4L3HA@mail.gmail.com> you wrote:
> > Just a quick Q. What is the ultimate intent here? Should we be aiming
> > to have U-Boot copy and decompress the data into RAM ready for Linux?
> 
> Yes.
> 
> Rigth from the beginning of PPCBoot / U-Boot we designed it that
> U-Boot would do all needed steps to verify, load and uncompress an
> image.  It make no sense to attach the uncompression and loading code
> to each and every image, and to download it and store it again and
> again and again.  This works really well for example on Power, only
> ARM is one of the examples where the PTB never bothered to acquaint
> themself with ideas that went beyond the capabilities of Blob or
> similar boot loaders.

Right, there's no negotiation between linux and uboot on this topic. I think 
this is going on for ages now.

> 
> > In theory this should be slightly faster since U-Boot already has the
> > data in its cache. I think zImage now supports having an FDT inside
> > but what is the advantage of zImage over a uImage with compressed
> > portions?
> 
> There is none.  Also, there is no advantage in attaching the DT blob
> to the Linux image/. This is only of use to braindead boot loaders.
> 
> Best regards,
> 
> Wolfgang Denk