ARMSingleKernel

Revision 3 as of 2010-05-28 14:16:36

Clear message

Summary

We wish to provide the possibility of building as many ARM platforms as possible into a single kernel. This will greatly simplify the maintain effort, reduce package numbers, centralize the development activities, and improve code quality by avoiding duplication.

Rationale

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 comparing with PC. Sometimes multiple kernels have to be maintained for different platforms, and sometimes the same fixes/features have to be duplicated across platforms. Having a generic kernel for as many platforms as possible, we could possibly have a single kernel package, thus save the effort such as building, packaging, bug fixing, and so on. Having a generic kernel supporting multiple platforms also means less development duplications.

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:

  • A structural directory (mach-*, plat-*)
  • Now most platforms of a same ARM machine class can be built into a single kernel
  • machine_desc() for multiple machines
  • MUTLI_CPU (struct processor)
  • MULTI_CACHE (struct cpu_cache_fns)
  • MULTI_TLB (struct cpu_tlb_fns)
  • 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]
  • Eliminate hardcoded mapping of IRQ HW status to IRQ number
  • Eliminate the constant of total number of IRQs (NR_IRQS)
  • Removal of the machdirs and platdirs variables from the build system
  • Manage different instruction set issues [possible but not high priority work item]
  • Fix the symbol clashes, duplicated defines with different values to make them runtime defined
  • Multiple clk API implementation and runtime selection
  • 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