Ubuntu Wiki

• Launchpad Entry: kernel-maverick-arm-single-zimage

• Created: 2010-04-29

• Contributors: EricMiao, NicolasPitre

• Packages affected: kernel

Summary

We wish to provide the ability to build as many ARM platforms as possible into a single kernel binary image. This will greatly simplify the archive packaging and maintenance effort by having only one kernel that could be built and booted on multiple ARM targets.

Rationale

Unlike for X86, what we generally refer to when mentioning "ARM" is pretty eclectic. While ARM Ltd has defined and standardized the ARM instruction set, the ARM licensees (aka vendors i.e. those who actually produce chips) have integrated that technology into wildly different SOCs. Therefore, there isn't such thing as a "common ARM architecture" as we mean it when talking about the "X86 architecture".

Those different ARM vendors have used their own set of IP blocks around the ARM CPU core, such as timers, interrupt controllers, memory controllers, IO peripherals, etc. Even the MMU architecture has seen some variations between different vendors and different revisions of the ARM architecture. There is some on-going work at ARM Ltd to standardize more pieces of an ARM system into a common specification. But the ARM systems we have to deal with today come from different vendors with considerable differences, almost like different architectures when it comes to software support.

Due to the number of different ARM cores, and different ARM SoCs, it is currently not possible to build all ARM platforms into a generic kernel as can be done in the PC world. The ARM support in the Linux kernel is already structured to allow multiple machines based on the same SoC family to coexist in the same compiled binary. And to some extent, the support for multiple CPU flavours may also be compiled in and selected at run time. But the possible combinations still have significant limitations that require multiple kernel binaries to be separately configured and built to cover all the ARM platforms we want to support.

Lifting those limitations means we could have a single ARM kernel configuration, a single kernel build, and a single kernel package to carry in the Ubuntu distribution archive that would work for all the platforms we wish to support. This also means that fixes for generic kernel bugs and the associated kernel update would have to be carried only once instead of duplicating that work for each platform.

User stories

Bryan has implemented a new cool feature on Freescale i.MX51, and would like to verify that feature on other ARM platforms, such as Marvell Dove. Now he has to switch to another branch due to different config options, upload, wait for the package to be built. Install that to Marvell Dove platforms, and verify. Should there be a bug, now he also has to exclude the cause due to different branches. And later he found bug in the package, and fixed it for Dove, now he also has to provide a fix for i.MX51 as well. This will be difficult to manage when the number of platforms increases.

Assumptions

Design

What we already have:

• Structural directories (arch/arm/mach-*, arch/arm/plat-*).
• Support for platforms from the same ARM machine class can be built into the same kernel, and selected at run time through the machine_desc structure (see linux/arch/arm/include/asm/mach/arch.h).
• Multiple CPU core (MMU/TLB/cache) support can be built into the same kernel, and selected at run time through:
  • struc processor (linux/arch/arm/include/asm/cpu-multi32.h),
  • struct cpu_cache_fns (linux/arch/arm/include/asm/cacheflush.h), and
  • struct cpu_tlb_fns (linux/arch/arm/include/asm/tlbflush.h).
• irq_chip, gpio_chip, …
• platform_device for most other peripherals.

What needs to be done:

• Runtime determined PHYS_OFFSET (where physical memory starts).
• Runtime determined TEXT_OFFSET (where the kernel is placed)
• A unified and optimized virt_to_phys()/phys_to_virt() [Nico suggests sparsemem may have already supported this]
• Runtime selection of the appropriate hardware IRQ controller support.
• Removal of the build-time constant for total number of IRQs (NR_IRQS)
• Replacement of the machdirs and platdirs variables to allow multiple mach-* and plat-* directories to be built.
• Fix the symbol clashes between different machine classes, like duplicated defines with different values that would need to be runtime defined
• Multiple clk API implementation and runtime selection
• Handling of incompatible instruction set issues (maybe with runtime patching) [might be necessary for UP versus SMP]
• Other code abstraction and code re-structuring

Implementation

Test/Demo Plan

Find two or more platforms we are going to support, and have a single kernel booting on both(all) of them.

Unresolved issues

BoF agenda and discussion

(from UDS-M by DaveMartin)

Need to look at:

• runtime determination of {PHYS,TEXT}_OFFEST
• handing of virt_to_phys and phys_to_virt
  • sparsemem?
• IRQ numbering
  • solvable with sparseirqs and dynamic irqs?
• build system
  • no multiple machinedirs possible at the moment, this should be
    • selectable via Kconfig instead
• instruction set issues
  • dynamic patching?
• fixing symbol clashes
  • more of an effort of turning macros into variables
• clock API
  • expand on this at the DT session later today
• other code abstractions, code restructuring
  • on an as-needed basis

Action Items:

• [ericm] look at the powerpc virq infrastructure
• [martinbogo] various macro-reduction efforts
• [nico] physical offset and text offset patches
• [nico] boot interface specification for decompressed kernel placement

CategorySpec