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. Of the four BSPs being handed over in the initial stage, the sugarbay and fishriver should be relatively straightforward. For sugarbay/huronriver, this should be a relatively straightforward task. It 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.
Tom, I am able to build 3.4 kernel and core-image-sato for sugarbay BSP. I will like to know what is involved in testing a BSP to make sure it is complete. Can you give more details how to test a BSP ?
For testing, you should make sure basic functionality works before passing it off to QA, who will do more involved testing according to the QA plan. Generally, for all the meta-intel BSPs, I build and boot a sato image. For all the BSPs, the BSP should successfully boot into X with all icons, etc. The mouse and keyboard should both work correctly. If the box has PS/2 ports, you should also test using a PS/2 mouse and keyboard. Open up the terminal application and you should get a functional terminal without error messages or anything unusual. From the terminal window, I run ifconfig to get the machines IP address. You should then be able to ssh into the box; this tests that network functionality is working. You should check the dmesg output to make sure there's nothing unusual there, such as kernel oopsen. You should also run 'uname -a' and make sure you're running the expected kernel version. For the BSPs you care about graphics for, you should also test that basic 3-d and video acceleration works. To test 3-d acceleration, you need to add 'tools-testapps' to EXTRA_IMAGE_FEATURES. This will add 'glxgears' and 'glxinfo' to the image. glxgears should run without any jumpiness when moving the mouse. glxinfo should show that direct rendering is being used, along with an appropriate OpenGL renderer string i.e. not showing software rendering. You should test this on the BSPs we care about 3d acceleration on: crownbay sugarbay chiefriver fri2 But not the -noemgd versions - we don't care about 3d on those. To test video acceleration, you should download a 1080p h264 video and play it using gstreamer e.g. gst-launch playbin2 uri="file:///home/root/dictator.mp4" The video should be smooth and high-definition and top should show low cpu utilization e.g. 5% on sugarbay and chiefriver, 25% or less on crownbay and fri2. It will be obvious if acceleration isn't working on the atom machines as you'll get about 1/2 frame a second if not. You should also hear sound when you play the videos, which provides a minimal sound test. You can also upload a .wav file and play it using the media player app. The video acceleration tests currently apply to the following BSPs: crownbay sugarbay chiefriver fri2 But not the -noemgd versions.
Tom, Thanks a lot for these detailed instructions. I can't ask for more clearer instructions. Now I need to find a good 1080p h264 video for testing :) Few more things I would like to know are, how the hand-off to QA for testing is performed. Is it one BSP hadded-off to QA at a time or is it performed when all BSPs are ready ? What is the process to initiate this hand-off ? Thanks, Nitin
(In reply to comment #3) > Tom, Thanks a lot for these detailed instructions. I can't ask for more > clearer instructions. Now I need to find a good 1080p h264 video for testing > :) > > Few more things I would like to know are, how the hand-off to QA for testing > is performed. Is it one BSP hadded-off to QA at a time or is it performed > when all BSPs are ready ? What is the process to initiate this hand-off ? > > > Thanks, > Nitin I can send you one that I use if you can tell me where to upload it. As for handing off, there really isn't a handoff process - QA will test whatever's in meta-intel - some of the BSPs may be 'old' and some may be recent upgrades. They'll take whatever's in meta-intel/master at each milestone, and also at release time, whatever's in the new release e.g. meta-intel/denzil. Essentially, the goal is to get them all working properly for each release, which you do by gradually upgrading them in master and then capturing them all in a release branch for release testing, then starting the whole process over for the next release.
> > I can send you one that I use if you can tell me where to upload it. Tome, you can put it in /tmp of yocto-hm1, I will move it from there. Thanks, Nitin
(In reply to comment #5) > > > > I can send you one that I use if you can tell me where to upload it. > > Tome, you can put it in /tmp of yocto-hm1, I will move it from there. > > Thanks, > Nitin OK, the file is /tmp/dictator.mp4
Tom and Nitin, please provide an estimate and specify the target milestone. Obviously this HAS to happen for the 1.3 release, so marking as a P1.
I am trying this, and finding that, with the linux-yocto3.4 kernel init is failing to come up and throwing seg-fault. The same setup with 3.2 linux yocto kernel boots fine. Not reached to the root cause of this issue yet. Looking at config differences between 3.2 & 3.4 kerneles. Also notice that on FRI1 the 3.4 kernel is unable to bring up "login" process, due to dynamic linking issues. Nitin
Today I tested linux-yocto kernel v3.4.3 from Bruces's contrib branch on sugarbay. And it booted fine, and also all the tests mentioned in this bug passed. Nitin
Once Bruce's 3.4.3 changes goes in, I will be able to push my changes on top.
This work is upstreamed now: http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=1fc06d4e90d728ff8260f8595d78497c9fc5864a
Hi, I have verified the version change to 3.4 with the Sugarbay build 0712-1.
Verified after last comment