Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Thu, Mar 19, 2015 at 08:57:21PM +0000, Chris Brandt wrote:
> Eventually....I got it to boot.
> 
> I had to remove both CONFIG_HIGHMEM and CONFIG_SMP and then I could
> boot completely from ROM (which for me is external QSPI flash that
> is memory mapping into linear CPU space at address 0x18000000)

At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.

However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed
in its dependencies) and building with SMP=y without SMP_ON_UP, and
trying to run on UP hardware will definitely fail.

To put that another way:
1. SMP_ON_UP relies on being able to change the kernel text, which it
   can't do with an XIP kernel.
2. UP hardware requires either a SMP=n kernel _or_ SMP=SMP_ON_UP=y
   kernel.

> So, the total changes was:
> 
> 1. start with shmobile_defconfig
> 2. remove all architectures but RZ/A1 (ARCH_R7S72100)
> 3. remove !ARCH_MULTIPLATFORM from XIP_KERNEL's dependencies
> 4. modify  'select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL'  in PHYS_OFFSET
>    (because I need to be able to set PHYS_OFFSET)

I'm not sure what you mean by this.  We have:

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        depends on !ARM_PATCH_PHYS_VIRT

which is quite correct - PHYS_OFFSET depends on not having the phys
offset patching code enabled.  However, for an XIP kernel, you don't
want to have the phys offset patching code enabled, so you want
ARM_PATCH_PHYS_VIRT to be off.

Maybe you mean the "select ARM_PATCH_PHYS_VIRT" under ARCH_MULTIPLATFORM?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.