Hello Kostja,
Nico had some answers for you, but I also have some answers for you, and some doubts. Since I am everywhere over this World (virtually), I will try to ad-hoc analyse your log/vse taki ja poprobuju razobratsja v vasei ssilke (v logah kotorie vi predostavili). Vi izvinite menja sto ja ENG klavirsei poljzujus6 dlja Ruskogo jazika.
_______
Not sure, since I am not too experienced with Coreboot logs. It seems that from somewhere (?) GOOGLE designers (they are here, on this list, reading my emails) also have workaround for HSW FSP (the first one they/GOOGLE did with IVB FSP). As Russians would say: lovkie pacani! ;-)
In other words, my best guess is that GOOGLE does not use INTEL HSW FSP, rather their own MRC binary algorithm with source code for the rest, substituting HSW FSP functions (molodci rebjata). And, Kostja, you are using (this is my impression) their/GOOGLE creations.
Now... I have several doubts, and I'll bring them, as the best as I can imagine (I jumped/glanced through the log, I'll analyze it more carefully over the weekend):
[1] ->
CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0)
CBFS: Locating 'mrc.cache'
CBFS: Found @ offset fec0 size 10000
find_current_mrc_cache_local: No valid MRC cache found.
CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0)
CBFS: Locating 'mrc.bin'
CBFS: Found @ offset 9fec0 size 2eb04
Looking scatchy to me. My best guess, Martin Roth, Nico Huber, Ron Minnich, maybe Patrick Georgi can better explain their own HSW MRC creations, and Coreboot HSW support. Maybe yes, maybe not... Every INTEL CORE family has different calling protocol/APIs used for FSP (from 1.0 via 1.1 to 2.0).
[2] ->
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x0000000080000000 size 0x7ff40000 type 6
0x0000000080000000 - 0x00000000d0000000 size 0x50000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000017ce00000 size 0x7ce00000 type 6
From what I see here, All Cool. You have on your system 4GB of memory, sounds that this holds, seems. So, somehow you succeeded allocating/configuring correctly your physical memory.
[3] ->
The latest log lines:
Space available for UMB: cf000-ee000, f6940-f7000
Returned 180224 bytes of ZoneHigh
e820 map has 9 items:
0: 0000000000000000 - 000000000009fc00 = 1 RAM
1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
3: 0000000000100000 - 000000007f751000 = 1 RAM
4: 000000007f751000 - 0000000082200000 = 2 RESERVED
5: 00000000f0000000 - 00000000f4000000 = 2 RESERVED
6: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED
7: 00000000fed84000 - 00000000fed85000 = 2 RESERVED
8: 0000000100000000 - 000000017ce00000 = 1 RAM
enter handle_19:
NULL
Booting from DVD/CD...
Device reports MEDIUM NOT PRESENT
scsi_is_ready returned -1
Boot failed: Could not read from CDROM (code 0003)
enter handle_18:
NULL
Booting from Hard Disk...
Booting from 0000:7c00
E820 comes out of SeaBIOS as output, so your SeaBIOS payload (probably) works correctly.
These lines say that you are passing your SeaBIOS. SeaBIOS is trying to pass thread of execution to the grub executable, called core.img .For the Legacy Boot it is allocated after the first 31KB (MBR has 512Bytes located on the sector 0, then there is a gap of 30.5KB (61 sectors), but for some reason it does not find it...
Ad-hoc suggestions to you:
[A] Did you ever tried to boot your GRUB + Linux HDD with some other boot-loader (BIOS, for example) - to experience if HDD alone boots to GRUB CLI All Good???
[B] You can try also with full blown INTEL HSW mobile FSP for your HSW based DT, it might work, or it might not... I am not sure. Maybe GOOGLE guys have more suggestions about this direction???
Also (as Nico) hope this helps. Hope dies last!
Zoran