[coreboot] Haswell port

[Zoran Stojsavljevic]

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 at 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)").
>
> 1. 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170727/072c465a/attachment.html>