Re: [yocto] [PATCH 1/1] meta-tlk: fix ignored SRC_URI appends
On 2012-10-04 20:51, Paul Eggleton wrote:
Hi Mihai,
On Thursday 04 October 2012 20:47:08 Mihai Lindner wrote:
Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used
SRC_URI_append instead of SRC_URI.
Also placed all variables in an .inc file to be required by all
linux-yocto recipes in here, since all versions use the same.
[YOCTO #3217]
Signed-off-by: Mihai Lindner mihaix.lind...@linux.intel.com
---
meta-tlk/recipes-kernel/linux/linux-yocto.inc | 3 +++
meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +--
meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +--
meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +--
4 files changed, 6 insertions(+), 18 deletions(-)
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto.inc
b/meta-tlk/recipes-kernel/linux/linux-yocto.inc new file mode 100644
index 000..96a3adf
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto.inc
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+SRC_URI_append += file://time-limited-kernel.cfg
You should use SRC_URI_append = file://time-limited-kernel.cfg (note
leading
space) here. Obviously what you have done does work, but we want to avoid
_append += as it can be confusing.
Cheers,
Paul
Hi Paul,
Ok, good to know. I will resend.
I was trying to avoid spaces in values and += fitted the description.
Thanks,
--
Mihai Lindner
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of Hello, World!
On Thu, 2012-10-04 at 20:00 -0700, Rudolf Streif wrote:
Disclaimer: I am no Bitbake expert. I just put this together by
rummaging through the Bitbake code for a couple of minutes. I am
reasonably confident that what I am saying below is rather accurate
but the Bitbake experts know better.
Indeed it is. One of my first tasks will be to *remove* as
much as possible from this until the only thing it does is
print out Hello, World! I'll be happy to share my results
if anyone is interested.
You can just do a recipe and overwrite do_build() in it e.g.
python do_build() {
bb.note(Hello World)
}
That would print:
NOTE: Hello World
and would probably only sent it to the task logfile.
bb.plain(Hello World)
would make it to the console though :)
[...]
1) Must a task function be a Python function? Or will a
bash function do?
Tasks must be Python functions.
No, they can be shell functions too.
Cheers,
Richard
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The BitBake equivalent of Hello, World!
Tasks must be Python functions.
No, they can be shell functions too.
Probably worth adding that if you are doing an _append() on a task
function, you have to match the original function type. E.g., if you
want to append a shell snippet to a python task function, you need to do
something like this (from the eglibc recipe):
do_unpack_append() {
bb.build.exec_func('do_move_ports', d)
}
do_move_ports() {
if test -d ${WORKDIR}/${EGLIBC_BRANCH}/ports ; then
rm -rf ${S}/ports
mv ${WORKDIR}/${EGLIBC_BRANCH}/ports ${S}/
fi
}
Tomas
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] meta-tlk: fix ignored SRC_URI appends
Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used SRC_URI_append instead of SRC_URI. Also placed all variables in an .inc file to be required by all linux-yocto recipes in here, since all versions use the same. [YOCTO #3217] Signed-off-by: Mihai Lindner mihaix.lind...@linux.intel.com --- The following changes since commit 6eea475e2038c1de3fbbd5bcd0986862ff85bb9a: meta-crownbay: remove 3.0 kernel support (2012-10-04 20:20:52 -0500) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mihai/bug3217 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mihai/bug3217 Mihai Lindner (1): meta-tlk: fix ignored SRC_URI appends meta-tlk/recipes-kernel/linux/linux-yocto.inc | 3 +++ meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +-- meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +-- meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +-- 4 files changed, 6 insertions(+), 18 deletions(-) create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto.inc -- 1.7.12 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] meta-tlk: fix ignored SRC_URI appends
Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used
SRC_URI_append instead of SRC_URI.
Also placed all variables in an .inc file to be required by all
linux-yocto recipes in here, since all versions use the same.
[YOCTO #3217]
Signed-off-by: Mihai Lindner mihaix.lind...@linux.intel.com
---
meta-tlk/recipes-kernel/linux/linux-yocto.inc | 3 +++
meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +--
meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +--
meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +--
4 files changed, 6 insertions(+), 18 deletions(-)
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto.inc
b/meta-tlk/recipes-kernel/linux/linux-yocto.inc
new file mode 100644
index 000..b1cf883
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto.inc
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+SRC_URI_append = file://time-limited-kernel.cfg
+PR .= .2
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 138cc21..bd54419 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-
-# enable the time limited kernel configuration options
-SRC_URI += file://time-limited-kernel.cfg
-
-PR .= .1
+require ${PN}.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
index 138cc21..bd54419 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-
-# enable the time limited kernel configuration options
-SRC_URI += file://time-limited-kernel.cfg
-
-PR .= .1
+require ${PN}.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
index 138cc21..bd54419 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-
-# enable the time limited kernel configuration options
-SRC_URI += file://time-limited-kernel.cfg
-
-PR .= .1
+require ${PN}.inc
--
1.7.12
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] eglibc fails to build
This is default configuration for poky-tiny and core-image-rt. Even with no changes to default configuration it fails to build. -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Thursday, October 04, 2012 1:03 PM To: Szankin, Maciej Cc: yocto@yoctoproject.org Subject: Re: [yocto] eglibc fails to build On Thu, 2012-10-04 at 10:02 +, Szankin, Maciej wrote: Hi, I’m having a hard time building yocto. I’m trying to build a tiny-poky / core-image-rt , but it doesn’t even matter as in every configuration it just fails on eglibc. Target architecture is x86. I will keep it clean so the error log returned by build is here - http://pastebin.com/RNv5u8H8 I think that only the last line are what matters the most. The only issue that I see is multiple reference (starts @ 241 line). Before this I had problems with building elfutils but adding libc-ftraverse and libc-posix-clang-wchar to DISTRO_FEATURES_LIBC_DEFAULTS fixed this. Is there anything that I can do with eglibc? It sounds like those libc options you've added have some dependencies or other configuration you're missing. I'm not sure what those are but it definitely looks like an unsupported set of eglibc configuration options combinations. Cheers, Richard - Intel Technology Poland sp. z o.o. z siedziba w Gdansku ul. Slowackiego 173 80-298 Gdansk Sad Rejonowy Gdansk Polnoc w Gdansku, VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, numer KRS 101882 NIP 957-07-52-316 Kapital zakladowy 200.000 zl This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] meta-tlk: fix ignored SRC_URI appends
On Fri, 2012-10-05 at 14:20 +0300, Mihai Lindner wrote: Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used SRC_URI_append instead of SRC_URI. Also placed all variables in an .inc file to be required by all linux-yocto recipes in here, since all versions use the same. [YOCTO #3217] Signed-off-by: Mihai Lindner mihaix.lind...@linux.intel.com --- meta-tlk/recipes-kernel/linux/linux-yocto.inc | 3 +++ Could you use a slightly less generic name for this include please? I worry about collisions... Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] meta-tlk: fix ignored SRC_URI appends
Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used
SRC_URI_append instead of SRC_URI.
Also placed all variables in an .inc file to be required by all
linux-yocto recipes in here, since all versions use the same.
[YOCTO #3217]
Signed-off-by: Mihai Lindner mihaix.lind...@linux.intel.com
---
meta-tlk/recipes-kernel/linux/linux-yocto-tlk.inc | 3 +++
meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +--
meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +--
meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +--
4 files changed, 6 insertions(+), 18 deletions(-)
create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto-tlk.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto-tlk.inc
b/meta-tlk/recipes-kernel/linux/linux-yocto-tlk.inc
new file mode 100644
index 000..b1cf883
--- /dev/null
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto-tlk.inc
@@ -0,0 +1,3 @@
+FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+SRC_URI_append = file://time-limited-kernel.cfg
+PR .= .2
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 138cc21..e316320 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-
-# enable the time limited kernel configuration options
-SRC_URI += file://time-limited-kernel.cfg
-
-PR .= .1
+require ${PN}-tlk.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
index 138cc21..e316320 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-
-# enable the time limited kernel configuration options
-SRC_URI += file://time-limited-kernel.cfg
-
-PR .= .1
+require ${PN}-tlk.inc
diff --git a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
index 138cc21..e316320 100644
--- a/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
+++ b/meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -1,6 +1 @@
-FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
-
-# enable the time limited kernel configuration options
-SRC_URI += file://time-limited-kernel.cfg
-
-PR .= .1
+require ${PN}-tlk.inc
--
1.7.12
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] meta-tlk: fix ignored SRC_URI appends
On 2012-10-05 14:51, Richard Purdie wrote: On Fri, 2012-10-05 at 14:20 +0300, Mihai Lindner wrote: Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used SRC_URI_append instead of SRC_URI. Also placed all variables in an .inc file to be required by all linux-yocto recipes in here, since all versions use the same. [YOCTO #3217] Signed-off-by: Mihai Lindner mihaix.lind...@linux.intel.com --- meta-tlk/recipes-kernel/linux/linux-yocto.inc | 3 +++ Could you use a slightly less generic name for this include please? I worry about collisions... Cheers, Richard Sure. Thanks, -- Mihai Lindner ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Making recipes depend on specific layers
I run into problems (typically with BSP layers) where I want the layer to build only against oe-core, but I also would like to have recipes that depend on other layers. Typically, a complex image that uses packages built from other layers. Now, I could just make a shim layer that contains the recipes that depends on a larger set of layers, but this gets annoying. What I'd like to do is provide a way for recipes to say they depend on other layers, but if that layer is not present, parsing should not fail. Obviously, attempting to build such a recipe would fail (with a suitable error message). Richard showed me some Python I can use to do this, but I'd like to know if this seems useful to other people. Obviously, switching layer sin and out can lead to madness, but I'd rather not try to protect the end user from every stupid thing they can do at the expense of making thing more complex from a shear number of layers view. Philip ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Making recipes depend on specific layers
Hi, On 05/10/12 14:58, Philip Balister wrote: I run into problems (typically with BSP layers) where I want the layer to build only against oe-core, but I also would like to have recipes that depend on other layers. Typically, a complex image that uses packages built from other layers. Not sure if I fully understood what you are trying to do, but I'd be worried about adding yet another dependency dimension to the system as a whole. Regarding the problems with coexisting bsp layers, I eventually came to the conclusion that it's best to avoid parsing any irrelevant bsp layers altogether. The way we handle this in Guacamayo is to keep the bsp-related recipes in dedicated directories that can be easily BBMASKed out: recipes-bsp/ti-appends: for recipes related to meta-ti recipes-bsp/rpi-appends: for recipes related to meta-raspberrypi For each machine we support we then have a machine conf that looks like this (e.g., for beagleboard.conf): # source canonical beagleboard.conf from meta-ti require ../../../layers/meta-ti/conf/machine/beagleboard.conf BBMASK .= |.*/meta-raspberrypi|.*/recipes-bsp/rpi-appends Consequently for any given machine only a single bsp layer is ever parsed and the layers do not interfere with each other; this currently triggers a bitbake warning about no recipes being in the masked out layers, but other than does exactly what it is meant to. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] HTTP-accessible poky repo?
I'd like to track yocto development more closely, but I'm stuck behind a restrictive HTTP-only firewall all day at work. Is there an official (or unofficial-but-up-to-date), HTTP-accessible mirror of git://git.yoctoproject.org/poky.git I can clone from? I can create a clone on github and run some cron scripts at home to sync it, but I'd rather not bother if there's already something like this out there... ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project 1.3 beta feedback
Below you can find my answers to the Yocto Project 1.3 beta testing survey. Regards, Andrea Experience survey of using Yocto 1.3 Q: Which architecture did you choose to build? A: qemuppc, beagleboard Q: How easily were you able to build an image and boot an image? A: Quite easily. I also took some time for reviewing the QS guide which looks adequate to me either for newbies or users coming from different build systems. Q: Is there any surprise to you in the process of doing this Beta testing? If so, would you please describe it and tell us how you expected it to work? A: Not really a surprise (already knew about that), but a very pleasant experience was knotty2. It results cleaner than its forever-scrolling parent. Q: How do you like our HOB interface? Please provide us with your thoughts and suggestions on HOB interface and functionality. A: I like the hob design. It actually does not support yet a few workflows that I consider much important for my work: i.e. adding new recipes, supporting kernel development (mainly configuration, patching). I understand not every user does require them and hence I don't consider myself as the actual hob's average target user. Anyway I appreciate the project is working on more intuitive tools like HOB and I look forward to see if similar effort will also bring us webhob experience in the future. People doing mainly package integration would benefit the best from HOB, since they need not to dig into the build system's details. Q: Was it easy to find the support you needed to build and boot an image? A: Procedures for the official emulated target are well documented and clear enough for the task required by this beta testing. Support for deploying and booting on reference real-hardware target is a little bit lacking but a lot of resources and documentation are already available online and I agree on not duplicating reference material. Q: Which Bugzilla reports did you submit? A: None till now. Still investigating on some oddities and discussing with the team on IRC. Also hit bug #3135, which is already fixed in master now. Q: Did you try anything else with Yocto 1.3? A: Building an SDK and investigating procedures to deploy toolchains, SDKs and ADTs is one of my primary goals. I built toolchains for the arm architecture and tested the environment to build a simple C source. Relocatable SDK is a good improvement in term of flexibility when deploying for application developers. The beta snapshot does bring bug #3135, but it's already fixed in master. Q: What would you like to have in Yocto Project for future releases? A: Documentation as a whole IMHO should and must improve a bit to make it more useful for reference. At the design level, I see the team is working very well, by keeping the documentation in a single place: this grants us consistency and its really a good point. I still see some confusion between online documentation, documentation source you can build from master and the latest online documentation which is often referenced on the mailing list. However I know that keeping all the docs up-to-date and consistent is not an easy job. Needs with respect to documentation do largely depend on the user's perspective. For instance, if your goal is writing new recipes for your own layers, you'll ask for a good variables reference and, maybe, a reasonable checklist with best conventions for keeping metadata consistent. This is also required if you want to contribute back with high degree of confidence that your patches will be considered and reviewed. If, on the other hand, your are more involved in kernel configuration and customization, your hope is to keep your work as much as possible integrated with the build system: this will grant you a closer develop-deploy-test flow by using the same tools will be used for production. Such a workflow does have documentation but I personally believe this is a point we can improve a lot. Yocto Project users do belong to a very heterogeneous base: I see a great challenge in keeping docs usable by differently focused people! ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project 1.3 beta feedback
Andrea, Thanks for the detailed feedback on the YP documentation. Agree that it is difficult to meet the needs of the wide group of users and that it is difficult to have the released documentation match that of the latest from the website. The latest documentation is always under development and I fear will never match the released documentation. One radical scheme to consider is releasing a separate tarball for documentation that a user could download and then insert into their poky repository on the local system. This would in a sense de-couple the docs and the released poky tarball. Probably not a popular idea among the team but an out-of-the-box one nonetheless. We will continue to try and improve specific workflows based on specific target audience needs. Feedback such as this helps. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Andrea Galbusera Sent: Friday, October 05, 2012 8:43 AM To: yocto@yoctoproject.org Subject: [yocto] Yocto Project 1.3 beta feedback Below you can find my answers to the Yocto Project 1.3 beta testing survey. Regards, Andrea Experience survey of using Yocto 1.3 Q: Which architecture did you choose to build? A: qemuppc, beagleboard Q: How easily were you able to build an image and boot an image? A: Quite easily. I also took some time for reviewing the QS guide which looks adequate to me either for newbies or users coming from different build systems. Q: Is there any surprise to you in the process of doing this Beta testing? If so, would you please describe it and tell us how you expected it to work? A: Not really a surprise (already knew about that), but a very pleasant experience was knotty2. It results cleaner than its forever-scrolling parent. Q: How do you like our HOB interface? Please provide us with your thoughts and suggestions on HOB interface and functionality. A: I like the hob design. It actually does not support yet a few workflows that I consider much important for my work: i.e. adding new recipes, supporting kernel development (mainly configuration, patching). I understand not every user does require them and hence I don't consider myself as the actual hob's average target user. Anyway I appreciate the project is working on more intuitive tools like HOB and I look forward to see if similar effort will also bring us webhob experience in the future. People doing mainly package integration would benefit the best from HOB, since they need not to dig into the build system's details. Q: Was it easy to find the support you needed to build and boot an image? A: Procedures for the official emulated target are well documented and clear enough for the task required by this beta testing. Support for deploying and booting on reference real-hardware target is a little bit lacking but a lot of resources and documentation are already available online and I agree on not duplicating reference material. Q: Which Bugzilla reports did you submit? A: None till now. Still investigating on some oddities and discussing with the team on IRC. Also hit bug #3135, which is already fixed in master now. Q: Did you try anything else with Yocto 1.3? A: Building an SDK and investigating procedures to deploy toolchains, SDKs and ADTs is one of my primary goals. I built toolchains for the arm architecture and tested the environment to build a simple C source. Relocatable SDK is a good improvement in term of flexibility when deploying for application developers. The beta snapshot does bring bug #3135, but it's already fixed in master. Q: What would you like to have in Yocto Project for future releases? A: Documentation as a whole IMHO should and must improve a bit to make it more useful for reference. At the design level, I see the team is working very well, by keeping the documentation in a single place: this grants us consistency and its really a good point. I still see some confusion between online documentation, documentation source you can build from master and the latest online documentation which is often referenced on the mailing list. However I know that keeping all the docs up-to-date and consistent is not an easy job. Needs with respect to documentation do largely depend on the user's perspective. For instance, if your goal is writing new recipes for your own layers, you'll ask for a good variables reference and, maybe, a reasonable checklist with best conventions for keeping metadata consistent. This is also required if you want to contribute back with high degree of confidence that your patches will be considered and reviewed. If, on the other hand, your are more involved in kernel configuration and customization, your hope is to keep your work as much as possible integrated with the build system: this will grant you a closer develop-deploy-test flow by using the same tools will be used for production. Such a workflow does have documentation but I personally believe
Re: [yocto] [PATCH 0/1] meta-tlk: fix ignored SRC_URI appends
On Fri, 2012-10-05 at 14:20 +0300, Mihai Lindner wrote: Fix SRC_URI appends ignored by meta-cedartrail and meta-crownbay. Used SRC_URI_append instead of SRC_URI. Also placed all variables in an .inc file to be required by all linux-yocto recipes in here, since all versions use the same. [YOCTO #3217] Signed-off-by: Mihai Lindner mihaix.lind...@linux.intel.com --- The following changes since commit 6eea475e2038c1de3fbbd5bcd0986862ff85bb9a: meta-crownbay: remove 3.0 kernel support (2012-10-04 20:20:52 -0500) are available in the git repository at: git://git.yoctoproject.org/poky-contrib mihai/bug3217 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mihai/bug3217 Pulled into meta-intel/master. Thanks, Tom Mihai Lindner (1): meta-tlk: fix ignored SRC_URI appends meta-tlk/recipes-kernel/linux/linux-yocto.inc | 3 +++ meta-tlk/recipes-kernel/linux/linux-yocto_3.0.bbappend | 7 +-- meta-tlk/recipes-kernel/linux/linux-yocto_3.2.bbappend | 7 +-- meta-tlk/recipes-kernel/linux/linux-yocto_3.4.bbappend | 7 +-- 4 files changed, 6 insertions(+), 18 deletions(-) create mode 100644 meta-tlk/recipes-kernel/linux/linux-yocto.inc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCHv2 1/1] crownbay.conf: add kernel parameters for EMGD video acceleration
-Original Message-
From: Hart, Darren
Sent: Thursday, October 04, 2012 3:34 PM
To: Kamble, Nitin A
Cc: Zanussi, Tom; yocto@yoctoproject.org
Subject: Re: [PATCHv2 1/1] crownbay.conf: add kernel parameters for EMGD
video acceleration
On 10/04/2012 03:23 PM, nitin.a.kam...@intel.com wrote:
From: Nitin A Kamble nitin.a.kam...@intel.com
This is recommended in the EMGD User Guide.
My understanding is the emgd kernel driver need to allocate memory
dynamically, and the vmalloc=256MB parameter ensures enough will be
available for the driver.
OK, this explains the change to vmalloc.
Why the change of vga=current and the drop of video=vesafb ?
Darren,
Good catch. I changed this for cleanup, but now I see that it affects the
splash screen. So I will resend the commit by dropping these extra changes.
Thanks,
Nitin
--
Darren
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/conf/machine/crownbay.conf |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index 40dbd1d..f02615e 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -21,7 +21,7 @@ PREFERRED_VERSION_xserver-xorg ?= 1.9.3
PREFERRED_VERSION_mesa-dri ?= 7.11
PREFERRED_VERSION_xf86-input-evdev ?= 2.6.0
-APPEND += video=vesafb vga=0x318
+APPEND += vga=current vmalloc=256MB
VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
commercial, gst-va-intel va-intel, va-intel, d)}
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCHv3 0/1] meta-intel misc commits
From: Nitin A Kamble nitin.a.kam...@intel.com Updated the kernel command line for crownbay BSP, after discussions with Darren. Thanks, Nitin The following changes since commit 7228f6b0c81817c8a8455ea78271abfd5d66fed8: meta-tlk: fix ignored SRC_URI appends (2012-10-05 14:47:55 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib nitin/misc http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/misc Nitin A Kamble (1): crownbay.conf: add kernel parameters for EMGD video acceleration meta-crownbay/conf/machine/crownbay.conf |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.3.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCHv3 1/1] crownbay.conf: add kernel parameters for EMGD video acceleration
From: Nitin A Kamble nitin.a.kam...@intel.com
This is recommended in the EMGD User Guide.
My understanding is that, the emgd kernel driver need
to allocate memory dynamically, and the vmalloc=256MB
parameter ensures enough will be available for the driver.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
meta-crownbay/conf/machine/crownbay.conf |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta-crownbay/conf/machine/crownbay.conf
b/meta-crownbay/conf/machine/crownbay.conf
index 40dbd1d..c18fa1d 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -21,7 +21,7 @@ PREFERRED_VERSION_xserver-xorg ?= 1.9.3
PREFERRED_VERSION_mesa-dri ?= 7.11
PREFERRED_VERSION_xf86-input-evdev ?= 2.6.0
-APPEND += video=vesafb vga=0x318
+APPEND += video=vesafb vga=0x318 vmalloc=256MB
VA_FEATURES = ${@bb.utils.contains(LICENSE_FLAGS_WHITELIST, \
commercial, gst-va-intel va-intel, va-intel, d)}
--
1.7.3.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
