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
On Wed, Jul 26, 2017 at 1:40 PM, Konstantin Novikov theshtabel@gmail.com wrote:
Hello, Zoran.
So, we closed that issue. Function northbridge_init() didn't executed, because we didn't had structure with desktop pci_driver. Memory map was builded, SeaBIOS now works correctly (boot from DVD and HDD). But load isn't correct. Ubuntu Linux and Live CD are died after load screen. Errors in terminal are different load-to-load (usually some "NMI watchdog: Watchdog detected hard LOCKUP on cpu #(0-3)").
- Ubuntu loaded in recovery mode. They are different in 'nomodeset'
parameter (Ubuntu Linux loads without graphics drivers). VGA BIOS included, bootspash and SeaBIOS output are visible. Can it be because of uncorrect graphics initialization? 2. How works memconfig? We has read dmesg from coreboot and native BIOS. In coreboot we used 0xf000000 memconfig base, in native used 0xf8000000. Is it critical? We tried to use 0xf8000000, but didn't loaded in SeaBIOS.
Thank you for your answers. Konstantin Novikov.