Date   

Re: configuring WiFi in Yocto

Ross Burton
 

On 24 August 2012 19:36, Jim Abernathy <jfabernathy@gmail.com> wrote:
On 08/24/2012 02:23 PM, Ross Burton wrote:
See the linux-firmware packages. There are a few split out sub packages, and
then linux-firmware contains the rest.

I see the rtl8192 firmware included in the linux-firmware recipe, but not
sure if there is a step to force a load of the firmware.
Whoops, accidentally took this off-list by using my phone.

If this is still broken, can you attach the output of dmesg, ifconfig
and iwconfig on a fresh boot?

Ross


Re: Kernel does not emit any boot-up messages

Gary Thomas
 

On 2012-08-29 05:04, Hartmut Behrens wrote:
Hi All,

A newbie question:

After creating a new bsp for an Overo using the yocto-bsp script and modifying some kernel config's using menuconfig, I successfully created and loaded the image
(core-image-minimal) onto an SD card and booted it.

However, I do not see the kernel emitting any boot messages. Am I forgetting to include some recipes?


OMAP36XX/37XX-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 512 MiB
NAND: 512 MiB
MMC: OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Beagle Rev Ax/Bx
No EEPROM on expansion board
Die ID #36be00029ff80000016071640201b009
Hit any key to stop autoboot: 0
SD/MMC found on device 0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
reading uImage

3356520 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.2.18-rt16-yocto-preempt-
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3356456 Bytes = 3.2 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Yocto (Built by Poky 7.0) 1.2+snapshot-20120828
ttyO2

overo login: root
root@overo:~# uname -a
Linux overo 3.2.18-rt16-yocto-preempt-rt #4 PREEMPT RT Tue Aug 28 22:36:26 SAST 2012 armv7l GNU/Linux
Make sure your [U-Boot] bootargs contain 'console=ttyO2,115200'

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------


Kernel does not emit any boot-up messages

Hartmut Behrens <hartmut.behrens@...>
 

Hi All,

A newbie question:

After creating a new bsp for an Overo using the yocto-bsp script and modifying some kernel config's using menuconfig, I successfully created and loaded the image (core-image-minimal) onto an SD card and booted it.

However, I do not see the kernel emitting any boot messages. Am I forgetting to include some recipes?


 

OMAP36XX/37XX-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MiB
NAND:  512 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Beagle Rev Ax/Bx
No EEPROM on expansion board
Die ID #36be00029ff80000016071640201b009
Hit any key to stop autoboot:  0 
SD/MMC found on device 0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
reading uImage

3356520 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   Linux-3.2.18-rt16-yocto-preempt-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3356456 Bytes = 3.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Yocto (Built by Poky 7.0) 1.2+snapshot-20120828 
 ttyO2

overo login: root
root@overo:~# uname -a
Linux overo 3.2.18-rt16-yocto-preempt-rt #4 PREEMPT RT Tue Aug 28 22:36:26 SAST 2012 armv7l GNU/Linux



Minutes: Yocto Project Technical Team Meeting - Tuesday, August 28, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

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

Attendees:
Cristian, LaurentiuS, Andrew, Cristina, ScottR, TomZ, Bjorn, Richard, Saul, Kevin, PaulE, DaveSt, Nitin, Belen, Mihai, Alex, Beth, Sean, Ross, Song
 
Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.3 M3 release readiness (All)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_3
https://wiki.yoctoproject.org/wiki/Yocto_1.3_Milestone_Test_Report (M3 report is at the bottom of the page)
- Function complete: most are completed, some are moved to M4, CCB approved that change.
- Build & Release: all features and core BSPs can be build with no error.
- Open bugs: All M3 high's are fixed, except 2 reopened recently.
. 2775 is reopened: RP - there is a kernel patch, we will need to identify and pull it in.
. 2675 is a 1.2.1 bug. QA verified that that is fixed.
- Build Performance: we have about 13 minutes improvement over M2.
- Consensus: release M3. song will send email to CCB and Beth/Michael will release this week.
 
* Yocto 1.3 status - 10 min (Song/team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
- Wiki status page updated with feature development and bug fixing progress.
- Record week for bug fixing: 39 resolved (medium above bugs). Please keep the good work going!
- Most of the high features will be changed to medium or medium+. Please send questions/comments to Song. Song will send email out later on.
- 2675 is targeted for M3, high.
- 1729-1730: multi-lib enabling, completed? Radu/Richard. Alex will follow up
- Beth: Fixed some long standing AB bugs last weekend. There will be more AB downtime coming (one on 9/7) to fix some long standing AB bug. Any questions/feedback please let me know.
-Beth: Master is mostly green except eclipse plug-in is failing. There is some kernel fetch issues. Will open a bug against this. Build appliance is in. make the water fall harder to read. Using grid view should help. Iona looked at the Eclipse issue, cannot recreate. Could be related to that some local libs are upgraded.
 
* SWAT team rotation: Ross -> Ross
- LaurentiuP is on vacation, Ross volunteered to stay on. Thank you, Ross!
 
* Opens - 10 min
- LaurentiuS: bug 2995. Saul/RP: already fixed.
- Richard - should mention nativesdk:
already mentioned this in mailing list. Got some issues, pulled some patches from the mailing list for this, would like to let people know this. Please let me know if you have any feedback.
 
* Team sharing - 20 min
- ScottR: new manual on the latest doc area on the website. All 6 docs concatenated together for the purpose of searching. Please take a look and comment if you can.
- Paul: working on some bitabke tools last week, enabled new feature to allow specify a recipe then search data files for you. Will follow cache directory recursively. Find out why a task was re-run. The patches are on the mailing list for this. Again, Tasks-rework, RFC sent out, please reply.
- Christian: working on adding a new machine qemu86 machine with kvm enabled, with gto to improve networking and other io performance. Add virtio driver next. It's not clearly how I will go with this one. There are some options. Looking for input. 2550. Saul: virtio is enabled by kernel by default right now. Will follow up with Christian
- RP: bitbake for tracing, and message improvement. If people are not clear where the error is after seeing the error message, please file bugs. It will improve the user experience. Show the error message in the bug.
-Bjorn: posted patches on package testing (Ptest), it would be nice to have everyone interested to take a look and point out errors. It's getting bigger, would like to make sure the direction is correct. So please send feedback. RP: this probably something we should talk more on the oe-core list. Saul: on the right track.


Re: Poky 1.3_M3 branch does not work with linux-yocto 3.0 kernel ?

Darren Hart <darren.hart@...>
 

On 08/27/2012 08:18 PM, Bruce Ashfield wrote:
On 12-08-27 8:14 PM, Saxena, Rahul wrote:
Hi,

I am building a BSP (meta-cedartrail) using 1.3 M3 branch of Poky.

When I try to boot a image such as core-image-sato, I get kernel panic
and errors such as:

VFS: Cannot open root device “ram0” or unkown-block(0,0)

Please append a correct “root=” boot option; here are the available

partitions:

VFS: unable to mount root fs on unknown block(0,0)

User configuration error – no valid rootfilesystem found

I do see that the root file system exists in
cedartrail-poky-linux/core-image-sato-1.0-r0/rootfs dir..

I did not see this problem when I uses a earlier commit of the Poky
master branch.

It seems like something broke with 1.3 M3 branch that prevents a proper
build with 3.0 kernel. I do need to build my BSP with 3.0 kernel.

(I was also told by Laurentiu Serban that 1.3 M3 Full Pass testing does
not include testing with the 3.0 kernel)

Any suggestions would be most welcome. I do need to build my BSP with
the 3.0 kernel.
Hmm. It should work, I booted one not that long ago. Can you force
qemux86 to prefer the 3.0 kernel and see if that boots ? That would
at least start to isolate the potential problem areas.
However, won't 3.0 be removed for the 1.3 release? Keeping with 3.4 and 3.2?

--
Darren


Bruce


Thanks

Rahul

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: Ubuntu PPA usage in Yocto

Khem Raj
 

On Tue, Aug 28, 2012 at 2:50 AM, Tim Verstraete
<Tim.Verstraete@medecbenelux.be> wrote:
Hi everybody,



I keep on seeing some interesting software packages into the PPA for Ubuntu
... now I was wondering is there a way within Yocto to reuse those PPA
package (not from the machine with apt-get) but with a recipe?



Take for example the TI OMAP4 … on the TI Launchpad I see:
https://launchpad.net/~tiomap-dev/+archive/release pvr-omap4-dkms and i
would like to use this. How should I add such thing in yocto.

well you would start by using PACKAGE_CLASSES = "
package_deb" in your local.conf

that should generate you an image with dpkg as packaging backend

IMAGE_FEATURES += "package-management"

that will add online package management component to your image

build your image and it should have knobs for hooking in feeds if you
know how its done for apt

bigger problems start here where the packages in that PPA may require
different versions of package dependencies than what you get from
yocto image and even
worse they might use a different ABI etc.



Thank in advance,



Kind regards,



Tim


_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Xorg keyboard not working

Chris Tapp
 

On 28 Aug 2012, at 11:07, Burton, Ross wrote:

On 27 August 2012 21:41, Chris Tapp <opensource@keylevel.com> wrote:
I've got a system that has a working console and four virtual terminals.

I can start X and run an application using

/usr/bin/xinit /usr/sbin/xinitrc -- /usr/bin/Xorg

The application runs fine and is expected to run with no user interaction. Keyboard input is sometimes needed to either kill the application or switch to another virtual terminal to make some configuration changes.

However, I can't seem to get the keyboard to work - I can't switch virtual terminal or force the application to exit and the caps-lock light doesn't toggle. This is the same keyboard that was used to kick the application off. xf86-input-keyboard and xf86-input-evdev are both listed in 'XSERVER' when the system is baked.

Where should I be looking to work out why the keyboard isn't working?
Does the keyboard work from a VT before X starts? What user does X
run as -- my hunch is that it doesn't have permission to access the
input devices. Check the Xorg log to see if there are any relevant
errors.
Yes, the keyboard works fine from the VTs. X is running as root and I can't see anything in the logs that are of any help!

Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: [PATCH 1/3] Add -ptest package group

Björn Stenberg <bjst@...>
 

Richard Purdie wrote:
Would a ptest.bbclass containing the above make more sense? How
widespread do we think these tests will be?
Most source packages include some form of test suite that we want to make into a -ptest package. I would guesstimate the number to be somewhere between the number of -dbg and the number of -dev packages. This is why I felt it made sense to add the handling of -ptest side-by-side with the handling of -dev and -dbg.

My biggest worry is the overhead of the patches to
software to enable the tests. Are you planning to engage the upstreams
and see if we can get them to accept the patches?
Upstreaming is absolutely the idea, both for the benefit of the entire ecosystem and of course to reduce the number of patches.

However I won't downplay the effort required to get hundreds of upstream projects to agree on a common concept for test cross compilation and result formatting.

I see two main options: Implement first or discuss first.

a) Implement first: We design and implement a good system for yocto/oe and then, once it has proven itself, engage the larger open source community with our already tested concept.

Pro: It's easier to discuss an already working system
Con: We'll have to manage patches for all packages until agreement

b) Discuss first: We invite the whole open source community to discuss and try to agree on how to handle cross-compiled test cases and test result formatting before we implement anything.

Pro: No increased patch load until agreement
Con: No result until agreement, which could potentially take a long time

My suggestion is a). I'm open for any and all suggestions that would make the patch load easier to manage.

Also these patches are against OE-Core so need to go to the
openembedded-code mailing list.
I'll update the patches with the feedback I've got and post them to oe-core for further discussion.

Thanks.

--
Björn


Re: Xorg keyboard not working

Ross Burton
 

On 27 August 2012 21:41, Chris Tapp <opensource@keylevel.com> wrote:
I've got a system that has a working console and four virtual terminals.

I can start X and run an application using

/usr/bin/xinit /usr/sbin/xinitrc -- /usr/bin/Xorg

The application runs fine and is expected to run with no user interaction. Keyboard input is sometimes needed to either kill the application or switch to another virtual terminal to make some configuration changes.

However, I can't seem to get the keyboard to work - I can't switch virtual terminal or force the application to exit and the caps-lock light doesn't toggle. This is the same keyboard that was used to kick the application off. xf86-input-keyboard and xf86-input-evdev are both listed in 'XSERVER' when the system is baked.

Where should I be looking to work out why the keyboard isn't working?
Does the keyboard work from a VT before X starts? What user does X
run as -- my hunch is that it doesn't have permission to access the
input devices. Check the Xorg log to see if there are any relevant
errors.

Ross


Ubuntu PPA usage in Yocto

Tim Verstraete <Tim.Verstraete@...>
 

Hi everybody,

 

I keep on seeing some interesting software packages into the PPA for Ubuntu ... now I was wondering is there a way within Yocto to reuse those PPA  package (not from the machine with apt-get) but with a recipe?

 

Take for example the TI OMAP4 … on the TI Launchpad I see: https://launchpad.net/~tiomap-dev/+archive/release pvr-omap4-dkms and i would like to use this. How should I add such thing in yocto.

 

Thank in advance,

 

Kind regards,

 

Tim


Re: [OE-core] RFC: OE-Core task rework

Paul Eggleton
 

On Wednesday 15 August 2012 10:46:49 Paul Eggleton wrote:
Hi all,

There have been a few requests to review the task recipes (i.e. package
groups) provided by OE-Core, and indeed these have not really been looked at
seriously since OE-Core was created. Ideally I think we want them to be
useful to a wide audience and provide useful units of functionality that
can be added to an image without the person doing the selection having to
manually select too many individual packages. Imagine presenting the list
of tasks to someone in a UI for assembling images (such as Hob or
Narcissus) and you can start to see that we have some work to do in this
area.

I know various distros and users of OE-Core have created their own tasks or
resurrected tasks from OE-Classic, and this is an opportunity to perhaps
look at bringing some of these (or at least, parts of them) into the core.
It is true that tasks will often be an expression of distro policy, and we
also can't have any tasks in OE-Core that refer to packages that don't
exist in OE- Core; thus distros will always be extending the base tasks or
adding their own - and that's fine. However, with some thought I believe we
can come up with a set of tasks that are generally useful to most people
using OE-Core.

For reference, I've compiled a list on the wiki of the current tasks in OE-
Core with links to the recipes and some notes:

http://www.openembedded.org/wiki/OE-Core_Task_Rework

Some of the things I think we ought to consider/address as part of this
exercise:

1) Do we rename "task" to something a little more understandable to the
uninitiated, such as "package group"? The word "task" is already used in a
much more natural sense within bitbake as a unit of work. Historically I
believe we picked up this term from Debian but I'm not aware of significant
use by other mainstream distributions.

2) Look at the existing tasks and:
* evaluate their usefulness
* remove any that are obsolete
* adjust existing contents if needed
* look for useful groups of packages that might be added

We need to pay particular attention to task-core-boot and task-base as
these are pulled in by default in any image that inherits from
core-image.bbclass - if these are not generally working for people that are
creating their own images, we need to change them such that they are.

3) Ensure all task recipes follow reasonable patterns:
* Fix recipe DESCRIPTIONs to make sense (and not contain Poky references)
* Ensure all individual packages have a decent SUMMARY/DESCRIPTION
* Try to make each task have a reasonable name - there are some current
uses of "core" and "base" that don't actually convey any meaning; LSB
specific tasks should be named as such, etc.
* Make all tasks inherit task.bbclass so that they get proper dbg/dev
packages and any other common task functionality

4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which
converts some IMAGE_FEATURES into the addition of tasks to be installed (see
classes/core-image.bbclass). At the very least we should probably rename
this if we rename tasks to package groups, and there's a question as to how
IMAGE_FEATURES scales - should every task be represented in there or only a
select list? Would we be better off not trying to bring any tasks in via
IMAGE_FEATURES at all and mostly leave that to control post-processing
(e.g. package-management, debug-tweaks, etc.)?

Please reply with your thoughts. Once we've come to a consensus on the
things we want to do (allowing plenty of time for discussion), I'll look at
putting together a set of patches that makes the appropriate changes.
So, any further thoughts on this one?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: Poky 1.3_M3 branch does not work with linux-yocto 3.0 kernel ?

Bruce Ashfield <bruce.ashfield@...>
 

On 12-08-27 8:14 PM, Saxena, Rahul wrote:
Hi,

I am building a BSP (meta-cedartrail) using 1.3 M3 branch of Poky.

When I try to boot a image such as core-image-sato, I get kernel panic
and errors such as:

VFS: Cannot open root device “ram0” or unkown-block(0,0)

Please append a correct “root=” boot option; here are the available

partitions:

VFS: unable to mount root fs on unknown block(0,0)

User configuration error – no valid rootfilesystem found

I do see that the root file system exists in
cedartrail-poky-linux/core-image-sato-1.0-r0/rootfs dir..

I did not see this problem when I uses a earlier commit of the Poky
master branch.

It seems like something broke with 1.3 M3 branch that prevents a proper
build with 3.0 kernel. I do need to build my BSP with 3.0 kernel.

(I was also told by Laurentiu Serban that 1.3 M3 Full Pass testing does
not include testing with the 3.0 kernel)

Any suggestions would be most welcome. I do need to build my BSP with
the 3.0 kernel.
Hmm. It should work, I booted one not that long ago. Can you force
qemux86 to prefer the 3.0 kernel and see if that boots ? That would
at least start to isolate the potential problem areas.

Bruce


Thanks

Rahul


Re: 1.3 M3 Full Pass test results

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

We used to get 115m and 127m for 1.3 M1 and M2 on our test machine.

Hello guys,

I am sorry I did not notice the last line in the e-mail.

When we ran the performance testing we pre-downloaded all the sources,
because last week had a lot of connectivity issues. I mentioned in the
e-mail that the build time refers to an image built after all the
sources were downloaded.
The machine on which the test was ran is the same as for M1.

I will ask Stefan to re-run the performance tests for the different
milestones so far, M1 and M2, in the same conditions as for M3 so we
would have a clear view.

I add Jiajun in the loop so he can help us if he can with a test to
see if this is related to an artifact as Richard said, but also there
were some improvements made by Beth on filesystem generation.

Br,
Laurentiu

-----Original Message-----
From: Liu, Song
Sent: Monday, August 27, 2012 8:50 PM
To: Serban, Laurentiu; Purdie, Richard
Cc: yocto@yoctoproject.org; Stewart, David C; Wold, Saul
Subject: RE: 1.3 M3 Full Pass test results

Hi Laurentiu,

Do you have any comment on the performance question Richard asked? I
know your team is using a machine with different configuration from
the one used by the Shanghai team. The performance figure from the
Shanghai team has been hovering around 110 mins. That's the case for
1.2 release and 1.3 M2 milestone report. 1.3 M1 milestone report has
the build time as 95 minutes, which I believe is from your team. So my
question is whether you used the same machine for M3 performance
testing as for M1. Another factor that might have caused the
difference (between 95 and 83 minutes) is your testing
procedure/environment such as other processes running at the same
time, memory usage, sstate cache, etc. If you used the same machine
and same testing procedure/environment, then we have some improvement in M3 compared with M1. Please let me know your thoughts.

Thanks,
Song

-----Original Message-----
From: Serban, Laurentiu
Sent: Friday, August 24, 2012 6:34 AM
To: Purdie, Richard
Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul
Subject: RE: 1.3 M3 Full Pass test results

Hello Richard,

Even if the installer is used in the default mode, issues still occur
(see comment 7). I think the root cause for these is the same, so I did not submit a new bug.

Thank you,
Laurentiu

-----Original Message-----
From: Purdie, Richard
Sent: Friday, August 24, 2012 1:22 PM
To: Serban, Laurentiu
Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul
Subject: Re: 1.3 M3 Full Pass test results

On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote:

Here are the results for the full pas tests on 1.3 M3 RC2. The
commit used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd.

Some details about the encountered issues below:

BSP – Sudoku-savant project build issue (2878)

ADT – the relocatable sdk issue (2980) causes 13 test cases to be on
faile/blocked state
I thought it worked as long as you didn't have to relocate it so no
tests should have been blocked, we just have the relocation issue?

, also the Clutter C template issue is unsolved (2577)
Core Build System – x32 is still an issue (2888), cleaning sstate
issue is still not solved (2897), incremental RPM image generation
(2969), source archiving (2619), the kvm issue was reproduced by
another colleague (2790) Yocto BSP creation via JSON (2693) or for
qemu (2991) fails, multilib issue (2918 – this requires a little
more investigation from QA),

HOB - all seems ok for RC2

Self-hosted-image - cannot start on Virtual Box (X issue), it is
very slow on qemu and it has a m4 package build (3005) issue on
VMWare. If the self-hosted-image is used on machine with internet
connectivity via proxy there will be an initial sanity check
failure, but this is not a blocking issue.

A mention for the performance testing: on a Ubbuntu 12.04 i7
machine using 8 threads the build time was 83 minutes (with prior fetching).
How does this compare with our other performance numbers. From what I
remember, we used to hover around the 105-115 minute mark. Did we have
some significant speed gains or is this just an artefact of changing
the test machine?

Cheers,

Richard

Best Regards,
Jiajun


Poky 1.3_M3 branch does not work with linux-yocto 3.0 kernel ?

Saxena, Rahul <rahul.saxena@...>
 

Hi,

 

I am building a BSP  (meta-cedartrail) using 1.3 M3 branch of Poky.

 

 

When I try to boot a image such as core-image-sato, I get kernel panic and errors such as:

VFS: Cannot open root device “ram0” or unkown-block(0,0)

 

Please append a correct “root=” boot option; here are the available

partitions:

 VFS: unable to mount root fs on unknown block(0,0)

 User configuration error – no valid rootfilesystem found

 

 

I do see that the root file system exists in cedartrail-poky-linux/core-image-sato-1.0-r0/rootfs dir..

 

I did not see this problem when I uses a earlier commit of the Poky master branch.

 

It seems like something broke with 1.3 M3 branch that prevents a proper build with 3.0 kernel. I do need to build my BSP with 3.0 kernel.

(I was also told by Laurentiu Serban that 1.3 M3 Full Pass testing does not include testing with the 3.0 kernel)  

 

Any suggestions would be most welcome.   I do need to build my BSP with the 3.0 kernel.

 

Thanks

Rahul


Yocto Bug Trend ww34

Serban, Laurentiu <laurentiu.serban@...>
 

Hello,

 

The bug trend wiki is updated for ww34: https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

 

Best regards,

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


Xorg keyboard not working

Chris Tapp
 

I've got a system that has a working console and four virtual terminals.

I can start X and run an application using

/usr/bin/xinit /usr/sbin/xinitrc -- /usr/bin/Xorg

The application runs fine and is expected to run with no user interaction. Keyboard input is sometimes needed to either kill the application or switch to another virtual terminal to make some configuration changes.

However, I can't seem to get the keyboard to work - I can't switch virtual terminal or force the application to exit and the caps-lock light doesn't toggle. This is the same keyboard that was used to kick the application off. xf86-input-keyboard and xf86-input-evdev are both listed in 'XSERVER' when the system is baked.

Where should I be looking to work out why the keyboard isn't working?

Chris Tapp

opensource@keylevel.com
www.keylevel.com


Agenda: Yocto Project Technical Team Meeting - Tuesday, August 28, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

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

Agenda:
 
* Opens collection - 5 min (Song)
* Yocto 1.3 M3 release readiness (All)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_3
https://wiki.yoctoproject.org/wiki/Yocto_1.3_Milestone_Test_Report (M3 report is at the bottom of the page)
* Yocto 1.3 status - 10 min (Song/team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
* SWAT team rotation: Ross -> LaurentiuP
* Opens - 10 min
* Team sharing - 20 min


-----Original Appointment-----


We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html

Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
76994298
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 participant:
1.972.995.7777x76994298#
 
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 26, 2012
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 21, 2013, 10:40 AM CDT


Re: Request for photos

David Stewart
 

All - still would like to include as many pictures as I can of real products using the Yocto Project. Have not heard any... do you have a photo you can send me urgently? (Otherwise I will just make stuff up, and you don't want me to do that...) :-)

Dave

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Stewart, David C
Sent: Tuesday, August 21, 2012 8:20 AM
To: yocto
Subject: [yocto] Request for photos

All - I'm prepping to give a talk at LinuxCon next week on an update to the
Yocto Project, and I would like to create a slide which shows a bunch of
devices which are based on YP.

Can you please send me a quick note with anything you know about to include
here? Particularly nice if you have a photo or logo for the thing.

Thanks!!

Dave


Re: 1.3 M3 Full Pass test results

Serban, Laurentiu <laurentiu.serban@...>
 

Hello Rahul,

 

1.3 M3 does not include testing with linux-yocto 3.0.

 

Br,

Laurentiu

 

From: Saxena, Rahul
Sent: Monday, August 27, 2012 7:27 PM
To: Serban, Laurentiu; yocto@...
Cc: Purdie, Richard; Wold, Saul
Subject: RE: 1.3 M3 Full Pass test results

 

Does this 1.3 M3 testing includes testing with the linux-yocto3.0 kernel ?

 

 

Thanks

Rahul

 

From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Serban, Laurentiu
Sent: Thursday, August 23, 2012 12:13 PM
To: yocto@...
Cc: Purdie, Richard; Wold, Saul
Subject: [yocto] 1.3 M3 Full Pass test results

 

Hello,

 

Here are the results for the full pas tests on 1.3 M3 RC2. The commit used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd.

Some details about the encountered issues below:

 

BSP – Sudoku-savant project build issue (2878)

ADT – the relocatable sdk issue (2980) causes 13 test cases to be on faile/blocked state , also the Clutter C template issue is unsolved (2577)

Core Build System – x32 is still an issue (2888), cleaning sstate issue is still not solved (2897), incremental RPM image generation (2969), source archiving (2619), the kvm issue was reproduced by another colleague (2790) Yocto BSP creation via JSON (2693) or for qemu (2991) fails, multilib issue (2918 – this requires a little more investigation from QA),

HOB - all seems ok for RC2

Self-hosted-image  - cannot start on Virtual Box (X issue), it is very slow on qemu and it has a m4 package build (3005) issue on VMWare. If the self-hosted-image is used on machine with internet connectivity via proxy there will be an initial sanity check failure, but this is not a blocking issue.

 

A mention for the performance testing: on a Ubbuntu 12.04  i7 machine using 8 threads the build time was 83 minutes (with prior fetching).

 

 

Test Result Summary

Component

Target

Status

Comments

BSP

Beagleboard

GOOD

Sudoku-savant project issue

Routerstationpro

GOOD

Sudoku-savant project issue

Mpc8315e-rdb

GOOD

Sudoku-savant project issue

eMenlow-sato-sdk

GOOD

Sudoku-savant project issue

Blacksand-sato

GOOD

The sdk image was not available

Crownbay-emgd-sato-sdk

GOOD

Sudoku-savant project issue

FRI2-sato-sdk

BUGGY

X Server issue blocks many test cases

Suspend issue

Dmesg issue

HuronRiver-sato-sdk

GOOD

Sudoku-savant project issue

Jasperforest-lsb-sdk

GOOD

Sudoku-savant project issue

QEMU

Qemuarm

GOOD

Everything runs well

Qemuppc

GOOD

Everything runs well

Qemumips

GOOD

Everything runs well

qemux86

GOOD

Everything runs well except for zypper bug 2694 for sato-sdk image

qemux86-64

GOOD

Everything runs well except for zypper bug 2694 for sato-sdk image

Core build system

 

BUGGY

x32 is still an issue (2888), cleaning sstate issue is still not solved (2897), incremental RPM image generation (2969), source archiving (2619), the kvm issue was reproduced by another colleague (2790), Yocto BSP creation via JSON (2693) or for qemu (2991) fails, multilib issue (2918)

HOB

 

GOOD

Everything runs well except for HOB recipe building from command line and and cross toolchain build (2695 and3001).

Compliance

GOOD

Sugarbay: Board unavailable; HuronRiver: Pass; Blacksand: Blocked

Stress

GOOD

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

Distribution Support

GOOD

Everything runs well for Ubuntu 12.04, Ubuntu 12.10 – nightly, OpenSuse 12.1, OpenSuse 12.2 RC2, Fedora 17, CentOs 6.3, Fedora 16

Power and Performance

GOOD

one qemux86 sato build on a Core i7 machine costs 83 minutes with the packages previously fetched.

ADT

 

BUGGY

the relocatable sdk issue (2980) causes 13 test cases to be on faile/blocked state , also the Clutter C template issue is unsolved (2577) Also 2768 bug affects native autoconf

 

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Beagleboard Sato-SDK

42

0

41

1 (2878)

0

Routerstationpro Sato-SDK

35

0

34

1 (2878)

0

Mpc8315e-rdb Sato-SDK

37

0

36

1 (2878)

0

eMenlow Sato-SDK

67

0

66

1 (2878)

0

n450 Sato

56

0

42

1(bug 2646)

13

Crownbay-noemgdSato-SDK

67

2

64

1 (2878)

0

FRI2 Sato-SDK

86

1

42

4 (bugs 3004, 2989, 2415)

39  (3004, 2037, 2415)

HuronRiver Sato-SDK

70

0

69

1(bug 2791)

0

Jasperforest lsb-SDK

34

0

33

1 (2878)

0

Qemuarm Sato

32

0

32

0

0

Qemuarm Sato-SDK

37

0

37

0

0

Qemumips Sato

32

0

32

0

0

Qemumips Sato-SDK

37

0

37

0

0

Qemuppc Sato

32

0

32

0

0

Qemuppc Sato-SDK

37

0

37

0

0

Qemux86-64 Sato

32

0

32

0

0

Qemux86-64 Sato-SDK

37

0

37

0

0

Qemux86 Sato

32

0

32

0

0

Qemux86 Sato-SDK

37

0

37

0

0

Core build system

64

0

43

12 (2969, 2619, 2897, 2790, 2888, 2693, 2918, 3005, 2991)

9 (bugs 2888 and 2684, 2996)

HOB

38

0

36

2 (bugs 2695 and 3001)

0

ADT

53

0

23

14 (2980, 2577, 2768)

16(2980)

Compliance

3

0

2

0

1 (n-450 image not available)

Stress

2

0

2

0

0

Distribution Support

8

0

8

0

0

Total

1007

3

886

40

78

 

Component

Bug Number

Target Milestone

System & Core OS

System Usage

Bug 2878 pkgconfig is missing from sato-sdk image

Bug 2989 [FRI2] dmesg PowerButton error

1.3

Bug 2415 connman doesn't provide a 3g configuration utility

1.3

Bug 2037 [fri2] system cannot enter S3 standby mode

1.2

Bug 3004 [FRI2]X server fails to start

Core build system

Bug 2969 Incremental RPM image generation is not working as expected.

Bug 2619 do_package_write_rpm fails - fakeroot issue

Bug 2897 sstate-cache-management.sh doesn't work with new sstate-cache layout

Bug 2790 eglibc-initial installs to /usr

Bug 2888 x32 build fails at gcc cross-initial do_compile

Bug 2693 Yocto BSP create via JSON file fails

Bug 2918 lib64-core-image-sato-sdk fails due to do_rootfs issue.

Bug 3005 1.3 M3 build-appliance comes with old poky tree and m4-native compile fails

Bug 2991  the image created with yocto-bsp tool fails to start - "unsupported machine type"

ADT

Bug 2980 toolchain issue - segmentation fault while configuring packages

1.3 M4

Bug 2768 iptables 1.4.13 configure fail using "autoreconf -fi"

1.3 M4

Bug 2577 Segmentation fault on qemuarm from /usr/lib/libust.so.0

1.3 M4

HOB

Bug 2695 [HOB]toolchain arch in settings is not saved

1.3 M4

Bug 3001 bblayers-hob.conf does not correspond with bblayers.conf

 

 

 

 

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


Re: 1.3 M3 Full Pass test results

Serban, Laurentiu <laurentiu.serban@...>
 

Hello guys,

I am sorry I did not notice the last line in the e-mail.

When we ran the performance testing we pre-downloaded all the sources, because last week had a lot of connectivity issues. I mentioned in the e-mail that the build time refers to an image built after all the sources were downloaded.
The machine on which the test was ran is the same as for M1.

I will ask Stefan to re-run the performance tests for the different milestones so far, M1 and M2, in the same conditions as for M3 so we would have a clear view.

I add Jiajun in the loop so he can help us if he can with a test to see if this is related to an artifact as Richard said, but also there were some improvements made by Beth on filesystem generation.

Br,
Laurentiu

-----Original Message-----
From: Liu, Song
Sent: Monday, August 27, 2012 8:50 PM
To: Serban, Laurentiu; Purdie, Richard
Cc: yocto@yoctoproject.org; Stewart, David C; Wold, Saul
Subject: RE: 1.3 M3 Full Pass test results

Hi Laurentiu,

Do you have any comment on the performance question Richard asked? I know your team is using a machine with different configuration from the one used by the Shanghai team. The performance figure from the Shanghai team has been hovering around 110 mins. That's the case for 1.2 release and 1.3 M2 milestone report. 1.3 M1 milestone report has the build time as 95 minutes, which I believe is from your team. So my question is whether you used the same machine for M3 performance testing as for M1. Another factor that might have caused the difference (between 95 and 83 minutes) is your testing procedure/environment such as other processes running at the same time, memory usage, sstate cache, etc. If you used the same machine and same testing procedure/environment, then we have some improvement in M3 compared with M1. Please let me know your thoughts.

Thanks,
Song

-----Original Message-----
From: Serban, Laurentiu
Sent: Friday, August 24, 2012 6:34 AM
To: Purdie, Richard
Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul
Subject: RE: 1.3 M3 Full Pass test results

Hello Richard,

Even if the installer is used in the default mode, issues still occur (see comment 7). I think the root cause for these is the same, so I did not submit a new bug.

Thank you,
Laurentiu

-----Original Message-----
From: Purdie, Richard
Sent: Friday, August 24, 2012 1:22 PM
To: Serban, Laurentiu
Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul
Subject: Re: 1.3 M3 Full Pass test results

On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote:

Here are the results for the full pas tests on 1.3 M3 RC2. The commit
used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd.

Some details about the encountered issues below:

BSP – Sudoku-savant project build issue (2878)

ADT – the relocatable sdk issue (2980) causes 13 test cases to be on
faile/blocked state
I thought it worked as long as you didn't have to relocate it so no tests should have been blocked, we just have the relocation issue?

, also the Clutter C template issue is unsolved (2577)

Core Build System – x32 is still an issue (2888), cleaning sstate
issue is still not solved (2897), incremental RPM image generation
(2969), source archiving (2619), the kvm issue was reproduced by
another colleague (2790) Yocto BSP creation via JSON (2693) or for
qemu (2991) fails, multilib issue (2918 – this requires a little more
investigation from QA),

HOB - all seems ok for RC2

Self-hosted-image - cannot start on Virtual Box (X issue), it is very
slow on qemu and it has a m4 package build (3005) issue on VMWare. If
the self-hosted-image is used on machine with internet connectivity
via proxy there will be an initial sanity check failure, but this is
not a blocking issue.

A mention for the performance testing: on a Ubbuntu 12.04 i7 machine
using 8 threads the build time was 83 minutes (with prior fetching).
How does this compare with our other performance numbers. From what I remember, we used to hover around the 105-115 minute mark. Did we have some significant speed gains or is this just an artefact of changing the test machine?

Cheers,

Richard