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...
1. Empty mach-* platform/subarch directory
● Mirrors ARM64 architecture
● All platforms merged in 2012 or later
● All ARM ...
1. Empty platform directory
2. Multiplatform and DT enabled
● Most of the actively developed traditional platforms
■ Exyno...
1. Empty platform directory
2. Multiplatform and DT enabled
3. Multiplatform with board files, optional DT
● Actively used...
1. Empty platform directory
2. Multiplatform and DT enabled
3. Multiplatform with board files, optional DT
4. Legacy platf...
Suggested rationale:
● Don’t break things we cannot test, but clean up as much
as we can
● Subject to refactoring if (and ...
● Device Tree binding review queue and quality of binding
reviews are constantly in question
● Pile of legacy code:
○ Plat...
● Debugging, instrumentation and profiling systems are
catching up e.g. kprobes/uprobes/tracing in different
modes such as...
More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro eng...
Upcoming SlideShare
Loading in …5
×

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

276
-1

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
276
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Tue-4-Mar, 10:05am, Arnd Bergmann, Deepak Saxena, Linus Walleij LCA14-202: ARM-SOC Status and directions
  2. 2. - 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. ● 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
  9. 9. ● 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
  10. 10. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×