LCA14: LCA14-202: ARM-SOC: Status and Directions
Upcoming SlideShare
Loading in...5
×
 

LCA14: LCA14-202: ARM-SOC: Status and Directions

on

  • 257 views

Resource: LCA14 ...

Resource: LCA14
Name: LCA14-202: ARM-SOC: Status and Directions
Date: 04-03-2014
Speaker: Arnd Bergmann, Deepak Saxena, Linus Walleij
Video: https://www.youtube.com/watch?v=Gw3AE3iQdgg

Statistics

Views

Total Views
257
Views on SlideShare
257
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

LCA14: LCA14-202: ARM-SOC: Status and Directions LCA14: LCA14-202: ARM-SOC: Status and Directions Presentation Transcript

  • Tue-4-Mar, 10:05am, Arnd Bergmann, Deepak Saxena, Linus Walleij LCA14-202: ARM-SOC Status and directions
  • - Device Tree impetus - Multiplatform targets defined and implemented - Varying degree of adaption on older platforms, the vast majority of v6+ systems now use exclusively multiplatform configuration - New platforms push all drivers under the drivers/ subsystem hierarchy and avoid ARM/plat/mach-specific drivers - New subsystems: pinctrl, clk, irqchip, clocksource, virtio/rpmsg/remoteproc, reset, extcon, iio ... - We are slowly processing the pile of older code: board files, drivers etc, still present in arch/arm/* Ground Covered So Far
  • 1. Empty mach-* platform/subarch directory ● Mirrors ARM64 architecture ● All platforms merged in 2012 or later ● All ARM reference platforms (vexpress, realview, …) ● Exceptions for quirks and bug fixes ● WIP: SMP support, L2x0, system controller Goal: Four sets of platforms
  • 1. Empty platform directory 2. Multiplatform and DT enabled ● Most of the actively developed traditional platforms ■ Exynos, OMAP, i.MX, shmobile, … ● Existing board files get removed over time ● Should include all ARMv6 and ARMv7 based ● Also select ARMv5 and ARMv4 platforms ● WIP: exynos, s5p, at91, kirkwood/orion/dove, integrator, versatile, realview Goal: Four sets of platforms
  • 1. Empty platform directory 2. Multiplatform and DT enabled 3. Multiplatform with board files, optional DT ● Actively used ARMv5 platforms ● No active maintainer to do DT conversion ● WIP: s3c, ● Future work: ks8695, gemini, w90x900, netx Goal: Four sets of platforms
  • 1. Empty platform directory 2. Multiplatform and DT enabled 3. Multiplatform with board files, optional DT 4. Legacy platforms without multiplatform: ● Hard to do multiplatform for ● Few remaining users/testers ● Not ready for deletion yet ● Examples: ebsa110, footbridge, sa1100, ixp, iop, rpc Goal: Four sets of platforms
  • Suggested rationale: ● Don’t break things we cannot test, but clean up as much as we can ● Subject to refactoring if (and only if): ○ Refactoring can be tested on real hardware ○ Refactoring provides modernization of the platform to recent kernel framework updates, e.g. if it is standing in the way of reforming irqchips/domains, generic timers, GPIO descriptors etc. Rationale
  • ● Device Tree binding review queue and quality of binding reviews are constantly in question ● Pile of legacy code: ○ Platforms with weird memory layout (hello RealView EB) ○ Elder PCI hosts ○ Drivers not building on the device model or using custom initcalls ○ Elder video framebuffer drivers need to move to DRM, plat-foo <plat/*> hierarchy is problematic etc. ● <mach/timex.h> removal is done for 3.15 ● early console (between debug_ll and module_init), possible fbcon for uart-less debugging ● turn more stuff into modules Imminent Problems
  • ● Debugging, instrumentation and profiling systems are catching up e.g. kprobes/uprobes/tracing in different modes such as thumb[2] ● ARM32 and also ARM64 are lacking proper kernel infrastructure for debugging and profiling hardware such as CoreSight and bus monitors ● Remove multiplatform roadblocks: ○ DMA remapping bus offsets, ○ moving PCI hosts to drivers/pci, ○ find a way forward for LCD panels, ○ IOMMU detection etc. ● Good runtime PM deployments (separate session!) Next Steps
  • More about Linaro Connect: http://connect.linaro.org More about Linaro: http://www.linaro.org/about/ More about Linaro engineering: http://www.linaro.org/engineering/ Linaro members: www.linaro.org/members