On Fri, 14 Oct 2011, Russell King - ARM Linux wrote:

On Fri, Oct 14, 2011 at 04:31:12PM -0400, Nicolas Pitre wrote:

quoted

On Fri, 14 Oct 2011, Russell King - ARM Linux wrote:

quoted

On Fri, Oct 14, 2011 at 04:14:12PM -0400, Nicolas Pitre wrote:

quoted

On Fri, 14 Oct 2011, Russell King - ARM Linux wrote:

quoted

On Fri, Oct 14, 2011 at 02:01:07PM -0400, Nicolas Pitre wrote:

quoted

The way I'm restructuring things around this is that AUTO_ZRELADDR will 
always be active by default, just like ARM_PATCH_PHYS_VIRT now.  This 
platform specific exclusion thinking is a step backward so I'd prefer if 
people would refrain from going there for the moment.

Are you expecting everyone to change the way they load the zImage
overnight then?

No, of course.  But adding restrictions in the kernel build because 
u-Boot's own image format dictates such restrictions doesn't make sense.  
Those restrictions must be pushed towards the uImage encapsulation step, 
not higher the kernel config hierarchy.

You're not understanding again.

I'm talking about people who _explicitly_ load the zImage at a different
address to which the decompressed image ends up.  With AUTO_ZRELADDR=y
their setup will break unless they stop that behaviour, which takes
away one of the advantages of using the zImage format.

Would you care to explain where you got this from?  Because I really do 
not understand what you're saying indeed.

My I point out that it's you who decided that I was talking about u-boot
when I said no such thing in my message.  I merely pointed out about
those people who may be loading the zImage elsewhere in memory and using
that facility to cut down on the boot time.  u-boot can't load zImages
directly.

Yet you started nattering on about uboot - which we know is a pile of
crap for dealing with this stuff.

OK, sorry for confusing matters.