summaryrefslogtreecommitdiffstats
path: root/Documentation/getting_started/devicetree.md
blob: 824c51201a24c861327e3477f3b7d1aee2700b53 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
# Adding new devices to a device tree

## Introduction

ACPI exposes a platform-independent interface for operating systems to perform
power management and other platform-level functions.  Some operating systems
also use ACPI to enumerate devices that are not immediately discoverable, such
as those behind I2C or SPI buses (in contrast to PCI).  This document discusses
the way that coreboot uses the concept of a "device tree" to generate ACPI
tables for usage by the operating system.

## Devicetree and overridetree (if applicable)

For mainboards that are organized around a "reference board" or "baseboard"
model (see ``src/mainboard/google/octopus`` or ``hatch`` for examples), there is
typically a devicetree.cb file that all boards share, and any differences for a
specific board ("variant") are captured in the overridetree.cb file.  Any
settings changed in the overridetree take precedence over those in the main
devicetree.  Note, not all mainboards will have the devicetree/overridetree
distinction, and may only have a devicetree.cb file.  Or you can always just
write the ASL (ACPI Source Language) code yourself.

### Naming and referencing devices

When declaring a device, it can optionally be given an alias that can be
referred to elsewhere. This is particularly useful to declare a device in one
device tree while allowing its configuration to be more easily changed in an
overlay. For instance, the AMD Picasso SoC definition
(`soc/amd/picasso/chipset.cb`) declares an IOMMU on a PCI bus that is disabled
by default:

```
chip soc/amd/picasso
	device domain 0 on
		...
		device pci 00.2 alias iommu off end
		...
	end
end
```

A device based on this SoC can override the configuration for the IOMMU without
duplicating addresses, as in
`mainboard/google/zork/variants/baseboard/devicetree_trembyle.cb`:

```
chip soc/amd/picasso
	device domain 0
		...
		device ref iommu on end
		...
	end
end
```

In this example the override simply enables the IOMMU, but it could also
set additional properties (or even add child devices) inside the IOMMU `device`
block.

---

It is important to note that devices that use `device ref` syntax to override
previous definitions of a device by alias must be placed at **exactly the same
location in the device tree** as the original declaration. If not, this will
actually create another device rather than overriding the properties of the
existing one. For instance, if the above snippet from `devicetree_trembyle.cb`
were written as follows:

```
chip soc/amd/picasso
	# NOTE: not inside domain 0!
	device ref iommu on end
end
```

Then this would leave the SoC's IOMMU disabled, and instead create a new device
with no properties as a direct child of the SoC.

## Device drivers

Platform independent device drivers are hooked up via entries in a devicetree.
See [Driver Devicetree Entries](drivers/dt_entries.md) for more info.

## Notes

 - **All fields that are left unspecified in the devicetree are initialized to
   zero.**