Correct. Yocto isn't really for porting the tools to a platform, but rather something to help you build [embedded] systems to run on the platform. n.b. it's polite to keep such discussions on the

Yocto Technical Team, Here is the agenda for our weekly meeting on Tuesday, May 17th at 8am Pacific. Thanks. - Julie Dial in: 916-356-2663, Bridge: 94, Passcode: 2750569 Agenda: 1) Review Yocto 1.1

Hi, The BSP guide uses some meta-intel layers as examples, but just as examples - we don't really want to put pointers to specific layers in there. (Are those the meta-xxx directories you're talking

When I clone the yocto git repo (git://git.pokylinux.org/poky.git) I don't get any of these meta-xxx directories that the BSP guide talks about. They seem to be kept in a separate git repository. My

Beyond that, there are some bigger issues. Remember that Yocto is just packaging for a Linux kernel and the user tools that surround it. Before you can add a new machine, especially one with a

Hi Scott, I thought I'd cc'd you on some other email where we talked about starting to store some of the other material we have about yocto alongside the documentation in the yocto-docs

on 2011-5-16 11:31, wangyang wrote: Add another machine is not that difficult, as Yocto is designed to be highly customizable for different H/W. What you need is a BSP layer for your H/W, it is

Hello! Because YOCTO supports x86, arm and so on MCU. I just want to know about how to port YOCTO to other MCU. Is it difficult, what's kind of knowledge needed? Thanks

Hi all, This is the weekly test report for Yocto 20110506 build. All meta-intel BSP build are not built out on autobuilder. Meanwhile, beagleboard could not boot up with latest image. gcc/g++

One thing that happens when you keep all figures in a folder that is hierarchically level with 'documentation' is that the figures become separated from the 'documentation' leg so to speak. It use

The benefit of the "store them all in the same folder" approach is that I can easily find and view the diagrams which might be useful without having to dig through several folders. I can of course

Currently I have been consistently using a ‘figures’directory within each manual directory to house any PNG files used in a givenmanual. However, the Yocto-docs repository has a

Hi, Richard I resend the patch and corrected some problems including: 1) name bitbake_mode -> extracaches 2) move extra cache definition to a different files And I test against cs (Add files missing

From: Liping Ke <liping.ke@...> Since Image Creator need extra cache fields which are not used by bitbake, we create the extra cache file to load this extra cache fields for making it more

From: Liping Ke <liping.ke@...> We introduce extra required fields as well as namedtuple recipeinfo class here. We also define the data retrieving methods for this extra recipeinfo class. This

From: Liping Ke <liping.ke@...> Data Retrive methods will be reused by Extra Cache Data fields. It is independent Class methods for data retrieving. Signed-off-by: Liping Ke

From: Liping Ke <liping.ke@...> When using ui mode, we will save ui_mode required extra cache fields into a separate cache file. This patch firstly introduce this extracaches parameter. It will

From: Liping Ke <liping.ke@...> Below four patches are for putting extra requested fields inito different cache files instead of using only on bb_cache.dat. Now image creator need extra three

I think you can add the Upstream-Status: after the exit on the script and before the patch proper starts. Have you confirmed that all these patches are actually used? I think that some are no longer

I find following dpatch files in the Yocto tree. Dpatch fileshave a small shell script at the beginning of the patch. Out of all these, all gcc patches are for all gcc-4.3.3 only,which is kind of