[Libreboot] C201 EPROM layout ? Was: Re: flashing the c201

[Xavi Drudis Ferran]

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.