Arm device tree and device driver initialization

Houcheng Lin

CCMA, ITRI

Agenda

• Problem: one kernel source to support all arm boards

• Boot with device tree binary

• Device tree syntax

• Machine init code

• Device init code

• x86 platform (one kernel binary support almost all boards)

Problem:One kernel source to support all arm boards

OS kernel

memory,mmu

timer Block device

netdevice

CPU,cache

Hardware HAL

hardware board

Kernelsource

build

select board

Kernel startup code have to initialize these hardware

• Startup code initialize following hardware– CPU, cache, MMU (usually comes with feature reg)

– exception table, GDT, then perform mode switching and enable MMU

– Interrupt controller, bridge chip

– timers, RTC, flash

– IO, block, network and optional devices

• Its purpose is kernel want to use them to– enable some kernel feature

– convert into usable kernel resources

arch

machine

board

One kernel source support all boards, a solution

• Horizontal and vertical divide these code– arch specific include and source– machine specific include and source– board specific include and source

• Pick one board– Header and Makefile links defines

and objects– One board header file that links

arch/ machine specific headers– One board Makefile that links arch/

machine specific sources’ objects

• Kernel config file– Generate header file and Makefile

include for needed kernel feature or drivers

arm

exynos tegra

ve eb aa bb

An example

#include <arm.h>#include <enynos.h>

#define UART0 0x00100c#define TIMER0 0x00200c#define UART_INT 23#define UART_INT 8

board header file

ARCH := armMACH := vexpress

ARCH_LIB := (ARCH)_lib.aMACH_OBJ = (MACH)_lib.aBOARD_OBJ := vexpress.ortos.elf:

$(LD) $(LDFLAGS) $(KERNEL_OBJ) \$(ARCH_LIB) $(MACH_OBJ) $(BOARD_OBJ)

board Makefile

arch/arm/*.c *.h Makefilearch/arm/machine/<machine-name>/*.c *.h Makefilearch/arm/board/<board-name>/*.c *.h Makefile

Source directory

Linux arm community’s initial work

• As hardware more powerful and support MMU, Linux add support to arm

• Linux ARM community starts to write codes and use this approach to support all arm boards

• Some problem when lots of arm boards’ code committed into kenrel:– huge number of #defines in headers– code is hard to maintain

• redundant code• stepping on each others toes (guys uses different names)• merge conflicts

Linus comment on 2001

I don't know who to "blame". I don't care. It really doesn't matter. you guys need to push back on the people sending you crap

Gaah. Guys, this whole ARM thing is a f*cking pain in the ass

steping on others toesThat usb_musb_init() thing in arch/arm/mach-omap2/usb-musb.calso seems to be totally insane.

Note: the layered and division approach can’t not handle various arm hardware and corresponding, existing sources

stop the crazy renaming already!

crap

ARM vendors do crazy shit

ARM device tree

• Device tree is a data structure for describing hardware• It extract board level detail from kernel source code to

device tree script (dts)• Each board has one dts file• Benefit

– moved hardware relevant #defines to dts– keep driver or init code one one copied; describe

variations in dts file. EX: memory mapped address, interrupt number, active-low, output pin number, peferedphy interface, etc

– Now, single kernel binary can support multiple similar boards

Example DTS:vexpress-v2p-ca15.dts

/ {model = "V2P-CA15";arm,hbi = <0x237>;arm,vexpress,site = <0xf>;compatible = "arm,vexpress,v2p-ca15,tc1",

"arm,vexpress,v2p-ca15", "arm,vexpress";

cpu { … }memory { …. }timer {

compatible = "arm,armv7-timer";interrupts = <1 13 0xf08>,

<1 14 0xf08>,<1 11 0xf08>,<1 10 0xf08>;

}…../include/ "vexpress-v2m-rs1.dtsi"

};

vexpress-v2p-ca15-tc1.dts

motherboard {model = "V2P-P1";arm,hbi = <0x237>;arm,vexpress,site = <0xf>;compatible = "arm,vexpress,v2m-p1“,

"simple-bus";#address-cells = <2>; /* SMB chip-select number and offset */flash@2,0000 { …. };ethernet@3,02000 {

compatible = "smsc,lan9118";reg = <3 0x02000000 0x10000>;interrupts = <15>;phy-mode = "mii";smsc,irq-active-high;vdd33a-supply=<&v2m_fixed_3v3>;....

};};

vexpress-v2m-rs1.dti

Device tree work flow

reference [2]

Device Tree Binary pass to kernel

• A device tree is passed to the kernel at boot time, kernel reference it during initialization

r0: 0r1: architecture IDr2: pointer to DTB

reference [1]

machine-init code with device tree

1. kernel run compatible machine-init() via compatible string match

2. Machine-init() create devices under system bus. Bus is also match by compatible string.

…..……static void __init v2m_dt_init(void){

l2x0_of_init(0x00400000, 0xfe0fffff);of_platform_populate(NULL, v2m_dt_bus_match, NULL, NULL);

}static const char * const v2m_dt_match[] __initconst = {

"arm,vexpress",NULL,

};DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")

.dt_compat = v2m_dt_match,

.smp = smp_ops(vexpress_smp_ops),

.smp_init = smp_init_ops(vexpress_smp_init_ops),

.map_io = v2m_dt_map_io,

.init_early = v2m_dt_init_early,

.init_machine= v2m_dt_init,MACHINE_END

arch/arm/mach-vexpress/v2m.c

arch/arm/mach-ooo/v3m.c…..……

It creates devices under this compatible bus

struct of_device_id v2m_dt_bus_match[] = {{ .compatible = "simple-bus", },{ .compatible = "arm,amba-bus", },{ .compatible = "arm,vexpress,config-bus", },{}};

1.

2.

Device-init code with device tree

1. Kernel runs all modules’ module-initfunction

2. The module-init function register platfrom driver

3. For every created platform device, it call its platform driver’s probe function

4. In probe, can access properties in device tree node and create a Linux kernel device object with private data

#ifdef CONFIG_OFstatic const struct of_device_id gdr_match[] = {

{ .compatible = "defer-reset" },};MODULE_DEVICE_TABLE(of, gdr_match);#endif

static struct platform_driver gdr_driver = {.probe = gdr_probe,.driver = {

.name = DRIVER_NAME,.owner = THIS_MODULE,.of_match_table = of_match_ptr(gdr_match),

}};static int __init gdr_init(void){

….platform_driver_register(&gdr_driver);

}module_init(gdr_init);

int gdr_probe(struct platform_device *pdev_gdr) {…..of_property_read_u32(of_node, “duration”, &duration);…..

}1.

2.

3.

4.

How x86 platform works ?

• In x86, one single kernel binary can support all hardware platforms. How can do it ?

• BIOS hides the low level hardware detail – BIOS initialize low level (memory, cpu, clock, voltage, current, … )– BIOS provide memory size and hard disk information to Linux

boot-loader

• Smart bus enumerate optional devices(PCI bridge or USB root hub )– enumerate devices to Linux kernel – get device identity and resource requirement– optional device’s driver may encapsulated as module and

initialized in ramdisk stage

• PC industry is much more standardized than arm hardware

$$

$$

X86 Platform boot, real mode

(boot-loader)

(compressed kernel)loaded by boot-loader

http://duartes.org/gustavo/blog/post/kernel-boot-process/

Access >1MB in real mode

The shuffling of the kernel back and forth in memory is to overcome limitations of the PC BIOS memory addressability (640k), and free up several hundred kilobytes of system memory (the actual amount freed is reported by the system). The 4k is used for handling virtual memory. The special load instructions (trampoline) are required to 'cheat' the system, as the instructions load part of the kernel into memory locations beyond the 640k barrier that the (then currently running "real mode") system knows about. In the process of shuffling the kernel around, the memory originally written to by the BIOS, and also where the setup and system programs were loaded are overwritten by the kernel image, hence the need for moving them to a safe place, beyond where the uncompressed kernel image is loaded. The actual load is slightly more complicated on x86 systems as not all BIOSs report their memory on the same registers, report information in different ways, or map their memory/system resources in unconventional ways. Also, some BIOSs must be prodded for information several times or have A20 Gate problems.

http://en.wikibooks.org/wiki/The_Linux_Kernel/Booting

Mode switch

reference [1]

Reference

[1] http://duartes.org/gustavo/blog/post/kernel-boot-process/

[2] http://www.slideshare.net/softpapa/device-tree-support-on-arm-linux-8930303

[3] http://en.wikibooks.org/wiki/The_Linux_Kernel/Booting

[4] Linux kernel source, vexpress board

[5] Linux kernel documentation, Platform Devices and Drivers