[PATCH] ARM: Allow MULTIPLATFORM to select XIP
Chris.Brandt at renesas.com
Fri Feb 19 05:49:38 PST 2016
On 19 Feb 2016, Arnd Bergmann wrote:
> In a different thread today, I was trying to come up with a way to
> reliably pick a PHYS_OFFSET value, and I think it can be done but it
> quickly gets ugly without extending the Kconfig language.
OK, I see that now (no idea how you guy weed through so many reflector emails)
> Also, the same problem exists in three areas:
> a) PHYS_OFFSET / DRAM_BASE
> b) XIP_PHYS_ADDR
> c) DEBUG_UART_VIRT/DEBUG_UART_PHYS
> The last one is already really ugly and by nature causes problems
> whenever someone enables DEBUG_LL and tries to boot a compressed
> kernel on a platform other than the one that was configured.
> XIP_PHYS_ADDR is probably the worst here, because the number does
> not just depend on the SoC family but the specific board configuration
> and could even change when you rearrange the partitions on your NOR
> flash (unless you enforce that the kernel has to start at the
> beginning of the ROM or some other fixed location).
> It would be nice to handle all three of the above in a similar manner,
> and I'm definitely open to a range of solutions for this, like
> - always allow turning XIP_KERNEL on for all configurations, and
> expect the user to know what they are doing (as your current
This method is the quickest and easiest (from a kbuild perspective), and I was going with the assumption that the less I modify, less likely I was to break something else.
> - allow turning on XIP_KERNEL as long as Kconfig can figure out that
> this has a chance of working on at least one platform (easy enough
> to implement, and similar to how we handle DEBUG_LL).
In the patch I was working on, if ARCH_MULTIPLATFORM was selected (which is the problem I'm trying to solve), you can only select XIP_KERNEL if 'MULTIPLATFORM_XIP_CAPABLE' is selected. At least then we could restrict the multiplatform platforms to ones that stand a chance of XIP booting (or at least have been known to boot at one point or another)
> - make XIP_KERNEL and DEBUG_LL depend on either CONFIG_EXPERT or
> a new "I know this breaks other platforms and I won't complain
> about that" flag.
A plausible deniability clause. Funny.
> - implement a Kconfig method to only allow XIP_KERNEL if exactly
> one platform is enable that supports it, or if all platforms
> use the exact same PHYS_OFFSET and XIP_PHYS_ADDR settings.
> Whether we want to enforce the same thing for DEBUG_LL is a
> separate matter once that infrastructure exists.
This last one would be my favorite.
It would be nice if you could turn a section of "config ARCH_xxx bool" options into "choice" single select with some magical dynamic #ifdef.
bool "Device A"
bool "Device B"
bool "Device C"
...but...this doesn't work:
arch/arm/mach-shmobile/Kconfig:51: unexpected 'endif' within choice block
arch/arm/mach-shmobile/Kconfig:131: unexpected 'endchoice' within if block
I need a:
__INLINE__ if XIP_KERNEL
Although...at some point I'd argue that you are trying to cater to a level of safety that is above and beyond XIP_KERNEL. There are probably multiple CONFIG options in the kernel that would break an XIP anyway.
A car with the best seat belts and airbags still won't help you if you drive it off a cliff.
More information about the linux-arm-kernel