<div dir="ltr">you want to extract the refcode blob as so:<br><br>cbfstool shellball.rom extract -r BOOT_STUB -n fallback/refcode -f refcode.elf -m x86<br><div><br></div><div>then add it into your build</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 31, 2017 at 8:43 AM, Zheng Bao <span dir="ltr"><<a href="mailto:fishbaoz@hotmail.com" target="_blank">fishbaoz@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div id="m_1773105490435710431divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir="ltr">
<p>Thanks. That really helps.</p>
<p><br>
</p>
<p>About the <font size="2"><span style="font-size:10pt">REFCODE_BLOB</span></font>, the BLOB I extracted from ball-rom is BIN, instead of ELF which is required by current CBFS and rmodule in source. (And revision in ball-rom is not in main tree of repository.)<br>
</p>
<br>
<p>Any idea to get <font size="2"><span style="font-size:10pt">REFCODE_BLOB</span></font>?</p>
<p><br>
</p>
<p>Thanks.</p>
<p><br>
</p>
<p>Zheng<br>
</p>
<div style="color:rgb(0,0,0)">
<div>
<hr style="display:inline-block;width:98%">
<div id="m_1773105490435710431x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Nico Huber <<a href="mailto:nico.huber@secunet.com" target="_blank">nico.huber@secunet.com</a>><br>
<b>Sent:</b> Monday, July 31, 2017 10:52 AM<br>
<b>To:</b> Zheng Bao; <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>; Matt DeVillier; <a href="mailto:stefan.reinauer@coreboot.org" target="_blank">stefan.reinauer@coreboot.org</a><br>
<b>Subject:</b> Re: [coreboot] Broadwell-U hangs at VGA init</font>
<div> </div>
</div>
</div><div><div class="h5">
<font size="2"><span style="font-size:10pt">
<div class="m_1773105490435710431PlainText">Hi Zheng,<br>
<br>
On 30.07.2017 16:13, Zheng Bao wrote:<br>
> I have got the mrc.bin and mem init has got passed.<br>
> Now the  new problem is that it hangs at VGA init.<br>
> <br>
> static void igd_setup_panel(struct device *dev)<br>
> {<br>
> config_t *conf = dev->chip_info;<br>
> u32 reg32;<br>
> <br>
> /* Setup Digital Port Hotplug */<br>
> reg32 = gtt_read(PCH_PORT_HOTPLUG);  <------- It hangs here.<br>
> if (!reg32) {<br>
> reg32 = (conf->gpu_dp_b_hotplug & 0x7) << 2;<br>
> reg32 |= (conf->gpu_dp_c_hotplug & 0x7) << 10;<br>
> reg32 |= (conf->gpu_dp_d_hotplug & 0x7) << 18;<br>
> gtt_write(PCH_PORT_HOTPLUG, reg32);<br>
> }<br>
> <br>
> It turns out as soon as i access VGA bar0+0xc4030, it hangs.<br>
> while accessing bar0 + 0xa00a is ok.<br>
<br>
sounds like the PCH part of the display engine isn't operational (pro-<br>
bably not all, but most register offsets with bit 19 set reside in the<br>
PCH). There are few steps to enable it [1], yet the Broadwell port seems<br>
to rely on the blob to do it. The datasheet [2] suggests that the same<br>
settings should be done for Broadwell too, but I can't find it in the<br>
source. So that leads to the conclusion: You forgot to add the second<br>
blob (HAVE_REFCODE_BLOB, it's BS, it's annoying, but you need it).<br>
<br>
That publicly documented settings move from the open source code into<br>
blobs is a very bad sign, IMO. Now, anybody tell me again, that things<br>
with Intel are getting better and they might become more open (the sta-<br>
tistics seem to say the opposite: the blobs get bigger, weirder, take<br>
over more responsibilities _and_ do a lot of stuff we already had open<br>
source for earlier platforms).<br>
<br>
Nico<br>
<br>
[1] src/southbridge/intel/<wbr>lynxpoint/lpc.c:725<br>
[2] Intel Document Number: 330837<br>
</div>
</span></font></div></div></div>
</div>
</div>

</blockquote></div><br></div>