mirror of
https://review.coreboot.org/chrome-ec.git
synced 2024-09-09 14:22:41 +02:00
3b361af2a7
This just reserves room. It doesn't actually perform any verification yet. BUG=chrome-os-partner:7459 TEST=manual make BOARD=link dump_fmap build/link/ec.bin Change-Id: I424db1d601a614be3dfe5abb200e24e8bc62e47e Signed-off-by: Bill Richardson <wfrichar@chromium.org>
40 lines
1.3 KiB
Text
40 lines
1.3 KiB
Text
In the most general case, the flash layout looks something like this:
|
|
|
|
+---------------------+
|
|
| Reserved for EC use |
|
|
+---------------------+
|
|
|
|
+---------------------+
|
|
| Vblock B |
|
|
+---------------------+
|
|
| RW firmware B |
|
|
+---------------------+
|
|
|
|
+---------------------+
|
|
| Vblock A |
|
|
+---------------------+
|
|
| RW firmware A |
|
|
+---------------------+
|
|
|
|
+---------------------+
|
|
| FMAP |
|
|
+---------------------+
|
|
| Public root key |
|
|
+---------------------+
|
|
| Read-only firmware |
|
|
+---------------------+
|
|
|
|
|
|
BIOS firmware (and kernel) put the vblock info at the start of each image
|
|
where it's easy to find. The Blizzard EC expects the firmware vector table
|
|
to come first, so we have to put the vblock at the end. This means we have
|
|
to know where to look for it, but that's built into the FMAP and the RO
|
|
firmware anyway, so that's not an issue.
|
|
|
|
The RO firmware doesn't need a vblock of course, but it does need some
|
|
reserved space for vboot-related things.
|
|
|
|
Using SHA256/RSA4096, the vblock is 2468 bytes (0x9a4), while the public
|
|
root key is 1064 bytes (0x428) and the current FMAP is 644 bytes (0x284). If
|
|
we reserve 4K at the top of each FW image, that should give us plenty of
|
|
room for vboot-related stuff.
|