요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
======================================
Chromebook Boot Flow
======================================
Most recent Chromebooks that use device tree are using the opensource
depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT
Image`_ which contains an OS image as well as a collection of device trees. It
is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
provide it to the OS.
The scheme that depthcharge_ uses to pick the device tree takes into account
three variables:
- Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
- Board revision number, determined at runtime (perhaps by reading GPIO
strappings, perhaps via some other method). This is $(REV) below.
- SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
For recent Chromebooks, depthcharge_ creates a match list that looks like this:
- google,$(BOARD)-rev$(REV)-sku$(SKU)
- google,$(BOARD)-rev$(REV)
- google,$(BOARD)-sku$(SKU)
- google,$(BOARD)
Note that some older Chromebooks use a slightly different list that may
not include SKU matching or may prioritize SKU/rev differently.
Note that for some boards there may be extra board-specific logic to inject
extra compatibles into the list, but this is uncommon.
Depthcharge_ will look through all device trees in the `FIT Image`_ trying to
find one that matches the most specific compatible. It will then look
through all device trees in the `FIT Image`_ trying to find the one that
matches the *second most* specific compatible, etc.
When searching for a device tree, depthcharge_ doesn't care where the
compatible string falls within a device tree's root compatible string array.
As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device
trees:
- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180"
- "google,lazor", "qcom,sc7180"
Then depthcharge_ will pick the first device tree even though
"google,lazor-rev4-sku0" was the second compatible listed in that device tree.
This is because it is a more specific compatible than "google,lazor".
It should be noted that depthcharge_ does not have any smarts to try to
match board or SKU revisions that are "close by". That is to say that
if depthcharge_ knows it's on "rev4" of a board but there is no "rev4"
device tree then depthcharge_ *won't* look for a "rev3" device tree.
In general when any significant changes are made to a board the board
revision number is increased even if none of those changes need to
be reflected in the device tree. Thus it's fairly common to see device
trees with multiple revisions.
It should be noted that, taking into account the above system that
depthcharge_ has, the most flexibility is achieved if the device tree
supporting the newest revision(s) of a board omits the "-rev{REV}"
compatible strings. When this is done then if you get a new board
revision and try to run old software on it then we'll at pick the
newest device tree we know about.
.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/
.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Chromebook Boot Flow
1-20device tree를 쓰는 최신 Chromebook 대부분은 open-source `depthcharge` bootloader를 사용합니다. depthcharge는 OS image와 여러 device tree를 함께 담은 FIT Image로 OS를 package할 것을 요구하며, FIT Image에서 올바른 device tree를 골라 OS에 전달합니다.
device tree 선택에는 세 변수가 관여합니다.
| 변수 | 결정 시점 | 의미 |
|---|---|---|
| `$(BOARD)` | depthcharge compile time | board name |
| `$(REV)` | runtime | GPIO strapping 또는 다른 방식으로 알아낸 board revision |
| `$(SKU)` | boot time | GPIO strapping에서 읽은 SKU number |
Compatible match priority
21-37최신 Chromebook에서 depthcharge는 가장 구체적인 조합부터 일반적인 board 이름까지 다음 우선순위의 match list를 만듭니다.
| 우선순위 | compatible |
|---|---|
| 1 | `google,$(BOARD)-rev$(REV)-sku$(SKU)` |
| 2 | `google,$(BOARD)-rev$(REV)` |
| 3 | `google,$(BOARD)-sku$(SKU)` |
| 4 | `google,$(BOARD)` |
일부 구형 Chromebook은 SKU matching이 없거나 SKU와 revision 우선순위가 다른 목록을 사용합니다. 드물게 board-specific logic이 추가 compatible을 삽입하기도 합니다.
depthcharge는 FIT Image의 모든 device tree에서 가장 구체적인 compatible과 일치하는 것을 먼저 찾고, 없으면 두 번째로 구체적인 compatible을 찾는 식으로 계속합니다.
Device tree selection example
38-55root compatible string array 안에서 compatible이 몇 번째에 있는지는 중요하지 않습니다. board가 `lazor`, revision 4, SKU 0이고 아래 두 device tree가 있다고 가정합니다.
- `google,lazor-rev5-sku0`, `google,lazor-rev4-sku0`, `qcom,sc7180`
- `google,lazor`, `qcom,sc7180`
`google,lazor-rev4-sku0`이 첫 device tree의 두 번째 compatible이어도 `google,lazor`보다 구체적이므로 depthcharge는 첫 device tree를 선택합니다.
depthcharge는 가까운 board 또는 SKU revision을 추측하지 않습니다. 현재 board가 rev4인데 rev4 device tree가 없다고 해서 rev3 device tree를 찾지 않습니다.
Board revision compatibility strategy
56-69board에 중요한 변경이 생기면 device tree에 반영할 변경이 없어도 revision number를 올리는 것이 일반적입니다. 따라서 하나의 device tree가 여러 revision을 지원하는 경우가 흔합니다.
가장 유연한 방법은 최신 board revision을 지원하는 device tree에서 `-rev{REV}` compatible을 생략하는 것입니다. 그러면 새 revision에서 오래된 software를 실행해도 software가 알고 있는 가장 최신 device tree를 선택할 수 있습니다.
요약과 해설
chromebook-boot-flow.rst:1-69선택 알고리즘은 가까운 revision을 추정하지 않고 compatible의 구체성만 따릅니다. 최신 revision용 device tree에 revision 없는 board-level compatible을 남기면 미래 board에서 오래된 image를 사용할 때 가장 나은 fallback을 제공합니다.
위에서 아래로 FIT Image 전체를 다시 검색합니다.