Bug 9267

Summary: test_parselogs (oeqa.runtime.parselogs.ParseLogsTest) failed on NUC 6i5SYH, firmware load for i915/skl_guc_ver4.bin failed
Product: [Build System, Metadata & Runtime] BSPs Reporter: Francisco Pedraza <francisco.j.pedraza.gonzalez>
Component: bsps-meta-yoctoAssignee: California Sullivan <california.l.sullivan>
Status: RESOLVED FIXED QA Contact: Apoorv <apoorv.sangal>
Severity: normal    
Priority: Medium CC: jianxun.zhang, jose.perez.carranza, sgw
Version: 2.1   
Target Milestone: 2.5   
Hardware: NUC   
OS: x86_64   
URL: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.1_M3.rc1/machines/genericx86-64/core-image-sato-sdk-genericx86-64.hddimg
Whiteboard:
OS type for building Yocto: --- Type of Regression: Regression (Found by QA test)
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
dparse logs
none
logs do_testimage none

Description Francisco Pedraza 2016-03-15 19:21:55 UTC 
Failed on NUC runnig $bitbake core-image-sato-sdk-c testimage

getting the following error messages:

Central error: [    0.738002] i915 0000:00:02.0: Direct firmware load for i915/skl_guc_ver4.bin failed with error -2

| Central error: [    0.740089] [drm:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -5 (ignored)

| Central error: [    0.689288] [drm:i915_firmware_load_error_print] *ERROR* The driver is built-in, so to load the firmware you need to

| Central error: [    0.689270] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1.bin failed with error -2

| Central error: [    0.689280] [drm:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (0)

| Central error: [    0.738015] [drm:intel_guc_ucode_init] *ERROR* Failed to fetch GuC firmware from i915/skl_guc_ver4.bin (error -2)


| Central error: [    0.737513] [drm] failed to retrieve link info, disabling eDP

| Central error: [    6.408821] udevd[361]: inotify_add_watch(6, /dev/loop0, 10) failed: No such file or directory

| Central error: [    0.738002] i915 0000:00:02.0: Direct firmware load for i915/skl_guc_ver4.bin failed with error -2

| Central error: [    0.740089] [drm:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -5 (ignored)

| Central error: [    0.689288] [drm:i915_firmware_load_error_print] *ERROR* The driver is built-in, so to load the firmware you need to

| Central error: [    0.689270] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1.bin failed with error -2


| Central error: [    0.689280] [drm:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (0)

| Central error: [    0.738015] [drm:intel_guc_ucode_init] *ERROR* Failed to fetch GuC firmware from i915/skl_guc_ver4.bin (error -2)

| Central error: [    0.737513] [drm] failed to retrieve link info, disabling eDP

| Central error: [    6.408821] udevd[361]: inotify_add_watch(6, /dev/loop0, 10) failed: No such file or directory
Comment 1 Francisco Pedraza 2016-03-15 19:25:40 UTC 
Created attachment 3029 [details]
dparse logs
Comment 2 Francisco Pedraza 2016-03-15 19:27:17 UTC 
Created attachment 3030 [details]
logs do_testimage
Comment 3 California Sullivan 2016-03-15 23:40:48 UTC 
The i915 firmware load messages are because graphics on Skylake (and Broxton) require a firmware blob, and the kernel does not know about it on boot.

I have tested setting CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR to point to the firmware blobs, and it fixes those error messages, but I do not believe its the appropriate solution, as we do not necessarily ship the firmware blobs.
Comment 4 California Sullivan 2016-03-23 00:04:08 UTC 
Adding the Skylake i915 firmware to the initramfs also works and is likely the way to go. However, right now we only have the i915 firmware in the catch-all linux-firmware package, so it needs to be broken into its own package to make sure we don't expand the initramfs too much. I believe that Saul is working on this.

For the firmware to load correctly on this NUC6 we also need to backport the following patch: https://lists.freedesktop.org/archives/intel-gfx/2016-January/086612.html
Comment 5 California Sullivan 2016-03-28 23:17:26 UTC 
As it probably is not appropriate to pollute the initramfs for everybody, we are only adding the firmware blobs to intel-core* MACHINEs (provided by the meta-intel layer) for now.

You will continue seeing this error with a genericx86-64 MACHINE.

Patches have been submitted to the linux-yocto and meta-intel mailing lists to implement this, and they are awaiting review/integration.
Comment 6 California Sullivan 2016-04-27 17:23:43 UTC 
Hmm, the fix in oe-core only works for our live images because we lose the initramfs once we install. I will need to revisit this.
Comment 7 Jose Perez C 2016-07-25 13:30:15 UTC 
Still reproducible on live image (booted not installed) on NUC 2.2 M2 

http://autobuilder.yoctoproject.org/pub/releases/yocto-2.2_M2.rc1/machines/genericx86-64/core-image-sato-sdk-genericx86-64.hddimg
Comment 8 California Sullivan 2016-08-03 16:27:48 UTC 
I have a fix coming but it will only be appropriate to put in meta-intel. In the mean time please whitelist this for genericx86* machines.
Comment 9 California Sullivan 2016-12-10 01:40:00 UTC 
I whitelisted this for genericx86-64, but my fix for meta-intel did not work.

Essentially I wanted to build the firmware into an intiramfs, and ship the kernel with the initramfs built in.

The INITRAMFS_IMAGE_BUNDLE and INITRAMFS_IMAGE variables do indeed create an initramfs/kernel bundle, but they appear to not be put into the images, as there is a large size discrepancy between the kernel that ends up in the image and the initramfs bzImage that gets created and put in the deploy directory.

I am able to hack kernel.bbclass to use the initramfs bundle if INITRAMFS_IMAGE_BUNDLE is set, but now I'm running into different kernel panics depending on what init I include in the initramfs.

This could take a bit longer...
Comment 10 California Sullivan 2017-12-08 00:25:17 UTC 
Someone had a smart idea of just building i915 as a module: https://lists.yoctoproject.org/pipermail/linux-yocto/2017-December/006703.html

That should fix it.