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 <[email protected]> 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 <[email protected]> > *Sent:* Monday, July 31, 2017 10:52 AM > *To:* Zheng Bao; [email protected]; Matt DeVillier; > [email protected] > *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 >
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
