public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: marek.vasut@gmail•com (Marek Vasut)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload
Date: Mon, 12 Mar 2012 18:42:59 +0100	[thread overview]
Message-ID: <201203121843.00025.marek.vasut@gmail.com> (raw)
In-Reply-To: <20120229205901.GR14173@pengutronix.de>

Dear Uwe Kleine-K?nig,

> On Wed, Feb 29, 2012 at 08:45:27PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 29, 2012 at 09:39:58PM +0100, Uwe Kleine-K?nig wrote:
> > > I'd bet your platform has cache support in the decompressor without
> > > knowing which platform you use. I suggest commenting out
> > > 
> > > 	bl	cache_on
> > > 
> > > in arch/arm/boot/compressed/head.S to see the difference.
> > > 
> > > How do you build the uImage containing the zImage? If you use the
> > > 
> > > in-kernel uImage target booting that usually means:
> > > 	- move the zImage to ZRELADDR
> > > 	- jump into zImage
> > > 	- decompress zImage to somewhere else
> > > 	- move decompressed image to ZRELADDR
> > > 	- jump to ZRELADDR
> > > 
> > > That is you have two relocations because the first location for sure
> > > conflicts with the decompressed image.
> > 
> > Actually, we do this slightly differently nowadays.  Inside zImage:
> > 	- if zImage location conflicts, move the decompressed data
> 
> s/de//
> 
> > 	  and decompressor to another location
> > 	
> > 	- decompress zImage to ZRELADDR
> > 	- jump to ZRELADDR
> > 
> > That reduces the size required for copying.  Of course, that copy can
> > (as it's always been the case) be totally eliminated by ensuring that
> > you load the zImage out of the way of the decompressed image.
> > 
> > So, really, comparing a standard uImage produced by the standard kernel
> > with gzipped Image is far from a fair comparison.  And that's actually
> > another argument for getting rid of the uImage target... it may make
> > people think a bit about what they're doing rather than accepting
> > whatever default location someone else chose for their kernel.
> 
> I'm all in favour to remove the uImage target because back in 2007 we
> already had a similar discussion[1]. (Back then I still thought that
> improving the uImage support would be a good idea.)
> 
> That said I think *in general* having support for U-Boot in the kernel
> is fine because I think U-Boot is the bootloader used most. But if you
> need some Kconfig settings or more than one Makefile target I think just
> building an Image or zImage and doing the U-Boot wrapping without the
> help of Linux' build system is preferable.

I believe eventually everyone will converge to having this option enabled. 
Therefore this config option will just be always on and can be squashed away.

> 
> Best regards
> Uwe
> 
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/36547/focus=36588

Best regards,
Marek Vasut

  parent reply	other threads:[~2012-03-12 17:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-29  0:03 [PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload Stephen Warren
2012-02-29  0:03 ` [PATCH 2/2] ARM: tegra: Add zreladdr etc to Makefile.boot for Tegra30 Stephen Warren
2012-02-29 12:29 ` [PATCH 1/2] ARM: Add Kconfig option to use mkimage -T kernel_noload Jean-Christophe PLAGNIOL-VILLARD
2012-02-29 16:58   ` Stephen Warren
2012-02-29 18:14     ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-29 18:33       ` Tim Bird
2012-02-29 18:50         ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 17:40           ` Marek Vasut
2012-03-12 17:44             ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-29 19:12         ` Uwe Kleine-König
2012-02-29 19:17           ` Stephen Warren
2012-02-29 19:44             ` Uwe Kleine-König
2012-02-29 19:59               ` Stephen Warren
2012-02-29 20:12                 ` Andre Renaud
2012-02-29 20:16                   ` Stephen Warren
2012-02-29 20:19                   ` Russell King - ARM Linux
2012-02-29 20:25                     ` Andre Renaud
2012-02-29 20:29                       ` Russell King - ARM Linux
2012-02-29 20:39                       ` Uwe Kleine-König
2012-02-29 20:45                         ` Russell King - ARM Linux
2012-02-29 20:59                           ` Uwe Kleine-König
2012-03-01  4:55                             ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 17:42                             ` Marek Vasut [this message]
2012-02-29 21:27                           ` Stephen Warren
2012-02-29 22:28                             ` Andre Renaud
2012-02-29 20:30                   ` Uwe Kleine-König
2012-02-29 23:53               ` Ryan Mallon
2012-03-12 17:44                 ` Marek Vasut
2012-03-01 15:34               ` Mark Brown
2012-03-01 17:01 ` Stephen Warren
2012-03-05  4:21   ` Olof Johansson
2012-03-05 20:29   ` Nicolas Pitre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201203121843.00025.marek.vasut@gmail.com \
    --to=marek.vasut@gmail$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox