[meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo at freescale.com]

Hi Bob, 

> -----Original Message-----
> From: Bob Cochran [mailto:yocto at mindchasers.com]
> Sent: Thursday, July 17, 2014 4:50 AM
> 
> On 07/16/2014 08:20 AM, Daiane.Angolini at freescale.com wrote:
> >
> >> -----Original Message-----
> >> From: meta-freescale-bounces at yoctoproject.org [mailto:meta-freescale-
> >> bounces at yoctoproject.org] On Behalf Of zhenhua.luo at freescale.com
> >> Sent: Wednesday, July 16, 2014 3:01 AM
> >>
> >> Hi all,
> >>
> >> Following is the proposal for FSL QorIQ SDK upstream, comment is
> welcome.
> 
> Zhenhua, this is great news.  Thank you.  I have added some questions
> below that are focused on determining to what extent this new process for
> QorIQ will help me with my current development.
[Luo Zhenhua-B19537] Thanks. 

> >> Upstream Plan
> >> • SDK 1.6 recipe upstream (Done)
> >>    − http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/
> >> • Optimize the recipes in meta-fsl-ppc (Done)
> 
> meta-fsl-networking is required to build fsl images (e.g., fsl-image-
> core), and patches to it have been made since SDK1.6.  How can we get the
> latest patch set?  Can we create a layer / repo on the community site or
> OE to track these patches (assuming that it's still necessary to retrieve
> the meta-fsl-networking repo from the SDK)?  Would it be bad form to just
> create a directory beneath meta-fsl-ppc that contained patches to meta-
> fsl-networking?
[Luo Zhenhua-B19537] We are trying to move recipes for public packages from fsl-networking to fsl-ppc layer.
	As you know, the source of some packages are maintained in internally, so even if the recipes are added in fsl-ppc layer, the build still doesn't work due to source fetch issue. 
	In current stage, SDK ISOs should be used to get bits provided by fsl-networking layer. 
	We plan to add some demo images bb of QorIQ targets in meta-fsl-demos layer to facilitate the image build for QorIQ targets. 

> Will SDK1.6 patches be provided and socialized to the community that
> originate as bug reports from SDK users? For example, will the community
> be made aware of a patch to linux-qoriq from an issue that originated via
> Freescale's service request process?
[Luo Zhenhua-B19537] We are working on the proposal to improve SDK release process(public bug report system, public patch submit and review infrastructure, frequent patch publish, etc). 

> For meta-fsl-ppc, can we maintain both an SDK1.6 branch and a master
> branch with the former branch being used only for patches that add bug
> fixes to the SDK1.6 image?  It's my hope that weeks from now I can build
> a more robust image from the Community release than using the static
> SDK1.6 snapshot, which was released in June.
[Luo Zhenhua-B19537] Yes, the SDK 1.6 bit backport from master to daisy is in our plan, it will be done after the recipes in master is stable. 

>   • Resolve the PPC and ARM
> >> layer compatibility issue (31-Jul)
> >>    − Replace fslmachine with qoriq for override implementation
> >>    − Compatibility issue in bbappends • LS1 Alpha release upstream
> >> (15-Aug)
> >>    − http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/
> >> • Update and debug the initial script to support QorIQ targets (29-Aug)
> >>    − https://github.com/Freescale/fsl-community-bsp-base
> >> • Update repo config to facilitate the SDK fetch (29-Aug)
> >>    − https://github.com/Freescale/fsl-community-bsp-platform
> >> • Add demo image in meta-fsl-demo (29-Aug)
> >>    − https://github.com/Freescale/meta-fsl-demos
> >> • Update the documentation (10-Sep)
> >>    − https://github.com/Freescale/Freescale.github.io
> >>    − https://github.com/Freescale/Documentation
> 
> 
> I had previously volunteered to write something up for inclusion on the
> Community site regarding QorIQ to benefit (new) community developers.  I
> would like to use your plan as the basis for its content and help keep it
> up to date over time.  Please share any concerns you have about this.
>   Otherwise, I'll send out a draft soon (I'm thinking in the form of an
> HTML5 doc).
[Luo Zhenhua-B19537] Great, please share when your plan is ready. 

> >> • Regression test for FSL community BSP periodically (19-Sep)
> >>    NOTE: the time and interval depends on the logistics readiness •
> >> Set up a public image mirror for community users' testing • LS1
> >> August release
> >> upstream(30-Sep) • SDK 1.7 upstream (Jan-2015)
> 
> 
> Will separate SDK(1.7) and community releases exist after Jan 2015?
> 
> I would like to see us include in the plan a beta process for the Jan
> 2015 release.
[Luo Zhenhua-B19537] The Yocto recipes of SDK 1.7 upstream will be done in Jan 2015, QorIQ SDK 1.7 is planned in this Dec. 

> • LS2 upstream (TBD)
> >>
> >> Regression Testing
> >> • Leverage repo(manifest project) to fetch code.
> >> • Weekly build for QorIQ PPC and LS ARM targets, the build is based on
> >> community layers,
> >>    the issues of Yocto Community BSP and FSL SDK should be separated
> due to
> >> differentiation.
> >> • Periodically sanity test for typical boards that are randomly
> selected
> >> according to board resource availability.
> >>
> >> Infrastructure
> >> • Bug management for community SDK
> >>    https://bugzilla.yoctoproject.org/
> >> • Mailing list
> >>    meta-freescale at freescale.com
> >>    FSL community SDK discussion, patch submit and review
> 
> 
> Is the meta-freescale email list now open to all QorIQ SW issues? 
> For example, I'm finding problems in the SDK image that I suspect are at the
> DPAA level.  After investigating, would it be appropriate to discuss my
> findings and potentially submit patches against code on the mail list
> (as opposed to using the Freescale SR process)?
[Luo Zhenhua-B19537] Before the FSL public mailing list is available, you can report the SDK issues via meta-freescale maillist.


Best Regards,

Zhenhua