причем трудно заподозрить что все чистая липа, что

причем трудно заподозрить что все чистая липа, что то всетаки работало

судя по "их" логам:

chronos@localhost / $ cat /sys/firmware/log
coreboot-4.0-r#72f4570 Mon Mar 12 12:52:22 PDT 2012 starting...
Setting up static southbridge registers... done.
Disabling Watchdog reboot... done.
Setting up static northbridge registers... done.
Waiting for MCHBAR to come up...ok
Initializing Graphics...
Back from sandybridge_early_initialization()
SMBus controller enabled.
Intel ME early init
Intel ME firmware is ready
ME: Requested 8MB UMA
Starting UEFI PEI System Agent
Read scrambler seed 0x0000272f from CMOS 0x70
Read S3 scrambler seed 0x0000cac5 from CMOS 0x74
CBFS: Looking for 'u-boot.dtb'
CBFS: found.
prepare_mrc_cache: at ff9ed010, entry 1 size b50 checksum 1c7c
CBFS: Looking for 'mrc.bin'
CBFS: found.
System Agent Version 1.2.2 Build 0
.......

но и просматривались их "костыли": CBFS: Looking for 'u-boot.dtb'
которые позже решили убрать т.е. вылизать код, но получилось как всегда ...

методика пользования костылями так же частично описана:

TEST CASE 1 - newly flashed image:
1) Install the new bios with flashrom and reboot
2) Check that no MRC data was found by Coreboot in firmware log:
"prepare_mrc_cache: invalid MRC data"
3) Check that U-boot wrote training data in firmware log:
"handle_mrc_cache: cached storage mismatch (-1/2895)"
"firmware_storage_spi: before adjustment"
"firmware_storage_spi: offset: 0x1ec000"
"firmware_storage_spi: length: 0xb58"
"firmware_storage_spi: after adjustment"
"firmware_storage_spi: offset: 0x1ec000"
"firmware_storage_spi: length: 0x1000"
"firmware_storage_spi: offset: 0x001ec000"
"firmware_storage_spi: adjusted offset: 0x001ec000"
4) Check the flash to see if it has data in first slot
> flashrom -r /tmp/bios.now
> hexdump -Cv -s $((0x1ec000)) -n $((0x10000)) /tmp/bios.now

TEST CASE 2 - ensure that it uses the saved training data:
1) Reboot
2) Check that Coreboot used the training data in firmware log:
"prepare_mrc_cache: at ff9ec009, entry 0 size b4f checksum 9c"
3) Check that U-boot did not have to update the data in firmware log:
"handle_mrc_cache: cached storage match"
4) Check the flash to see if it still only has data in first slot:
> flashrom -r /tmp/bios.now
> hexdump -Cv -s $((0x1ec000)) -n $((0x10000)) /tmp/bios.now

TEST CASE 3 - ensure that it fills the next slot with new data:
1) Corrupt the seed checksum in CMOS:
> io_write8 0x70 0x78
> io_write8 0x71 0x00
2) Reboot
3) Check that Coreboot did not use cached data in firmware log:
"prepare_mrc_cache: invalid seed checksum"
4) Check that U-boot wrote new training data at new offset in firmware log:
"handle_mrc_cache: cached storage mismatch (2895/2895)"
"firmware_storage_spi: before adjustment"
"firmware_storage_spi: offset: 0x1ed000"
"firmware_storage_spi: length: 0xb58"
"firmware_storage_spi: after adjustment"
"firmware_storage_spi: offset: 0x1ed000"
"firmware_storage_spi: length: 0x1000"
"firmware_storage_spi: offset: 0x001ed000"
"firmware_storage_spi: adjusted offset: 0x001ed000"
.............

см.
groups.google.com/a/chromium.org/forum/?fromgroups#!msg/chromium-os-checki...

судя по методике "оживления", биос (?? или u-boot??) оживляется под виртуальной машиной , а как скорее всего под ней и отлаживается, а как быть с реальным железом ??

т.е. чтото у них получилось, но к coreboot это пока имеет слабое отношение