Re: [yocto] syslinux filesystem size limitation
Hello, On Thu, 2012-03-15 at 18:37 +0530, Joshua Immanuel wrote: In yocto I find that the live image (hddimg) is generated using syslinux (in bootimg.bbclass). But, I find there has been no check enforced to find whether the filesystem size exceeds 1 GB. The image will not boot if the hddimg size exceeds 1GB. This is due to the limitation in syslinux. For the benefit of others who arrived at this thread via search I am writing this. Apparently, there is no 1GB limitation with syslinux. The problem was due to mkdosfs tool in poky edison branch. The complete discussions about this can be found in the (long) comments section of this bug. https://bugzilla.yoctoproject.org/show_bug.cgi?id=2138 I would like to thank Darren for helping me in debugging this problem. Regards -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in signature.asc Description: This is a digitally signed message part ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Mon, 2012-03-26 at 02:43 -0500, Peter Seebach wrote: On Sat, 24 Mar 2012 17:15:15 + Richard Purdie richard.pur...@linuxfoundation.org wrote: This implies that once we enable pseudo for a child, there is some change in the parent which persists. Hmm. Is the parent running with pseudo loaded? If it were, then I would expect this -- pseudo does some environment magic that can affect the parent, and also cause it to stash values for later restoration. BitBake always runs with pseudo loaded but disabled. When we fork a child, we decide whether to enable it or not and setup the environment to either bring pseudo to life, or unload it from memory entirely. It sounds to me like our enable/disable code confuses the heck out of pseudo in the parent environment, likely overwriting a stashed value which it needs to be able to find itself again (prefix/localstate). Obviously we can change the way we manipulate the environment although that isn't entirely straightforward as we need to ensure the pseudo paths don't leak into sstate package checksums for example. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Request for Yocto Project 1.2 release Beta Program Users Yocto T-Shirt
Hi Song, Just wondering how many volunteers for the Beta release you have. Do you think it would be possible to add some usability testing of Hob to the Beta programme? This would involve us contacting a few of the volunteers and asking them to do a couple of simple things with Hob while we watch (sitting with them or remotely by sharing the screen over Skype or similar). Thanks! Belen On 09/03/2012 23:33, Liu, Song song@intel.com wrote: Hi all, It's that time again. We are starting the Beta program for Yocto Project 1.2 release. This release focuses on usability of the Yocto Project. HOB2 is the second version of our Human Oriented Builder (GUI based), which will help developers build customized Linux image in a much more intuitive and smoother way. Build appliance will help users on Windows to get started with Yocto Project quickly. There are also many other features such as multi-lib improvement, error handling improvement, BSP tools, etc. Please volunteer or send me the names who you think should be a good candidate for our Beta release users. Anyone who is interested in Yocto Project and/or has some technical background in embedded Linux area should be just fine. And this time, we will send our Beta users some Yocto T-Shirts and I'm sure you will look more attractive in them :) If you do want to volunteer or have someone in mind, please send me the names sometime next week. Thank you for your support and we really appreciate it! Thanks, Song ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 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
[yocto] can all of the licensing discussion be centralized in an appendix?
still clawing my way through the ref manual and it seems that there's *way* too much coverage of licensing sprinkled throughout. most people are not going to care about licensing until the time comes to maybe start distributing their BSP. as it stands, in the *development* version of the ref manual, section 3.4 is all about licensing, then ch 4 is essentially the BSP guide where section 4.2.1 is License Files and all of section 4.3 is BSP Licensing Considerations. that just seems like too much licensing info that breaks up the flow of the reference manual. can all of that be moved to one location and referenced from there? rday p.s. i'm also not keen on an entire chapter of the ref manual being nothing more than an include of the BSP guide. if you've got a perfectly respectable BSP guide, there's no point having it magically appear as part of another manual. but that's just my $0.02. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ref manual, ch 5, claims that toolchain should be installed under /opt/poky
currently, ch 5 of the reference manual claims that a generated meta-toolchain tarball should be unpacked under /opt/poky, which might be *historically* correct but i just baked a meta-toolchain and its tarball contents are all prefixed with ./usr/local/, which seems inconsistent with that. is the toolchain tarball relocatable these days? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] numerous poky references now need to be deleted from docs
could have mentioned this in my previous post, but there are numerous uses of the phrase poky in, for instance, the yocto reference manual that need to be scrapped. as one example, toolchains that used to be untarred under /opt/poky now appear to belong (more reasonably) under /usr/local. references to toolchain commands like arm-poky-linux-gnueabi-gcc should now be (in the case of an arm toolchain) arm-oe-linux-gnueabi-gcc. what used to be /opt/poky/environment-setup-i586-poky-linux is now some form of environment-setup-armv5te-oe-linux-gnueabi. you get the idea -- lots of poky removal to be done. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Support of meta-kde for Poky
Hi, the development of meta-kde has come to a point where kde-applications can be tested (and maybe used). Status of meta-kde: Most common applications work, for example: Calligra (not all of the toolkit), Kate, KCalc, Konqueror, Kwin Kwin_gles (KDE window manager), Okular and the applications from KDE-baseapps. Plasma Active (and Desktop) do not work correctly, but I'm working on it. Plasma Netbook seems to work, but it needs more testing. Involving the community: As the development of meta-kde advanced to a point where developers can use the layer to port KDE applications. I'd like to invite others to test the layer, port their favorite KDE applications and express their opinions about the current status. Feel free to ask questions and suggest applications to be ported. meta-kde has no mailing list, so I'm looking for a list to host the discussion, any suggestions? Current issues with Poky: The giflib recipe is not contained in Poky. Is this based on a design decision, or just because no one needs it? As a meta-kde developer I don't want to limit the testing of meta-kde. Would it be feasible to add giflib to Poky? In this case I'm welcoming your suggestions. According to Robert Yang this is the only dependency missing in Poky. If there will be more missing dependencies in the future. adding a meta-kde-poky compatibility layer would be a better solution. -- Regards Samuel ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Support of meta-kde for Poky
Op 26 mrt. 2012, om 07:55 heeft Samuel Stirtzel het volgende geschreven: Hi, the development of meta-kde has come to a point where kde-applications can be tested (and maybe used). Status of meta-kde: Most common applications work, for example: Calligra (not all of the toolkit), Kate, KCalc, Konqueror, Kwin Kwin_gles (KDE window manager), Okular and the applications from KDE-baseapps. Plasma Active (and Desktop) do not work correctly, but I'm working on it. Plasma Netbook seems to work, but it needs more testing. Involving the community: As the development of meta-kde advanced to a point where developers can use the layer to port KDE applications. I'd like to invite others to test the layer, port their favorite KDE applications and express their opinions about the current status. Feel free to ask questions and suggest applications to be ported. meta-kde has no mailing list, so I'm looking for a list to host the discussion, any suggestions? Current issues with Poky: The giflib recipe is not contained in Poky. Is this based on a design decision, or just because no one needs it? As a meta-kde developer I don't want to limit the testing of meta-kde. Would it be feasible to add giflib to Poky? In this case I'm welcoming your suggestions. Just add meta-oe to the poky stack. This is how the layer model is supposed to work. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Support of meta-kde for Poky
On Monday 26 March 2012 14:55:40 Samuel Stirtzel wrote: the development of meta-kde has come to a point where kde-applications can be tested (and maybe used). Status of meta-kde: Most common applications work, for example: Calligra (not all of the toolkit), Kate, KCalc, Konqueror, Kwin Kwin_gles (KDE window manager), Okular and the applications from KDE-baseapps. Plasma Active (and Desktop) do not work correctly, but I'm working on it. Plasma Netbook seems to work, but it needs more testing. Involving the community: As the development of meta-kde advanced to a point where developers can use the layer to port KDE applications. I'd like to invite others to test the layer, port their favorite KDE applications and express their opinions about the current status. Feel free to ask questions and suggest applications to be ported. Great work! I will give it a try over the next few days and let you know how I get on. (Sorry I know I promised to do this some weeks ago.) meta-kde has no mailing list, so I'm looking for a list to host the discussion, any suggestions? Probably just the oe-devel list - if the volume of commits gets too high then we can look at splitting off a separate one. Current issues with Poky: The giflib recipe is not contained in Poky. Is this based on a design decision, or just because no one needs it? It's based upon nothing in OE-Core needing it. (The poky repository is just OE-Core + bitbake + meta-yocto + yocto-docs). As a meta-kde developer I don't want to limit the testing of meta-kde. It should be OK to use meta-oe with Poky, and therefore meta-kde can depend upon it. However we are aware that meta-oe overlays a bunch of recipes that ideally it should not. We're working (albeit slowly) to address these. An alternative in the meantime would be to add giflib to meta-kde, this will do no significant harm if it is already available in another layer (and giflib doesn't look like it has really changed since 2008, so I don't think it will be much of a maintenance burden). As an aside it would be interesting to know why KDE requires additional gif support from giflib when gif loading is already built into Qt (and we do enable it in our Qt recipes). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Support of meta-kde for Poky
On Monday 26 March 2012 14:19:56 Paul Eggleton wrote: On Monday 26 March 2012 14:55:40 Samuel Stirtzel wrote: meta-kde has no mailing list, so I'm looking for a list to host the discussion, any suggestions? Probably just the oe-devel list - if the volume of commits gets too high Er, that should have been the volume of *messages*. Sorry. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] [linux-yocto-3.2][meta] common-pc: Add PCNET32 to the config
On 12-03-23 05:52 PM, Darren Hart wrote: In support of the self-hosted-image, add CONFIG_PCNET32 to the common-pc BSP default cfg. This enables the qemux86 image to be run on both qemux86 machines as well as the vmware 32b machine. Since the qemux86 machine optionally supports pcnet, this seems a reasonable compromise to managing a dedicated BSP for a self-hosted-image machine which would be superset of the qemux86 machine. As this is a single CONFIG_ option, add it to the common-pc.cfg directly, rather than defining a new feature. merged. I don't have any other pending commits, so I'll push this out later today as a standalone update. Cheers, Bruce The following changes since commit 514847185c78c07f52e02750fbe0a03ca3a31d8f: meta: update kver to v3.2.11 (2012-03-16 10:42:41 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib dvhart/meta/pcnet http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=dvhart/meta/pcnet Darren Hart (1): [meta] common-pc: Add PCNET32 to the config meta/cfg/kernel-cache/bsp/common-pc/common-pc.cfg |3 +++ meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg |1 + 2 files changed, 4 insertions(+), 0 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can all of the licensing discussion be centralized in an appendix?
Is BSP licensing different than non-BSP licensing? If not, then licensing could be combined into a single section. Can someone answer this for me? Also, good point on the BSP guide appearing as a chapter in the reference manual. I have not liked this. Is there any rational reason to have it this way? Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Monday, March 26, 2012 5:53 AM To: Yocto discussion list Subject: [yocto] can all of the licensing discussion be centralized in an appendix? still clawing my way through the ref manual and it seems that there's *way* too much coverage of licensing sprinkled throughout. most people are not going to care about licensing until the time comes to maybe start distributing their BSP. as it stands, in the *development* version of the ref manual, section 3.4 is all about licensing, then ch 4 is essentially the BSP guide where section 4.2.1 is License Files and all of section 4.3 is BSP Licensing Considerations. that just seems like too much licensing info that breaks up the flow of the reference manual. can all of that be moved to one location and referenced from there? rday p.s. i'm also not keen on an entire chapter of the ref manual being nothing more than an include of the BSP guide. if you've got a perfectly respectable BSP guide, there's no point having it magically appear as part of another manual. but that's just my $0.02. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ 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] meta-x32: disagreement between ref manual and README.TXT
Typo fixed. Nitin needs to respond on the apparent core inconsistency. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Sunday, March 25, 2012 10:17 AM To: Yocto discussion list Subject: [yocto] meta-x32: disagreement between ref manual and README.TXT poky ref manual reads: As usual, use BitBake to build an image that supports the x32 psABI. Here is an example: $ bitake core-image-sato As usual, run your image using QUEM [sic]: $ runqemu qemux86-64 core-image-sato while the README.TXT file that comes with the experimental/meta-x32 layer reads: build bitbake core-image-minimal-x32 4. boot the image runqemu qemux86-64 core-image-minimal-x32 thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ 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] can all of the licensing discussion be centralized in an appendix?
On Mon, 2012-03-26 at 14:26 +, Rifenbark, Scott M wrote: Is BSP licensing different than non-BSP licensing? If not, then licensing could be combined into a single section. Can someone answer this for me? The focus of those sections are different and should probably be in separate sections - the BSP licensing section of the BSP Guide deals mainly with the licensing considerations affecting BSP images, while the rest of the Manual deals with the nuts and bolts of how to deal with licenses when writing recipes. Also, good point on the BSP guide appearing as a chapter in the reference manual. I have not liked this. Is there any rational reason to have it this way? I guess it's there for convenience, but the only reason I can see for keeping it there other than that is that it's the only chapter that deals with the kernel. It would probably make sense would be to remove everything in the the BSP Guide from the reference manual, except for the kernel section, which should stay since it's of general interest and not just to people dealing with BSPs. Does that make sense? Tom Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Monday, March 26, 2012 5:53 AM To: Yocto discussion list Subject: [yocto] can all of the licensing discussion be centralized in an appendix? still clawing my way through the ref manual and it seems that there's *way* too much coverage of licensing sprinkled throughout. most people are not going to care about licensing until the time comes to maybe start distributing their BSP. as it stands, in the *development* version of the ref manual, section 3.4 is all about licensing, then ch 4 is essentially the BSP guide where section 4.2.1 is License Files and all of section 4.3 is BSP Licensing Considerations. that just seems like too much licensing info that breaks up the flow of the reference manual. can all of that be moved to one location and referenced from there? rday p.s. i'm also not keen on an entire chapter of the ref manual being nothing more than an include of the BSP guide. if you've got a perfectly respectable BSP guide, there's no point having it magically appear as part of another manual. but that's just my $0.02. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-x32: disagreement between ref manual and README.TXT
-Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Sunday, March 25, 2012 9:17 AM To: Yocto discussion list Subject: [yocto] meta-x32: disagreement between ref manual and README.TXT poky ref manual reads: As usual, use BitBake to build an image that supports the x32 psABI. Here is an example: $ bitake core-image-sato As usual, run your image using QUEM [sic]: $ runqemu qemux86-64 core-image-sato while the README.TXT file that comes with the experimental/meta-x32 layer reads: build bitbake core-image-minimal-x32 4. boot the image runqemu qemux86-64 core-image-minimal-x32 thoughts? rday Hi Robert, It is not a significant difference. Images with -x32 in their names contain an additional utility named file. Which can let one check the file types of elf binaries. And the absence of this file utility does not affect functionality of x32 images. Thanks, Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Mon, 2012-03-26 at 11:44 -0500, Peter Seebach wrote: On Sat, 24 Mar 2012 17:41:43 + Richard Purdie richard.pur...@linuxfoundation.org wrote: One or the other of the above on their own doesn't do this. Funky. That's very strange. I wouldn't have expected LOCALSTATEDIR to have any effect either way; it might change how pseudo runs, but it shouldn't affect whether it's being enabled. If we are starting with pseudo loaded, I'm pretty sure it's unsafe to unset PSEUDO_PREFIX ever. After a fork(), pseudo will still be in memory, and if PSEUDO_PREFIX is unset, Bad Things Happen. This is pretty much what we do at the moment, it gets unset after we load. Pseudo is of course disabled at this point. I guess we just got lucky to this point and avoided Bad Things? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Beta Testing (Yocto 1.2)
Hi All, Experience survey of Using Yocto 1.2 Q: Which architecture did you choose to build? A: qemu x86 (minimal) atom-pc (minimal) Q: How easily were you able to build an image and boot an image? A: Reasonably easy to create and boot up an image the as-is way(terminal). 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: There was no surprises. Once the environment setup was correct and layer configuration is set, it's easy to build the Yocto image. Q: How do you like our HOB interface? Please provide us with your thoughts and suggestions on HOB interface and functionality. A: The HOB interface is awesome. With HOB, the building process seems more fun and easier and simplified for a beginner. The manual method gives a bigger challenge to create an image. Q: Was it easy to find the support you needed to build and boot an image? A: Yes. Online documentation was adequately comprehensive. Q: Which Bugzilla reports did you submit? A: None. Q: Did you try anything else with Yocto 1.2? A: Nope. Just image creation and boot-up. Q: What would you like to have in Yocto Project for future releases? A: BSP customization and Selection for Real-time OS mode. Besides that could add smart package selection to suit different ecosystem. Example (Medical, Retail, Military, Robotics) Regards, Kanapathy Murugayah ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Unable to find recipe for glibc-2.11.1
Hi, I am looking for recipe of glibc-2.11.1 version. I googled for it but no success. Can anyone please suggest me the link from where i can download the same? Thanks and Regards Navani Kamal Srivastava ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Mon, 26 Mar 2012 17:47:29 +0100 Richard Purdie richard.pur...@linuxfoundation.org wrote: This is pretty much what we do at the moment, it gets unset after we load. Pseudo is of course disabled at this point. I guess we just got lucky to this point and avoided Bad Things? I suspect so. What's weird to me is that PSEUDO_PREFIX wasn't in the environment before, either. So I still don't quite get this. I am still missing something which will make this all make sense. ... at this point, I am leaning towards viewing this as a bug where it is not enough to simply correct the behavior, I will not feel confident in it until I have understood how it could have happened, but worked in many other cases. -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tentative list of vars to be dropped from variable glossary
Another variable that seems to be dropped from the latest 1.1.1 revision of the Reference Manual is BBMASK. In previous versions of the manual it was explained that this variable can be used to remove packages from images. However, that did not work for me and it did not surprise me either. To include a package with an image you will have to make it a dependency of that image. If you then hide the recipe of the package using BBMASK then you are breaking the dependency and the Bitbake will complain with Nothing provides package because the dependency is still there. I could not think of any other use case for BBMASK in the way it is implemented. Are there any? Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Sat, 24 Mar 2012 17:15:15 + Richard Purdie richard.pur...@linuxfoundation.org wrote: What puzzles me is we get this value from envbackup[key] = os.environ.get(PSEUDO_PREFIX) so its already not in the environment. So basically if we read PSEUDO_PREFIX from the environment we get nothing. If we unset the value back to being nothing, things break. Yes. This is, of course, obviously impossible. Hmm. Well, hmm. When we start up, we should pick up PSEUDO_PREFIX from our environment, and during some of the initial client setup, we should be stashing that value in our stashed values table. At this point, so far as I can tell, nothing should ever unset that stashed value. On fork(), we don't change anything until we're in the client side of the fork, but that setup should happen in the same address space, with the values still stashed. I did find one other thing, though, which worries me. I added a popen() wrapper, and the thing is. We're calling popen() with the antimagic bit set (the one that suppresses all the wrappers). Which would cause all sorts of problems, and I can't figure out how it'd be happening. So my new theory: * There's something specific causing us to end up invoking popen() with the antimagic bit set. This is obviously impossible. * But that means that, even if we trap other syscalls made by popen(), we won't be doing wrappers or fixups. * And that could expose problems to do with PSEUDO_PREFIX getting unset unexpectedly. So I think adding it to BB_ENV_EXTRAWHITE will hide this, but it won't explain how we're getting into a popen() call in antimagic mode. (Antimagic is the internal thing pseudo uses while trying to do client/server communications. Pretty sure it never calls popen.) -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
Oh, nevermind, I just realized: We use antimagic as the implementation goo for PSEUDO_DISABLED. So a call to os.popen() from a program which has PSEUDO_DISABLED set is going to think it's in antimagic mode. And suddenly, the trick is revealed: os.popen() is bypassing all the runqueue stuff which is trying to ensure that the environment is in a valid state. So if bitbake code calls os.popen(), it may behave weirdly, for the same reason that any other direct invocation of fork() or system() or whatnot would behave weirdly -- because bitbake is running with pseudo in a strange state. So I think the thing is: Because bitbake is running with PSEUDO_DISABLED, any child process that is not explicitly set to either enable or unload pseudo is going to be running under pseudo, with PSEUDO_DISABLED. And that means we need to ensure that PSEUDO_PREFIX stays set, because we need that even when pseudo is disabled. (It's used during some of the initial setup sanity checks.) -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can all of the licensing discussion be centralized in an appendix?
there's *way* too much coverage of licensing sprinkled throughout.
most people are not going to care about licensing until the time comes
to maybe start distributing their BSP.
The ability of collecting licensing information, tracking license changes
and providing the license information automatically with the images and
packages for deployment is in my opinion a major feature of Yocto albeit
underestimated. Most people will only appreciate it once they have to
deliver that information with a product for the end user. However, it
starts much earlier, with the recipe.
How to include licensing tracking information with your recipe needs to be
part of the section explaining how to write recipes of the reference
manual. In both, the current 1.1 and the upcoming 1.1.1, versions of the
manual the license tracking section is a little disjoint from the sections
explaining how to add packages/recipes in my opinion. The examples include
the license tracking info, of course because otherwise the sanity checker
will not allow building the recipe, but they don't explain that you
actually need it (unless you use LICENSE = CLOSED).
Since the license tracking and deployment feature follows the rule garbage
in, garbage out the manual cannot stress enough providing the correct info
in particular when writing recipes for upstream projects.
Side note: And nice features for a future release are SPDX info (already
worked on as far as I know) and providing the license info in
${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/images so
that one knows what licenses are in use for what image. That would be very
convenient when building multiple images with different package content.
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can all of the licensing discussion be centralized in an appendix?
Rudi,
I would like you to examine the latest documents (the ones under
development). I have added some new licensing information and would like your
feedback for this upcoming version. There are licensing discussions in both
the latest versions of the BSP Guide and the reference manual. Since, at the
moment, the BSP Guide is included as a chapter in the reference manual, I'll
point you to the latest version of the reference manual:
http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html.
Thanks,
Scott
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Rudolf Streif
Sent: Monday, March 26, 2012 2:52 PM
To: yocto@yoctoproject.org
Subject: Re: [yocto] can all of the licensing discussion be centralized in an
appendix?
there's *way* too much coverage of licensing sprinkled throughout.
most people are not going to care about licensing until the time comes
to maybe start distributing their BSP.
The ability of collecting licensing information, tracking license changes and
providing the license information automatically with the images and packages
for deployment is in my opinion a major feature of Yocto albeit underestimated.
Most people will only appreciate it once they have to deliver that information
with a product for the end user. However, it starts much earlier, with the
recipe.
How to include licensing tracking information with your recipe needs to be part
of the section explaining how to write recipes of the reference manual. In
both, the current 1.1 and the upcoming 1.1.1, versions of the manual the
license tracking section is a little disjoint from the sections explaining how
to add packages/recipes in my opinion. The examples include the license
tracking info, of course because otherwise the sanity checker will not allow
building the recipe, but they don't explain that you actually need it (unless
you use LICENSE = CLOSED).
Since the license tracking and deployment feature follows the rule garbage in,
garbage out the manual cannot stress enough providing the correct info in
particular when writing recipes for upstream projects.
Side note: And nice features for a future release are SPDX info (already worked
on as far as I know) and providing the license info in
${TMPDIR}/deploy/licenses according to the images in ${TMPDIR}/images so that
one knows what licenses are in use for what image. That would be very
convenient when building multiple images with different package content.
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] initrdscripts: fix init-live.sh and use unionfs
[YOCTO #1487]
Use unionfs to mount rootfs and make root file system can be writen when using
liveCD to boot up.
Set UNION_FS variable depending on kenrel config, so that it can work with
kernel which doesn't
have unionfs feature.
Signed-off-by: Yang Shi yang@windriver.com
---
meta/recipes-core/initrdscripts/files/init-live.sh | 21 +--
.../initrdscripts/initramfs-live-boot_1.0.bb |9 +++-
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh
b/meta/recipes-core/initrdscripts/files/init-live.sh
index eb5ab5b..abaf16c 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -7,6 +7,7 @@ ROOT_IMAGE=rootfs.img
MOUNT=/bin/mount
UMOUNT=/bin/umount
ISOLINUX=
+UNIONFS=no
early_setup() {
mkdir /proc
@@ -89,10 +90,24 @@ case $label in
mkdir $ROOT_MOUNT
mknod /dev/loop0 b 7 0 2/dev/null
- if ! $MOUNT -o rw,loop,noatime,nodiratime
/media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then
- fatal Couldnt mount rootfs image
+
+ if [ $UNIONFS = yes ]; then
+ mkdir /rootfs-tmp
+
+ if ! $MOUNT -o rw,loop,noatime,nodiratime
/media/$i/$ISOLINUX/$ROOT_IMAGE /rootfs-tmp ; then
+ fatal Couldnt mount rootfs image
+ else
+ mkdir /cow
+ mount -t tmpfs -o rw,noatime,mode=755 tmpfs /cow
+ mount -t unionfs -o dirs=/cow:/rootfs-tmp=ro unionfs $ROOT_MOUNT
+ boot_live_root
+ fi
else
- boot_live_root
+ if ! $MOUNT -o rw,loop,noatime,nodiratime
/media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then
+ fatal Couldnt mount rootfs image
+ else
+ boot_live_root
+ fi
fi
;;
install)
diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
index e85a0e1..f7f0c9d 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
@@ -2,10 +2,17 @@ DESCRIPTION = A live image init script
LICENSE = MIT
LIC_FILES_CHKSUM =
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420
RDEPENDS = udev
+DEPENDS = virtual/kernel
SRC_URI = file://init-live.sh
-PR = r7
+PR = r8
+do_compile() {
+ if grep -q CONFIG_UNION_FS=y ${STAGING_KERNEL_DIR}/.config; then
+ sed -i 's/UNIONFS=no/UNIONFS=yes/g' ${WORKDIR}/init-live.sh
+ fi
+}
+
do_install() {
install -m 0755 ${WORKDIR}/init-live.sh ${D}/init
}
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] sato: Remove questioned ISO image
[YOCTO #1487]
For the liveCD image, interactive bootup is needed, but psplash prevents from
booting interactively. In such case ISO image is not usable, so remove ISO image
and the corresponding link and throw error info to warn outside to enable
unionfs in kenrel.
Signed-off-by: Yang Shi yang@windriver.com
---
meta/recipes-sato/images/core-image-sato.bb | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-sato/images/core-image-sato.bb
b/meta/recipes-sato/images/core-image-sato.bb
index 11c3318..10e2239 100644
--- a/meta/recipes-sato/images/core-image-sato.bb
+++ b/meta/recipes-sato/images/core-image-sato.bb
@@ -9,3 +9,19 @@ IMAGE_FEATURES += apps-console-core ${SATO_IMAGE_FEATURES}
LICENSE = MIT
inherit core-image
+
+LIVE = ${@base_contains('IMAGE_FSTYPES', 'live', 'yes', 'no', d)}
+
+do_check_unionfs() {
+if [ ${NOISO} = 1 ]; then
+return
+fi
+
+if [ ${LIVE} = yes ] ! grep -q CONFIG_UNION_FS=y
${STAGING_KERNEL_DIR}/.config; then
+rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
+rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+bbfatal Building LIVE CD without UNION FS enabled in kernel
+fi
+}
+
+addtask check_unionfs before do_build after do_bootimg
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2] Fix init-live.sh to use unionfs for live CD and remove questioned ISO image
Use unionfs to mount rootfs and make root file system can be writen when using liveCD to boot up. Set UNION_FS variable depending on kenrel config, so that it can work with kernel which doesn't have unionfs feature. Without UNION FS enabled in kernel, minimal liveCD image can be bootup to ignore the failure of mouting read-only filesystem. For the sato liveCD image, interactive bootup is needed, but psplash prevents from booting interactively. In such case ISO image is not usable, so remove ISO image and the corresponding link and throw error info to warn outside to enable unionfs in kenrel. We tried a lot of different ways to achieve this: 1. Check if ISO image is built in initramfs-live-boot.bb or not, then prevent from generating ISO image. But, we can't distinguish minimal image or sato image. 2. Check if x11 feature is included in initramfs-live-boot.bb or not, then prevent from generating ISO image. But, x11 feature is contained in minimal image as well even though the package is not built. 3. Tried to append some check code in build_iso() in core-image-sato.bb, but poky can't support append code in build_xxx functions like what we do for do_xxx funcitons. So, we came up with current solution. Any new suggestion is appreciated. One more thing is that if IMAGE_FSTYPE += live is not set in conf/local.conf with this fix, we will get below error when building sato image: ERROR: Running idle function Traceback (most recent call last): File /home/yshi/yocto/poky/bitbake/lib/bb/server/process.py, line 122, in ProcessServer.idle_commands(delay=0.1): try: retval = function(self, data, False) if retval is False: File /home/yshi/yocto/poky/bitbake/lib/bb/cooker.py, line 1130, in buildTargetsIdle(server=ProcessServer(ProcessServer-1, started), rq=bb.runqueue.RunQueue instance at 0x74e4638, abort=False): try: retval = rq.execute_runqueue() except runqueue.TaskFailure as exc: File /home/yshi/yocto/poky/bitbake/lib/bb/runqueue.py, line 947, in RunQueue.execute_runqueue(): self.rqexe = RunQueueExecuteDummy(self) if self.rqdata.prepare() == 0: self.state = runQueueComplete File /home/yshi/yocto/poky/bitbake/lib/bb/runqueue.py, line 719, in RunQueueData.prepare(): procdep.append(self.taskData.fn_index[self.runq_fnid[dep]] + . + self.runq_task[dep]) self.runq_hash[task] = bb.parse.siggen.get_taskhash(self.taskData.fn_index[self.runq_fnid[task]], self.runq_task[task], procdep, self.dataCache) File /home/yshi/yocto/poky/bitbake/lib/bb/siggen.py, line 153, in SignatureGeneratorOEBasicHash.get_taskhash(fn='/home/yshi/yocto/poky/meta/recipes-sato/images/core-image-sato.bb', task='do_bootimg', deps=[], dataCache=bb.cache.CacheData object at 0x2148490): k = fn + . + task data = dataCache.basetaskhash[k] self.runtaskdeps[k] = [] KeyError: '/home/yshi/yocto/poky/meta/recipes-sato/images/core-image-sato.bb.do_bootimg' NOTE: Preparing runqueue Bruce pointed out there was a large discussion about this on hte list last week, so this should be a known issue in poky. The following changes since commit f81b0593e74a31cb2d992df0583948ff57e3ed98: gdbm: Activate -enable-libgdbm-compat and add symlinks to headers in include/gdbm (2012-03-23 17:56:29 +0200) are available in the git repository at: git://git.yoctoproject.org/poky-contrib yshi/1487 http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=yshi/1487 Yang Shi (2): initrdscripts: fix init-live.sh and use unionfs sato: Remove questioned ISO image meta/recipes-core/initrdscripts/files/init-live.sh | 21 +-- .../initrdscripts/initramfs-live-boot_1.0.bb |9 +++- meta/recipes-sato/images/core-image-sato.bb| 16 +++ 3 files changed, 42 insertions(+), 4 deletions(-) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Mon, 2012-03-26 at 12:18 -0500, Peter Seebach wrote: On Mon, 26 Mar 2012 17:47:29 +0100 Richard Purdie richard.pur...@linuxfoundation.org wrote: This is pretty much what we do at the moment, it gets unset after we load. Pseudo is of course disabled at this point. I guess we just got lucky to this point and avoided Bad Things? I suspect so. What's weird to me is that PSEUDO_PREFIX wasn't in the environment before, either. So I still don't quite get this. I am still missing something which will make this all make sense. ... at this point, I am leaning towards viewing this as a bug where it is not enough to simply correct the behavior, I will not feel confident in it until I have understood how it could have happened, but worked in many other cases. This is why I'm not saying lets just set PSEUDO_PREFIX. Its bothering me too. What puzzles me is we get this value from envbackup[key] = os.environ.get(PSEUDO_PREFIX) so its already not in the environment. So basically if we read PSEUDO_PREFIX from the environment we get nothing. If we unset the value back to being nothing, things break. Yes. This is, of course, obviously impossible. Obviously :). Except the code does this and I've watched it happen. I'm not claiming to understand it... Hmm. Well, hmm. When we start up, we should pick up PSEUDO_PREFIX from our environment, and during some of the initial client setup, we should be stashing that value in our stashed values table. At this point, so far as I can tell, nothing should ever unset that stashed value. On fork(), we don't change anything until we're in the client side of the fork, but that setup should happen in the same address space, with the values still stashed. When we poke new values into the environment, will it corrupt the internal stash? Oh, nevermind, I just realized: We use antimagic as the implementation goo for PSEUDO_DISABLED. So a call to os.popen() from a program which has PSEUDO_DISABLED set is going to think it's in antimagic mode. And suddenly, the trick is revealed: os.popen() is bypassing all the runqueue stuff which is trying to ensure that the environment is in a valid state. So if bitbake code calls os.popen(), it may behave weirdly, for the same reason that any other direct invocation of fork() or system() or whatnot would behave weirdly -- because bitbake is running with pseudo in a strange state. I'd be very surprised if we don't make some other system() call somewhere in bitbake's parent context. If this were a trigger, it could go a long way to explaining some errors people have reported though. So I think the thing is: Because bitbake is running with PSEUDO_DISABLED, any child process that is not explicitly set to either enable or unload pseudo is going to be running under pseudo, with PSEUDO_DISABLED. And that means we need to ensure that PSEUDO_PREFIX stays set, because we need that even when pseudo is disabled. (It's used during some of the initial setup sanity checks.) This is the answer I was expecting we'd come to. I'm still a little surprised we don't make any system() calls though. I just tried putting a os.system(true) call into the breakit class and it doesn't trigger the warnings. Could that be down to the lack of a popen wrapper? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 00/14][meta-intel] Cover letter for updating meta-cedartrail BSP with PVR Graphics driver
From: Rahul Saxena rahul.sax...@intel.com Cover letter for updating the Cedar Trail BSP (meta-cedartrail) with PVR Graphics driver. This patch set updates meta-cedartrail (edison branch) to include Power VR driver for Graphics and Video hardware acceleration. The patches enable BSP build with PVR driver or VESA driver depending upon MACHINE setting in local.conf. In addition the patches add web-webkit, audio and video samples to sato image. The Cedar Trail platform is based on the Cedarview processor (Intel® Atom™ N2600, N2800 and D2700 processor)and Tiger Point Chipset (Intel® NM10 Expres Signed-off-by: Rahul Saxena rahul.sax...@.intel.com -- The following changes since commit 31eaee8e24d570207338ada64f2df36cdbd5353d: meta-intel: update SRCREVs (2012-02-22 11:58:38 -0600) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib rsaxena-cedartrailpvrrelease26March http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=rsaxena-cedartrailpvrrelease26March Rahul Saxena (14): meta-cedartrail: Separate conf files for the Cedar Trail BSP boot cases of with and without pvr driver meta-cedartrail: update BBFILES to include meta-intel/common path meta-cedartrail: update README with instructions for PVR Graphics driver build meta-cedatrail: add recipe for setting audio mixer settings during boot meta-cedartrail: seperate xorg.conf files for pvr and no-pvr cases meta-cedartrail: add Cedar Trail PVR driver meta-cedartrail: update Kernel recipes to add support for pvr driver meta-cedartrail: add libva recipe meta-cedartrail: add recipes to instal audio and video samples meta-cedartrail: update formfactor recipe for pvr and no-pvr case meta-cedartrail: Add web-webkit, audio and video samples to sato image meta-cedartrail: Update SRC_URI in kernel recipe append files to point to linux-yocto_3.0 meta-cedartrail: update SRC_REV_meta for no-pvr case meta-cedartrail: change libva license to MIT meta-cedartrail/README | 50 +++- meta-cedartrail/conf/layer.conf|4 +- meta-cedartrail/conf/machine/cedartrail-nopvr.conf | 41 + meta-cedartrail/conf/machine/cedartrail.conf | 15 +++- .../cedartrail-audio/cedartrail-audio.bb | 30 +++ .../cedartrail-audio/cedartrail-audio | 42 + .../formfactor/cedartrail-nopvr/machconfig |3 + .../xorg-driver/cdv-graphics-drivers_1.0.bb| 89 .../xserver-xf86-config/cedartrail-nopvr/xorg.conf | 26 ++ .../xserver-xf86-config/cedartrail/xorg.conf | 24 ++ .../linux/linux-yocto-rt_3.0.bbappend | 16 - .../recipes-kernel/linux/linux-yocto_3.0.bbappend | 17 +++- .../ogg-CC-BY-3.0-music-samples_0.1.bb | 20 + .../video-samples/bigbuckbunny-ogg.bb | 20 + meta-cedartrail/recipes-multimedia/libva/libva.inc | 59 + .../recipes-multimedia/libva/libva_1.0.15.bb | 31 +++ .../images/core-image-sato-dev.bbappend|3 + .../images/core-image-sato-sdk.bbappend|3 + .../recipes-sato/images/core-image-sato.bbappend |3 + 19 files changed, 468 insertions(+), 28 deletions(-) create mode 100644 meta-cedartrail/conf/machine/cedartrail-nopvr.conf create mode 100644 meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio.bb create mode 100644 meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio/cedartrail-audio create mode 100644 meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail-nopvr/machconfig mode change 100755 = 100644 meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail/machconfig create mode 100644 meta-cedartrail/recipes-graphics/xorg-driver/cdv-graphics-drivers_1.0.bb create mode 100644 meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail-nopvr/xorg.conf mode change 100755 = 100644 meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf create mode 100644 meta-cedartrail/recipes-mediasamples/music-samples/ogg-CC-BY-3.0-music-samples_0.1.bb create mode 100644 meta-cedartrail/recipes-mediasamples/video-samples/bigbuckbunny-ogg.bb create mode 100644 meta-cedartrail/recipes-multimedia/libva/libva.inc create mode 100644 meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato-dev.bbappend create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato-sdk.bbappend create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato.bbappend -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 01/14] meta-cedartrail: Separate conf files for the Cedar Trail BSP boot cases of with and without pvr driver
From: Rahul Saxena rahul.sax...@intel.com Seperate Cedar Trail machine configuration files, one file each for build with pvr graphics driver and without pvr driver (with VESA driver) The Cedar Trail platform is based on the Cedarview processor (Intel® Atom™ N2600, N2800 and D2700 processor)and Tiger Point Chipset (Intel® NM10 Express). Signed-off-by: Rahul Saxena rahul.sax...@.intel.com --- meta-cedartrail/conf/machine/cedartrail-nopvr.conf | 41 meta-cedartrail/conf/machine/cedartrail.conf | 15 +-- 2 files changed, 52 insertions(+), 4 deletions(-) create mode 100644 meta-cedartrail/conf/machine/cedartrail-nopvr.conf diff --git a/meta-cedartrail/conf/machine/cedartrail-nopvr.conf b/meta-cedartrail/conf/machine/cedartrail-nopvr.conf new file mode 100644 index 000..b664272 --- /dev/null +++ b/meta-cedartrail/conf/machine/cedartrail-nopvr.conf @@ -0,0 +1,41 @@ +#@TYPE: Machine +#@NAME: Cedartrail-nopvr + +#@DESCRIPTION: Machine configuration for Cedartrail systems +# i.e. Cedarview (N2600, N2800 and D2700) processor + +# Tiger Point (Intel® NM10 Express) Chipset + +include conf/machine/include/tune-atom.inc + +MACHINE_FEATURES = kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ +acpi serial usbgadget alsa + +KERNEL_IMAGETYPE = bzImage + +PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto +PREFERRED_VERSION_linux-yocto ?= 3.0% + +PREFERRED_PROVIDER_linux-libc-headers ?= linux-libc-headers-yocto +PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim +PREFERRED_PROVIDER_virtual/libgl ?= mesa-dri +PREFERRED_PROVIDER_virtual/xserver ?= xserver-xf86-dri-lite +PREFERRED_PROVIDER_virtual/xserver-xf86 ?= xserver-xf86-dri-lite +XSERVER ?= xserver-xf86-dri-lite \ + xf86-input-mouse \ + xf86-input-keyboard \ + xf86-input-evdev \ + xf86-input-synaptics \ + xf86-video-vesa + +SYSLINUX_OPTS = serial 3 115200 +SERIAL_CONSOLE = 115200 ttyS3 +APPEND += console=ttyS3,115200 console=tty3 + +MACHINE_EXTRA_RRECOMMENDS = kernel-modules eee-acpi-scripts cedartrail-audio + +IMAGE_FSTYPES ?= ext3 cpio.gz live + +GLIBC_ADDONS = nptl +GLIBC_EXTRA_OECONF = --with-tls + +MACHINE_ESSENTIAL_EXTRA_RDEPENDS = grub diff --git a/meta-cedartrail/conf/machine/cedartrail.conf b/meta-cedartrail/conf/machine/cedartrail.conf index 23ee0a7..21adb46 100755 --- a/meta-cedartrail/conf/machine/cedartrail.conf +++ b/meta-cedartrail/conf/machine/cedartrail.conf @@ -2,17 +2,19 @@ #@NAME: Cedartrail #@DESCRIPTION: Machine configuration for Cedartrail systems -# i.e. Cedarview processor + Tiger Point Chipset +# i.e. Cedarview (N2600, N2800 and D2700) processor + +# Tiger Point (Intel® NM10 Express) Chipset include conf/machine/include/tune-atom.inc MACHINE_FEATURES = kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ -acpi serial usbgadget + acpi serial usbgadget alsa KERNEL_IMAGETYPE = bzImage PREFERRED_PROVIDER_virtual/kernel ?= linux-yocto PREFERRED_VERSION_linux-yocto ?= 3.0% +PREFERRED_VERSION_mesa-dri ?= 7.10.2 PREFERRED_PROVIDER_linux-libc-headers ?= linux-libc-headers-yocto PREFERRED_PROVIDER_virtual/libx11 ?= libx11-trim @@ -24,11 +26,16 @@ XSERVER ?= xserver-xf86-dri-lite \ xf86-input-keyboard \ xf86-input-evdev \ xf86-input-synaptics \ - xf86-video-vesa + mesa-dri \ + cdv-graphics-drivers +PREFERRED_VERSION_xserver-xf86-dri-lite ?= 1.9.3 + +SYSLINUX_OPTS = serial 3 115200 SERIAL_CONSOLE = 115200 ttyS3 +APPEND += console=ttyS3,115200 console=tty3 -MACHINE_EXTRA_RRECOMMENDS = kernel-modules eee-acpi-scripts +MACHINE_EXTRA_RRECOMMENDS = kernel-modules eee-acpi-scripts cedartrail-audio IMAGE_FSTYPES ?= ext3 cpio.gz live -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 02/14] meta-cedartrail: update BBFILES to include meta-intel/common path
From: Rahul Saxena rahul.sax...@intel.com
Update BBFILES to include the path to xserver-xf86-dri-lite_1.9.3.bb
Cedar Trail PVR driver is dependent on Version 1.9.3 of xserver.
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
meta-cedartrail/conf/layer.conf |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta-cedartrail/conf/layer.conf b/meta-cedartrail/conf/layer.conf
index cb4142d..c506c5b 100755
--- a/meta-cedartrail/conf/layer.conf
+++ b/meta-cedartrail/conf/layer.conf
@@ -3,7 +3,9 @@ BBPATH := ${BBPATH}:${LAYERDIR}
# We have a recipes directory, add to BBFILES
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
- ${LAYERDIR}/recipes-*/*/*.bbappend
+ ${LAYERDIR}/recipes-*/*/*.bbappend \
+${LAYERDIR}/../common/recipes-graphics/*/*.bb \
+${LAYERDIR}/../common/recipes-graphics/*/*.bbappend
BBFILE_COLLECTIONS += cedartrail
BBFILE_PATTERN_cedartrail := ^${LAYERDIR}/
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 03/14] meta-cedartrail: update README with instructions for PVR Graphics driver build
From: Rahul Saxena rahul.sax...@intel.com Update README file with information on building image with PVR graphics driver. Also provide info on enabling build of recipes for glxgears demo apps, video and music samples. Signed-off-by: Rahul Saxena rahul.sax...@.intel.com --- meta-cedartrail/README | 50 ++- 1 files changed, 48 insertions(+), 2 deletions(-) diff --git a/meta-cedartrail/README b/meta-cedartrail/README index 67cba6b..f17410c 100755 --- a/meta-cedartrail/README +++ b/meta-cedartrail/README @@ -2,13 +2,17 @@ This README file contains information on building the meta-cedartrail BSP layer, and booting the images contained in the /binary directory. Please see the corresponding sections below for details. +The 'Cedar Trail' platform consists of the Cedarview (Intel® Atom⢠+N2600, N2800 and D2700) processor, plus the Tiger Point +(Intel® NM10 Express) Chipset. + Table of Contents = I. Building the meta-cedartrail BSP layer II. Booting the images in /binary - +III. Miscellaneous Notes I. Building the meta-cedartrail BSP layer = @@ -24,10 +28,28 @@ bblayers.conf e.g.: yocto/meta-intel/meta-cedartrail \ -To enable the cedartrail layer, add the cedartrail MACHINE to local.conf: +The meta-cedartrail layer contains support for two different machine +configurations. These configurations are identical except for the fact +that the one prefixed with 'cedartrail' makes use of Intel' proprietary +PowerVR Graphics/Media drivers to enable Graphics and Media acceleration +in the processor, while the one prefixed with 'cedartrail-nonopvr' uses +non-accelerated graphics driver (VESA). + +If you want to enable the layer that supports Power VR graphics add the +following to the local.conf file: MACHINE ?= cedartrail +Power VR Graphics user-space driver binaries are covered by a +Intel Free Distribution Binary License. The build of this driver +can be enabled by adding the following line to the local.conf file: + PVR_LICENSE = yes + +If you want to enable the layer that does not support Power VR graphics +add the following to the local.conf file: + + MACHINE ?= cedartrail-nopvr + You should then be able to build a cedartrail image as such: $ source oe-init-build-env @@ -81,3 +103,27 @@ the syslinux boot: prompt, or the boot: prompt contains strange characters), try doing this first: # dd if=/dev/zero of=/dev/sdf bs=1M count=512 + +Miscellaneous Notes + + +Video and Music Samples +--- +This BSP includes recipes to download Ogg format video and +music files that can be played-back with the Video and music players +included in the sato images. The sample files are installed in +/home/Music and /home/Videos directories. + + +Adding Glxgears to image +- +Glxgears can be added to the generated image by adding debug-tweaks +option to the extra image features variable in the default local.conf +before building the BSP. + +e.g. to add Glxgears, locate the following line in local.conf +EXTRA_IMAGE_FEATURES = debug-tweaks + +and change above line to.. + +EXTRA_IMAGE_FEATURES = debug-tweaks tools-testapps -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 04/14] meta-cedatrail: add recipe for setting audio mixer settings during boot
From: Rahul Saxena rahul.sax...@intel.com
Recipe is copied from n450-audio.bb with a few parameters changed
to adjust volume settings for Front mixer during boot.
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
.../cedartrail-audio/cedartrail-audio.bb | 30 ++
.../cedartrail-audio/cedartrail-audio | 42
2 files changed, 72 insertions(+), 0 deletions(-)
create mode 100644
meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio.bb
create mode 100644
meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio/cedartrail-audio
diff --git a/meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio.bb
b/meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio.bb
new file mode 100644
index 000..9a43f02
--- /dev/null
+++ b/meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio.bb
@@ -0,0 +1,30 @@
+SUMMARY = Provide a basic init script to enable audio
+DESCRIPTION = Set the volume and unmute the Front mixer setting during boot.
+SECTION = base
+LICENSE = MIT
+LIC_FILES_CHKSUM =
file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58
+
+PR = r0
+
+inherit update-rc.d
+
+RDEPENDS = alsa-utils-amixer
+
+SRC_URI = file://cedartrail-audio
+
+INITSCRIPT_NAME = cedartrail-audio
+INITSCRIPT_PARAMS = defaults 90
+
+do_install() {
+ install -d ${D}${sysconfdir} \
+ ${D}${sysconfdir}/init.d
+ install -m 0755 ${WORKDIR}/cedartrail-audio ${D}${sysconfdir}/init.d
+cat ${WORKDIR}/${INITSCRIPT_NAME} | \
+sed -e 's,/etc,${sysconfdir},g' \
+-e 's,/usr/sbin,${sbindir},g' \
+-e 's,/var,${localstatedir},g' \
+-e 's,/usr/bin,${bindir},g' \
+-e 's,/usr,${prefix},g'
${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
+chmod 755 ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
+}
+
diff --git
a/meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio/cedartrail-audio
b/meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio/cedartrail-audio
new file mode 100644
index 000..efd08d3
--- /dev/null
+++
b/meta-cedartrail/recipes-bsp/cedartrail-audio/cedartrail-audio/cedartrail-audio
@@ -0,0 +1,42 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: cedartrail mixer setup
+# Required-Start:$syslog
+# Required-Stop: $syslog
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: Initialize the cedartrail audio mixer
+# Description: Unmute FRONT and set volume
+### END INIT INFO
+
+# Author: Darren Hart dvh...@linux.intel.com
+# Based on /etc/init.d/skeleton
+
+PATH=/sbin:/usr/sbin:/bin:/usr/bin
+DESC=Audio mixer settings
+NAME=cedartrail-audio
+AMIXER=`which amixer`
+SCRIPTNAME=/etc/init.d/$NAME
+
+# Exit if amixer is not installed
+[ -x $AMIXER ] || exit 0
+
+do_start() {
+ # Enable the Front simple controls (black phones jack)
+ $AMIXER sset Front 90 on /dev/null
+}
+
+case $1 in
+start)
+ echo $NAME: setting default mixer settings.
+ do_start
+ ;;
+stop)
+ ;;
+*)
+ echo Usage: $SCRIPTNAME {start|stop} 2
+ exit 3
+ ;;
+esac
+
+exit 0
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 05/14] meta-cedartrail: seperate xorg.conf files for pvr and no-pvr cases
From: Rahul Saxena rahul.sax...@intel.com Seperate xserver configuration files, one file each for the case of with pvr graphics driver and for no pvr (i.e. with VESA driver) Signed-off-by: Rahul Saxena rahul.sax...@.intel.com --- .../xserver-xf86-config/cedartrail-nopvr/xorg.conf | 26 .../xserver-xf86-config/cedartrail/xorg.conf | 24 ++ 2 files changed, 34 insertions(+), 16 deletions(-) create mode 100644 meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail-nopvr/xorg.conf mode change 100755 = 100644 meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf diff --git a/meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail-nopvr/xorg.conf b/meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail-nopvr/xorg.conf new file mode 100644 index 000..da4fc3c --- /dev/null +++ b/meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail-nopvr/xorg.conf @@ -0,0 +1,26 @@ +Section Device +Identifier Generic VESA +Driver vesa +EndSection + +Section Monitor +IdentifierGeneric Monitor +OptionDPMS +EndSection + +Section Screen +IdentifierDefault Screen +Device Generic VESA +Monitor Generic Monitor +DefaultDepth 24 +EndSection + +Section ServerLayout +Identifier Default Layout +Screen Default Screen +EndSection + +Section ServerFlags +OptionDontZap 0 +OptionAutoAddDevices False +EndSection diff --git a/meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf b/meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf old mode 100755 new mode 100644 index da4fc3c..1d085a4 --- a/meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf +++ b/meta-cedartrail/recipes-graphics/xorg-xserver/xserver-xf86-config/cedartrail/xorg.conf @@ -1,23 +1,15 @@ Section Device -Identifier Generic VESA -Driver vesa -EndSection - -Section Monitor -IdentifierGeneric Monitor -OptionDPMS -EndSection - -Section Screen -IdentifierDefault Screen -Device Generic VESA -Monitor Generic Monitor -DefaultDepth 24 +Option DRIDisableVSyncFalse +Identifier Card0 +Driver pvr +BusID PCI:0:2:0 +Option SoftEXA Off +Option FlipChain On EndSection Section ServerLayout -Identifier Default Layout -Screen Default Screen +Identifier default screen +Option AIGLX on EndSection Section ServerFlags -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 07/14] meta-cedartrail: update Kernel recipes to add support for pvr driver
From: Rahul Saxena rahul.sax...@intel.com
Modify kernel recipes to enable pvr kernel patches and to include
additional Kernel config files for pvr driver
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
.../linux/linux-yocto-rt_3.0.bbappend | 13 -
.../recipes-kernel/linux/linux-yocto_3.0.bbappend | 15 +++
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
b/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
index 3978951..828e6fd 100755
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
@@ -2,10 +2,21 @@ FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_cedartrail = cedartrail
KMACHINE_cedartrail = cedartrail
-# The Cedarview processors have hyperthreading and includes dual-core versions
+COMPATIBLE_MACHINE_cedartrail-nopvr = cedartrail
+KMACHINE_cedartrail-nopvr = cedartrail
+KERNEL_FEATURES_append_cedartrail-nopvr += cfg/smp.scc
+
+COMPATIBLE_MACHINE_cedartrail = cedartrail
+KMACHINE_cedartrail = cedartrail
KERNEL_FEATURES_append_cedartrail += cfg/smp.scc
+KERNEL_FEATURES_append_cedartrail += cfg/drm-cdvpvr.scc
+KERNEL_FEATURES_append_cedartrail += bsp/cedartrail/cedartrail-pvr-merge.scc
# Update the following to use a different BSP branch or meta SRCREV
+#KBRANCH_cedartrail-nopvr = yocto/standard/preempt-rt/base
+#SRCREV_machine_pn-linux-yocto-rt_cedartrail-nopvr ?=
+#SRCREV_meta_pn-linux-yocto-rt_cedartrail-nopvr ?=
+
#KBRANCH_cedartrail = yocto/standard/preempt-rt/base
#SRCREV_machine_pn-linux-yocto-rt_cedartrail ?=
#SRCREV_meta_pn-linux-yocto-rt_cedartrail ?=
diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 858db15..14c0b9d 100755
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -1,10 +1,17 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+COMPATIBLE_MACHINE_cedartrail-nopvr = cedartrail
+KMACHINE_cedartrail-nopvr = yocto/standard/cedartrail
+KERNEL_FEATURES_append_cedartrail-nopvr += cfg/smp.scc
+
COMPATIBLE_MACHINE_cedartrail = cedartrail
KMACHINE_cedartrail = yocto/standard/cedartrail
-
-# The Cedarview processors have hyperthreading and includes dual-core versions
KERNEL_FEATURES_append_cedartrail += cfg/smp.scc
+KERNEL_FEATURES_append_cedartrail += cfg/drm-cdvpvr.scc
+KERNEL_FEATURES_append_cedartrail += bsp/cedartrail/cedartrail-pvr-merge.scc
+
+SRCREV_machine_pn-linux-yocto_cedartrail ?=
5746120ee0afefd1e28400bea4b74f285bd5e59a
+SRCREV_meta_pn-linux-yocto_cedartrail ?=
a4ac64fe873f08ef718e2849b88914725dc99c1c
-SRCREV_machine_pn-linux-yocto_cedartrail ?=
f389d310965a56091f688b28ea8be6d9cbb7fbbe
-SRCREV_meta_pn-linux-yocto_cedartrail ?=
04a52a32cbdf0972033b97b83eaa83eb275dfdc9
+SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?=
5746120ee0afefd1e28400bea4b74f285bd5e59a
+SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?=
d588bdafc0d9b4d2386144b7d76a1d379e2d16c0
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 08/14] meta-cedartrail: add libva recipe
From: Rahul Saxena rahul.sax...@intel.com
The libva recipe is based on libva recipe published by Tom Zanussi
in meta-intel/common area in the 1.2_Mx branches. The main difference is
that this recipe sources the packages from the Cedar Trail section of
the MeeGo download website.
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
meta-cedartrail/recipes-multimedia/libva/libva.inc | 59
.../recipes-multimedia/libva/libva_1.0.15.bb | 31 ++
2 files changed, 90 insertions(+), 0 deletions(-)
create mode 100644 meta-cedartrail/recipes-multimedia/libva/libva.inc
create mode 100644 meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
diff --git a/meta-cedartrail/recipes-multimedia/libva/libva.inc
b/meta-cedartrail/recipes-multimedia/libva/libva.inc
new file mode 100644
index 000..2c1c75d
--- /dev/null
+++ b/meta-cedartrail/recipes-multimedia/libva/libva.inc
@@ -0,0 +1,59 @@
+SUMMARY = Video Acceleration (VA) API for Linux
+DESCRIPTION = Video Acceleration API (VA API) is a library (libVA) \
+and API specification which enables and provides access to graphics \
+hardware (GPU) acceleration for video processing on Linux and UNIX \
+based operating systems. Accelerated processing includes video \
+decoding, video encoding, subpicture blending and rendering. The \
+specification was originally designed by Intel for its GMA (Graphics \
+Media Accelerator) series of GPU hardware, the API is however not \
+limited to GPUs or Intel specific hardware, as other hardware and \
+manufacturers can also freely use this API for hardware accelerated \
+video decoding.
+
+HOMEPAGE = http://www.freedesktop.org/wiki/Software/vaapi;
+BUGTRACKER = https://bugs.freedesktop.org;
+
+SECTION = x11
+
+INC_PR = r1
+
+DEPENDS = libxext libxfixes libdrm mesa-dri
+
+inherit autotools pkgconfig
+
+PACKAGES =+ ${PN}-x11 ${PN}-tpi ${PN}-glx ${PN}-egl
+PROVIDES =+ ${PN}-x11 ${PN}-tpi ${PN}-glx ${PN}-egl
+PACKAGES =+ ${PN}-x11-dev ${PN}-tpi-dev ${PN}-glx-dev ${PN}-egl-dev
+PACKAGES =+ ${PN}-x11-dbg ${PN}-tpi-dbg ${PN}-glx-dbg ${PN}-egl-dbg
+RPROVIDES_${PN}-dev =+ ${PN}-x11-dev ${PN}-tpi-dev ${PN}-glx-dev
${PN}-egl-dev
+
+RDEPENDS_${PN}-tpi =+ ${PN}
+RDEPENDS_${PN}-x11 =+ ${PN}
+RDEPENDS_${PN}-glx =+ ${PN}-x11
+RDEPENDS_${PN}-egl =+ ${PN}-x11
+
+FILES_${PN}-dbg += ${libdir}/dri/.debug
+FILES_${PN} += ${libdir}/dri
+
+FILES_${PN}-x11 =+ ${libdir}/libva-x11*${SOLIBS}
+FILES_${PN}-tpi =+ ${libdir}/libva-tpi*${SOLIBS}
+FILES_${PN}-glx =+ ${libdir}/libva-glx*${SOLIBS}
+FILES_${PN}-egl =+ ${libdir}/libva-egl*${SOLIBS}
+
+FILES_${PN}-x11-dev =+ ${libdir}/libva-x11*${SOLIBSDEV}
+FILES_${PN}-tpi-dev =+ ${libdir}/libva-tpi*${SOLIBSDEV}
+FILES_${PN}-glx-dev =+ ${libdir}/libva-glx*${SOLIBSDEV}
+FILES_${PN}-egl-dev =+ ${libdir}/libva-egl*${SOLIBSDEV}
+FILES_${PN}-x11-dev =+ ${libdir}/libva-x11*.la
+FILES_${PN}-tpi-dev =+ ${libdir}/libva-tpi*.la
+FILES_${PN}-glx-dev =+ ${libdir}/libva-glx*.la
+FILES_${PN}-egl-dev =+ ${libdir}/libva-egl*.la
+FILES_${PN}-x11-dev =+ ${libdir}/pkgconfig/libva-x11*.pc
+FILES_${PN}-tpi-dev =+ ${libdir}/pkgconfig/libva-tpi*.pc
+FILES_${PN}-glx-dev =+ ${libdir}/pkgconfig/libva-glx*.pc
+FILES_${PN}-egl-dev =+ ${libdir}/pkgconfig/libva-egl*.pc
+
+FILES_${PN}-x11-dbg =+ ${libdir}/.debug/libva-x11.*
+FILES_${PN}-tpi-dbg =+ ${libdir}/.debug/libva-tpi.*
+FILES_${PN}-glx-dbg =+ ${libdir}/.debug/libva-glx.*
+FILES_${PN}-egl-dbg =+ ${libdir}/.debug/libva-egl.*
diff --git a/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
b/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
new file mode 100644
index 000..2800464
--- /dev/null
+++ b/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
@@ -0,0 +1,31 @@
+require libva.inc
+
+LICENSE = CC-BY-3.0
+LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/CC-BY-3.0;md5=dfa02b5755629022e267f10b9c0a2ab7
+
+PR = R0
+
+CDR_TRAIL = download.meego.com/live/MeeGo:/1.2.0:/CedarTrail:
+
+SRC_URI = \
+
http://${CDR_TRAIL}/oss/standard/i586/libva-1.0.15-1.1.i586.rpm;name=binary \
+
http://${CDR_TRAIL}/oss/standard/i586/libva-devel-1.0.15-1.1.i586.rpm;name=devel
\
+
+
+SRC_URI[binary.md5sum] = cb326945cec5ea4d1d369efc7a56e4f4
+SRC_URI[binary.sha256sum] =
e96f44647d5e9a4e2a7c769ed24d6bc142d928041300ea3e2e76e6af2d154926
+SRC_URI[devel.md5sum] = 799348cf8b6d239076d1b11844b94299
+SRC_URI[devel.sha256sum] =
f1ae4028d471790a1e7d601b69106824e4628e6db380e91eaaf08fa493e1a802
+
+do_install() {
+
+install -m 0644 ${WORKDIR}/libva-1.0.15-1.1.i586.rpm ${D}
+install -m 0644 ${WORKDIR}/libva-devel-1.0.15-1.1.i586.rpm ${D}
+
+cd ${D}
+
+rpm2cpio libva-1.0.15-1.1.i586.rpm | cpio -idmv
+rpm2cpio libva-devel-1.0.15-1.1.i586.rpm | cpio -idmv
+
+rm -f *.rpm
+}
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 09/14] meta-cedartrail: add recipes to instal audio and video samples
From: Rahul Saxena rahul.sax...@intel.com
Install Ogg format audio and video sample files
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
.../ogg-CC-BY-3.0-music-samples_0.1.bb | 20
.../video-samples/bigbuckbunny-ogg.bb | 20
2 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644
meta-cedartrail/recipes-mediasamples/music-samples/ogg-CC-BY-3.0-music-samples_0.1.bb
create mode 100644
meta-cedartrail/recipes-mediasamples/video-samples/bigbuckbunny-ogg.bb
diff --git
a/meta-cedartrail/recipes-mediasamples/music-samples/ogg-CC-BY-3.0-music-samples_0.1.bb
b/meta-cedartrail/recipes-mediasamples/music-samples/ogg-CC-BY-3.0-music-samples_0.1.bb
new file mode 100644
index 000..5da3e10
--- /dev/null
+++
b/meta-cedartrail/recipes-mediasamples/music-samples/ogg-CC-BY-3.0-music-samples_0.1.bb
@@ -0,0 +1,20 @@
+SUMMARY = ogg file format music samples
+DESCRIPTION = Installs ogg file format music samples in /home/Music dir
+
+LICENSE = CC-BY-3.0
+LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/CC-BY-3.0;md5=dfa02b5755629022e267f10b9c0a2ab7
+
+DEPENDS +=
+
+
+PR = r0
+SRC_URI =
http://downloads.yoctoproject.org/releases/media/music/ogg-CC-BY-3.0-music-samples-${PV}.tar.bz2
\
+
+
+do_install() {
+
+install -d ${D}${base_prefix}/home/music
+install -m 0644 ${WORKDIR}/ogg-CC-BY-3.0-music-samples-${PV}/*/*.ogg
${D}${base_prefix}/home/music
+}
+
+FILES_${PN} += ${base_prefix}/home/music/*.ogg
diff --git
a/meta-cedartrail/recipes-mediasamples/video-samples/bigbuckbunny-ogg.bb
b/meta-cedartrail/recipes-mediasamples/video-samples/bigbuckbunny-ogg.bb
new file mode 100644
index 000..2225af4
--- /dev/null
+++ b/meta-cedartrail/recipes-mediasamples/video-samples/bigbuckbunny-ogg.bb
@@ -0,0 +1,20 @@
+SUMMARY = Big Buck Bunny video OGG sample
+DESCRIPTION = Installs Big Buck Bunny Video OGG file samples in /home/video
dir
+
+LICENSE = CC-BY-3.0
+LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/CC-BY-3.0;md5=dfa02b5755629022e267f10b9c0a2ab7
+
+DEPENDS +=
+
+
+PR = r0
+SRC_URI =
http://blender-mirror.kino3d.org/peach/bigbuckbunny_movies/big_buck_bunny_720p_stereo.ogg
\
+
+
+do_install() {
+
+install -d ${D}${base_prefix}/home/Videos
+install -m 0644 ${WORKDIR}/*.ogg ${D}${base_prefix}/home/Videos
+}
+
+FILES_${PN} += ${base_prefix}/home/Videos/*.ogg
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 10/14] meta-cedartrail: update formfactor recipe for pvr and no-pvr case
From: Rahul Saxena rahul.sax...@intel.com Seperate machconfig files for pvr and no-pvr case Signed-off-by: Rahul Saxena rahul.sax...@.intel.com --- .../formfactor/cedartrail-nopvr/machconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) create mode 100644 meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail-nopvr/machconfig mode change 100755 = 100644 meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail/machconfig diff --git a/meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail-nopvr/machconfig b/meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail-nopvr/machconfig new file mode 100644 index 000..ffce012 --- /dev/null +++ b/meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail-nopvr/machconfig @@ -0,0 +1,3 @@ +# Assume a USB mouse and keyboard are connected +HAVE_TOUCHSCREEN=0 +HAVE_KEYBOARD=1 diff --git a/meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail/machconfig b/meta-cedartrail/recipes-bsp/formfactor/formfactor/cedartrail/machconfig old mode 100755 new mode 100644 -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 11/14] meta-cedartrail: Add web-webkit, audio and video samples to sato image
From: Rahul Saxena rahul.sax...@intel.com Update sato images to include web-webkit and audio video samples Signed-off-by: Rahul Saxena rahul.sax...@.intel.com --- .../images/core-image-sato-dev.bbappend|3 +++ .../images/core-image-sato-sdk.bbappend|3 +++ .../recipes-sato/images/core-image-sato.bbappend |3 +++ 3 files changed, 9 insertions(+), 0 deletions(-) create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato-dev.bbappend create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato-sdk.bbappend create mode 100644 meta-cedartrail/recipes-sato/images/core-image-sato.bbappend diff --git a/meta-cedartrail/recipes-sato/images/core-image-sato-dev.bbappend b/meta-cedartrail/recipes-sato/images/core-image-sato-dev.bbappend new file mode 100644 index 000..4022c58 --- /dev/null +++ b/meta-cedartrail/recipes-sato/images/core-image-sato-dev.bbappend @@ -0,0 +1,3 @@ +IMAGE_INSTALL += web-webkit +IMAGE_INSTALL += bigbuckbunny-ogg +IMAGE_INSTALL += ogg-CC-BY-3.0-music-samples diff --git a/meta-cedartrail/recipes-sato/images/core-image-sato-sdk.bbappend b/meta-cedartrail/recipes-sato/images/core-image-sato-sdk.bbappend new file mode 100644 index 000..4022c58 --- /dev/null +++ b/meta-cedartrail/recipes-sato/images/core-image-sato-sdk.bbappend @@ -0,0 +1,3 @@ +IMAGE_INSTALL += web-webkit +IMAGE_INSTALL += bigbuckbunny-ogg +IMAGE_INSTALL += ogg-CC-BY-3.0-music-samples diff --git a/meta-cedartrail/recipes-sato/images/core-image-sato.bbappend b/meta-cedartrail/recipes-sato/images/core-image-sato.bbappend new file mode 100644 index 000..4022c58 --- /dev/null +++ b/meta-cedartrail/recipes-sato/images/core-image-sato.bbappend @@ -0,0 +1,3 @@ +IMAGE_INSTALL += web-webkit +IMAGE_INSTALL += bigbuckbunny-ogg +IMAGE_INSTALL += ogg-CC-BY-3.0-music-samples -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 12/14] meta-cedartrail: Update SRC_URI in kernel recipe append files to point to linux-yocto_3.0
From: Rahul Saxena rahul.sax...@intel.com
Current poky/edison points to linux-yocto-3.0-1.1.x.git repo. However this repo
does not have
cedartrail branch. Hence point to linux-yocto_3.0 via kernel recipe append
files
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
.../linux/linux-yocto-rt_3.0.bbappend |3 +++
.../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 ++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
b/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
index 828e6fd..759c3b7 100755
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
@@ -1,4 +1,7 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.0.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
+
COMPATIBLE_MACHINE_cedartrail = cedartrail
KMACHINE_cedartrail = cedartrail
diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 14c0b9d..0a05d8b 100755
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -1,5 +1,7 @@
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+SRC_URI =
git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
+
COMPATIBLE_MACHINE_cedartrail-nopvr = cedartrail
KMACHINE_cedartrail-nopvr = yocto/standard/cedartrail
KERNEL_FEATURES_append_cedartrail-nopvr += cfg/smp.scc
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 13/14] meta-cedartrail: update SRC_REV_meta for no-pvr case
From: Rahul Saxena rahul.sax...@intel.com SRC_REV_meta for no-pvr case updated to be same as that used for pvr build Signed-off-by: Rahul Saxena rahul.sax...@.intel.com --- .../recipes-kernel/linux/linux-yocto_3.0.bbappend |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend index 0a05d8b..03c5a27 100755 --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend @@ -16,4 +16,4 @@ SRCREV_machine_pn-linux-yocto_cedartrail ?= 5746120ee0afefd1e28400bea4b74f285bd SRCREV_meta_pn-linux-yocto_cedartrail ?= a4ac64fe873f08ef718e2849b88914725dc99c1c SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 5746120ee0afefd1e28400bea4b74f285bd5e59a -SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= d588bdafc0d9b4d2386144b7d76a1d379e2d16c0 +SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= a4ac64fe873f08ef718e2849b88914725dc99c1c -- 1.7.4.1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 14/14] meta-cedartrail: change libva license to MIT
From: Rahul Saxena rahul.sax...@intel.com
The license type in libva recipe was incorrect. Changed it to MIT
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
.../recipes-multimedia/libva/libva_1.0.15.bb |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
b/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
index 2800464..3a4cb0c 100644
--- a/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
+++ b/meta-cedartrail/recipes-multimedia/libva/libva_1.0.15.bb
@@ -1,9 +1,9 @@
require libva.inc
-LICENSE = CC-BY-3.0
-LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/CC-BY-3.0;md5=dfa02b5755629022e267f10b9c0a2ab7
+LICENSE = MIT
+LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302
-PR = R0
+PR = R0
CDR_TRAIL = download.meego.com/live/MeeGo:/1.2.0:/CedarTrail:
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 06/14] meta-cedartrail: add Cedar Trail PVR driver
From: Rahul Saxena rahul.sax...@intel.com
The Cedar Trail PVR driver consists of user-space binaries that enable
the Video and Graphics acceleration capabilites of the Power VR SGX545
Integrated Graphics Controller in the Cedarview processor.
The driver binaries are provided under Intel Free Distribution Binary License
The instructions to enable the build of this driver are provided in the
meta-cedartrail/README file
Signed-off-by: Rahul Saxena rahul.sax...@.intel.com
---
.../xorg-driver/cdv-graphics-drivers_1.0.bb| 89
1 files changed, 89 insertions(+), 0 deletions(-)
create mode 100644
meta-cedartrail/recipes-graphics/xorg-driver/cdv-graphics-drivers_1.0.bb
diff --git
a/meta-cedartrail/recipes-graphics/xorg-driver/cdv-graphics-drivers_1.0.bb
b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-graphics-drivers_1.0.bb
new file mode 100644
index 000..249246b
--- /dev/null
+++ b/meta-cedartrail/recipes-graphics/xorg-driver/cdv-graphics-drivers_1.0.bb
@@ -0,0 +1,89 @@
+SUMMARY = Cedartrail PowerVR Graphics Driver version [Gold] 1.0 binaries
+DESCRIPTION = 2D, 3D and Media user space driver for Cedartrail platform \
+The binaries are covered by the Intel Free Distribution Binary License. \
+The user must make himself/herself aware of the Licensing terms \
+before enabling build of the Cedartrail PowerVR Graphics Driver via \
+this recipe. Please see the README in meta-cedartrail for instructions \
+for enabling the build of the driver
+
+
+PR = r0
+
+S = ${WORKDIR}/cdv-graphics-drivers_${PV}
+
+LICENSE = Intel Free Distribution Binary License
+LIC_FILES_CHKSUM = \
+
file://${S}/usr/share/doc/psb-video-cdv-0.12/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65
\
+
file://${S}/usr/share/doc/pvr-bin-cdv-1.7.788837_05/license.txt;md5=b14d99f8d4ed664e9ce95057f0bb5b65
+
+DEPENDS = libva
+
+CDR_TRAIL = download.meego.com/live/MeeGo:/1.2.0:/CedarTrail:
+
+SRC_URI = \
+
http://${CDR_TRAIL}/non-oss/MeeGo_1.2.0_CedarTrail/i586/psb-video-cdv-0.12-1.1.i586.rpm;name=psb
\
+
http://${CDR_TRAIL}/non-oss/MeeGo_1.2.0_CedarTrail/i586/pvr-bin-cdv-1.7.788837_05-1.1.i586.rpm;name=pvr
\
+
http://${CDR_TRAIL}/oss/standard/i586/libwsbm-cdv-1.1.0-3.1.i586.rpm;name=libwsbm
\
+
+SRC_URI[psb.md5sum] = d4b6b383722264f3b781aeb240c88037
+SRC_URI[psb.sha256sum] =
e88f95fc73a79adf76ee33d3d9874cec23bb1afe8149d7dc5842d67e58da72f5
+SRC_URI[pvr.md5sum] = 951fa9edcbc2a3ddb30450079869362e
+SRC_URI[pvr.sha256sum] =
537dd8a98ac2e3a101063abc62682c3be8c37ac29782a876eafce113ffa5b421
+SRC_URI[libwsbm.md5sum] = 8d90436b151ddf72f620771f2552b597
+SRC_URI[libwsbm.sha256sum] =
82f78f47c151f0e7d567574ee372504e5b395fb13796caa765f9c30754b5bf63
+
+do_configure () {
+
+# Extract license files from rpms
+rpm2cpio ${WORKDIR}/psb-video-cdv-0.12-1.1.i586.rpm |cpio -ivd
./usr/share/doc/psb-video-cdv-0.12/license.txt
+rpm2cpio ${WORKDIR}/pvr-bin-cdv-1.7.788837_05-1.1.i586.rpm |cpio -ivd
./usr/share/doc/pvr-bin-cdv-1.7.788837_05/license.txt
+
+}
+
+do_install() {
+
+install -m 0644 ${WORKDIR}/psb-video-cdv-0.12-1.1.i586.rpm ${D}
+install -m 0644 ${WORKDIR}/pvr-bin-cdv-1.7.788837_05-1.1.i586.rpm ${D}
+install -m 0644 ${WORKDIR}/libwsbm-cdv-1.1.0-3.1.i586.rpm ${D}
+
+cd ${D}
+
+rpm2cpio psb-video-cdv-0.12-1.1.i586.rpm | cpio -idmv
+rpm2cpio pvr-bin-cdv-1.7.788837_05-1.1.i586.rpm | cpio -idmv
+rpm2cpio libwsbm-cdv-1.1.0-3.1.i586.rpm | cpio -idmv
+
+install -m 0755 ${D}/${libdir}/libpvr2d.so.1.7.788837
${D}/${libdir}/libpvr2d.so
+install -m 0755 ${D}/${libdir}/libsrv_um.so.1.7.788837
${D}/${libdir}/libsrv_um.so
+install -m 0755 ${D}/${libdir}/libegl4ogl.so.1.7.788837
${D}/${libdir}/libegl4ogl.so
+install -m 0755 ${D}/${libdir}/libPVROGL_MESA.so.1.7.788837
${D}/${libdir}/libPVROGL_MESA.so
+install -m 0755 ${D}/${libdir}/libIMGegl.so.1.7.788837
${D}/${libdir}/libIMGegl.so
+install -m 0755 ${D}/${libdir}/libusc.so.1.7.788837 ${D}/${libdir}/libusc.so
+install -m 0755 ${D}/${libdir}/libOpenVG.so.1.7.788837
${D}/${libdir}/libOpenVG.so
+
+install -m 0644 ${S}/usr/share/doc/psb-video-cdv-0.12/license.txt
${WORKDIR}/license-destdir/cdv-graphics-drivers/license.txt
+
+rm -f *.rpm
+}
+
+FILES_${PN} += ${libdir}/pvr/cdv/lib*.so.*
+FILES_${PN} += ${base_libdir}/firmware
+FILES_${PN} += ${libdir}/debug/usr/bin
+FILES_${PN} += ${libdir}/debug/usr/lib
+FILES_${PN} += ${libdir}/lib*.so
+
+FILES_${PN} += ${libdir}/dri/*.so
+FILES_${PN} += ${libdir}/pvr/cdv/dri/*.so
+FILES_${PN} += ${libdir}/xorg/modules/drivers/*.so
+FILES_${PN} += ${libdir}/pvr/cdv/xorg/modules/drivers/*.so
+
+FILES_${PN}-dbg += ${libdir}/dri/.debug/*
+
+addtask check_pvr_license before do_fetch
+
+python do_check_pvr_license() {
+pn = bb.data.getVar('PN', d, 1)
+pvr_license = bb.data.getVar('PVR_LICENSE', d, 1)
+if not pvr_license or not pvr_license.lower() == yes:
+bb.debug(1, Skipping %s because it may have a non-free license % pn)
+raise bb.parse.SkipPackage(because it requires PVR_LICENSE = \yes\
Re: [yocto] can all of the licensing discussion be centralized in an appendix?
Scott, ** http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html . ** ** Yes, I looked at that one but I now noticed that I referenced it incorrectly. This is the latest version, however, in the revision history it shows Revision 1.1, October 6, 2011, Released with the Yocto Project Release 1.1. Now, this one http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html is the current one but its revision history shows Revision 1.1.1, March 15, 2012, Released with the Yocto Project Release 1.1.1. Ok, now I get how I confused myself successfully. I presume that the first is the newer one although its revision history suggests otherwise? Would you mind updating the revision history with something like Revision 1.2, WIP, To be released with Yocto Project Release 1.2? The latest one does not seem to have a section about writing recipes anymore at all. Are you planning on putting it back? While the previous one had a section on writing recipes it did so in a vacuum. It told you how to write a recipe but not really where to put it and how to include it with an image. The latter it explained in the next section about customizing an image. The info about the licensing is great and dead-nuts on, however, a reader new to the Yocto Project would be missing the context. A good add-on to that paragraph would be that if you omit the md5 parameter in the LIC_FILES_CHKSUM variable Bitbake will actually spit it out for you which is in particular useful if the checksum is calculated over a subset of a license file specified by startline and endline because md5sum won't easily do that for you. These are my suggestions: * Remove 3.3 x32 and 3.4 Licenses from section 3. Section 3 currently looks a little bit like a kitchen sink. The first two paragraphs deal with build system components and architecture, x32 then mixes a very specific technology into it for particular targets, and then Licenses tops it off with package licensing details. I would dedicate Section 3 to Yocto Project Build System Architecture only. * Then I would dedicate a section 4 to Build Customization: ** The first subsection could deal with the most trivial customization through local.conf: EXTRA_IMAGE_FEATURES, IMAGE_INSTALL_append and CORE_IMAGE_EXTRA_INSTALL (formerly known as POKY_EXTRA_INSTALL) ** The second subsection should then explain how to create your own layer within the build environment because before adding any recipe you need to have a layer to add it to. Mixing your own recipes in with meta or meta-yocto works but is not sustainable when upgrading to a newer release of the Yocto Project. And it's good practice too to keep your own stuff separate. ** The third subsection should then explain how to extend images writing your own recipes: *** writing a recipe that includes a base image and then adds more packages: require recipes-core/images/core-imabg-base.bb IMAGE_INSTALL += strace *** writing an image that inherits from core-image IMAGE_INSTALL = task-core-boot task-core-extended IMAGE_FEATURES += blabla inherit core-image ** the fourth subsection should then explain how to add your own packages with your own recipes. Now you already have everything in place: a layer to add to and a ways of including your recipes with an image. And here we then also need to explain the licensing stuff because recipes for building packages won't fly without. ** the fifth section should then just reference the BSP manual for BSPs. Finally for my concept, we need to find a home for x32. I would put that under an Advanced Topics section which could act as a container for other stuff too such as multi-lib etc. Rudi *From:* yocto-boun...@yoctoproject.org [mailto: yocto-boun...@yoctoproject.org] *On Behalf Of *Rudolf Streif *Sent:* Monday, March 26, 2012 2:52 PM *To:* yocto@yoctoproject.org *Subject:* Re: [yocto] can all of the licensing discussion be centralized in an appendix? ** ** there's *way* too much coverage of licensing sprinkled throughout. most people are not going to care about licensing until the time comes to maybe start distributing their BSP. The ability of collecting licensing information, tracking license changes and providing the license information automatically with the images and packages for deployment is in my opinion a major feature of Yocto albeit underestimated. Most people will only appreciate it once they have to deliver that information with a product for the end user. However, it starts much earlier, with the recipe. ** ** How to include licensing tracking information with your recipe needs to be part of the section explaining how to write recipes of the reference manual. In both, the current 1.1 and the upcoming 1.1.1, versions of the manual the license tracking section is a little disjoint from the sections explaining how to add packages/recipes in my opinion. The examples include the license tracking
Re: [yocto] can all of the licensing discussion be centralized in an appendix?
Rudi, Great comments! Thanks very much. I will immediately update the revision history tables to show the 1.2 release as WIP. Not having it there did cause you confusion. Good suggestion. Regarding your other observations. If you have the time I would appreciate you looking at the YP Development manual, particularly Chapter 4. Much of the how-to stuff that was in the YP reference manual has been moved to there. Adding a Package section that you noted was now missing is in fact in that area. Let me give you some background on the strategy of the two manuals I am trying to eventually turn the YP reference guide into a reference guide with minimal how-to information. That is the long-term goal. The YP Development Manual has been getting some how-to stuff added to it. Chapter 4 (Common Tasks) tells how to create layers, add a package, customize images, etc.). Here is the link to the latest YP Development Manual: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html. With this new context, maybe you can augment or comment on your previous comments :) I appreciate your help, Scott From: rstr...@linuxfoundation.org [mailto:rstr...@linuxfoundation.org] On Behalf Of Rudolf Streif Sent: Monday, March 26, 2012 4:02 PM To: Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: Re: [yocto] can all of the licensing discussion be centralized in an appendix? Scott, http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html. Yes, I looked at that one but I now noticed that I referenced it incorrectly. This is the latest version, however, in the revision history it shows Revision 1.1, October 6, 2011, Released with the Yocto Project Release 1.1. Now, this one http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html is the current one but its revision history shows Revision 1.1.1, March 15, 2012, Released with the Yocto Project Release 1.1.1. Ok, now I get how I confused myself successfully. I presume that the first is the newer one although its revision history suggests otherwise? Would you mind updating the revision history with something like Revision 1.2, WIP, To be released with Yocto Project Release 1.2? The latest one does not seem to have a section about writing recipes anymore at all. Are you planning on putting it back? While the previous one had a section on writing recipes it did so in a vacuum. It told you how to write a recipe but not really where to put it and how to include it with an image. The latter it explained in the next section about customizing an image. The info about the licensing is great and dead-nuts on, however, a reader new to the Yocto Project would be missing the context. A good add-on to that paragraph would be that if you omit the md5 parameter in the LIC_FILES_CHKSUM variable Bitbake will actually spit it out for you which is in particular useful if the checksum is calculated over a subset of a license file specified by startline and endline because md5sum won't easily do that for you. These are my suggestions: * Remove 3.3 x32 and 3.4 Licenses from section 3. Section 3 currently looks a little bit like a kitchen sink. The first two paragraphs deal with build system components and architecture, x32 then mixes a very specific technology into it for particular targets, and then Licenses tops it off with package licensing details. I would dedicate Section 3 to Yocto Project Build System Architecture only. * Then I would dedicate a section 4 to Build Customization: ** The first subsection could deal with the most trivial customization through local.conf: EXTRA_IMAGE_FEATURES, IMAGE_INSTALL_append and CORE_IMAGE_EXTRA_INSTALL (formerly known as POKY_EXTRA_INSTALL) ** The second subsection should then explain how to create your own layer within the build environment because before adding any recipe you need to have a layer to add it to. Mixing your own recipes in with meta or meta-yocto works but is not sustainable when upgrading to a newer release of the Yocto Project. And it's good practice too to keep your own stuff separate. ** The third subsection should then explain how to extend images writing your own recipes: *** writing a recipe that includes a base image and then adds more packages: require recipes-core/images/core-imabg-base.bbhttp://core-imabg-base.bb IMAGE_INSTALL += strace *** writing an image that inherits from core-image IMAGE_INSTALL = task-core-boot task-core-extended IMAGE_FEATURES += blabla inherit core-image ** the fourth subsection should then explain how to add your own packages with your own recipes. Now you already have everything in place: a layer to add to and a ways of including your recipes with an image. And here we then also need to explain the licensing stuff because recipes for building packages won't fly without. ** the fifth section should then just reference the BSP manual for BSPs. Finally for my
Re: [yocto] tentative list of vars to be dropped from variable glossary
On Mon, 2012-03-26 at 12:42 -0700, Rudolf Streif wrote: Another variable that seems to be dropped from the latest 1.1.1 revision of the Reference Manual is BBMASK. In previous versions of the manual it was explained that this variable can be used to remove packages from images. However, that did not work for me and it did not surprise me either. BBMASK removes recipes from being parsed. It does not remove them from images although that would I guess be an indirect result since you could no longer build them. To include a package with an image you will have to make it a dependency of that image. If you then hide the recipe of the package using BBMASK then you are breaking the dependency and the Bitbake will complain with Nothing provides package because the dependency is still there. I could not think of any other use case for BBMASK in the way it is implemented. Are there any? Its designed so that if you for example didn't care out any *gpe* recipe, you could exclude them entirely and not even have the parse overhead. Its less useful now things are split into layers but nonetheless still valid syntax. Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tentative list of vars to be dropped from variable glossary
Thanks, Richard. Clearer now but not entirely. BBMASK removes recipes from being parsed. It does not remove them from images although that would I guess be an indirect result since you could no longer build them. Yes, it removes it from being parsed. I used, for test although not sensible, BBMASK = base-passwd. If I then tried building core-image-minimal it fails with Nothing provides base-passwd. If one could use BBMASK to customize images as suggested in http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage-localconf then one would expect the package to be removed indirectly from the image. However, that does not happen, the build just fails. Its designed so that if you for example didn't care out any *gpe* recipe, you could exclude them entirely and not even have the parse overhead. That use case makes sense. If I know that I don't include certain packages like *gpe* in the images I am building then I can speed up the build/parsing process by masking the recipes and therefore the regular expression syntax makes perfectly sense. Thanks, Rudi ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] who are using archlinux?
who are using archlinux? I want to talk about gconf compile fail problem. -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Mon, 26 Mar 2012 22:45:16 +0100
Richard Purdie richard.pur...@linuxfoundation.org wrote:
I'm still a little surprised we don't make any system() calls though.
I just tried putting a os.system(true) call into the breakit
class and it doesn't trigger the warnings. Could that be down to the
lack of a popen wrapper?
I think that part could be, but this doesn't explain why adding the
popen() wrapper doesn't fix it. Oh, wait. Yes, it does. I think I am
now happy with this, although I have a loose end or two.
So, here's what I've figured out.
We start bitbake with PSEUDO_PREFIX set. This then gets stored in the
internal stash. Thus, on any call we catch, we should be restoring it.
We then unset it, because it's not part of the whitelisted environment.
Now, what this means is that when we spawn child processes, they should
be getting the environment, but the parent bitbake is running with
PSEUDO_DISABLED. Which, in turn, sets antimagic. So most calls run
through their non-wrapped form.
The problem: I wrote my popen() wrapper wrong. See, I carefully
removed the check for pseudo_disabled from the top of it. But! That
code path is not actually the only way in which pseudo_disabled affects
behavior. That's just an *OPTIMIZATION*. The pseudo_disabled flag
also means that antimagic is set, and I copied that part of the wrapper
in unmodified:
if (antimagic 0) {
/* call the real syscall */
rc = (*real_popen)(command, mode);
} else {
/* exec*() use this to restore the sig mask */
pseudo_saved_sigmask = saved;
rc = wrap_popen(command, mode);
}
And antimagic is 1, so I call real popen. Which forks. And even
though pseudo isn't in the LD_PRELOAD environment variable, it's still
in the process's address space, but PSEUDO_PREFIX isn't set, and for
some reason, the stashed value is missing. Not sure I can explain that
part yet; maybe we do have a path where we wipe the stashed value.
But the underlying problem is that my popen() wrapper was never
actually doing the setupenv/dropenv, or just a setupenv.
And the other underlying problem is that calling os.popen() directly is
probably something we should discourage, because we really do want to
know, for each subprocess we plan to spawn, whether it is running in
the pseudo environment or not. So if you call os.popen(), you get
whatever state bitbake is in, which may not be at all what you wanted
or intended.
If I fix the popen() patch, it may actually start working again,
although I'm still not totally sure why the prefix is getting wiped out.
So... I think...
1. We should probably whitelist PSEUDO_PREFIX because life is a heck
of a lot easier if we aren't trying to set it and unset it all the time.
2. I need to fix my popen patch.
3. Once I've fixed that, I can probably do a much better job of
articulating what's happening to pseudo_prefix that's causing us to end
up with a child process where both the internal stash and the
environment variable are unset.
The big thing I was missing was that PSEUDO_DISABLED implies that
everything will always have antimagic = 1.
-s
--
Listen, get this. Nobody with a good compiler needs to be justified.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
