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

[Bob Cochran]

On 07/23/2014 03:41 AM, zhenhua.luo at freescale.com wrote:
> 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.


Therefore, I'll point out that the FSL Community BSP Home Page states 
that Community releases are done in April and October and this is 
potentially in conflict with a Jan 2015 release.

Or maybe I should ask whether the SDK 1.7 upstream, which is planned for 
Jan 2015, is the same as a planned community release.


>
>> • 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
>