Skip to content

Commit 9646879

Browse files
orangecmsorangecms
committed
move boot flow etc from mask ROMs and loaders to platform init
1 parent 91675a1 commit 9646879

File tree

2 files changed

+61
-58
lines changed

2 files changed

+61
-58
lines changed

‎src/mask-roms-loaders.md‎

Lines changed: 3 additions & 58 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,10 @@ typically remain mostly the same over time for the same vendor, because change
77
would mean cost.
88
This initial code is designed to load the changeable application code from
99
rewritable storages, such as SPI flash parts, SD cards, or eMMC, or possibly an
10-
internal reprogrammable memory part.
10+
internal reprogrammable memory part. Those stages are also referred to as
11+
[platform initialization](platform-initialization.md).
1112

12-
Those loaders may fall back to a mechanism allowing for talking to the SoC
13+
Mask ROM loaders may fall back to a mechanism allowing for talking to the SoC
1314
directly, e.g. via USB or UART. Because each vendor has their own implementation
1415
of such a mechanism, they also have their own software utilities that understand
1516
the respective protocol. With that software, one may read out chip information,
@@ -47,59 +48,3 @@ perform MMIO access, transfer data into memory and execute it, set fuses, etc.
4748
- [`sg_boot`](https://github.com/platform-system-interface/sg_boot)
4849
- StarFive JingHong (JH)
4950
- [`jh_boot`](https://github.com/platform-system-interface/jh_boot)
50-
51-
### Boot Flows
52-
53-
Since memory and storage parts can be complex, additional firmware and loaders
54-
are implemented in software. They would initialize the platform step by step,
55-
phase by phase, or stage by stage; projects differ in naming.
56-
57-
| Project/Vendor | mask ROM | ................ | ..... | .................. | ................... | .......... |
58-
| ----------------- | -------- | ---------------- | ----- | ------------------ | ------------------- | ---------- |
59-
| U-Boot | (N/A) | TPL | SPL | platform-dependent | U-Boot proper | OS |
60-
| EDK2 | (N/A) | SEC | PEI | DXE | BDS | payload/OS |
61-
| Oxide | (N/A) | phbl | X | (-) | (-) | OS |
62-
| coreboot | (N/A) | boot block / CAR | ROM | RAM stage | payload | OS |
63-
| sunxi (Allwinner) | FEL | (-) | boot0 | maybe intermediate | maybe U-Boot proper | OS |
64-
| RISC-V | ZSBL | (-) | FSBL | SBI | boot loader | OS |
65-
| oreboot | mask ROM | boot block | bt0 | main | LinuxBoot | OS |
66-
67-
**Note**:
68-
[oreboot
69-
](https://github.com/oreboot/oreboot/tree/main/Documentation/boot-flow.md) and
70-
[coreboot](https://doc.coreboot.org/getting_started/architecture.html) do not
71-
implement boot loaders to access external storage themselves. Instead, they
72-
provide options for payloads that could load a final OS or stand for themselves;
73-
it is up to the vendor designing a system with it. A _boot block_ is only
74-
necessary for some specific platforms, and possibly _CAR_ (cache-as-RAM).
75-
RISC-V does not have a term for this, since it is conceptually not necessary.
76-
Generic naming does not make much sense either, since different hardware
77-
platforms require some stages or not depending on their constraints. Nor does
78-
counting, due to different points of view: U-Boot, for example, starts counting
79-
[backwards from its proper environment (the one offering a shell)](
80-
https://u-boot.readthedocs.io/en/latest/develop/spl.html#u-boot-boot-phases), to
81-
secondary and (rarely) tertiary program loader (SPL/TPL), while
82-
[RISC-V starts counting forward, the mask ROM being the Zero Stage Boot Loader
83-
(ZSBL)](https://riscv.org/wp-content/uploads/2019/12/Summit_bootflow.pdf).
84-
85-
**Note**:
86-
Vendors may define additional constraints in addition to their hardware
87-
limitiations. For example, AMD implements DRAM initialization in signed code
88-
that runs on a coprocessor before the main x86 cores come out of reset.
89-
Because the signatures of the binaries involved are verified, they cannot be
90-
customized by anyone but those who hold the signing keys, i.e., the vendor,
91-
unless ways to circumvent the verification are found. This is also true for many
92-
OEM products in general, where custom firmware is not part of the product
93-
design. I.e., it is [protected against modification](platform-security.md).
94-
95-
### References
96-
97-
#### Arm platforms
98-
99-
- [How Arm systems are booted](https://youtu.be/GXFw8SV-51g)
100-
- [U-Boot / Amlogic](https://youtu.be/u0-swEMDFp0)
101-
- Arm secure boot chain on Ampere Altra
102-
* [Armed to boot talk](https://youtu.be/i2IG6Au34xM)
103-
* [Armed to boot blog post](https://blog.cloudflare.com/armed-to-boot/)
104-
105-
#### RISC-V platforms

‎src/platform-initialization.md‎

Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,3 +11,61 @@ Early platform firmware takes the responsibility to bring up DRAM and other
1111
controllers as needed to load and boot an operating system. Due to the high
1212
diversity of hardware, every SoC, SoM and mainboard comes with specific
1313
necessities.
14+
15+
### Boot Flows
16+
17+
Since memory and storage parts can be complex, additional firmware and loaders
18+
are implemented in software. They would initialize the platform step by step,
19+
phase by phase, or stage by stage; projects differ in naming.
20+
21+
| Project/Vendor | mask ROM | ................ | ..... | .................. | ................... | .......... |
22+
| ----------------- | -------- | ---------------- | ----- | ------------------ | ------------------- | ---------- |
23+
| U-Boot | (N/A) | TPL | SPL | platform-dependent | U-Boot proper | OS |
24+
| EDK2 | (N/A) | SEC | PEI | DXE | BDS | payload/OS |
25+
| Oxide | (N/A) | phbl | X | (-) | (-) | OS |
26+
| coreboot | (N/A) | boot block / CAR | ROM | RAM stage | payload | OS |
27+
| sunxi (Allwinner) | FEL | (-) | boot0 | maybe intermediate | maybe U-Boot proper | OS |
28+
| RISC-V | ZSBL | (-) | FSBL | SBI | boot loader | OS |
29+
| oreboot | mask ROM | boot block | bt0 | main | LinuxBoot | OS |
30+
31+
**Note**:
32+
[oreboot
33+
](https://github.com/oreboot/oreboot/tree/main/Documentation/boot-flow.md) and
34+
[coreboot](https://doc.coreboot.org/getting_started/architecture.html) do not
35+
implement boot loaders to access external storage themselves. Instead, they
36+
provide options for payloads that could load a final OS or stand for themselves;
37+
it is up to the vendor designing a system with it. A _boot block_ is only
38+
necessary for some specific platforms, and possibly _CAR_ (cache-as-RAM).
39+
RISC-V does not have a term for this, since it is conceptually not necessary.
40+
Generic naming does not make much sense either, since different hardware
41+
platforms require some stages or not depending on their constraints. Nor does
42+
counting, due to different points of view: U-Boot, for example, starts counting
43+
[backwards from its proper environment (the one offering a shell)](
44+
https://u-boot.readthedocs.io/en/latest/develop/spl.html#u-boot-boot-phases), to
45+
secondary and (rarely) tertiary program loader (SPL/TPL), while
46+
[RISC-V starts counting forward, the mask ROM being the Zero Stage Boot Loader
47+
(ZSBL)](https://riscv.org/wp-content/uploads/2019/12/Summit_bootflow.pdf).
48+
49+
**Note**:
50+
Vendors may define additional constraints in addition to their hardware
51+
limitiations. For example, AMD implements DRAM initialization in signed code
52+
that runs on a coprocessor before the main x86 cores come out of reset.
53+
Because the signatures of the binaries involved are verified, they cannot be
54+
customized by anyone but those who hold the signing keys, i.e., the vendor,
55+
unless ways to circumvent the verification are found. This is also true for many
56+
OEM products in general, where custom firmware is not part of the product
57+
design. I.e., it is [protected against modification](platform-security.md).
58+
59+
### References
60+
61+
#### Arm platforms
62+
63+
- [How Arm systems are booted](https://youtu.be/GXFw8SV-51g)
64+
- [U-Boot / Amlogic](https://youtu.be/u0-swEMDFp0)
65+
- Arm secure boot chain on Ampere Altra
66+
* [Armed to boot talk](https://youtu.be/i2IG6Au34xM)
67+
* [Armed to boot blog post](https://blog.cloudflare.com/armed-to-boot/)
68+
69+
#### RISC-V platforms
70+
71+
**TODO**

0 commit comments

Comments
 (0)