arm/google/chromebook-boot-flow.rst

1 .. SPDX-License-Identifier: GPL-2.0
7 Most recent Chromebooks that use device tree are using the opensource
9 Image`_ which contains an OS image as well as a collection of device trees. It
10 is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
13 The scheme that depthcharge_ uses to pick the device tree takes into account
16 - Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
17 - Board revision number, determined at runtime (perhaps by reading GPIO
19 - SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
23 - google,$(BOARD)-rev$(REV)-sku$(SKU)
24 - google,$(BOARD)-rev$(REV)
25 - google,$(BOARD)-sku$(SKU)
26 - google,$(BOARD)
31 Note that for some boards there may be extra board-specific logic to inject
34 Depthcharge_ will look through all device trees in the `FIT Image`_ trying to
36 through all device trees in the `FIT Image`_ trying to find the one that
39 When searching for a device tree, depthcharge_ doesn't care where the
40 compatible string falls within a device tree's root compatible string array.
41 As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device
44 - "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180"
45 - "google,lazor", "qcom,sc7180"
47 Then depthcharge_ will pick the first device tree even though
48 "google,lazor-rev4-sku0" was the second compatible listed in that device tree.
54 device tree then depthcharge_ *won't* look for a "rev3" device tree.
58 be reflected in the device tree. Thus it's fairly common to see device
62 depthcharge_ has, the most flexibility is achieved if the device tree
63 supporting the newest revision(s) of a board omits the "-rev{REV}"
66 newest device tree we know about.