Bug 2544 - Move emenlow BSP to the 3.4 kernel
Summary: Move emenlow BSP to the 3.4 kernel
Status: VERIFIED FIXED
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-configuration (show other bugs)
Version: 1.3
Hardware: E-Menlow Multiple
: High enhancement
Target Milestone: 1.3 M3
Assignee: Nitin Kamble
QA Contact:
URL:
Whiteboard: (P1) Nitin: Please size and target.
Depends on:
Blocks:
 
Reported: 2012-06-05 21:19 UTC by Tom Zanussi
Modified: 2012-08-14 07:54 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Zanussi 2012-06-05 21:19:30 UTC
This bug is a placeholder for 1.3 BSP-related work to be handed off (from Tom to Nitin).

In general, we want to move all the meta-intel BSPs to the new kernel version every cycle.

For emenlow, we not only want to move the BSP to the 3.4 kernel, but we also want to at the same time upgrade the graphics to EMGD, as requested by customers (see bug 2391).  This may mean replacing the current emenlow psb graphics i.e. removing it in favor of EMGD, or we may want to keep the psb graphics around, which in itself will require additional kernel modifications and recipe upgrades.

The same considerations as mentioned in bug 2543 therefore would apply here, with the additional work of adding the -noemgd version, assuming we wanted a non-proprietary version, which we should now be able to do with the recent gma500 driver in the kernel.

As for the kernel itself, the work basically entails modifying the kernel recipes and machine configuration to upgrade to the new kernel, along with verifying that all the kernel configuration related to the BSP in the meta branch of the 3.4 kernel repo exists and has been properly enabled.  Note that with 2-point kernel version jumps e.g. 3.2 -> 3.4, the underlying kernel options may have changed and may no longer apply and therefore the corresponding features may no longer exist or their contents may have changed, etc.  Moving a BSP to a new kernel therefore entails testing all the functionality to make sure nothing's regressed.
Comment 1 Nitin Kamble 2012-06-08 23:05:52 UTC
will start moving to BSPs 3.4 with emenlow
Comment 2 Nitin Kamble 2012-06-12 23:52:07 UTC
I created a v3.4 recipe extension of linux-yocto for emenlow machine. I am not switching to emgd yet. The kernel is booting, network is working, but the X is not coming up. The X log as seen bellow shows missing kernel drm  driver.

I also see modprobe failures:
root@emenlow:/lib/modules/3.4.1-yocto-standard# modprobe drm
Segmentation fault
root@emenlow:/lib/modules/3.4.1-yocto-standard# modprobe psb
Segmentation fault

And dmesg is showing messages like this:
modprobe[994]: segfault at 83535630 ip 4d1ab1f8 sp bfd2028c error 6 in libkmod.so.2.1.2[4d1a3000+17000]
modprobe[995]: segfault at 83535630 ip 4d1ab1f8 sp bfb2dfcc error 6 in libkmod.so.2.1.2[4d1a3000+17000]

and lsmod is failing too:
root@emenlow:/lib/modules/3.4.1-yocto-standard# lsmod
Segmentation fault
dmesg: lsmod[1002]: segfault at 83535630 ip 4d1ab1f8 sp bfd9799c error 6 in libkmod.so.2.1.2[4d1a3000+17000]

root@emenlow:/lib/modules/3.4.1-yocto-standard# cat /proc/modules
root@emenlow:/lib/modules/3.4.1-yocto-standard#


Tom,
  I see you have patches of psb/drm in the emenlow branch. So I guess you have seen this kind of failure before. So can you help me understand what this error means? And what is the right approach to fix it?


(==) PSB(0): DPI set to (96, 96)
(--) Depth 24 pixmap format is 32 bpp
(II) PSB(0): Debug: psbScreenInit
(II) PSB(0): Debug: psbDRIScreenInit
(II) PSB(0): Debug: SAREA size is 8192
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: open result is -1, (No such device or address)
drmOpenDevice: Open failed
[drm] failed to load kernel module "psb"
(EE) [drm] drmOpen failed.
(EE) PSB(0): [dri] DRIScreenInit failed. Disabling DRI.
(EE) [drm] Could not uninstall irq handler.
(EE) PSB(0): This driver currently needs DRM to operate.

Fatal server error:
AddScreen/ScreenInit failed for driver 0


Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

root@emenlow:~# ls /dev/dri/
root@emenlow:~#
Comment 3 Tom Zanussi 2012-06-13 14:25:35 UTC
Normally for emenlow, when Bruce brings things over from the previous kernel, the commits for emenlow in the kernel don't apply, so I end up doing it all myself, which generally entails fixing the problems I see when starting from scratch.  See for example, the series of commits starting with the below in the 3.2 kernel: 

commit 7bf09a070caace0a36ecb8385df2dd92d2047ddf
Author: Tom Zanussi <tom.zanussi@intel.com>
Date:   Fri Jul 29 23:17:39 2011 -0500

    drm: add the base source of the Poulsbo (psb) 2D X11 driver
    
    The complete source of the base (unpatched) psb-kernel-source Poky
    package, moved into the kernel tree so it can be build as a
    first-class citizen instead of as an external module.  Subsequent
    patches will remove the unnecessary parts.
    
    The code here is all the code contained in this tarball:
    
    https://launchpad.net/~gma500/+archive/ppa/+files/
        psb-kernel-source_4.42.0-0ubuntu2~1010um5.tar.gz

So what I do is start by downloading the psb-kernel-src as above (I believe that code isn't really being updated much any more, which is one of the reasons also to move to EMGD) and apply it to the tree with all the changes noted in the other commits in that series.

For the past couple kernel upgrades, this has been non-trivial and there have also been run-times problems (also reflected in the commit history).

In the case of the 3.4 kernel, apparently all the patches did apply so Bruce merged them into the 3.4 kernel.

Whether they built correctly or not is another question - you should look at the build output and the generated .config to make sure all the settings in the drm-psb feature actually appear in the ending .config and the module gets built.  It seem from your results that it may not have.

But actually it seems like your image has bigger problems unrelated to the psb driver if the module commands are segfaulting e.g. if lsmod segfaults, it's a problem you'll need to look into.

My plan for the 3.4 kernel was to just not do the psb upgrade this time around i.e. drop it in favor of emgd and a new -noemgd version like the other emgd bsps.

So I would recommend upgrading to emgd first, and dropping the psb stuff, but that's up to you.
Comment 4 Nitin Kamble 2012-06-22 06:17:36 UTC
I tried v3.4.3 kernel pieces from bruce's contrib branch. And the emenlow bsp is booting fine. The X is refusing to come up, due to missing psb kernel driver. As Tom is working on changing emenlow bsp from psb driver to emgd driver for graphics, I am ignoring the graphics issues for now. The network, keyboard, mouse are working well.
Comment 5 Nitin Kamble 2012-06-22 20:51:34 UTC
Once Bruce's 3.4.3 changes goes in, I will be able to push my changes on top.
Comment 7 Alexandru Georgescu 2012-08-14 07:54:10 UTC
Setting to verified fixed.