* yocto-bsp create @ 2012-08-15 20:06 Chris Tapp 2012-08-15 20:14 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Chris Tapp @ 2012-08-15 20:06 UTC (permalink / raw) To: yocto@yoctoproject.org Project I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-) I've got a few questions/comments: 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?). 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable? 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered? 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the <mybsp>.cfg file)? 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful. Chris Tapp opensource@keylevel.com www.keylevel.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yocto-bsp create 2012-08-15 20:06 yocto-bsp create Chris Tapp @ 2012-08-15 20:14 ` Bruce Ashfield 2012-08-16 20:26 ` Chris Tapp 0 siblings, 1 reply; 6+ messages in thread From: Bruce Ashfield @ 2012-08-15 20:14 UTC (permalink / raw) To: Chris Tapp; +Cc: yocto@yoctoproject.org Project On 12-08-15 04:06 PM, Chris Tapp wrote: > I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-) You really want TomZ to answer, but I'll throw in a few comments here, since I'm currently reviewing a batch of code from Tom. > > I've got a few questions/comments: > > 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?). For the 3.2 tree, it is standard/default/base, which is a name that we quickly determined was not optimal, and in the 3.4 kernel tree it is standard/base. So the answer is, it depends on the kernel you are using, but the tools know and have the right defaults. > > 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable? They are collections of functionality and configuration. So if you are working on a new machine that is close to something that is already in tree, you'd start from the existing machine branch. If you want to do something new, standard/base, if you want the preempt-rt kernel, standard/preempt-rt/base, etc. > > 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered? > > 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the<mybsp>.cfg file)? AFAIK, no. Since that would imply that all the kernel tunings were parsed and made available. Adding it to your .cfg is the right thing. If there is a BSP that already falls into your class, and you inherit it, you'd get the right tuning by default. > > 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful. Tom and I were working on a way to dump these, I'm not sure if that ever completed. The meta branch of the kernel repo has all the details, with short descriptions in the .scc files. As with anything, documenting a moving source code target is hard, so I suggest looking at the branch. Have a look at the 3.4 kernel tree, meta branch, there's a README with details about the categories, and contents. Cheers, Bruce > > Chris Tapp > > opensource@keylevel.com > www.keylevel.com > > > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yocto-bsp create 2012-08-15 20:14 ` Bruce Ashfield @ 2012-08-16 20:26 ` Chris Tapp 2012-08-16 23:48 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Chris Tapp @ 2012-08-16 20:26 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto@yoctoproject.org Project On 15 Aug 2012, at 21:14, Bruce Ashfield wrote: > On 12-08-15 04:06 PM, Chris Tapp wrote: >> I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-) > > You really want TomZ to answer, but I'll throw in a few comments > here, since I'm currently reviewing a batch of code from Tom. > >> >> I've got a few questions/comments: >> >> 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?). > > For the 3.2 tree, it is standard/default/base, which is a name that we > quickly determined was not optimal, and in the 3.4 kernel tree it is standard/base. > So the answer is, it depends on the kernel you are using, but the tools > know and have the right defaults. > >> >> 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable? > > They are collections of functionality and configuration. So if you are > working on a new machine that is close to something that is already > in tree, you'd start from the existing machine branch. If you want to > do something new, standard/base, if you want the preempt-rt kernel, > standard/preempt-rt/base, etc. > >> >> 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered? >> >> 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the<mybsp>.cfg file)? > > AFAIK, no. Since that would imply that all the kernel tunings were parsed > and made available. Adding it to your .cfg is the right thing. If > there is a BSP that already falls into your class, and you inherit > it, you'd get the right tuning by default. > >> >> 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful. > > Tom and I were working on a way to dump these, I'm not sure if that > ever completed. The meta branch of the kernel repo has all the details, > with short descriptions in the .scc files. > > As with anything, documenting a moving source code target is hard, so > I suggest looking at the branch. > > Have a look at the 3.4 kernel tree, meta branch, there's a README with > details about the categories, and contents. Thanks, that's got me going in the right direction. However, I've just recreated the BSP (to use standard/default/base) and I'm now getting an error when I build the kernel: ERROR: Function failed: do_patch (see... /log.do_patch.31458 for further information) ERROR: Logfile of failure stored in: ... /log.do_patch.31458 Log data follows: | ERROR: Function failed: do_patch (see ... /log.do_patch.31458 for further information) | checkpoint is already restored, nothing to do | error: 'refs/heads/standard/default/base' exists; cannot create 'refs/heads/standard/default/base/LX800' | fatal: Failed to lock ref for update: Not a directory | warning: could not find (or was already included): features/dmaengine/dmaengine.scc | warning: could not find (or was already included): features/framebuffer/vesafb.scc | warning: could not find (or was already included): features/intel-e1xxxx/intel-e100.scc | warning: could not find (or was already included): features/intel-e1xxxx/intel-e1xxxx.scc | warning: could not find (or was already included): features/dmaengine/dmaengine.scc | warning: could not find (or was already included): features/serial/8250.scc | warning: could not find (or was already included): features/hpet/hpet.scc | warning: could not find (or was already included): features/ericsson-3g/f5521gw.scc | warning: could not find (or was already included): features/framebuffer/vesafb.scc | warning: could not find (or was already included): cfg/usb-mass-storage.scc | warning: could not find (or was already included): cfg/boot-live.scc | warning: could not find (or was already included): features/power/intel.scc | warning: could not find (or was already included): features/logbuf/size-normal.scc | warning: could not find (or was already included): features/latencytop/latencytop.scc | warning: could not find (or was already included): features/profiling/profiling.scc | warning: could not find (or was already included): user-patches.scc | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found | [INFO] validating against known patches (LX800-base-meta) | error: Your local changes to the following files would be overwritten by checkout: | Makefile | drivers/tty/serial/pch_uart.c | drivers/usb/host/pci-quirks.c | fs/namei.c | fs/nfs/super.c | fs/splice.c | include/linux/nfs_xdr.h | kernel/time/ntp.c | net/ipv4/arp.c | scripts/mod/modpost.c | Please, commit your changes or stash them before you can switch branches. | Aborting | ERROR: could not checkout branch base | ERROR. could not update git tree | ERROR. Could not modify standard/default/base/LX800 NOTE: package linux-yocto-3.2.18+git1+49f931bc294d5b6be60502bbd448cff5aa766235_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1.1: task do_patch: Failed I'm guessing this is related to using the same BSP name when I recreated it? What do I need to do to get back to something that builds (which it did before)? Chris Tapp opensource@keylevel.com www.keylevel.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yocto-bsp create 2012-08-16 20:26 ` Chris Tapp @ 2012-08-16 23:48 ` Bruce Ashfield [not found] ` <5053D9BB-9E6B-4D25-B5B0-9B08DBB381E5@keylevel.com> 0 siblings, 1 reply; 6+ messages in thread From: Bruce Ashfield @ 2012-08-16 23:48 UTC (permalink / raw) To: Chris Tapp; +Cc: yocto@yoctoproject.org Project On 12-08-16 4:26 PM, Chris Tapp wrote: > On 15 Aug 2012, at 21:14, Bruce Ashfield wrote: > >> On 12-08-15 04:06 PM, Chris Tapp wrote: >>> I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-) >> >> You really want TomZ to answer, but I'll throw in a few comments >> here, since I'm currently reviewing a batch of code from Tom. >> >>> >>> I've got a few questions/comments: >>> >>> 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?). >> >> For the 3.2 tree, it is standard/default/base, which is a name that we >> quickly determined was not optimal, and in the 3.4 kernel tree it is standard/base. >> So the answer is, it depends on the kernel you are using, but the tools >> know and have the right defaults. >> >>> >>> 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable? >> >> They are collections of functionality and configuration. So if you are >> working on a new machine that is close to something that is already >> in tree, you'd start from the existing machine branch. If you want to >> do something new, standard/base, if you want the preempt-rt kernel, >> standard/preempt-rt/base, etc. >> >>> >>> 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered? >>> >>> 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the<mybsp>.cfg file)? >> >> AFAIK, no. Since that would imply that all the kernel tunings were parsed >> and made available. Adding it to your .cfg is the right thing. If >> there is a BSP that already falls into your class, and you inherit >> it, you'd get the right tuning by default. >> >>> >>> 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful. >> >> Tom and I were working on a way to dump these, I'm not sure if that >> ever completed. The meta branch of the kernel repo has all the details, >> with short descriptions in the .scc files. >> >> As with anything, documenting a moving source code target is hard, so >> I suggest looking at the branch. >> >> Have a look at the 3.4 kernel tree, meta branch, there's a README with >> details about the categories, and contents. > > > Thanks, that's got me going in the right direction. > > However, I've just recreated the BSP (to use standard/default/base) and I'm now getting an error when I build the kernel: > > ERROR: Function failed: do_patch (see... /log.do_patch.31458 for further information) > ERROR: Logfile of failure stored in: ... /log.do_patch.31458 > Log data follows: > | ERROR: Function failed: do_patch (see ... /log.do_patch.31458 for further information) > | checkpoint is already restored, nothing to do > | error: 'refs/heads/standard/default/base' exists; cannot create 'refs/heads/standard/default/base/LX800' > | fatal: Failed to lock ref for update: Not a directory > | warning: could not find (or was already included): features/dmaengine/dmaengine.scc > | warning: could not find (or was already included): features/framebuffer/vesafb.scc > | warning: could not find (or was already included): features/intel-e1xxxx/intel-e100.scc > | warning: could not find (or was already included): features/intel-e1xxxx/intel-e1xxxx.scc > | warning: could not find (or was already included): features/dmaengine/dmaengine.scc > | warning: could not find (or was already included): features/serial/8250.scc > | warning: could not find (or was already included): features/hpet/hpet.scc > | warning: could not find (or was already included): features/ericsson-3g/f5521gw.scc > | warning: could not find (or was already included): features/framebuffer/vesafb.scc > | warning: could not find (or was already included): cfg/usb-mass-storage.scc > | warning: could not find (or was already included): cfg/boot-live.scc > | warning: could not find (or was already included): features/power/intel.scc > | warning: could not find (or was already included): features/logbuf/size-normal.scc > | warning: could not find (or was already included): features/latencytop/latencytop.scc > | warning: could not find (or was already included): features/profiling/profiling.scc > | warning: could not find (or was already included): user-patches.scc > | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found > | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found > | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 21: dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found > | ./2-LX800-9dbd5e3915bb4ed4d3809d315087c405.sco: line 33: vesafb_68b329da9893e34099c7d8ad5cb9c940: command not found > | [INFO] validating against known patches (LX800-base-meta) > | error: Your local changes to the following files would be overwritten by checkout: > | Makefile > | drivers/tty/serial/pch_uart.c > | drivers/usb/host/pci-quirks.c > | fs/namei.c > | fs/nfs/super.c > | fs/splice.c > | include/linux/nfs_xdr.h > | kernel/time/ntp.c > | net/ipv4/arp.c > | scripts/mod/modpost.c > | Please, commit your changes or stash them before you can switch branches. > | Aborting > | ERROR: could not checkout branch base > | ERROR. could not update git tree > | ERROR. Could not modify standard/default/base/LX800 > NOTE: package linux-yocto-3.2.18+git1+49f931bc294d5b6be60502bbd448cff5aa766235_1+8b8cfaaab2b8d79ac56e8c9a85bad9ae7bca399c-r1.1: task do_patch: Failed > > I'm guessing this is related to using the same BSP name when I recreated it? What do I need to do to get back to something that builds (which it did before)? ech. That means that the tree was somehow dirty and branches couldn't be switched/checked out. If you have a copy of your BSP layer, I can try a build here and shed some light on what exactly went wrong. Bruce > > Chris Tapp > > opensource@keylevel.com > www.keylevel.com > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <5053D9BB-9E6B-4D25-B5B0-9B08DBB381E5@keylevel.com>]
[parent not found: <502E5C6B.7040709@windriver.com>]
[parent not found: <35B0FBF5-FE52-4C75-BBF6-F260A1954F76@keylevel.com>]
[parent not found: <502E9C97.6000209@windriver.com>]
[parent not found: <860E0816-033F-4091-ABFB-A3B699D260BD@keylevel.com>]
[parent not found: <502E9FED.8070907@windriver.com>]
* Re: yocto-bsp create [not found] ` <502E9FED.8070907@windriver.com> @ 2012-08-17 19:56 ` Chris Tapp 2012-08-21 17:50 ` Tom Zanussi 0 siblings, 1 reply; 6+ messages in thread From: Chris Tapp @ 2012-08-17 19:56 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto@yoctoproject.org Project On 17 Aug 2012, at 20:47, Bruce Ashfield wrote: > On 12-08-17 03:40 PM, Chris Tapp wrote: >> >> On 17 Aug 2012, at 20:33, Bruce Ashfield wrote: >> >>> On 12-08-17 03:32 PM, Chris Tapp wrote: >>>> On 17 Aug 2012, at 15:59, Bruce Ashfield wrote: >>>> >>>>> On 12-08-17 06:47 AM, Chris Tapp wrote: >>>>>> >>>>>> On 17 Aug 2012, at 00:48, Bruce Ashfield wrote: >>>>>> >>>>>>> ech. That means that the tree was somehow dirty and branches couldn't >>>>>>> be switched/checked out. >>>>>>> >>>>>>> If you have a copy of your BSP layer, I can try a build here and shed >>>>>>> some light on what exactly went wrong. >>>>>> >>>>>> >>>>>> Thanks Bruce. Meta layer attached. >>>>> >>>>> Fixed here. This was completely generated from the tools ? If so, the >>>>> branching information was wrong. >>>>> >>>>> KBRANCH_LX800 = "standard/default/LX800" >>>>> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800 = "standard/default/LX800" >>>>> >>>>> The "base" is always inferred and only exists because of the >>>>> way that git manages refs on disk. So the branch that you >>>>> want to build is what I have above, and the tools will >>>>> automatically make that branch point off the default/base >>>>> branch. >>>>> >>>>> Let me know if that did come from the tools and I'll follow >>>>> up to the list. >>>> >>>> I'm 99.99% sure it did, but it runs ok after making the changes you give above, deleting tmp/ and rebuilding. >>>> >>>> I've not g0t any real changes in yet, so I'll go try again and see what I get. It's just possible I didn't do a complete rebuild (i.e. nuke tmp/) which may have caused a problem last time round. >>> >>> ok. cool. no rush. I was just going to do a final update on the mailing >>> list to not leave it hanging, and if there's a bug in the scripts, we >>> can let Tom know .. so he can fix it! >> >> >> I've just recreated the BSP. I selected option 4 for the kernel branch (standard/default/base), which gives: >> >> KBRANCH_LX800 = "standard/default/base/LX800" >> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800 = "standard/default/base/LX800" > > ok. Worth firing off a bug report to Tom Zaunussi. .. that > won't work .. ever. Just bringing this back on-list. I'll get something added to the tracker. Chris Tapp opensource@keylevel.com www.keylevel.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: yocto-bsp create 2012-08-17 19:56 ` Chris Tapp @ 2012-08-21 17:50 ` Tom Zanussi 0 siblings, 0 replies; 6+ messages in thread From: Tom Zanussi @ 2012-08-21 17:50 UTC (permalink / raw) To: Chris Tapp; +Cc: yocto@yoctoproject.org Project On Fri, 2012-08-17 at 20:56 +0100, Chris Tapp wrote: > On 17 Aug 2012, at 20:47, Bruce Ashfield wrote: > > > On 12-08-17 03:40 PM, Chris Tapp wrote: > >> > >> On 17 Aug 2012, at 20:33, Bruce Ashfield wrote: > >> > >>> On 12-08-17 03:32 PM, Chris Tapp wrote: > >>>> On 17 Aug 2012, at 15:59, Bruce Ashfield wrote: > >>>> > >>>>> On 12-08-17 06:47 AM, Chris Tapp wrote: > >>>>>> > >>>>>> On 17 Aug 2012, at 00:48, Bruce Ashfield wrote: > >>>>>> > >>>>>>> ech. That means that the tree was somehow dirty and branches couldn't > >>>>>>> be switched/checked out. > >>>>>>> > >>>>>>> If you have a copy of your BSP layer, I can try a build here and shed > >>>>>>> some light on what exactly went wrong. > >>>>>> > >>>>>> > >>>>>> Thanks Bruce. Meta layer attached. > >>>>> > >>>>> Fixed here. This was completely generated from the tools ? If so, the > >>>>> branching information was wrong. > >>>>> > >>>>> KBRANCH_LX800 = "standard/default/LX800" > >>>>> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800 = "standard/default/LX800" > >>>>> > >>>>> The "base" is always inferred and only exists because of the > >>>>> way that git manages refs on disk. So the branch that you > >>>>> want to build is what I have above, and the tools will > >>>>> automatically make that branch point off the default/base > >>>>> branch. > >>>>> > >>>>> Let me know if that did come from the tools and I'll follow > >>>>> up to the list. > >>>> > >>>> I'm 99.99% sure it did, but it runs ok after making the changes you give above, deleting tmp/ and rebuilding. > >>>> > >>>> I've not g0t any real changes in yet, so I'll go try again and see what I get. It's just possible I didn't do a complete rebuild (i.e. nuke tmp/) which may have caused a problem last time round. > >>> > >>> ok. cool. no rush. I was just going to do a final update on the mailing > >>> list to not leave it hanging, and if there's a bug in the scripts, we > >>> can let Tom know .. so he can fix it! > >> > >> > >> I've just recreated the BSP. I selected option 4 for the kernel branch (standard/default/base), which gives: > >> > >> KBRANCH_LX800 = "standard/default/base/LX800" > >> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800 = "standard/default/base/LX800" > > > > ok. Worth firing off a bug report to Tom Zaunussi. .. that > > won't work .. ever. > > Just bringing this back on-list. > > I'll get something added to the tracker. > Just back from vacation and getting to this... Yeah, this is a known bug and was fixed by the yocto-bsp patchsets I sent out just before I left. See the last entry in the bug below for links to the branches that fixed it and a few other issues: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2693 I see that the denzil branch has been updated with the changes, but have yet to hit master. Tom > Chris Tapp > > opensource@keylevel.com > www.keylevel.com > > > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-08-21 17:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-15 20:06 yocto-bsp create Chris Tapp
2012-08-15 20:14 ` Bruce Ashfield
2012-08-16 20:26 ` Chris Tapp
2012-08-16 23:48 ` Bruce Ashfield
[not found] ` <5053D9BB-9E6B-4D25-B5B0-9B08DBB381E5@keylevel.com>
[not found] ` <502E5C6B.7040709@windriver.com>
[not found] ` <35B0FBF5-FE52-4C75-BBF6-F260A1954F76@keylevel.com>
[not found] ` <502E9C97.6000209@windriver.com>
[not found] ` <860E0816-033F-4091-ABFB-A3B699D260BD@keylevel.com>
[not found] ` <502E9FED.8070907@windriver.com>
2012-08-17 19:56 ` Chris Tapp
2012-08-21 17:50 ` Tom Zanussi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.