Broadwell IGD (on Auron_Paine)

[Georg Wicherski]

Hi,

thanks to Marc Jones' SGD patch for the Auron board
(f3214d02482a4104d7276f06d6b326b2a54c4262), I was able to get my
Auron_Paine up to ramstage.

Unfortunately, the IGD code in soc/intel/broadwell/ appears to be
somewhat broken. Based off Aaron's guidance on IRC, I've pin-pointed the
issue to be within igd_setup_panel . The first gtt_read there seems to
hang already (BIOS_SPEW log attached). Find my current code with those
debug prints at http://review.coreboot.org/#/c/11907/2. FWIW, I've
tested with some commenting-out, etc. that it's any gtt_read that
immediately causes a hang there. Also dumped the gtt_res, small excerpt
from the log:

--8<--
igd's gtt_res = { base=e0000000, size=1000000, limit=e0ffffff,
flags=60000201 }
igd_init: waited for pre-graphics delay to pass
igd_init: went through early init
igd_init: RP1 graphics frequency is set
gtt_read(PCH_PORT_HOTPLUG)
--8<--

People on IRC mentioned that this is an issue that people may have run
into before on Broadwell, any suggestions on how to fix the hang there?

Thanks,
G

[Stefan Reinauer]

* Georg Wicherski  [151019 17:39]:
> Hi,
>
> thanks to Marc Jones' SGD patch for the Auron board
> (f3214d02482a4104d7276f06d6b326b2a54c4262), I was able to get my
> Auron_Paine up to ramstage.
>
> Unfortunately, the IGD code in soc/intel/broadwell/ appears to be
> somewhat broken. Based off Aaron's guidance on IRC, I've pin-pointed the
> issue to be within igd_setup_panel . The first gtt_read there seems to
> hang already (BIOS_SPEW log attached). Find my current code with those
> debug prints at http://review.coreboot.org/#/c/11907/2. FWIW, I've
> tested with some commenting-out, etc. that it's any gtt_read that
> immediately causes a hang there. Also dumped the gtt_res, small excerpt
> from the log:
>
> --8<--
> igd's gtt_res = { base=e0000000, size=1000000, limit=e0ffffff,
> flags=60000201 }
> igd_init: waited for pre-graphics delay to pass
> igd_init: went through early init
> igd_init: RP1 graphics frequency is set
> gtt_read(PCH_PORT_HOTPLUG)
> --8<--
>
> People on IRC mentioned that this is an issue that people may have run
> into before on Broadwell, any suggestions on how to fix the hang there?
>
> Thanks,
> G

Hi Georg,

it seems that the refcode binary was not running. Can you verify that
it was part of the image and gets executed?

Stefan

[Georg Wicherski]

On 10/19/2015 09:15 PM, Stefan Reinauer wrote:
> it seems that the refcode binary was not running. Can you verify that
> it was part of the image and gets executed?

Of course, good find.

The reference code blob was actually in the CBFS but unfortunately the
code to run it was disabled if no such blob was directly provided to
KConfig.

http://review.coreboot.org/#/c/11907/4 now actually works on my
Auron_Paine and correctly boots with framebuffer into a payload.

There is one remaining issue, when using GRUB2 as payload and using the
at_keyboard terminal_input, the machine resets. The last debug print I
can see from GRUB2 is from term/at_keyboard.c:367 with current_set=0, so
I suppose the crasher is the write_mode(1) a few lines down.

Is this a GRUB2 issue or Coreboot issue (the at_keyboard is related to
the EC, maybe not properly initialized)?

Thanks for all involved so far!
G

[Georg Wicherski]

On 10/23/2015 02:44 PM, Georg Wicherski wrote:
> There is one remaining issue, when using GRUB2 as payload and using the
> at_keyboard terminal_input, the machine resets. The last debug print I
> can see from GRUB2 is from term/at_keyboard.c:367 with current_set=0, so
> I suppose the crasher is the write_mode(1) a few lines down.
>
> Is this a GRUB2 issue or Coreboot issue (the at_keyboard is related to
> the EC, maybe not properly initialized)?

I should mention, I observed exactly the same bug/behavior on a Peppy
board (which is pretty close to the Auron_Paine).

Using a USB keyboard, I can happily edit stuff in GRUB2 and boot into
Linux 4.x (which then crashes in gpio_lynxpoint, but I can simply
blacklist that module for now).