Re: [coreboot] Broadwell-U hangs at VGA init

[Matt DeVillier]

you want to extract the refcode blob as so:

cbfstool shellball.rom extract -r BOOT_STUB -n fallback/refcode -f
refcode.elf -m x86

then add it into your build

On Mon, Jul 31, 2017 at 8:43 AM, Zheng Bao  wrote:
> Thanks. That really helps.
>
> About the REFCODE_BLOB, 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.)
>
> Any idea to get REFCODE_BLOB?
>
> Thanks.
> Zheng
>
> *From:* Nico Huber 
> *Sent:* Monday, July 31, 2017 10:52 AM
> *To:* Zheng Bao; [e-mail]; Matt DeVillier;
> [e-mail]
> *Subject:* Re: [coreboot] Broadwell-U hangs at VGA init
>
> Hi Zheng,
>
> On 30.07.2017 16:13, Zheng Bao wrote:
> > I have got the mrc.bin and mem init has got passed.
> > Now the  new problem is that it hangs at VGA init.
> >
> > static void igd_setup_panel(struct device *dev)
> > {
> > config_t *conf = dev->chip_info;
> > u32 reg32;
> >
> > /* Setup Digital Port Hotplug */
> > reg32 = gtt_read(PCH_PORT_HOTPLUG);  <------- It hangs here.
> > if (!reg32) {
> > reg32 = (conf->gpu_dp_b_hotplug & 0x7) << 2;
> > reg32 |= (conf->gpu_dp_c_hotplug & 0x7) << 10;
> > reg32 |= (conf->gpu_dp_d_hotplug & 0x7) << 18;
> > gtt_write(PCH_PORT_HOTPLUG, reg32);
> > }
> >
> > It turns out as soon as i access VGA bar0+0xc4030, it hangs.
> > while accessing bar0 + 0xa00a is ok.
>
> sounds like the PCH part of the display engine isn't operational (pro-
> bably not all, but most register offsets with bit 19 set reside in the
> PCH). There are few steps to enable it [1], yet the Broadwell port seems
> to rely on the blob to do it. The datasheet [2] suggests that the same
> settings should be done for Broadwell too, but I can't find it in the
> source. So that leads to the conclusion: You forgot to add the second
> blob (HAVE_REFCODE_BLOB, it's BS, it's annoying, but you need it).
>
> That publicly documented settings move from the open source code into
> blobs is a very bad sign, IMO. Now, anybody tell me again, that things
> with Intel are getting better and they might become more open (the sta-
> tistics seem to say the opposite: the blobs get bigger, weirder, take
> over more responsibilities _and_ do a lot of stuff we already had open
> source for earlier platforms).
>
> Nico
>
> [1] src/southbridge/intel/lynxpoint/lpc.c:725
> [2] Intel Document Number: 330837