[oe] What is the relationship between Open Embedded for MSM and Yocto Project?

[Brian Hutchinson]

On Wed, Apr 16, 2014 at 7:51 PM, Journeyer J. Joh
<oosaprogrammer at gmail.com>wrote:

> Hi Denys Dmytriyenko,
>
> I would recommend you to talk to someone from your company who's more
> > familiar
> > with the code base that you are trying to look at and how it is derived
> > and/or
> > relates to OpenEmbedded and the Yocto Project.
>
>
> This is what exactly I am sorry for..
> I, in my team, the only one who works with linux.
> There are people who works with linux but, until now, I cannot meet them
> easily. I feel mail-list more kindly than them..
> And I am new to this company...
> Telling this story doesn't look fit to the purpose of this maillist but,
> this is just my story..
>
> And this is the reason why I thank you for your kindness..
> But I agree I should try to talk with people in my company.
>
> I don't know what "OE for MSM" is, that you keep referring, probably
> your company's
> > product based on OE.
>
>
> I think this might be the OE for MSM:
>
> https://www.codeaurora.org/xwiki/bin/QLBEP/WebHome
>
> Thank you ...
> Sincerely
> Journeyer
>
>
>
> Hi Journeyer,

After paying more attention to the platform you are using ... I'm doubtful
that the sdk instructions we mentioned to you before will actually work for
you especially seeing that the snapshot of OE at the links you provided are
2011/2012 vintage.  You may want to investigate the older bitbake
meta-toolchain recipes (meta-toolchain-sdk too).

So if the sdk instructions don't work, but you need to work with the latest
OE/Yocto releases ... you may have to do things like I've had to do in the
past for some platforms that aren't directly supported by OE, Yocto etc.
 I've had to use the kernel/u-boot that came from the silicon vendor (never
mainlined and probably never will and are frozen in time) and I build
u-boot and kernel source from vendor outside of bitbake (standalone). You
can use the toolchain that is probably provided with the MDM and setup OE
or Yocto to use that toolchain as an external toolchain to build current
released filesystem images and packages.  This way you have new
applications in the rootfs but may be stuck (if it isn't mainlined) with
old kernel.

Your mileage will vary if you decide to go down this road as there can be
land mines ... It is always best to keep toolchain, kernel, and root
filesystem moving forward (not necessarily using the latest but not lagging
too far behind it) and not let one of them get pinned being static but some
times you don't have much of a choice (I've been there).  Sometimes when
you try to build new filesystem images with old toolchains you run into
problems.  Building old kernels with new toolchains also causes problems.
 So if you are like me and have a product that needs new kernels and
filesystem images to keep up with security threats etc., ... you're going
to have a hard life for a while (ask me how I know).

You can also study the platform specific differences between what
codeaurora (the working example that supports your platform) provided and
what the latest releases of OE/yocto provide and make new recipies and
bsp's in the latest releases of OE or Yocto to support your platform which
is the right thing to do ... but requires the most knowledge of the build
system to do.

I hope I'm not confusing you ... just trying to give you ideas of what
options you have so you can best pick a solution that fits with what you
are trying to do.  You may have to pick a less than ideal solution to start
with and as you learn more move toward adding platform/BSP support for your
hardware to the latest version of OE, Yocto etc.

Regards,

Brian