Hi Zhenhua,
Can we get an update on Layerscape? It's been about 6 months since the
Yocto layers organization for Layerscape was last talked about on this
board.
When will we first see an instance of the stage 2 organization (e.g.,
meta-fsl-layerscape) in the yocto project source repos
(http://git.yoctoproject.org/cgit/cgit.cgi/)?
Thanks,
Bob
On 03/03/2013 10:48 PM, Luo Zhenhua-B19537 wrote:
Hello all,
I have incorporated the comments of previous discussion into the reorg
design document, please take a look.
*Summary of Yocto reorg*
* To support Layerscape release, both ARM architecture and PPC
architecture are required to be supported by Yocto.
* Currently Yocto support for i.MX SDK and QorIQ SDK are developed and
maintained separately, some duplicated packages are not shared between
ARM SDK and PPC SDK. And will not be efficient and effective maintained
for Layerscape support.
* More clear naming of Yocto layers for FSL specific will be helpful for
PPC, ARM and Layercape support simultaneously.
* Subsequent slides introduces the plan and design of FSL Yocto layers
re-org.
*FSL Yocto Layers Reorg Diagram*
yocto-re-org.png
*FSL Yocto Layers Reorg – Stage1*
* Stage1: ~ Jun-2013
* Following layers will coexist:
poky: the opensource version
meta-oe: the opensource branch corresponding to poky
meta-virtualization: the opensource virtualization layer
meta-fsl-ppc-toolchain: fsl toolchain recipes
meta-fsl-ppc: fsl public packages for PPC targets
meta-fsl-ppc-private: fsl private packages for PPC targets
meta-fsl-arm: fsl packages for ARM targets
meta-fsl-demos: demo rootfs recipes of ARM targets
meta-fsl-networking: recipes specific to networking SDK
Other necessary upstream layers
*FSL Yocto Layers Reorg – Stage2*
* Stage2: Jul-2013 ~ Dec-2013
* Following change will be made:
Poky/meta-oe/meta-virtualization for opensource are reused
Following architecture specific layers are maintained in
git.am.freescale.net, git.freescale.com and git.yoctoproject.org
meta-fsl-arm: layer for FSL arm machines
meta-fsl-ppc: layer for FSL ppc machines
Following SDK specific layers are maintained in git.am.freescale.net
and git.freescale.com
meta-fsl-toolchain: layer for fsl toolchain recipes
meta-fsl-multimedia: layer for multimedia SDK
meta-fsl-networking: layer for networking SDK
meta-fsl-layerscape: layer for layerscape SDK
*FSL Yocto Layers Reorg – More info*
* Layer of getting layers specific to Freescale SDK
* Layer name: meta-freescale-sdk
* The function of this layer is similar as
https://github.com/Freescale/fsl-community-bsp-platform and it is
maintained in FSL internal/external git tree
* A branch is created for each FSL SDK release to include the scripts
to fetch necessary layers of specified version
* Multiple branch maintain
* Align with the branch policy of poky: denzil, danny, master ...
* A tag of sub-layers will be created for each FSL release
* Upstream / public branches will try to work with all Yocto
releases, while SDK releases could contain a lot of hacks to more things
working, or pre-release things out there door.
* SDK releases sometimes skip entire Yocto releases (e.g. danny). SDK
versions may contain slightly different versions. This comes into play
more with oe-core where we don't have official control and we need to
include a specific fix for the SDK. Layers themselves tend to have less
reason to deviate from the upstream versions since we control both sides
so they should be the same.
* Meta-fsl-toolchain layer maintain
* This layer is maintained in FSL internal/external git tree
* Directory structure:
meta-fsl-toolchain
|-- meta-gcc4.6-eglib2.13-binutils-2.21a
|-- meta-gcc4.7-eglib2.15-binutils-2.23
* SCM
* Unify the mailing list of FSL layers
* Opensource: [email protected]
<mailto:[email protected]>_**
* U-boot/Linux on FSL official git tree (git.freescale.com)
* The source in git.freescale.com will be updated when SDK is formally
released, since full verification should be conducted to ensure
quality. So Kernel in FSL official git tree will not be synced with
internal git tree during the developing phase.
* The kernel team can’t have everything upstreamed for an SDK release
and supporting all feature and bug fixes. Besides we will pick a kernel
and test and fix it so it will always fall out of sync. (e.g. latest
kernel release - 1 release + fixes).
* Yocto sync on git.am.freescale.net, gitfrescale.com and
git.yoctoproject.org
* These should be much closer to the same for the layers we control.
Due to the limited resources spread around, we can't always get all
fixes in the oe-core/poky for an SDK release timely. But a lot of times
we can get them into the branch for that release and eventually a point
release. Upstream/public branches will try to work with all Yocto
releases, while SDK releases could contain a lot of hacks to more things
working.
Best Regards,
Zhenhua
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
