Thread (18 messages) flat view 18 messages, 4 authors, 2016-02-23
STALE3821d

[PATCH] ARM: Allow MULTIPLATFORM to select XIP

From: Chris.Brandt@renesas.com (Chris Brandt)
Date: 2016-02-19 13:49:38

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
  patch)
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.

	Arnd
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.

if XIP_KERNEL
choice
endif

config DEVICE_A
	bool "Device A"

config DEVICE_B
	bool "Device B"

config DEVICE_C
	bool "Device C"

if XIP_KERNEL
endchoice
endif


...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
choice
endif




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.


Chris
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help