[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Libreboot] C201 EPROM layout ? Was: Re: flashing the c201
From: |
Xavi Drudis Ferran |
Subject: |
[Libreboot] C201 EPROM layout ? Was: Re: flashing the c201 |
Date: |
Fri, 23 Sep 2016 14:06:46 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hello
I've been reading about C201 libreboot (thanks, Paul Kocialkowski) and
after a few hours I haven't managed to understand some things. They're
possibly obvious, but I'm either missing some docs or not finding
the code that would explain it or something.
> > ---------- Forwarded message ----------
> > From: *Paul Kocialkowski* <address@hidden>
> > Date: Monday, August 8, 2016
> > Subject: On flashing the c201
> > To: Rendov Norra <address@hidden>
> >
[...]
> >
> > Some notes and suggestion that may help you:
> > * Make sure you've followed https://libreboot.org/docs/install/c201.html
> > and especially "Installing Libreboot externally, with a SPI flash
> > programmer"
>From there I found the command
./cros-flash-replace flash.img coreboot ro-frid
which is in
resources/libreboot/install/depthcharge/cros-flash-replace
and uses
resources/libreboot/install/depthcharge/veyron_speedy/layout.txt
My read is that what it does is changing two segments of the EPROM
00000000:000fffff coreboot
001eff00:001effff ro-frid
coreboot would be a cbfs image with the bootblock, stages and payload.
ro-frid would be the string "libreboot-r20160907-20-gb204a20" (or
whatever is the current libreboot version) padded with trailing 00 up
to 100 bytes, generated by
resources/scripts/helpers/build/roms/withdepthcharge
And cros-flash-replace will write these two segments over the original
EPROM image and leave the rest intact. The rest I guess would be described in
coreboot/src/mainboard/google/veyron/chromeos.fmd
(or I may have mistook the file?)
which contains
address@hidden 0x400000 {
address@hidden 0x200000 {
address@hidden 0x1f0000 {
address@hidden 128K
COREBOOT(CBFS)@0x20000 0xe0000
address@hidden 0x1000
address@hidden 0xeef00
address@hidden 0x100
}
address@hidden 0x10000
}
address@hidden 0x78000 {
address@hidden 0x2000
FW_MAIN_A(CBFS)@0x2000 0x75f00
address@hidden 0x100
}
address@hidden 0x4000 {
address@hidden 0x4000
}
address@hidden 0x4000
address@hidden 0x78000 {
address@hidden 0x2000
FW_MAIN_B(CBFS)@0x2000 0x75f00
address@hidden 0x100
}
address@hidden 0x8000
RW_LEGACY(CBFS)@0x300000 0x100000
}
so
address@hidden 128K
COREBOOT(CBFS)@0x20000 0xe0000
would be replaced by coreboot and
address@hidden 0x100
would be replaced by ro-frid.img
but then it leaves alone
address@hidden 0x1000
address@hidden 0xeef00
in the readonly section of the EPROM, and
all the rw section.
According to
https://lists.nongnu.org/archive/html/libreboot-dev/2015-08/msg00001.html
http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-data-structures
GBB must be the GoogleBinaryBlockHeader, containing public keys
for the verified boot of chromeOS
But what is FMAP and the RW sections ? Specially RW_SHARED ? I guess
RW_SECTION_A and RW_SECTION_B is two copies of the
coreboot/vboot/kernel and some keys for normal ChromeOS boot, and
ChromeOS recovery boot, and for updating one while keeping the other
as backup or something. I also guess RW_ELOG must be space for boot
logs of some kind. But what is RW_VPD and RW_LEGACY? I would have
guessed RW_LEGACY is for booting from legacy BIOS, but it makes no
sense on ARM, does it? Or is it just an older version of the firmware
used as backup when updating it ? It's mentioned in
docs/depthcharge/index.html but it is not explained.
Is libreboot as distributed using any of these original (non built) sections ?
I'm guessing no. But it's a bit odd to write in specific areas of the
EPROM, preserving the original content elsewhere, instead of just erasing
the original EPROM and writing the built code at the beginning or something.
Why preserve something that is not used and should be backed up to a file
somewhere ? It makes the install process slightly more complex (although
it is only sane to backup the original contents, so the extra step
is just padding instead of ovewriting with another image).
One year ago it seemed like the plan was adding optional verified boot.
Maybe that explains why it is written this way ? Because the rest of EPROM
may eventually be replaced by libreboot verified boot components (with
user generated / user selected keys, of course) ? But it might also
be elsewhere, not the same exact offsets as teh factory image, I guess.
Sorry for being long and maybe thick.
Thanks.