1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Re: GRUB fix for 1.1: Preferred approach for default grub version

Tom Zanussi <tom.zanussi@...>
 

On Mon, 2011-10-03 at 12:01 -0700, Richard Purdie wrote:
On Mon, 2011-10-03 at 11:48 -0700, Darren Hart wrote:
When grub2 was merged int oe-core, it became the default (rather than
being explicitly requested by the 64b meta-intel BSPs). This breaks the
live install on 32b systems, like the n450 - installing grub v1.99 with
a grub v1 config.

We have a couple options on how to fix this.

1) Set PREFERRED_PROVIDER_grub="0.97" in all 32b x86 machine configs
2) Set DEFAULT_PREFERENCE="-1" in the grub_1.99.bb recipe which would
affect all of oe-core.
3) Some alternate approach which would be the equivalent of
DEFAULT_PREFERENCE, but only for meta-yocto BSPs or the poky
"distro".

Given the time frame, I'd prefer to agree on the approach before writing
and testing patches. Preferences?
I thought I'd been assured grub2 worked fine for our 32 and 64 bit
platforms? :/.

The correct question here is why doesn't grub2 work on 32 bit platforms?
I did test it with both 32-bit and 64-bit BSPs in meta-intel, so it
should work for the n450 too.

Tom

The answer might be "we need for time than is available in the 1.1
release to fix it" but I'd at least like to see the answer to the
question before we start with workarounds.

Cheers,

Richard
Re: GRUB fix for 1.1: Preferred approach for default grub version

Tom Zanussi <tom.zanussi@...>
 

On Mon, 2011-10-03 at 11:48 -0700, Darren Hart wrote:
When grub2 was merged int oe-core, it became the default (rather than
being explicitly requested by the 64b meta-intel BSPs). This breaks the
live install on 32b systems, like the n450 - installing grub v1.99 with
a grub v1 config.

We have a couple options on how to fix this.

1) Set PREFERRED_PROVIDER_grub="0.97" in all 32b x86 machine configs
2) Set DEFAULT_PREFERENCE="-1" in the grub_1.99.bb recipe which would
affect all of oe-core.
3) Some alternate approach which would be the equivalent of
DEFAULT_PREFERENCE, but only for meta-yocto BSPs or the poky
"distro".

Given the time frame, I'd prefer to agree on the approach before writing
and testing patches. Preferences?
Not sure why it wouldn't work for the n450 - it worked for the other
32-bit BSPs in meta-intel. Let me take a look...

Tom

Thanks,
Re: GRUB fix for 1.1: Preferred approach for default grub version

Richard Purdie
 

On Mon, 2011-10-03 at 11:48 -0700, Darren Hart wrote:
When grub2 was merged int oe-core, it became the default (rather than
being explicitly requested by the 64b meta-intel BSPs). This breaks the
live install on 32b systems, like the n450 - installing grub v1.99 with
a grub v1 config.

We have a couple options on how to fix this.

1) Set PREFERRED_PROVIDER_grub="0.97" in all 32b x86 machine configs
2) Set DEFAULT_PREFERENCE="-1" in the grub_1.99.bb recipe which would
affect all of oe-core.
3) Some alternate approach which would be the equivalent of
DEFAULT_PREFERENCE, but only for meta-yocto BSPs or the poky
"distro".

Given the time frame, I'd prefer to agree on the approach before writing
and testing patches. Preferences?
I thought I'd been assured grub2 worked fine for our 32 and 64 bit
platforms? :/.

The correct question here is why doesn't grub2 work on 32 bit platforms?

The answer might be "we need for time than is available in the 1.1
release to fix it" but I'd at least like to see the answer to the
question before we start with workarounds.

Cheers,

Richard
GRUB fix for 1.1: Preferred approach for default grub version

Darren Hart <dvhart@...>
 

When grub2 was merged int oe-core, it became the default (rather than
being explicitly requested by the 64b meta-intel BSPs). This breaks the
live install on 32b systems, like the n450 - installing grub v1.99 with
a grub v1 config.

We have a couple options on how to fix this.

1) Set PREFERRED_PROVIDER_grub="0.97" in all 32b x86 machine configs
2) Set DEFAULT_PREFERENCE="-1" in the grub_1.99.bb recipe which would
affect all of oe-core.
3) Some alternate approach which would be the equivalent of
DEFAULT_PREFERENCE, but only for meta-yocto BSPs or the poky
"distro".

Given the time frame, I'd prefer to agree on the approach before writing
and testing patches. Preferences?

Thanks,

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
Re: Fixes to consider for a Bernard point release.

Liu, Song <song.liu@...>
 

Thank you Scott. This is a great list to start with.

Hi Everyone,

I changed the email subject and moved this thread to the public mailing list. Let's use this thread as the place to collect patches we recommend for the 1.0 Bernard point release. So please contribute if you have something in mind. But please make sure that this effort won't affect any of your 1.1 release related work. 1.1 release is our priority now.

Thanks!
Song

-----Original Message-----
From: Scott Garman [mailto:scott.a.garman@...]
Sent: Friday, September 30, 2011 4:30 PM
To: Liu, Song
Cc: Yocto Project Discussions
Subject: Security related fixes to consider for a Bernard point release.

Hi Song,

At the last staff meeting, Paul brought up the possibility of doing
another point-release for Bernard, at least to include some security
fixes. I went and ran a scan on the bernard recipe versions using my CVE
checker scripts, and came up with this short list of security fixes that
we may wish to consider:

python CVE-2011-1015
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1015
libpng CVE-2011-2690
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2690
libpng CVE-2011-2692
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2692

So it looks like only the python and libpng recipes would need to be
upgraded.

Scott

--
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center
Minutes: Yocto Project 1.1 release go/no-go meeting

Liu, Song <song.liu@...>
 

Attendees:
Beth, Josh, Scott Rifenbark, Richard, Mark, Dirk, Saul, John Cherry, Dave, Darren, Song
 
* Background:
Linux Foundation security breach knocked out our access to build and repos servers for a few days. We were also upgrading autobuilder at the time and we had some issues with the upgrade also. So we have to delay our release. We have brought the release date change recommendation to the Yocto CCB (Change Control Board), and the board has approved the change. The new release date is Oct 17th. (Our QA team in Shanghai has a national holiday from Oct. 1st to Oct. 7th). So the purpose of this meeting is to go over things we are going to put in RC4, and come up with a contingency plan if RC4 fails our release standard.
 
* RC3 status: Mostly green, Some HOB and mutilib issues, fixes for HOB and multilib,
 
* What fixes are being recommended to include in RC4:
- HOB fixes
- Small kernel update, fix some configuration issues,
- Multi-lib issues: most of them are low risk, one invasive change, but we will test it this week
- QA team (Shanghai) is on a 7-day holiday. We have time to test these fixes before QA next week
- We already have the patches in edison contrib branch, other than the x qt3 issues, our build is green
- X32 recipe kernel.org URL issue, blocking X32 test, recommend include
- Fixes for 1523/1533, already in master, recommend to include
 
* Action item: Triage team will review all open bugs and work out a list of items we will document in 1.1 release note.
 
* Contingency plan:
- IF RC4 has some serious issues, we have 2 options, one is to go back to RC3, the other is to have another RC5. We will have one week before ELCE after Oct. 17th and our mirror sites are still down.
- The team agrees that we should go with RC5 for contingency.
[PATCH 4/4] meta-sugarbay: update README

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Update meta-sugarbay to reflect the new image names and a couple other
minor cleanups.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
meta-sugarbay/README | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta-sugarbay/README b/meta-sugarbay/README
index 7899205..2d72f8a 100644
--- a/meta-sugarbay/README
+++ b/meta-sugarbay/README
@@ -10,8 +10,7 @@ Table of Contents
=================

I. Building the meta-sugarbay BSP layer
- II. Special notes for building the meta-sugarbay BSP layer
-III. Booting the images in /binary
+ II. Booting the images in /binary


I. Building the meta-sugarbay BSP layer
@@ -34,8 +33,8 @@ To enable the sugarbay layer, add the sugarbay MACHINE to local.conf:

You should then be able to build a sugarbay image as such:

- $ source poky-init-build-env
- $ bitbake poky-image-sato-live
+ $ source oe-init-build-env
+ $ bitbake core-image-sato

At the end of a successful build, you should have a live image that
you can boot from a USB flash drive (see instructions on how to do
@@ -45,10 +44,11 @@ As an alternative to downloading the BSP tarball, you can also work
directly from the meta-intel git repository. For each BSP in the
'meta-intel' repository, there are multiple branches, one
corresponding to each major release starting with 'laverne' (0.90), in
-addition to the latest code which tracks the current master. Instead
-of extracting a BSP tarball at the top level of your yocto build tree,
-you can equivalently check out the appropriate branch from the
-meta-intel repository at the same location.
+addition to the latest code which tracks the current master (note that
+not all BSPs are present in every release). Instead of extracting a
+BSP tarball at the top level of your yocto build tree, you can
+equivalently check out the appropriate branch from the meta-intel
+repository at the same location.


II. Booting the images in /binary
@@ -61,7 +61,7 @@ Under Linux, insert a USB flash drive. Assuming the USB flash drive
takes device /dev/sdf, use dd to copy the live image to it. For
example:

-# dd if=poky-image-sato-live-sugarbay-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-sugarbay-20101207053738.hddimg of=/dev/sdf
# sync
# eject /dev/sdf

--
1.7.0.4
[PATCH 3/4] meta-jasperforest: update README

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Update meta-jasperforest to reflect the new image names and a couple
other minor cleanups.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
meta-jasperforest/README | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/meta-jasperforest/README b/meta-jasperforest/README
index 6421d06..7652da0 100644
--- a/meta-jasperforest/README
+++ b/meta-jasperforest/README
@@ -35,8 +35,8 @@ To enable the jasperforest layer, add the jasperforest MACHINE to local.conf:

You should then be able to build a jasperforest image as such:

- $ source poky-init-build-env
- $ bitbake poky-image-sato-live
+ $ source oe-init-build-env
+ $ bitbake core-image-sato

At the end of a successful build, you should have a live image that
you can boot from a USB flash drive (see instructions on how to do
@@ -46,10 +46,11 @@ As an alternative to downloading the BSP tarball, you can also work
directly from the meta-intel git repository. For each BSP in the
'meta-intel' repository, there are multiple branches, one
corresponding to each major release starting with 'laverne' (0.90), in
-addition to the latest code which tracks the current master. Instead
-of extracting a BSP tarball at the top level of your yocto build tree,
-you can equivalently check out the appropriate branch from the
-meta-intel repository at the same location.
+addition to the latest code which tracks the current master (note that
+not all BSPs are present in every release). Instead of extracting a
+BSP tarball at the top level of your yocto build tree, you can
+equivalently check out the appropriate branch from the meta-intel
+repository at the same location.


II. Booting the images in /binary
@@ -62,7 +63,7 @@ Under Linux, insert a USB flash drive. Assuming the USB flash drive
takes device /dev/sdf, use dd to copy the live image to it. For
example:

-# dd if=poky-image-sato-live-jasperforest-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-jasperforest-20101207053738.hddimg of=/dev/sdf
# sync
# eject /dev/sdf

--
1.7.0.4
[PATCH 2/4] meta-fishriver: update README

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Update meta-fishriver to reflect the new image names and a couple
other minor cleanups.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
meta-fishriver/README | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/meta-fishriver/README b/meta-fishriver/README
index 013f76e..b76056c 100644
--- a/meta-fishriver/README
+++ b/meta-fishriver/README
@@ -6,13 +6,12 @@ Please see the corresponding sections below for details.
Table of Contents
=================

- I. Special notes on the meta-fishriver BSP layer
- II. Building the meta-fishriver BSP layer
-III. Booting the images in /binary
+ I. Building the meta-fishriver BSP layer
+ II. Booting the images in /binary


-II. Building the meta-fishriver BSP layer
-=========================================
+I. Building the meta-fishriver BSP layer
+========================================

In order to build an image with BSP support for a given release, you
need to download the corresponding BSP tarball from the 'Board Support
@@ -31,8 +30,8 @@ To enable the fishriver layer, add the fishriver MACHINE to local.conf:

You should then be able to build a fishriver image as such:

- $ source poky-init-build-env
- $ bitbake poky-image-sato-live
+ $ source oe-init-build-env
+ $ bitbake core-image-sato

At the end of a successful build, you should have a live image that
you can boot from a USB flash drive (see instructions on how to do
@@ -42,14 +41,15 @@ As an alternative to downloading the BSP tarball, you can also work
directly from the meta-intel git repository. For each BSP in the
'meta-intel' repository, there are multiple branches, one
corresponding to each major release starting with 'laverne' (0.90), in
-addition to the latest code which tracks the current master. Instead
-of extracting a BSP tarball at the top level of your yocto build tree,
-you can equivalently check out the appropriate branch from the
-meta-intel repository at the same location.
+addition to the latest code which tracks the current master (note that
+not all BSPs are present in every release). Instead of extracting a
+BSP tarball at the top level of your yocto build tree, you can
+equivalently check out the appropriate branch from the meta-intel
+repository at the same location.


-III. Booting the images in /binary
-==================================
+II. Booting the images in /binary
+=================================

This BSP contains bootable live images, which can be used to directly
boot Yocto off of a USB flash drive.
@@ -58,7 +58,7 @@ Under Linux, insert a USB flash drive. Assuming the USB flash drive
takes device /dev/sdf, use dd to copy the live image to it. For
example:

-# dd if=poky-image-sato-live-fishriver-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-fishriver-20101207053738.hddimg of=/dev/sdf
# sync
# eject /dev/sdf

--
1.7.0.4
[PATCH 1/4] meta-emenlow: update README

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Update meta-emenlow to reflect the new image names and a couple
other minor cleanups.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
meta-emenlow/README | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/meta-emenlow/README b/meta-emenlow/README
index 6592a70..fc3317e 100644
--- a/meta-emenlow/README
+++ b/meta-emenlow/README
@@ -40,8 +40,8 @@ To enable the emenlow layer, add the emenlow MACHINE to local.conf:

You should then be able to build an emenlow image as such:

- $ source poky-init-build-env
- $ bitbake poky-image-sato-live
+ $ source oe-init-build-env
+ $ bitbake core-image-sato

At the end of a successful build, you should have a live image that
you can boot from a USB flash drive (see instructions on how to do
@@ -51,10 +51,11 @@ As an alternative to downloading the BSP tarball, you can also work
directly from the meta-intel git repository. For each BSP in the
'meta-intel' repository, there are multiple branches, one
corresponding to each major release starting with 'laverne' (0.90), in
-addition to the latest code which tracks the current master. Instead
-of extracting a BSP tarball at the top level of your yocto build tree,
-you can equivalently check out the appropriate branch from the
-meta-intel repository at the same location.
+addition to the latest code which tracks the current master (note that
+not all BSPs are present in every release). Instead of extracting a
+BSP tarball at the top level of your yocto build tree, you can
+equivalently check out the appropriate branch from the meta-intel
+repository at the same location.


II. Booting the images in /binary
@@ -67,7 +68,7 @@ Under Linux, insert a USB flash drive. Assuming the USB flash drive
takes device /dev/sdf, use dd to copy the live image to it. For
example:

-# dd if=poky-image-sato-live-emenlow-20101207053738.hddimg of=/dev/sdf
+# dd if=core-image-sato-emenlow-20101207053738.hddimg of=/dev/sdf
# sync
# eject /dev/sdf

--
1.7.0.4
[PATCH 0/4] meta-intel: README updates

tom.zanussi@...
 

From: Tom Zanussi <tom.zanussi@...>

Some minor updates to the meta-intel BSP README files.

The following changes since commit 527d0c90cc37ca988745578e213fb451fd6a6fe4:
Tom Zanussi (1):
xpsb-glx: Move the pkgconfig file(s) to the -dev package

are available in the git repository at:

git://git.yoctoproject.org/meta-intel.git tzanussi/readme-updates
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/readme-updates

Tom Zanussi (4):
meta-emenlow: update README
meta-fishriver: update README
meta-jasperforest: update README
meta-sugarbay: update README

meta-emenlow/README | 15 ++++++++-------
meta-fishriver/README | 28 ++++++++++++++--------------
meta-jasperforest/README | 15 ++++++++-------
meta-sugarbay/README | 18 +++++++++---------
4 files changed, 39 insertions(+), 37 deletions(-)
Agenda: Yocto Technical Team Meeting - (Tuesday, October 04, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

* Opens collection - 5 min (Song)
* Yocto 1.1 M4 status review and issues - 15 min (team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria#Milestone_
- Bug fixing & QA (Song)
- Build status (Beth)
- Release schedule and contingency plan
* Opens - 10 min
* Weekly team sharing (30 min)

--------------------------------------------

Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 28, 2011 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
49611427
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a chairperson:
1.972.995.7777x67184230#
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x49611427#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free)
Airtel subscribers use 0008 009 861 212 (Toll Free)
From TI Campus use 89957777
Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 28, 2011
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 22, 2012, 10:40 AM CDT
Agenda: Yocto Project 1.1 release go/no-go meeting - (Monday, October 03, 2011 8:00 AM-8:30 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

Hi team,

The release date change for Yocto 1.1 has been approved by Yocto CCB (Change Control Board). The new release date is Oct 17th, 2011. But I would like to use this meeting to:

1. Discuss our strategy for RC4 and what goes into RC4
2. Discuss the contingency plan if RC4 does not meet our expectation.

Song


Monday, October 03, 2011, 08:00 AM US Pacific Time
916-356-2663, 8-356-2663, Bridge: 94, Passcode: 4176277
Speed dialer: inteldialer://94,4176277 | Learn more
Re: github instead of kernel.org

McClintock Matthew-B29882 <B29882@...>
 

On Fri, Sep 30, 2011 at 10:02 AM, James Abernathy <jfabernathy@...> wrote:
Since Linus Torvalds has switched the linux git from kernel.org to
https://github.com/torvalds/linux.git ,

Is there a simple edit to make the switch in Yocto/poky???
You can try updating the recipe itself and/or place around with
KERNELORG_MIRROR.

-M
Fullpass Test Report for Yocto 1.1 M4 RC3 20110923 Build

Xu, Jiajun <jiajun.xu@...>
 

Hi All,

       This is the fullpass test report for Yocto 1.1 M4 20110923 build. There are 2 new bugs found. x32 build could not work due to kernel.org fetch failure. All lib32/lib64 build against qemux86/qemux86-64 could not work, which should be fixed in master. Hob does not work stable with ipk/deb switching. There is no regression issue found for performance testing. Both Crashme/Helltest testing on Jasperforest and LTP testing on Beagleboard could pass 24 hours stress testing.

Note：For different images, they are built against different commit/branch on autobuilder. You can refer to “Commit Information” section for detailed information. The test report is archived @https://wiki.pokylinux.org/wiki/Yocto_1.1_Milestone_Test_Report

 

 

Test Summary:

---------------------------------------

Test Result Summary

Component

Target

Status

Comments

BSP

eMenlow

GOOD

I2C_transfer error; Standby failed;

Blacksand

GOOD

Everything runs well

Crownbay-emgd

GOOD

Xorg eat lots of cup's resource after standby

Sugarbay

GOOD

Everything runs well

Jasperforest-lsb

GOOD

I/OAT DMA engine init failed;

Beagleboard

GOOD

Everything runs well

Routerstationpro

GOOD

Everything runs well

Mpc8315e-rdb

GOOD

Everything runs well

QEMU

qemux86

GOOD

Everything runs well

qemux86-64

GOOD

Everything runs well

qemuarm

GOOD

Everything runs well

qemuppc

GOOD

Everything runs well

qemumips

GOOD

Everything runs well

ADT

　

GOOD

Everything runs well

Core build system

　

BUGGY

Multilib could not work; lib32/lib64 build against qemux86/qemux86-64 could not work; x32 build not work due to broken source URL.

Power/Performance

　

GOOD

Power consumption of sugarbay and crownbay are 42.91W and 23.82W respectively
Build time for a sato image on Core i7 machine is 127 minutes.

Compliance

　

GOOD

No regression for LTP and POSIX

Stress

　

GOOD

Both Crashme/Helltest testing on Jasperforest and LTP testing on Beagleboard could pass 24 hours stress testing.

HOB

　

BUGGY

Switching package format in hob is unstable;

 

　

Critical bugs, more than 50% test cases are blocked

　

Only Normal, Minor or Enhancement bugs, or less than 10% test cases failed

　

Normal, Major and Critical bugs, and more than 10% test cases failed

Detailed Test Result for each component

 

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

 

eMenlow Sato-SDK

63

0

61

2 (bug 310, 503)

0

 

n450 Sato-SDK

73

0

73

0

0

 

Crownbay-Sato-SDK

74

0

73

1 (bug 1258)

0

 

Sugarbay Sato-SDK

67

0

67

0

0

 

Jasperforest lsb-SDK

32

0

31

1 (bug 1188)

0

 

Beagleboard Sato-SDK

39

0

39

0

0

 

Routerstationpro Sato-SDK

33

0

33

0

0

 

Mpc8315e-rdb Sato-SDK

36

0

36

0

0

 

Qemux86-64 Sato

29

0

28

1 (bug 1174)

0

 

Qemux86-64 Sato-SDK

34

0

33

1 (bug 1174)

0

 

Qemux86 Sato

29

0

28

1 (bug 1174)

0

 

Qemux86 Sato-SDK

34

0

33

1 (bug 1174)

0

 

Qemuarm Sato

29

0

29

0

0

 

Qemuarm Sato-SDK

34

0

34

0

0

 

Qemumips Sato

29

0

29

0

0

 

Qemumips Sato-SDK

34

0

34

0

0

 

Qemuppc Sato

21

0

21

0

0

 

Qemuppc Sato-SDK

26

0

26

0

0

 

ADT

6

0

6

0

0

 

Core build system

31

0

22

9 (bug 1496, 1497, 1498, 1519, 1522, 1527, 1529)

0

 

Power & Performance

5

0

5

0

0

 

Compliance

2

0

2

0

0

 

Stress

3

0

3

0

0

 

HOB

26

0

24

2 (bug 1521)

0

 

Total

789

0

770

17

0

 

 

 

Commit Information

---------------------------------------

 

For Crownbay:

Tree/Branch: Poky/Edison

Commit id: 0e9784d26df51bd564b8f23bd40a6c36969abd5c

Meta branch: Edison

Commit id: 7eb193fc4994b880ce115fc00fb52b4d9cda530e

 

For eMenlow/Blacksand/Sugarbay/Jasperforest/Qemex86-64/:

Tree/Branch: Poky-contrib/Edison

Commit id: 0e9784d26df51bd564b8f23bd40a6c36969abd5c

Meta branch: Edison

Commit id: d1e7b21f79d3ecfc6fbdb1d995f0b6e6bff8bea5

 

For Beagleboard/Routerstationpro/Mpc8315e-rdb/QemuArm/QemuMips/QemuPPC:

Tree/Branch: Poky/edison
Commit id: 41c564fe605fa4685fd27b1721e3424ac8a96db1

 

Issue Summary

---------------------------------------

Component

Bug Number

Target Milestone

System & Core OS

System Usage

Bug 503 - [emenlow] system cannot enter S3 standby mode

1.1

Bug 1082 - [x86_64] No icons shown on X desktop with sato image

1.0 M2

Bug 1174: [zypper/rpm] package install/removal costs lots of disk space

1.1 M3

Other

Bug 310 - [eMenlow] i2c_transfer error on e-Menlow

1.1

Bug 1188 - [japerforest] I/OAT DMA engine init failed

post 1.1

Bug 1258 -[crownbay] Xorg eats lots of CPU time after standby

1.1 M4

Core build system

New! Bug 1527 - [multilib] lib64 build against qemux86-64 failed during do_rootfs

1.1

New! Bug 1529 - [x32] x32 build broken due to kernel.org fetch failure

1.1

Bug 1496 - [multilib] no lib32-task-core-ssh-dropbear found for lib32 image build

1.1

Bug 1497 - [multilib] lib32 build against qemux86-64 failed during do_rootfs

1.1

Bug 1498 - [multilib] lib64 build against qemux86 failed during do_rootfs

1.1

Bug 1519 - [multilib/rpm] X not start up with lib32 build with connman against qemux86-64

　

Bug 1522 - [multilib/ipk] /var/lib/opkg/status changed after the 1st boot

　

Bug 1502 - [multilib] lib64-dpkg is unbuildable for lib64 build

post 1.1

Power & Performance

Power consumption of sugarbay and crownbay are 42.91W and 23.82W respectively.
Build time for a sato image on Core i7 machine is 127 minutes. Detailed result on https://wiki.yoctoproject.org/wiki/Performance_Test.

　

Compliance

LTP result: https://wiki.yoctoproject.org/wiki/LTP_result
POSIX result: https://wiki.pokylinux.org/wiki/Posix_result

　

Stress

Both Crashme and Helltest testing on Jasperforest could pass 24 hours stress testing.

　

Hob

Bug 1521 - Switching package format in hob is unstable

1.1

 

 

Verified Fixed Bug:

---------------------------------------

1.     Bug 1493 - gcc-cross-canadian set to 4.6 when GCCVERSION is 4.5.1

2.     Bug 1480 - [HOB] Could not trigger another build after stop build

3.     Bug 1492 - non-GPLv3 build broken with incompatible license for gcc-crosssdk-intermediate

4.     Bug 1495 - [x32] No tclibc-glibc.inc found for x32 build

5.     Bug 1493 - gcc-cross-canadian set to 4.6 when GCCVERSION is 4.5.1

 

Best Regards,

Jiajun

?
Yocto 1.1 M4 RC3 - 20110923 detail_testreport-fullpass.ods

github instead of kernel.org

Jim Abernathy
  

Since Linus Torvalds has switched the linux git from kernel.org to https://github.com/torvalds/linux.git ,
Is there a simple edit to make the switch in Yocto/poky???

 

 

Jim A
FW: Virtual keyboard ?

Noel_V
 

Hi Gary,

Tweaked my arm configuration (with touch-screen) as you said and, ok I
see a virtual keyboard poping-up as YOU expected. So far so good.

But now I'm facing another question that I would like to try.

I would like to open a web-page (BUT do not have WEB-browser on this
yocto-1.0 build, correct me if I'm wrong {please} ) I wonder what will
happen if I touch an edit-field located on the 'bottom' of the screen
(this is where the virtual key-board-pops-up)?

Do you have (or know wher to find) any INFO onhow this 'auto-pupop' of
the virtual keyboard is working (in other words how does the key-board
getting triggered to be shown/hidden) ?

Regards Noel.


PS: sorry for forgetting the CC to the mailing list.

-----Original Message-----
From: Gary Thomas [mailto:gary@...]
Sent: 30Sep11 16:09
To: Vellemans, Noel
Subject: Re: [yocto] Virtual keyboard ?

On 2011-09-30 08:05, Vellemans, Noel wrote:
Ok, I'll give it a try...

At this time I'm running an ARMV7 build on imx537 cpu (w. a mouse and
keyb), but I'll tweak the config and connect a Touch-screen to it ..
To give it a try.

Thanks for the response
Good luck. Note: it's polite to copy replies on the mailing list so
that everyone can see it and benefit from the discussion.

-----Original Message-----
From: Gary Thomas [mailto:gary@...]
Sent: 30Sep11 15:54
To: Vellemans, Noel
Cc: yocto@...
Subject: Re: [yocto] Virtual keyboard ?

On 2011-09-30 07:31, Vellemans, Noel wrote:
Hi all,

I have a question where I can not find an direct answer to on the
Yocto-web/wiki.

I wonder if the Yocto-arm-sato build supports a device that has
no-REAL keyboard but only a touch-screen.

If so, does the VIRTUAL-keyboard pup-op automatically, if you touch
something that is editable (like in android and/or meego) ?

Yes, this works fine. You just need to set these in
/etc/formfactor/machconfig:
HAVE_TOUCHSCREEN=1
HAVE_KEYBOARD=0

NOTE : I've been playing with the Yocto-1.0 build into qemu and I do
not find how to 'REMOVE' the virtual keyboard once it is visible on
screen.

If it comes up by demand, it will go away when you press enter.

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
Re: [PATCH 0/5][KERNEL] some meta-intel bsp cleanup

Bruce Ashfield <bruce.ashfield@...>
 

On 11-09-29 04:17 PM, tom.zanussi@... wrote:
From: Tom Zanussi<tom.zanussi@...>

This patchset is another step in some cleanup I'm doing for
the meta-intel bsps, basically removing unneeded or redundant
options and abstracting out useful features, in this case a
new vesafb feature used in this patchset by crownbay, emenlow,
and jasperforest.

Please pull into linux-yocto-3.0-(next).
All good stuff. I'll stage this to be in 3.0 for post 1.1
updates, and in the -dev kernel for the next kernel version
that is pushed out.

Bruce


Pull URL: git://git.pokylinux.org/linux-yocto-2.6.37-contrib
Branch: tzanussi/bsp-cleanup-2
Browse: http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/bsp-cleanup-2

Thanks,

Tom

Tom Zanussi (5):
features/drm-psb: add related config options
meta: add vesafb feature
crownbay: cleanup bsp config
emenlow: cleanup bsp config
jasperforest: cleanup bsp config

meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg | 34 ++++--------------
meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc | 5 ++-
meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg | 35 +++++--------------
meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc | 2 +
.../kernel-cache/bsp/jasperforest/jasperforest.cfg | 7 +---
.../kernel-cache/bsp/jasperforest/jasperforest.scc | 2 +
meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg | 13 +++++++
.../kernel-cache/features/framebuffer/vesafb.cfg | 8 ++++
.../kernel-cache/features/framebuffer/vesafb.scc | 1 +
9 files changed, 48 insertions(+), 59 deletions(-)
create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.scc
Re: [PATCH 3/5][KERNEL] crownbay: cleanup bsp config

Bruce Ashfield <bruce.ashfield@...>
 

On 11-09-29 04:17 PM, tom.zanussi@... wrote:
From: Tom Zanussi<tom.zanussi@...>

Remove unnecessary options or options already defined in base configs.
Ack'd. Looks like a nice streamlining.

Bruce


Signed-off-by: Tom Zanussi<tom.zanussi@...>
---
meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg | 34 +++++-----------------
meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc | 5 ++-
2 files changed, 11 insertions(+), 28 deletions(-)

diff --git a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg
index 5daa65b..76a48eb 100644
--- a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg
+++ b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg
@@ -27,6 +27,12 @@ CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_HDA_INTEL=y
CONFIG_SATA_AHCI=y
+CONFIG_AGP=y
+CONFIG_PM=y
+CONFIG_ACPI=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_INPUT=y

# Make sure these are on, otherwise the bootup won't be fun
CONFIG_EXT3_FS=y
@@ -37,33 +43,9 @@ CONFIG_SHMEM=y
CONFIG_TMPFS=y
CONFIG_PACKET=y

-# These are needed for the Poulsbo kernel modules
-CONFIG_I2C=y
-CONFIG_AGP=y
-CONFIG_VFAT_FS=y
-CONFIG_PM=y
-CONFIG_ACPI=y
-CONFIG_FB=y
-CONFIG_BACKLIGHT_LCD_SUPPORT=y
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
-CONFIG_INPUT=y
-CONFIG_VIDEO_V4L2=y
-CONFIG_VIDEO_IVTV=y
-CONFIG_MEDIA_SUPPORT=y
-CONFIG_VIDEO_CAPTURE_DRIVERS=y
-CONFIG_VIDEO_DEV=y
-CONFIG_VIDEO_V4L2_COMMON=y
-CONFIG_I2C_ALGOBIT=y
-CONFIG_FB_CFB_COPYAREA=y
-CONFIG_FB_CFB_IMAGEBLIT=y
-CONFIG_FB_CFB_FILLRECT=y
-CONFIG_VIDEO_FB_IVTV=y
-
# Needed for booting (and using) USB memory sticks
-CONFIG_USB_STORAGE=y
-CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_GZIP=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
+
+CONFIG_RD_GZIP=y
diff --git a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc
index 63b7ad6..3114cbc 100644
--- a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc
+++ b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc
@@ -8,10 +8,11 @@ include features/intel-e1xxxx/intel-e1xxxx.scc
include features/drm-emgd/drm-emgd.scc
include features/dmaengine/dmaengine.scc
include features/serial/8250.scc
+include features/hpet/hpet.scc
+include features/framebuffer/vesafb.scc
+include cfg/usb-mass-storage.scc

include features/logbuf/size-normal.scc

include features/latencytop/latencytop.scc
include features/profiling/profiling.scc
-
-include features/hpet/hpet.scc
Re: [PATCH 2/5][KERNEL] meta: add vesafb feature

Bruce Ashfield <bruce.ashfield@...>
 

On 11-09-29 04:17 PM, tom.zanussi@... wrote:
From: Tom Zanussi<tom.zanussi@...>

Add a 'vesafb feature' that adds basic vesa framebuffer support.
This one is quite useful. I've seen a similar set of options
collected in other kernels and it has come in handy.

Bruce


Signed-off-by: Tom Zanussi<tom.zanussi@...>
---
.../kernel-cache/features/framebuffer/vesafb.cfg | 8 ++++++++
.../kernel-cache/features/framebuffer/vesafb.scc | 1 +
2 files changed, 9 insertions(+), 0 deletions(-)
create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.scc

diff --git a/meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg b/meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
new file mode 100644
index 0000000..9c7f35d
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
@@ -0,0 +1,8 @@
+CONFIG_FB=y
+CONFIG_FB_VESA=y
+CONFIG_FB_BOOT_VESA_SUPPORT=y
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
diff --git a/meta/cfg/kernel-cache/features/framebuffer/vesafb.scc b/meta/cfg/kernel-cache/features/framebuffer/vesafb.scc
new file mode 100644
index 0000000..c113097
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/framebuffer/vesafb.scc
@@ -0,0 +1 @@
+kconf non-hardware vesafb.cfg
54461 - 54480 of 57416