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* <[email protected]> > > Date: Monday, August 8, 2016 > > Subject: On flashing the c201 > > To: Rendov Norra <[email protected]> > > [...] > > > > 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 FLASH@0x0 0x400000 { WP_RO@0x0 0x200000 { RO_SECTION@0x0 0x1f0000 { BOOTBLOCK@0 128K COREBOOT(CBFS)@0x20000 0xe0000 FMAP@0x100000 0x1000 GBB@0x101000 0xeef00 RO_FRID@0x1eff00 0x100 } RO_VPD@0x1f0000 0x10000 } RW_SECTION_A@0x200000 0x78000 { VBLOCK_A@0x0 0x2000 FW_MAIN_A(CBFS)@0x2000 0x75f00 RW_FWID_A@0x77f00 0x100 } RW_SHARED@0x278000 0x4000 { SHARED_DATA@0x0 0x4000 } RW_ELOG@0x27c000 0x4000 RW_SECTION_B@0x280000 0x78000 { VBLOCK_B@0x0 0x2000 FW_MAIN_B(CBFS)@0x2000 0x75f00 RW_FWID_B@0x77f00 0x100 } RW_VPD@0x2f8000 0x8000 RW_LEGACY(CBFS)@0x300000 0x100000 } so BOOTBLOCK@0 128K COREBOOT(CBFS)@0x20000 0xe0000 would be replaced by coreboot and RO_FRID@0x1eff00 0x100 would be replaced by ro-frid.img but then it leaves alone FMAP@0x100000 0x1000 GBB@0x101000 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.
