Re: [yocto] Adding features to a machine
On Thu, Dec 8, 2011 at 4:02 PM, Darren Hart dvh...@linux.intel.com wrote: On 12/08/2011 12:36 PM, Marc Ferland wrote: On Thu, Dec 8, 2011 at 2:50 PM, Darren Hart dvh...@linux.intel.com mailto:dvh...@linux.intel.com wrote: On 12/08/2011 11:13 AM, Marc Ferland wrote: Hi, I have a crownbay based machine here and I would like to add the bluetooth machine feature to it. Do I have to create a whole new BSP for this? I haven't seen any examples showing how to _modify_ a machine description. Have you tried modifying either MACHINE_FEATURES_crownbay or KERNEL_FEATURES_crownbay from local.conf? I haven't attempted this myself, but I believe it should work. Tried both. With MACHINE_FEATURES_crownbay += bluetooth I get: NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'modutils-depmod' (but /home/marc/dev/poky/poky-src/meta/recipes-kernel/update-modules/ update-modules_1.0.bb http://update-modules_1.0.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'modutils-depmod' is unbuildable, removing... Hrm, yes, I don't see what provides modutils-depmod. I believe you may have found a bug. Mind filing one? Missing or unbuildable dependency chain was: ['modutils-depmod'] NOTE: Runtime target 'perf' is unbuildable, removing... Missing or unbuildable dependency chain was: ['perf', 'update-modules', 'modutils-depmod'] NOTE: Runtime target 'task-core-tools-profile' is unbuildable, removing... Missing or unbuildable dependency chain was: ['task-core-tools-profile', 'perf', 'update-modules', 'modutils-depmod'] ERROR: Required build target 'sonatest-test-image' has no buildable providers. Missing or unbuildable dependency chain was: ['sonatest-test-image', 'task-core-tools-profile', 'perf', 'update-modules', 'modutils-depmod'] With KERNEL_FEATURES_crownbay += bluetooth, I get the following when recompiling the kernel: Log data follows: | Deleted branch meta-temp (was 620917d). | WARNING: addon feature bluetooth was not found | ERROR: required features were not found. aborting BTW, I did not find any precise kernel feature for bluetooth when looking in builddir/tmp/work/crownbay-poky-linux/linux-yocto/linux/meta/cfg/kernel-cache/ Right, you would need to add something if you need a driver that isn't listed there or in the crownbay BSP. Sorry to bring this up again, but since the documentation states that bluetooth is a valid MACHINE_FEATURE option and no configuration fragment is present to support this feature does that mean that it cannot really work by simply adding the option? Could this be a bug/missing feature? BTW, I got bluetooth working but I add to create a config fragment like you suggested which is kind of confusing since a MACHINE_FEATURE already exists for this functionality. Regards, Marc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Sanity tested distributions list
On Tuesday 06 December 2011 15:59:39 McClintock Matthew-B29882 wrote: On Tue, Dec 6, 2011 at 9:43 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: We had some discussions [1] [2] about this last cycle but I don't feel we reached a proper conclusion on the list of tested distributions we want to set (SANITY_TESTED_DISTROS) and I assume we want to support a few more distros (latest versions of Fedora Ubuntu, presumably?). I'd like to update and re- post the patch [3] so we can close bug #1096 [4] but for that we need to agree on the list. I'm fairly comprehensively testing something close to the edison 1.1.1 release on CentOS 5.5 and Ubuntu 10.04 LTS. We plan on adding more but maybe not in time for our next release. I can definitely see a compelling reason to mark CentOS 5.x as supported, but the problem with it is it doesn't come with Python 2.6, so BitBake won't work out of the box (actually right now it fails before it has a chance to show a reasonable error message, which is even worse). We really need a concise set of instructions on how to install the external python tarball, at the moment I don't think we have these. Did you need to perform any other special steps on either of these distributions? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Sanity tested distributions list
On 12/12/11 09:16, Paul Eggleton wrote: I can definitely see a compelling reason to mark CentOS 5.x as supported, but the problem with it is it doesn't come with Python 2.6, so BitBake won't work out of the box (actually right now it fails before it has a chance to show a reasonable error message, which is even worse). We really need a concise set of instructions on how to install the external python tarball, at the moment I don't think we have these. It's been a while since I wrote them, and therefore since I tested them, but: https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies Joshua -- Joshua Lock Yocto Project Johannes factotum Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Sanity tested distributions list
On Mon, Dec 12, 2011 at 11:16 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Tuesday 06 December 2011 15:59:39 McClintock Matthew-B29882 wrote: On Tue, Dec 6, 2011 at 9:43 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: We had some discussions [1] [2] about this last cycle but I don't feel we reached a proper conclusion on the list of tested distributions we want to set (SANITY_TESTED_DISTROS) and I assume we want to support a few more distros (latest versions of Fedora Ubuntu, presumably?). I'd like to update and re- post the patch [3] so we can close bug #1096 [4] but for that we need to agree on the list. I'm fairly comprehensively testing something close to the edison 1.1.1 release on CentOS 5.5 and Ubuntu 10.04 LTS. We plan on adding more but maybe not in time for our next release. I can definitely see a compelling reason to mark CentOS 5.x as supported, but the problem with it is it doesn't come with Python 2.6, so BitBake won't work out of the box (actually right now it fails before it has a chance to show a reasonable error message, which is even worse). We really need a concise set of instructions on how to install the external python tarball, at the moment I don't think we have these. Did you need to perform any other special steps on either of these distributions? I'm not 100% sure what I did to bring up our CentOS box but I think all I needed was to install python 2.6. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Mirroring.
All, You may have noticed over the past few days some slowness when trying to access the autobuilder or the downloads area on the yocto websites. This was due to someone attempting to wget the entire downloads directory and accounting for about 75% of the hits against the webserver over a period of a few days. Please, if you are attempting to mirror via wget, don't. - It's inefficient. rsync is better. - You really don't need all of downloads.yoctoproject.org, do you? If you do, see above and email me. - If you end up doing it and your wget ends up causing bandwidth issues due to flooding our connection, you will end up bandwidth limited (which is bad if you ever need to use the autobuilder PREMIRRORS/MIRRORS) - It effects other users and it's really not the right way of doing it. If you wish to mirror the yocto download site, please contact me and I can tell you how to go about doing it correctly. Also, please remember that we are mirrored via kernel.org @ http://mirrors.kernel.org/yocto -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto: ktypes/tiny and some questions along the way
On 12/11/2011 09:14 PM, Bruce Ashfield wrote: On 11-12-09 5:52 PM, Darren Hart wrote: Bruce, I'm looking at introducing a new kernel type, ktypes/tiny. Tiny will define a core set of kernel policy options, such as proc, sys, devtmpfs, futex, epoll, elf bin format, etc. It will not enable any drivers, filesystems, debug options, or networking options by default. This would be the responsibility of the BSP to add a named feature implementing this. Taking a look at the ktypes we have now resulted in some questions: dvhart@envy:~/source/linux/linux-yocto-3.0/meta/cfg/kernel-cache/ktypes $ tree . ├── base │ ├── base.cfg │ ├── base.scc │ ├── hardware.cfg │ ├── hardware.kcf │ ├── non-hardware.cfg │ └── non-hardware.kcf ├── preempt-rt │ ├── preempt-rt.cfg │ └── preempt-rt.scc ├── standard │ ├── perf-force-include-of-stdbool.h.patch │ ├── perf-hard-code-NO_LIBPERL-NO_LIBPYTHON.patch │ ├── standard-patches.scc │ ├── standard.cfg │ ├── standard.scc │ └── x86-add-TIF_32BIT-compatibility-define.patch These form a hiearchy, each inheriting from the layer beneath like so: base/standard/preempt-rt As I dig into this I see that some policy is infact laid down by base, including things like: CONFIG_MODULES=y CONFIG_INET=y CONFIG_PREEMPT=y CONFIG_NFS_FS=y CONFIG_MSDOS_PARTITION=y These pull in the IP stack, the block layer, etc. Because of this, I can't really inherit from base for ktypes/tiny. I would like to inherit the hardware and non-hardware kcf files though, as well as any patches that might make their way into base. Which leads me to standard. I would like to see a much smaller set of config policy options set in base. Most likely these should be exactly what we agree on for tiny, and tiny wouldn't add any additional policy as it implements only what is required for a Yocto Project built kernel. NOTE: kernel version is 3.0+ $ cat base/base.scc | head -n 1 set_kernel_version 2.6.37 FYI: nothing uses this at the moment. But I fixed that here. There are three patches in standard, only two of which (the perf ones) are listed in the standard.scc. As I believe any kernel we build should have these, I would like to see any global patches applied to base, leaving standard to define policy, and include named features. standard only includes 3 patches because they were a bit hard to classify elsewhere. In a more fully populated kernel, it does include quite a bit more directly. directly = git repository commits? With these changes, I could add ktypes/tiny as follows: $ cat tiny/tiny.scc include ktypes/base branch tiny include features/xyz/xyz.scc include cfg/abc.scc Another point of interest is preempt-rt, as I can see people wanting to build tiny preempt-rt. I think the best approach here is to create ktypes/tiny/preempt-rt-tiny/preempt-rt-tiny.scc. Note: I believe this fails with .patch.patch $ cat features/rt/rt.scc | grep patch patch rt-apply-patch-3.0.10-rt27.patch.patch Love my patch.patch. Script went wild on that one, luckily the content in the branch is king :) I fixed that here when I was auditing 3.0.12+rt so that looks more sane now. I'm working on a patch series that implements the suggestions I've made above. Bruce, do you have any issues with this approach? Allow me to ramble a bit below ... No big issues. At some level(s) it is just a shell game. We can move configs and patches around to the appropriate level to get the building blocks that we need and get common functionality into a common location. base was (is) intended to document the branch point from the mainline kernel, and contain largely configuration and very few patches. Any important or larger size functional additions go into the standard kernel. What is the value of having base and standard as separate branches? Isn't base easily derivable from the standard git history? Still if it isn't used anywhere, then the branch is a no-op and adds no complexity, so that's fine. So branching from base for a new kernel type is something we can do, but it will risk missing additions (say for example tracing fixes, or the next super-duper debug via kprobes patch series), since they'll go into the standard kernel. OK, that's no good. My moving patches down to base was intended to avoid just that problem. And given the above, leaving them in standard is preferred. OK, that poses some issues discussed below. If I just slide all the patches down into base, why not just call 'base' 'standard' or just make standard have the configuration you are working on for tiny. The point I'm attempting to make, is that the base/common point can be whatever we decide it needs to be, standard can be renamed, content moved up and down, etc. i.e. standard could have it's config changed, a new branch created off standard ( and options moved there), or standard could be streamlined and the boards include more common
[yocto] Agenda: Yocto Technical Team Meeting - Tuesday, December 13, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Agenda: * Opens collection - 5 min (Saul) * Yocto 1.0.2 and 1.1.1 point release update - 10 min (Josh/Beth) * Yocto 1.2 M1 Status (features development) - 10 min (Saul/Beth) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status * M2 Planning * Opens - 10 min * Action item Review - 5 min 1. Mark will review unsorted features from Wind River team and try to have them scheduled. (Status Check) * Weekly team sharing (20 min) -Original Appointment- 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. US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a chairperson: 1.972.995.x67184230# BlackBerry users, click this link to join your conference as a participant: 1.972.995.x49611427# 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-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): From IP phone dial 8-995 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 8995 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 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 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding features to a machine
On 12/12/2011 08:11 AM, Marc Ferland wrote:
On Thu, Dec 8, 2011 at 4:02 PM, Darren Hart dvh...@linux.intel.com
mailto:dvh...@linux.intel.com wrote:
On 12/08/2011 12:36 PM, Marc Ferland wrote:
On Thu, Dec 8, 2011 at 2:50 PM, Darren Hart
dvh...@linux.intel.com mailto:dvh...@linux.intel.com
mailto:dvh...@linux.intel.com mailto:dvh...@linux.intel.com
wrote:
On 12/08/2011 11:13 AM, Marc Ferland wrote:
Hi,
I have a crownbay based machine here and I would like to add the
bluetooth machine feature to it. Do I have to create a whole new
BSP for
this? I haven't seen any examples showing how to _modify_ a
machine
description.
Have you tried modifying either MACHINE_FEATURES_crownbay or
KERNEL_FEATURES_crownbay from local.conf? I haven't attempted this
myself, but I believe it should work.
Tried both.
With MACHINE_FEATURES_crownbay += bluetooth I get:
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'modutils-depmod' (but
/home/marc/dev/poky/poky-src/meta/recipes-kernel/update-modules/update-modules_1.0.bb
http://update-modules_1.0.bb
http://update-modules_1.0.bb RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'modutils-depmod' is unbuildable, removing...
Hrm, yes, I don't see what provides modutils-depmod. I believe you may
have found a bug. Mind filing one?
Missing or unbuildable dependency chain was: ['modutils-depmod']
NOTE: Runtime target 'perf' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['perf',
'update-modules',
'modutils-depmod']
NOTE: Runtime target 'task-core-tools-profile' is unbuildable,
removing...
Missing or unbuildable dependency chain was:
['task-core-tools-profile',
'perf', 'update-modules', 'modutils-depmod']
ERROR: Required build target 'sonatest-test-image' has no buildable
providers.
Missing or unbuildable dependency chain was: ['sonatest-test-image',
'task-core-tools-profile', 'perf', 'update-modules',
'modutils-depmod']
With KERNEL_FEATURES_crownbay += bluetooth, I get the following when
recompiling the kernel:
Log data follows:
| Deleted branch meta-temp (was 620917d).
| WARNING: addon feature bluetooth was not found
| ERROR: required features were not found. aborting
BTW, I did not find any precise kernel feature for bluetooth when
looking in
builddir/tmp/work/crownbay-poky-linux/linux-yocto/linux/meta/cfg/kernel-cache/
Right, you would need to add something if you need a driver that isn't
listed there or in the crownbay BSP.
Sorry to bring this up again, but since the documentation states that
bluetooth is a valid MACHINE_FEATURE option and no configuration
fragment is present to support this feature does that mean that it
cannot really work by simply adding the option? Could this be a
bug/missing feature?
BTW, I got bluetooth working but I add to create a config fragment like
you suggested which is kind of confusing since a MACHINE_FEATURE already
exists for this functionality.
The bug you filed needs to get fixed, when it does, the MACHINE_FEATURES
+= bluetooth combined with the stock linux-yocto kernel will combine
with the definition of task-base-bluetooth to give you what you are
looking for.
See meta/recipes-core/tasks/task-base.bb:
RDEPENDS_task-base-bluetooth = \
bluez4 \
RRECOMMENDS_task-base-bluetooth = \
kernel-module-bluetooth \
kernel-module-l2cap \
kernel-module-rfcomm \
kernel-module-hci-vhci \
kernel-module-bnep \
kernel-module-hidp \
kernel-module-hci-uart \
kernel-module-sco \
${@base_contains('COMBINED_FEATURES', 'usbhost',
'kernel-module-hci-usb', '',d)} \
${@base_contains('COMBINED_FEATURES', 'pcmcia',
'kernel-module-bluetooth3c-cs', '',d)} \
${@base_contains('COMBINED_FEATURES', 'pcmcia',
'kernel-module-bluecard-cs', '',d)} \
${@base_contains('COMBINED_FEATURES', 'pcmcia',
'kernel-module-bluetoothuart-cs', '',d)} \
${@base_contains('COMBINED_FEATURES', 'pcmcia',
'kernel-module-dtl1-cs', '',d)} \
What this does is include the required kernel module packages created by
the linux-yocto recipe in the package feed for your image.
Saul mentioned he would try and have a look at that bug, CC'ing him for
reference. Looking at that bug though, I see Richard has commented:
http://bugzilla.yoctoproject.org/show_bug.cgi?id=1814
Can you try with his suggestion, using:
MACHINE_FEATURES_append_crownbay = bluetooth
I believe the assignment you were using before explains why you hit the
original modutils-depmod failure. See:
$ git grep modutils-depmod
Re: [yocto] Fullpass Test Report for Yocto 1.0.2 Build
I think we should pull in the patch for 1236 from master, update the DISTRO_VERSION and respin. Any thoughts? Joshua On 11/12/11 19:10, Xu, Jiajun wrote: Hi all, We have finished qemux86-64 testing. Thanks for Josh’s help on image build. There is one bug found with qemux86-64, “Broken ldd due to wrong path for ld.so”. Detailed test result has been updated as attachment. *Detailed Test Result for each component* *Target* *Total TCs*** *Not Run* *Passed*** *Failed*** *Not testable (Blocked)*** *Qemux86-64 Sato* 30 0 28 2 (bug 1174, 1234) 0 *Qemux86-64 Sato-SDK* 35 0 31 3 (bug 1236, 1174, 1234) 0 Best Regards, Jiajun *From:*yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] *On Behalf Of *Xu, Jiajun *Sent:* Friday, December 09, 2011 5:25 PM *To:* p...@pokylinux.org; yocto@yoctoproject.org *Subject:* [yocto] Fullpass Test Report for Yocto 1.0.2 Build Hi All, This is the fullpass test report for Yocto 1.0.2 build. Qemux86-64 image failed on autobuilder due to bintuils compile failed. There are 5 old bugs existing with this build, all of them are not critical. Rpm/zypper install costs lots of disk space. Install/Remove button does not work in sato image. UNFS does not work with qemuppc. CVS configure failed with x86_64 toolchain. Another generic bug is that the DISTRO_VERSION is still set to 1.0.1, which needs to be updated to 1.0.2. Note: The test report is archived @ https://wiki.yoctoproject.org/wiki/Yocto_1.0.2_Test_Report. *Test Summary:* *---* *Test Result Summary* *Component* *Target* *Status* *Comments* *BSP* Beagleboard GOOD Everything runs well Routerstationpro GOOD Everything runs well Mpc8315e-rdb GOOD Everything runs well *QEMU* qemux86 GOOD RPM log costs lots of disk space; Sato desktop includes useless 'Install/Remove software' icon qemux86-64 BLOCK build failed on autobuilder qemuarm GOOD RPM log costs lots of disk space; Sato desktop includes useless 'Install/Remove software' icon qemuppc GOOD RPM log costs lots of disk space; qemumips GOOD RPM log costs lots of disk space; Sato desktop includes useless 'Install/Remove software' icon *ADT* BUGGY unfs does not work with qemuppc; cvs configure fail with no cvs_cv_func_printf_ptr set *Core build system* GOOD Everything runs well *Compliance* GOOD All LTP IPC related cases failed on routerstationpro *Stress* GOOD Both Crashme and Helltest on Jasperforest and both Crashme and LTP on Beagleboard could pass 24 hours stress testing. 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)*** *Beagleboard Sato-SDK* 20 0 20 0 0 *Routerstationpro Sato-SDK* 32 0 32 0 0 *Mpc8315e-rdb Sato-SDK* 33 0 33 0 0 *Qemux86 Sato* 30 0 28 2 (bug 1174, 1234) 0 *Qemux86 Sato-SDK* 35 0 32 2 (bug 1174, 1234) 0 *Qemuarm Sato* 30 0 29 1 (bug 1234) 0 *Qemuarm Sato-SDK* 35 0 34 1 (bug 1234) 0 *Qemumips Sato* 30 0 29 1 (bug 1234) 0 *Qemumips Sato-SDK*
