Upload
duongnhu
View
263
Download
4
Embed Size (px)
Citation preview
FOSDEM 2013
ARM support in theLinux kernel
Thomas PetazzoniFree [email protected]
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 1/1
Thomas Petazzoni
I Embedded Linux engineer and trainer at Free Electrons since2008
I Embedded Linux development: kernel and driverdevelopment, system integration, boot time and powerconsumption optimization, consulting, etc.
I Embedded Linux training, Linux driver development trainingand Android system development training, with materialsfreely available under a Creative Commons license.
I http://free-electrons.com
I Contributing the kernel support for the new Armada 370and Armada XP ARM SoCs from Marvell.
I Major contributor to Buildroot, an open-source, simple andfast embedded Linux build system
I Living in Toulouse, south west of France
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 2/1
Agenda
I Background on the ARM architecture and Linux support
I The problems
I Changes in the ARM kernel support
I Getting the support for a SoC in mainline, story of Armada370/XP
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 3/1
From the ARM architecture to a board
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 4/1
From the ARM architecture to a board, examples
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 5/1
Schematic view of a board
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 6/1
No standardization
I Beyond the ARM core itself, a lot of freedom is left to theSoC vendor.
I There is no standard for the devices, the management ofclocks, pinmuxing, IRQ controllers, timers, etc.
I Note: some things like IRQ controllers and timers are nowstandardized.
I There isn’t a mechanism to enumerate the devices availableinside the SoC. All devices have to be known by the kernel.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 7/1
“Old” ARM code organization in the Linux kernel
I arch/arm/I arch/arm/{kernel,mm,lib,boot}/
The core ARM kernel. Contains the code related to the ARMcore itself (MMU, interrupts, caches, etc.). Relatively smallcompared to the SoC-specific code.
I arch/arm/mach-<foo>/The SoC-specific code, and board-specific code, for a givenSoC family.
I arch/arm/mach-<foo>/board-<bar>.c.The board-specific code.
I drivers/
The device drivers themselves.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 8/1
Issue #1: too much code, lack of review
I Exploding number of ARM SoC, from different vendors
I The historical maintainer, Russell King, got overflowed bythe amount of code to review.
I Code started to flow directly from sub-architecturemaintainers directly to Linus Torvalds.
I Focus of each sub-architecture teams on their ownproblems, no vision of the other sub-architectures.
I Consequences: lot of code duplication, missing commoninfrastructures, maintenability problems, etc.
I Linus, March 2011: Gaah. Guys, this whole ARM thing is af*cking pain in the ass.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 9/1
Issue #2: the need for multiplatform kernel
I On x86 PC, one can build a single kernel image (with manymodules) that boots and work on all PCs
I Good for distributions: they can ship a single kernel image.
I On ARM, it was impossible to build a single kernel thatwould boot on systems using different SoCs.
I Issue for distributions: they have to build and maintain akernel image almost for each ARM hardware platform theywant to support.
I Need for ARM multiplatform support in the kernel.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 10/1
Change #1: arm-soc and maintainers
I A new maintainer team for theARM sub-architectures: ArndBergmann (Linaro) and OlofJohansson (Google)
I All the ARM SoC-specific codegoes through them, in a tree calledarm-socI They send the changes accumulated in arm-soc to Linus
Torvalds.
I Those maintainers have a cross-SoC view: detection of thingsthat should be factorized, consistency accross SoC-specificcode.
I Core ARM changes continue to go through Russell King.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 11/1
Change #2: Device Tree
I Most devices inside an ARM SoC and on the board cannot bedynamically enumerated: they have to be staticallydescribed.
I The old way of doing this description was by using C code,registering platform_device structures for each hardwaredevice.
I This has been replaced by a hardware description done instructure separated from the kernel, called the Device Tree.
I Also used on PowerPC, Microblaze, ARM64, Xtensa,OpenRisc, etc.
I The Device Tree Source, in text format, gets compiled into aDevice Tree Blob, in binary format, thanks to the Device TreeCompiler.
I Sources are stored in arch/arm/boot/dts
I At boot time, the kernel parses the Device Tree to instantiatethe available devices.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 12/1
Change #2: Before the Device Tree...
From arch/arm/mach-at91/at91sam9263_devices.cstatic struct resource udc_resources[] = {
[0] = {
.start = AT91SAM9263_BASE_UDP,
.end = AT91SAM9263_BASE_UDP + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = NR_IRQS_LEGACY + AT91SAM9263_ID_UDP,
.end = NR_IRQS_LEGACY + AT91SAM9263_ID_UDP,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device at91_udc_device = {
.name = "at91_udc",
.id = -1,
.dev = {
.platform_data = &udc_data,
},
.resource = udc_resources,
.num_resources = ARRAY_SIZE(udc_resources),
};
some_init_code() {
platform_device_register(&at91_udc_device);
}
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 13/1
Change #2: SoC Device Tree example
/include/ "skeleton.dtsi"
/ {
compatible = "brcm,bcm2835";
model = "BCM2835";
interrupt-parent = <&intc>;
chosen {
bootargs = "earlyprintk console=ttyAMA0";
};
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x7e000000 0x20000000 0x02000000>;
[...]
intc: interrupt-controller {
compatible = "brcm,bcm2835-armctrl-ic";
reg = <0x7e00b200 0x200>;
interrupt-controller;
#interrupt-cells = <2>;
};
uart@20201000 {
compatible = "brcm,bcm2835-pl011", "arm,pl011", "arm,primecell";
reg = <0x7e201000 0x1000>;
interrupts = <2 25>;
clock-frequency = <3000000>;
status = "disabled";
};
};
};
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 14/1
Change #2: Board Device Tree example
/dts-v1/;
/memreserve/ 0x0c000000 0x04000000;
/include/ "bcm2835.dtsi"
/ {
compatible = "raspberrypi,model-b", "brcm,bcm2835";
model = "Raspberry Pi Model B";
memory {
reg = <0 0x10000000>;
};
soc {
uart@20201000 {
status = "okay";
};
};
};
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 15/1
Change #2: Device Tree inheritance
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 16/1
Change #2: Booting with a Device Tree
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 17/1
Change #3: Multiplatform kernel
I Fits the need of distributions willing to build a single kernelimage that works on many ARM platforms.
I The SoC choice now contains a Allow multiple platforms tobe selected option, and all the SoC families that arecompatible with this can be compiled together in the samekernel.
I There is still a split between ARMv4/ARMv5 on one side, andARMv6/ARMv7 on the other side.
I A lot of changes have been done in the ARM kernel to makethis possible: avoid two different platforms from defining thesame symbol, from using the same header names, no more#ifdef but runtime detection instead.
I The support for all new SoCs must use the multiplatformmechanism.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 18/1
Change #4: Pinctrl subsystem, introduction
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 19/1
Change #4: Pinctrl subsystem, old code
I Each ARM sub-architecture had its own pin-muxing code
I The API was specific to each sub-architecture
I A lot of similar functionality implemented in different ways
I The pin-muxing had to be done at the SoC level, and couldn’tbe requested by device drivers
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 20/1
Change #4: Pinctrl subsystem, new subsystem
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 21/1
Change #5: Clocks
I In a System-on-Chip, all peripherals are driven by one or moreclocks.
I Those clocks are organized in a tree, and often are softwareconfigurable.
I Since quite some time, the kernel had a simple API: clk_get,clk_enable, clk_disable, clk_put that were used bydevice drivers.
I Each ARM sub-architecture had its own implementation ofthis API.
I Does not work for multiplatform kernels.
I Does not allow code sharing, and common mechanisms.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 22/1
Change #5: Common clock framework
I A proper common clock framework has been added inkernel 3.4, released in May 2012
I This framework:I Implements the clk_get, clk_put, clk_prepare,
clk_unprepare, clk_enable, clk_disable, clk_get_rate,etc. API for usage by device drivers
I Implements some basic clock drivers (fixed rate, gatable,divider, fixed factor, etc.) and allows the implementation ofcustom clock drivers using struct clk_hw andstruct clk_ops
I Allows to declare the available clocks and their association todevices in the Device Tree (preferred) or statically in thesource code (old method)
I Provides a debugfs representation of the clock treeI Is implemented in drivers/clk
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 23/1
Change #5: Common clock framework architecture
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 24/1
Change #6: More things in drivers/
I Another goal of the ARM cleanup is to have less code inarch/arm and create proper drivers and relatedinfrastructures.
I For exampleIRQ controller drivers drivers/irqchip/
Timer drivers drivers/clocksource/
PCI host controller drivers drivers/pci/host/
Clock drivers drivers/clk/
Pinmux drivers drivers/pinctrl/
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 25/1
Armada 370/XP, step 1
Went into Linux 3.6, 10 patches
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 26/1
Armada 370/XP, step 2
Went into Linux 3.7, 35 patches
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 27/1
Armada 370/XP, step 3
Went into Linux 3.8, 99 patches
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 28/1
Armada 370/XP, step 4
Hopefully going in 3.9 :-)
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 29/1
Getting an ARM SoC in mainline
I Throw away the vendor BSP code. Most likely it iscompletely crappy. You have to start from scratch.
I Start small, and send code piece by piece. Don’t wait tohave everything fully working.
I Comply with the latest infrastructure changes: DeviceTree, clock framework, pinctrl subsystem. They aremandatory.
I Read and post to the LAKML, Linux ARM Kernel MailingList
I Listen to reviews and comments, and repost updatedversions regularly.
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 30/1
Questions?
Thomas Petazzoni
Thanks to Gregory Clement (Free Electrons, working with me onMarvell mainlining), Lior Amsalem and Maen Suleiman (Marvell)
Slides under CC-BY-SA 3.0http://free-electrons.com/pub/conferences/2013/fosdem/arm-support-
kernel/
Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com 31/1