Commit | Line | Data |
---|---|---|
b32e592d SB |
1 | QCOM device tree bindings |
2 | ------------------------- | |
3 | ||
4 | Some qcom based bootloaders identify the dtb blob based on a set of | |
5 | device properties like SoC and platform and revisions of those components. | |
6 | To support this scheme, we encode this information into the board compatible | |
7 | string. | |
8 | ||
9 | Each board must specify a top-level board compatible string with the following | |
10 | format: | |
11 | ||
12 | compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]" | |
13 | ||
14 | The 'SoC' and 'board' elements are required. All other elements are optional. | |
15 | ||
16 | The 'SoC' element must be one of the following strings: | |
17 | ||
18 | apq8016 | |
19 | apq8074 | |
20 | apq8084 | |
21 | apq8096 | |
22 | msm8916 | |
23 | msm8974 | |
24 | msm8996 | |
25 | ||
26 | The 'board' element must be one of the following strings: | |
27 | ||
28 | cdp | |
29 | liquid | |
30 | dragonboard | |
31 | mtp | |
32 | sbc | |
33 | ||
34 | The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor> | |
35 | where the minor number may be omitted when it's zero, i.e. v1.0 is the same | |
36 | as v1. If all versions of the 'board_version' elements match, then a | |
37 | wildcard '*' should be used, e.g. 'v*'. | |
38 | ||
39 | The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9. | |
40 | ||
41 | Examples: | |
42 | ||
43 | "qcom,msm8916-v1-cdp-pm8916-v2.1" | |
44 | ||
45 | A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version | |
46 | 2.1. | |
47 | ||
48 | "qcom,apq8074-v2.0-2-dragonboard/1-v0.1" | |
49 | ||
50 | A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in | |
51 | foundry 2. |