[PATCH 4/6] ARM: mxc: don't allow to compile together i.MX51 and i.MX53

[Nicolas Pitre]

On Sun, 8 May 2011, Russell King - ARM Linux wrote:

> On Wed, May 04, 2011 at 10:48:40AM -0500, Matt Sealey wrote:
> > CONFIG_ARM_PATCH_PHYS_VIRT
> > 
> > These two config options, with absolutely no bootloader changes, will
> > basically mask off some address (instruction pointer?) at the time of
> > the check and therefore derive a perfectly good PHYS_OFFSET at runtime
> > and make sure it is in use... within some limits (first 128MB, assumes
> > that start of memory is at some particular alignment)?
> 
> The V:P fixup will only handle bits 31-24, or 31-16 if the
> ARM_PATCH_PHYS_VIRT_16BIT option is selected (for MSM).  If the offset
> doesn't wholy fit into these, then the fixup function will complain and
> your kernel won't boot.  So, it'll go down to 64K alignment.
> 
> It does rely on the kernel being placed correctly in memory.  So if the
> start of the kernel text is built to be 32K above PAGE_OFFSET, then the
> kernel will assume that physical memory starts 32K below where the
> 'Image' ended up in physical memory.  If you place the kernel in physical
> memory 16MB above the start, then it'll assume that physical memory starts
> 16MB above where it actually did.

If CONFIG_AUTO_ZRELADDR is set, then zImage will automatically place the 
kernel Image correctly in memory, assuming that zImage is itself loaded 
within the first 128MB of memory.

> There is one thing to watch out for though - if you did place it 16MB
> above, but still tell the kernel via ATAGs that the physical memory
> starts where it really does, then I'd expect things to explode as
> the kernel direct mapped memory would likely extend below PAGE_OFFSET.

Yeah... We should probably add a warning and truncate the beginning of 
the memory bank in that case.  This would also prevent memory from being 
wrongly declared below PHYS_OFFSET even without the P2V feature enabled.


Nicolas