Toward a single kernel zImage for multiple ARM platforms

Status:
Needs a specification.

Work items for NN:
[eric.y.miao] make PHYS_OFFSET run-time: INPROGRESS
[npitre] make TEXT_OFFSET run-time: INVALID (not worth the effort)
[eric.y.miao] generic phys_to_virt() and virt_to_phys(): INPROGRESS
[npitre] allow multiple machdirs and platdirs to be built: TODO
[eric.y.miao] cleanup of machine specific header files: TODO
[eric.y.miao] investigate into virtual IRQ: DONE
[eric.y.miao] make NR_IRQs a run-time variable: INPROGRESS
[eric.y.miao] allow multiple run-time mapping to IRQ number: INPROGRESS
[eric.y.miao] Make ISA_DMA_THRESHOLD run-time: INPROGRESS
[eric.y.miao] Support multi-arch arch_adjust_zones(): INPROGRESS
[eric.y.miao] Support multi-arch compatible sparsemem: TODO
[eric.y.miao] Make MAX_DMA_CHANNELS run-time: INVALID (actually no need to make it run-time)
[eric.y.miao] Further generalize of GPIO API: TODO
[eric.y.miao] Make IO_SPACE_LIMIT constant across all arch: INPROGRESS
[eric.y.miao] Generalize definition of io() : TODO
[eric.y.miao] Generalize arch specific {in,out}{b,w,l}() : TODO
[eric.y.miao] Generalize arch_ioremap() and arch_iounmap(): TODO
[eric.y.miao] Make PCIBIOS_MIN_* variables run-time: TODO
[eric.y.miao] Make VMALLOC_END arch specific variable: TODO
[eric.y.miao] Generalize smp_cross_call() and hard_smp_processor_id(): TODO
[eric.y.miao] Generalize arch specific barriers : TODO

Work items for NN:
[npitre] fix symbol clashes, duplicatation: TODO

* The work item of common clock framework is removed and will be tracked in bp:arm-m-using-device-tree-on-arm.

Discussion Note:
(food for thoughts from Nicolas Pitre)

The following are prerequisites:

* Runtime determined PHYS_OFFSET.
  Patches exist but they impose a runtime overhead which can be totally
  eliminated with some runtime patching trickery.

* Removal of the machdirs and platdirs variables from the build system.
  This can be replaced with standard Kbuild syntax for directory inclusion,
  however some care is needed for proper -I argument to gcc.

* Fix the symbol clashes, duplicated defines with different values to make
  them runtime defined (but only if necessary -- keep the compile time ones
  otherwise), Etc.

* Manage different instruction set issues. The lowest common subset
  for different targets must be used, but some operations might require
  special handling (e.g. atomic ops on ARMv5 vs ARMv6K).

That's about it.

It should be noted that none of the above can be fixed by the device tree.
Hence DT is orthogonal to having a single kernel image for multiple targets
on ARM.

(additional food for thoughts from Eric Miao)

* eliminate the build-time TEXT_OFFSET, so the kernel header decompressor
knows where to put the kernel image at run-time

* a flexible phys_to_virt() and virt_to_phys() implementation without too
much performance degradation, while allow different memory layout (unlike
x86, different size of memories could be connected on multiple chip selects
whose address could be not contigous)

  ( Nico: IIRC you once suggested highmem for this? )

* the mapping to IRQ number during IRQ processing is currently hardcoded by
macro (for optimization purpose), and needs to be modified to allow mappings
of different IRQ controller

* eliminate the constant of total number of IRQ at build time, otherwise we
have to decide a maximum IRQ number and resulting in space waste.
  - sparse IRQ, now dynamic IRQ could a good fit here

* common clock framework, though we have struct clk and API, every machine
  class defines their own. Yet the clock framework needs to be flexible
  enough, otherwise won't be accepted by RMK

  - jk has done some work on this and could be a good start

* platform drivers move to depends on platform_device_id to support sharability
between different SoCs, instead of using cpu_is_xxx() or other vendor specific
ID registers, which is not guaranteed to work on all platforms

* there are still platform drivers using hardcoded constants for I/O memory
and IRQ number, these could be converted to using 'struct resource', which
needs board/SoC code to get them right

(eric.y.miao, 2010-05-25) Investigated into the virtual IRQ mechanism in
arch/powerpc. It looks to me like a generic framework for mapping hardware
status into the virtual IRQ number used by software. The PIC is normally
represented by 'struct irq_host' and a table is maintained for the mapping
of hardware IRQ irq_hw_number_t to the irq_host, and then translation is
done to get the virtual IRQ number. It has a close relationship to device
tree, where a device can just have a number (offset) of the IRQ within its
interrupt domain (or PIC) which in turn is represented by a device tree
node. This is flexible enough solution.

However, most ARM platforms choose a much simpler solution, and heavily
use chained IRQ handler to deal with such translation. Will stick to this
simple model at the moment not to make massive changes.

The issue of allowing multiple run-time mapping to IRQ number, however, is
not related to this virtual IRQ. The ppc_md.get_irq(), though is somehow a
very samiliar solution.