Same comment here... Otherwise, all looks very nice. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel

This begs the questions where other distributions (and OSVs) fit into yocto. regards, Koen

hah, I stand corrected :-) -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel

This does not appear to handle something like: BBLAYERS = " \ /path/to/layer1 \ /path/to/layer2" Need to strip the " from the end of the last line. Also doesn't handle: BBLAYERS +=

Agreed - this first pass as far as the input I/O was mainly to enable the ADT developers to start integrating now, and I believe they're starting out using the command-line versions. This can easily

same comments here... This looks like a healthy list of dependencies. Do we need to augment the required packages list? Oh, I didn't know about that. My ABCs have been rather amateur by comparison.

i do understand the distinction and i will admit, i'm sometimes sloppy with my terminology. as someone who is constantly berating others for their lack of precision, i should know better.

Hey all - from the project perspective, the Yocto Project includes Poky, so I think it's very appropriate for Robert to think that using YP implies using Poky. This is in all of the project's official

Responded privately to Tom on this one... -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel

WOW! I suppose this is the initial patch, so a files are going in whole - but WOW! Are all of these created by hand? I'm thinking about supporting this going forward, will we have to create 10+ new

This -i approach is adequate for an initial pass. However, a python module API would be preferable. However, if the ADT integration is written in java.... perhaps -i is the best way as I'm not sure if

Hi Zhenhua, Can you be more specific about what you are looking for? When you build an image with the cpio.gz image type, you can boot that as an initramfs with the following kernel command

just for fun, i addressed the only thing that was stopping me, and that was that runqemu was looking for a slightly different sysroots directory name than the toolchain provided,

i briefly saw your point until i noticed that the yocto toolchain i installed comes with qemu-system-* executables, which would take precedence over the normal host ones, so i'm still skeptical.

I see what you're saying, but the problem with this is the qemu version we build is not the same as qemu that might be installed on the host machine. We apply quite a number of patches to qemu in

i gathered that. but is it unreasonable to suggest that this is something that *should* be easy to do? if new users simply want to see what a yocto-generated image looks like under qemu,

Only that we assume you *have* built the image in order to be able to use the runqemu script. If you haven't, well, you won't necessarily have some of the utilities the script looks for (e.g.

i want to do a short writeup on the *simplest* recipe for how to run the pre-built yocto qemu image you can get here: http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu/ and

Well, if you use the angstrom setupscript you get 'yocto'. Your phrasing seems to suggest you are confusing 'yocto' with 'poky', which is a common mistake.

Hello all, Does Yocto support initramfs build? Best Regards, Zhenhua