[RFC] The proposal of FSL QorIQ SDK upstream

[RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

Hi all, 

Following is the proposal for FSL QorIQ SDK upstream, comment is welcome. 

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)
• 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
• 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)
• 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@freescale.com
  FSL community SDK discussion, patch submit and review 

More to do 
• Setup public bug management system for FSL SDKs. 
• Push all modules to public git repository to ensure FSL community BSP sync with FSL released SDK. 
• Setup an external mailing list for external git repository for FSL SDK discussion, patch submission, patch review. 
• Setup an patch management tool(patchwork or gerrit) to manage patches from community. 
• Enhance the commit message in patch to facilitate the patch search for specific issue. 


Best Regards,

Zhenhua

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Daiane.Angolini]

> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of zhenhua.luo@freescale.com
> Sent: Wednesday, July 16, 2014 3:01 AM
> To: meta-freescale@yoctoproject.org
> Subject: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream
> 
> Hi all,
> 
> Following is the proposal for FSL QorIQ SDK upstream, comment is welcome.
> 
> 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) • 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
> • 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) • 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@freescale.com
>   FSL community SDK discussion, patch submit and review
> 
> More to do
> • Setup public bug management system for FSL SDKs.
> • Push all modules to public git repository to ensure FSL community BSP
> sync with FSL released SDK.
> • Setup an external mailing list for external git repository for FSL SDK
> discussion, patch submission, patch review.
> • Setup an patch management tool(patchwork or gerrit) to manage patches
> from community.
> • Enhance the commit message in patch to facilitate the patch search for
> specific issue.
> 

I like your list, and I don´t remember (now) anything else to add.
I assume it´s a high level list, and details on how-to and what-to do is for future discussion.

However, your email highlighted a critical issue we (ARM+PPC) have. You used 4 different names to call "the community source code".

BSP - board support package [1]
" is a collection of information that defines how to support a particular hardware device, set of devices, or hardware platform."

It means that the current "FSL Community BSP" name is wrong. The resultant code provides more that "info to define how to support HW". To be very simplistic, in a BSP there is no image recipe.

SDK - Software Development Kit [2]

Being defined (in YP) as toolchain+sysroot+setup-env script.

I assume meta-fsl-ppc does not provide *only* SDK. I assume it provides both BSP and the tools to allow user to create the SDK.

So, call meta-fsl-arm/extra+meta-fsl-pcc+meta-fsl-demos+Documentation+fsl-community-bsp-base+fsl-community-bsp-platform only as "FSL Community BSP" is not complete/right/cool.


Historically, we started to build the "FSL Community BSP" identity in past one year. At first, I used to thought about it as "meta-fsl-arm" (once upon a time, we cloned one by one the needed repos). Then "meta-fsl-arm" became incomplete, and we created the super-set of projects that, together, would form a bigger and stronger project, and we decided to call it "FSL Community BSP"

I think we can use the ARM+PCC technical union effort to start building our identity as community.

[1] http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#bsp
[2] http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#sdk-generation-dev-environment


Daiane

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 07/16/2014 08:20 AM, Daiane.Angolini@freescale.com wrote:
>
>
>> -----Original Message-----
>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>> bounces@yoctoproject.org] On Behalf Of zhenhua.luo@freescale.com
>> Sent: Wednesday, July 16, 2014 3:01 AM
>> To: meta-freescale@yoctoproject.org
>> Subject: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream
>>
>> 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.

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

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?

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.


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


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


• 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@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)?



>>
>> More to do
>> • Setup public bug management system for FSL SDKs.
>> • Push all modules to public git repository to ensure FSL community BSP
>> sync with FSL released SDK.
>> • Setup an external mailing list for external git repository for FSL SDK
>> discussion, patch submission, patch review.
>> • Setup an patch management tool(patchwork or gerrit) to manage patches
>> from community.
>> • Enhance the commit message in patch to facilitate the patch search for
>> specific issue.
>>
>
> I like your list, and I don´t remember (now) anything else to add.
> I assume it´s a high level list, and details on how-to and what-to do is for future discussion.
>
> However, your email highlighted a critical issue we (ARM+PPC) have. You used 4 different names to call "the community source code".
>
> BSP - board support package [1]
> " is a collection of information that defines how to support a particular hardware device, set of devices, or hardware platform."
>
> It means that the current "FSL Community BSP" name is wrong. The resultant code provides more that "info to define how to support HW". To be very simplistic, in a BSP there is no image recipe.
>
> SDK - Software Development Kit [2]
>
> Being defined (in YP) as toolchain+sysroot+setup-env script.
>
> I assume meta-fsl-ppc does not provide *only* SDK. I assume it provides both BSP and the tools to allow user to create the SDK.
>
> So, call meta-fsl-arm/extra+meta-fsl-pcc+meta-fsl-demos+Documentation+fsl-community-bsp-base+fsl-community-bsp-platform only as "FSL Community BSP" is not complete/right/cool.
>
>
> Historically, we started to build the "FSL Community BSP" identity in past one year. At first, I used to thought about it as "meta-fsl-arm" (once upon a time, we cloned one by one the needed repos). Then "meta-fsl-arm" became incomplete, and we created the super-set of projects that, together, would form a bigger and stronger project, and we decided to call it "FSL Community BSP"
>
> I think we can use the ARM+PCC technical union effort to start building our identity as community.
>
> [1] http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#bsp
> [2] http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#sdk-generation-dev-environment
>
>
> Daiane
>

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

Hi Daiane, 

Thanks for your comments.

The details on how/what-to-do needs more discussion, especially for documentation update, arm and ppc layer collaborate, testing, etc. Some works in the item lists have been done, some works are being done, some works are to be done. 

Regarding the name, I don't know what name is good, maybe FSL Community Yocto Embedded Linux, any better idea? 


Best Regards,

Zhenhua


> -----Original Message-----
> From: Angolini Daiane-B19406
> Sent: Wednesday, July 16, 2014 8:20 PM
> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
> Subject: RE: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK
> upstream
> 
> 
> 
> > -----Original Message-----
> > From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> > bounces@yoctoproject.org] On Behalf Of zhenhua.luo@freescale.com
> > Sent: Wednesday, July 16, 2014 3:01 AM
> > To: meta-freescale@yoctoproject.org
> > Subject: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream
> >
> > Hi all,
> >
> > Following is the proposal for FSL QorIQ SDK upstream, comment is
> welcome.
> >
> > 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) • 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
> > • 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) • 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@freescale.com
> >   FSL community SDK discussion, patch submit and review
> >
> > More to do
> > • Setup public bug management system for FSL SDKs.
> > • Push all modules to public git repository to ensure FSL community
> > BSP sync with FSL released SDK.
> > • Setup an external mailing list for external git repository for FSL
> > SDK discussion, patch submission, patch review.
> > • Setup an patch management tool(patchwork or gerrit) to manage
> > patches from community.
> > • Enhance the commit message in patch to facilitate the patch search
> > for specific issue.
> >
> 
> I like your list, and I don´t remember (now) anything else to add.
> I assume it´s a high level list, and details on how-to and what-to do is
> for future discussion.
> 
> However, your email highlighted a critical issue we (ARM+PPC) have. You
> used 4 different names to call "the community source code".
> 
> BSP - board support package [1]
> " is a collection of information that defines how to support a particular
> hardware device, set of devices, or hardware platform."
> 
> It means that the current "FSL Community BSP" name is wrong. The
> resultant code provides more that "info to define how to support HW". To
> be very simplistic, in a BSP there is no image recipe.
> 
> SDK - Software Development Kit [2]
> 
> Being defined (in YP) as toolchain+sysroot+setup-env script.
> 
> I assume meta-fsl-ppc does not provide *only* SDK. I assume it provides
> both BSP and the tools to allow user to create the SDK.
> 
> So, call meta-fsl-arm/extra+meta-fsl-pcc+meta-fsl-
> demos+Documentation+fsl-community-bsp-base+fsl-community-bsp-platform
> only as "FSL Community BSP" is not complete/right/cool.
> 
> 
> Historically, we started to build the "FSL Community BSP" identity in
> past one year. At first, I used to thought about it as "meta-fsl-arm"
> (once upon a time, we cloned one by one the needed repos). Then "meta-
> fsl-arm" became incomplete, and we created the super-set of projects that,
> together, would form a bigger and stronger project, and we decided to
> call it "FSL Community BSP"
> 
> I think we can use the ARM+PCC technical union effort to start building
> our identity as community.
> 
> [1] http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#bsp
> [2] http://www.yoctoproject.org/docs/current/ref-manual/ref-
> manual.html#sdk-generation-dev-environment
> 
> 
> Daiane

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

Hi Bob, 

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Thursday, July 17, 2014 4:50 AM
> 
> On 07/16/2014 08:20 AM, Daiane.Angolini@freescale.com wrote:
> >
> >> -----Original Message-----
> >> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> >> bounces@yoctoproject.org] On Behalf Of zhenhua.luo@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@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

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 07/23/2014 03:16 AM, zhenhua.luo@freescale.com wrote:
> Hi Daiane,
>
> Thanks for your comments.
>
> The details on how/what-to-do needs more discussion, especially for documentation update, arm and ppc layer collaborate, testing, etc. Some works in the item lists have been done, some works are being done, some works are to be done.
>
> Regarding the name, I don't know what name is good, maybe FSL Community Yocto Embedded Linux, any better idea?


How will QorIQ ARM specific (meta) data be organized / labeled?  Is it 
going in meta-fsl-arm?

Aren't there 3 different sets of data: fsl-imx-arm, fsl-qoriq-arm, and 
fsl-qori-ppc?

Sorry if this has already been resolved, and I just didn't catch it.


>
>
> Best Regards,
>
> Zhenhua
>
>
>> -----Original Message-----
>> From: Angolini Daiane-B19406
>> Sent: Wednesday, July 16, 2014 8:20 PM
>> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
>> Subject: RE: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK
>> upstream
>>
>>
>>
>>> -----Original Message-----
>>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>>> bounces@yoctoproject.org] On Behalf Of zhenhua.luo@freescale.com
>>> Sent: Wednesday, July 16, 2014 3:01 AM
>>> To: meta-freescale@yoctoproject.org
>>> Subject: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream
>>>
>>> Hi all,
>>>
>>> Following is the proposal for FSL QorIQ SDK upstream, comment is
>> welcome.
>>>
>>> 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) • 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
>>> • 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) • 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@freescale.com
>>>    FSL community SDK discussion, patch submit and review
>>>
>>> More to do
>>> • Setup public bug management system for FSL SDKs.
>>> • Push all modules to public git repository to ensure FSL community
>>> BSP sync with FSL released SDK.
>>> • Setup an external mailing list for external git repository for FSL
>>> SDK discussion, patch submission, patch review.
>>> • Setup an patch management tool(patchwork or gerrit) to manage
>>> patches from community.
>>> • Enhance the commit message in patch to facilitate the patch search
>>> for specific issue.
>>>
>>
>> I like your list, and I don´t remember (now) anything else to add.
>> I assume it´s a high level list, and details on how-to and what-to do is
>> for future discussion.
>>
>> However, your email highlighted a critical issue we (ARM+PPC) have. You
>> used 4 different names to call "the community source code".
>>
>> BSP - board support package [1]
>> " is a collection of information that defines how to support a particular
>> hardware device, set of devices, or hardware platform."
>>
>> It means that the current "FSL Community BSP" name is wrong. The
>> resultant code provides more that "info to define how to support HW". To
>> be very simplistic, in a BSP there is no image recipe.
>>
>> SDK - Software Development Kit [2]
>>
>> Being defined (in YP) as toolchain+sysroot+setup-env script.
>>
>> I assume meta-fsl-ppc does not provide *only* SDK. I assume it provides
>> both BSP and the tools to allow user to create the SDK.
>>
>> So, call meta-fsl-arm/extra+meta-fsl-pcc+meta-fsl-
>> demos+Documentation+fsl-community-bsp-base+fsl-community-bsp-platform
>> only as "FSL Community BSP" is not complete/right/cool.
>>
>>
>> Historically, we started to build the "FSL Community BSP" identity in
>> past one year. At first, I used to thought about it as "meta-fsl-arm"
>> (once upon a time, we cloned one by one the needed repos). Then "meta-
>> fsl-arm" became incomplete, and we created the super-set of projects that,
>> together, would form a bigger and stronger project, and we decided to
>> call it "FSL Community BSP"
>>
>> I think we can use the ARM+PCC technical union effort to start building
>> our identity as community.
>>
>> [1] http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#bsp
>> [2] http://www.yoctoproject.org/docs/current/ref-manual/ref-
>> manual.html#sdk-generation-dev-environment
>>
>>
>> Daiane

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Bob Cochran
> Sent: Wednesday, July 23, 2014 9:42 PM
> 
> On 07/23/2014 03:16 AM, zhenhua.luo@freescale.com wrote:
> > Hi Daiane,
> >
> > Thanks for your comments.
> >
> > The details on how/what-to-do needs more discussion, especially for
> documentation update, arm and ppc layer collaborate, testing, etc. Some
> works in the item lists have been done, some works are being done, some
> works are to be done.
> >
> > Regarding the name, I don't know what name is good, maybe FSL Community
> Yocto Embedded Linux, any better idea?
> 
> 
> How will QorIQ ARM specific (meta) data be organized / labeled?
[Luo Zhenhua-B19537] All targets in fsl-ppc layer are QorIQ PPC machines, the targets in fsl-arm layer with "ls" prefix is QorIQ ARM, the others are i.mx. 

>  Is it going in meta-fsl-arm?
[Luo Zhenhua-B19537] Yes. 

> Aren't there 3 different sets of data: fsl-imx-arm, fsl-qoriq-arm, and
> fsl-qori-ppc?
[Luo Zhenhua-B19537] Correct, maybe we can enhance the setup-environment script to category those targets and print them in the console when the script is executed. 


Best Regards,

Zhenhua

> Sorry if this has already been resolved, and I just didn't catch it.
> 
> 
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >
> >> -----Original Message-----
> >> From: Angolini Daiane-B19406
> >> Sent: Wednesday, July 16, 2014 8:20 PM
> >> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
> >> Subject: RE: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK
> >> upstream
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: meta-freescale-bounces@yoctoproject.org
> >>> [mailto:meta-freescale- bounces@yoctoproject.org] On Behalf Of
> >>> zhenhua.luo@freescale.com
> >>> Sent: Wednesday, July 16, 2014 3:01 AM
> >>> To: meta-freescale@yoctoproject.org
> >>> Subject: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK
> >>> upstream
> >>>
> >>> Hi all,
> >>>
> >>> Following is the proposal for FSL QorIQ SDK upstream, comment is
> >> welcome.
> >>>
> >>> 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) • 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
> >>> • 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) • 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@freescale.com
> >>>    FSL community SDK discussion, patch submit and review
> >>>
> >>> More to do
> >>> • Setup public bug management system for FSL SDKs.
> >>> • Push all modules to public git repository to ensure FSL community
> >>> BSP sync with FSL released SDK.
> >>> • Setup an external mailing list for external git repository for FSL
> >>> SDK discussion, patch submission, patch review.
> >>> • Setup an patch management tool(patchwork or gerrit) to manage
> >>> patches from community.
> >>> • Enhance the commit message in patch to facilitate the patch search
> >>> for specific issue.
> >>>
> >>
> >> I like your list, and I don´t remember (now) anything else to add.
> >> I assume it´s a high level list, and details on how-to and what-to do
> >> is for future discussion.
> >>
> >> However, your email highlighted a critical issue we (ARM+PPC) have.
> >> You used 4 different names to call "the community source code".
> >>
> >> BSP - board support package [1]
> >> " is a collection of information that defines how to support a
> >> particular hardware device, set of devices, or hardware platform."
> >>
> >> It means that the current "FSL Community BSP" name is wrong. The
> >> resultant code provides more that "info to define how to support HW".
> >> To be very simplistic, in a BSP there is no image recipe.
> >>
> >> SDK - Software Development Kit [2]
> >>
> >> Being defined (in YP) as toolchain+sysroot+setup-env script.
> >>
> >> I assume meta-fsl-ppc does not provide *only* SDK. I assume it
> >> provides both BSP and the tools to allow user to create the SDK.
> >>
> >> So, call meta-fsl-arm/extra+meta-fsl-pcc+meta-fsl-
> >> demos+Documentation+fsl-community-bsp-base+fsl-community-bsp-platform
> >> only as "FSL Community BSP" is not complete/right/cool.
> >>
> >>
> >> Historically, we started to build the "FSL Community BSP" identity in
> >> past one year. At first, I used to thought about it as "meta-fsl-arm"
> >> (once upon a time, we cloned one by one the needed repos). Then
> >> "meta- fsl-arm" became incomplete, and we created the super-set of
> >> projects that, together, would form a bigger and stronger project,
> >> and we decided to call it "FSL Community BSP"
> >>
> >> I think we can use the ARM+PCC technical union effort to start
> >> building our identity as community.
> >>
> >> [1]
> >> http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#bsp
> >> [2] http://www.yoctoproject.org/docs/current/ref-manual/ref-
> >> manual.html#sdk-generation-dev-environment
> >>
> >>
> >> Daiane
> 
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 07/23/2014 03:41 AM, zhenhua.luo@freescale.com wrote:
> Hi Bob,
>
>> -----Original Message-----
>> From: Bob Cochran [mailto:yocto@mindchasers.com]
>> Sent: Thursday, July 17, 2014 4:50 AM
>>
>> On 07/16/2014 08:20 AM, Daiane.Angolini@freescale.com wrote:
>>>
>>>> -----Original Message-----
>>>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>>>> bounces@yoctoproject.org] On Behalf Of zhenhua.luo@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@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
>

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Friday, July 25, 2014 2:08 AM
> To: Luo Zhenhua-B19537
> 
> On 07/23/2014 03:41 AM, zhenhua.luo@freescale.com wrote:
> > Hi Bob,
> >
> >> -----Original Message-----
> >> From: Bob Cochran [mailto:yocto@mindchasers.com]
> >> Sent: Thursday, July 17, 2014 4:50 AM
> >>
> >> On 07/16/2014 08:20 AM, Daiane.Angolini@freescale.com wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: meta-freescale-bounces@yoctoproject.org
> >>>> [mailto:meta-freescale- bounces@yoctoproject.org] On Behalf Of
> >>>> zhenhua.luo@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.
[Luo Zhenhua-B19537] Due to the release time gap of Yocto(Apri/Oct) and QorIQ SDK(Jun/Dec), so QorIQ SDK 1.6(2014-Jun) content will be in Yocto 1.7(2014-Oct), the QorIQ SDK 1.7(2014-Dec) content will be included in Yocto 1.8(2015-Apr). 


Best Regards,

Zhenhua

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

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Ahsan, Noor]

I noticed that in SDK 1.6 3.12 kernel was used. It will be the same in SDK 1.7?

Noor

-----Original Message-----
From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-bounces@yoctoproject.org] On Behalf Of zhenhua.luo@freescale.com
Sent: Tuesday, July 29, 2014 2:57 PM
To: Bob Cochran
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Friday, July 25, 2014 2:08 AM
> To: Luo Zhenhua-B19537
> 
> On 07/23/2014 03:41 AM, zhenhua.luo@freescale.com wrote:
> > Hi Bob,
> >
> >> -----Original Message-----
> >> From: Bob Cochran [mailto:yocto@mindchasers.com]
> >> Sent: Thursday, July 17, 2014 4:50 AM
> >>
> >> On 07/16/2014 08:20 AM, Daiane.Angolini@freescale.com wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: meta-freescale-bounces@yoctoproject.org
> >>>> [mailto:meta-freescale- bounces@yoctoproject.org] On Behalf Of 
> >>>> zhenhua.luo@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.
[Luo Zhenhua-B19537] Due to the release time gap of Yocto(Apri/Oct) and QorIQ SDK(Jun/Dec), so QorIQ SDK 1.6(2014-Jun) content will be in Yocto 1.7(2014-Oct), the QorIQ SDK 1.7(2014-Dec) content will be included in Yocto 1.8(2015-Apr). 


Best Regards,

Zhenhua

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

--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

Yes. 

> -----Original Message-----
> From: Ahsan, Noor [mailto:Noor_Ahsan@mentor.com]
> Sent: Wednesday, August 20, 2014 8:28 PM
> To: Luo Zhenhua-B19537; Bob Cochran
> Cc: meta-freescale@yoctoproject.org
> Subject: RE: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK
> upstream
> 
> I noticed that in SDK 1.6 3.12 kernel was used. It will be the same in
> SDK 1.7?
> 
> Noor
> 
> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of zhenhua.luo@freescale.com
> Sent: Tuesday, July 29, 2014 2:57 PM
> To: Bob Cochran
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK
> upstream
> 
> > -----Original Message-----
> > From: Bob Cochran [mailto:yocto@mindchasers.com]
> > Sent: Friday, July 25, 2014 2:08 AM
> > To: Luo Zhenhua-B19537
> >
> > On 07/23/2014 03:41 AM, zhenhua.luo@freescale.com wrote:
> > > Hi Bob,
> > >
> > >> -----Original Message-----
> > >> From: Bob Cochran [mailto:yocto@mindchasers.com]
> > >> Sent: Thursday, July 17, 2014 4:50 AM
> > >>
> > >> On 07/16/2014 08:20 AM, Daiane.Angolini@freescale.com wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: meta-freescale-bounces@yoctoproject.org
> > >>>> [mailto:meta-freescale- bounces@yoctoproject.org] On Behalf Of
> > >>>> zhenhua.luo@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.
> [Luo Zhenhua-B19537] Due to the release time gap of Yocto(Apri/Oct) and
> QorIQ SDK(Jun/Dec), so QorIQ SDK 1.6(2014-Jun) content will be in Yocto
> 1.7(2014-Oct), the QorIQ SDK 1.7(2014-Dec) content will be included in
> Yocto 1.8(2015-Apr).
> 
> 
> Best Regards,
> 
> Zhenhua
> 
> > >> • 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@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
> > >
> 
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: 9/8 community meeting, was [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:
> Hi all,
>
> Following is the proposal for FSL QorIQ SDK upstream, comment is welcome.

[snip]

>
> More to do
> • Setup public bug management system for FSL SDKs.
> • Push all modules to public git repository to ensure FSL community BSP sync with FSL released SDK.
> • Setup an external mailing list for external git repository for FSL SDK discussion, patch submission, patch review.
> • Setup an patch management tool(patchwork or gerrit) to manage patches from community.
> • Enhance the commit message in patch to facilitate the patch search for specific issue.


Can we get an update on the items listed above during tomorrow's 
community meeting (or soon afterwards)?

Also, I had previously asked about creating a branch on meta-fsl-ppc 
that could be used to track patches / improvements for SDK1.6 in 
addition to master, which I think is basically being used to set up 1.7.

I need to start getting after some bugs on SDK1.6 related to various 
kernel oops that pop up inconsistently.  I would love to see an 
infrastructure in place to help with this.

Thanks,

Bob






>
>
> Best Regards,
>
> Zhenhua
>

Re: 9/8 community meeting, was [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

Bob, 

Please see my inline comments. 

> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Bob Cochran
> Sent: Monday, September 08, 2014 9:05 AM
> 
> On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:
> >
> > More to do
> > • Setup public bug management system for FSL SDKs.
> > • Push all modules to public git repository to ensure FSL community BSP
> sync with FSL released SDK.
> > • Setup an external mailing list for external git repository for FSL
> SDK discussion, patch submission, patch review.
> > • Setup an patch management tool(patchwork or gerrit) to manage patches
> from community.
> > • Enhance the commit message in patch to facilitate the patch search
> for specific issue.
> 
> Can we get an update on the items listed above during tomorrow's
> community meeting (or soon afterwards)?
[Luo Zhenhua-B19537] Those items are being worked on, I will send an separated email when the infrastructure is available. 

> Also, I had previously asked about creating a branch on meta-fsl-ppc that
> could be used to track patches / improvements for SDK1.6 in addition to
> master, which I think is basically being used to set up 1.7.
[Luo Zhenhua-B19537] Why can't those fixes be submitted to master directly? 

> I need to start getting after some bugs on SDK1.6 related to various
> kernel oops that pop up inconsistently.  I would love to see an
> infrastructure in place to help with this.
[Luo Zhenhua-B19537] Can you please summarize the defects of SDK 1.6 and post by email before infrastructure readiness? 


Best Regards,

Zhenhua

> Thanks,
> 
> Bob
> 
> 
> 
> 
> 
> 
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> 
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: 9/8 community meeting, was [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 09/09/2014 09:28 AM, zhenhua.luo@freescale.com wrote:
> Bob,
>
> Please see my inline comments.
>
>> -----Original Message-----
>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>> bounces@yoctoproject.org] On Behalf Of Bob Cochran
>> Sent: Monday, September 08, 2014 9:05 AM
>>
>> On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:
>>>
>>> More to do
>>> • Setup public bug management system for FSL SDKs.
>>> • Push all modules to public git repository to ensure FSL community BSP
>> sync with FSL released SDK.
>>> • Setup an external mailing list for external git repository for FSL
>> SDK discussion, patch submission, patch review.
>>> • Setup an patch management tool(patchwork or gerrit) to manage patches
>> from community.
>>> • Enhance the commit message in patch to facilitate the patch search
>> for specific issue.
>>
>> Can we get an update on the items listed above during tomorrow's
>> community meeting (or soon afterwards)?
> [Luo Zhenhua-B19537] Those items are being worked on, I will send an separated email when the infrastructure is available.
>
>> Also, I had previously asked about creating a branch on meta-fsl-ppc that
>> could be used to track patches / improvements for SDK1.6 in addition to
>> master, which I think is basically being used to set up 1.7.
> [Luo Zhenhua-B19537] Why can't those fixes be submitted to master directly?

Hi Zhenhua,

Thank you for the reply.

A master branch and some documentation is great for getting a board up & 
running, but I don't think it is sufficient for putting together a 
stable code base (snap shot) and then working out the defects.

I have been assuming that each FSL SDK release is a starting point for a 
product code base, and I am hoping that the FSL Community becomes the 
venue where each SDK (perhaps mirrored as a particular meta-fsl-ppc 
branch) can be tested and improved to the point that it is stable & 
product worthy for various customer targets.

If all patches, upgrades, and new code goes to the same (meta-fsl-ppc) 
master branch, then the line is blurred between improving the last SDK 
and setting up the next, which isn't necessarily more stable than the 
previous one.

Along the same line, I ask that the community works together to develop 
a statement on a process for using the code available in the community 
repos to develop, test, and release a product.  I hope you and others 
believe this is an attainable and worthy goal.  I would hope that a 
single process could eventually apply to both QorIQ and i.MX.

>
>> I need to start getting after some bugs on SDK1.6 related to various
>> kernel oops that pop up inconsistently.  I would love to see an
>> infrastructure in place to help with this.
> [Luo Zhenhua-B19537] Can you please summarize the defects of SDK 1.6 and post by email before infrastructure readiness?


Regarding a defect list, I'm going to start investigating a couple of 
them tomorrow.  As typical, the problems I see are inconsistent.  The 
two I'm going to try to recreate and document are i) kernel oops during 
user space init during; ii) kernel oops during nfs nework copy (of 
rootfs onto an SSD).  I hope to have some useful defect facts by next 
week.

During the 9/8 community call, I was asked to enter a bug report in 
yocto bugzilla as a test case.  Are you OK with me entering a new 
bugzilla item?

Thanks,

Bob










>
>
> Best Regards,
>
> Zhenhua
>
>> Thanks,
>>
>> Bob
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> Best Regards,
>>>
>>> Zhenhua
>>>
>>
>> --
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: 9/8 community meeting, was [RFC] The proposal of FSL QorIQ SDK upstream

[zhenhua.luo]

Hi Bob, 

The QorIQ SDK always bases on the stable Yocto release, e.g. SDK 1.6 uses Yocto 1.6(daisy), besides upstream all SDK recipes in master to ensure those content is included in the upcoming Yocto release(Yocto 1.7),  the SDK 1.6 release bits should also be upstreamed to Yocto 1.6(daisy), so the fixes for SDK 1.6 can be submitted against daisy branch, does this sound good for you? 

With regard to the bugs of QorIQ SDK, you can submit in Yocto Bugzilla until the FSL public bug report system is ready. 


Best Regards,

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Thursday, September 11, 2014 11:46 PM
> To: Luo Zhenhua-B19537
> Cc: meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] 9/8 community meeting, was [RFC] The proposal
> of FSL QorIQ SDK upstream
> 
> On 09/09/2014 09:28 AM, zhenhua.luo@freescale.com wrote:
> > Bob,
> >
> > Please see my inline comments.
> >
> >> -----Original Message-----
> >> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> >> bounces@yoctoproject.org] On Behalf Of Bob Cochran
> >> Sent: Monday, September 08, 2014 9:05 AM
> >>
> >> On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:
> >>>
> >>> More to do
> >>> • Setup public bug management system for FSL SDKs.
> >>> • Push all modules to public git repository to ensure FSL community
> >>> BSP
> >> sync with FSL released SDK.
> >>> • Setup an external mailing list for external git repository for FSL
> >> SDK discussion, patch submission, patch review.
> >>> • Setup an patch management tool(patchwork or gerrit) to manage
> >>> patches
> >> from community.
> >>> • Enhance the commit message in patch to facilitate the patch search
> >> for specific issue.
> >>
> >> Can we get an update on the items listed above during tomorrow's
> >> community meeting (or soon afterwards)?
> > [Luo Zhenhua-B19537] Those items are being worked on, I will send an
> separated email when the infrastructure is available.
> >
> >> Also, I had previously asked about creating a branch on meta-fsl-ppc
> >> that could be used to track patches / improvements for SDK1.6 in
> >> addition to master, which I think is basically being used to set up 1.7.
> > [Luo Zhenhua-B19537] Why can't those fixes be submitted to master directly?
> 
> Hi Zhenhua,
> 
> Thank you for the reply.
> 
> A master branch and some documentation is great for getting a board up &
> running, but I don't think it is sufficient for putting together a stable code base
> (snap shot) and then working out the defects.
> 
> I have been assuming that each FSL SDK release is a starting point for a product
> code base, and I am hoping that the FSL Community becomes the venue where
> each SDK (perhaps mirrored as a particular meta-fsl-ppc
> branch) can be tested and improved to the point that it is stable & product
> worthy for various customer targets.
> 
> If all patches, upgrades, and new code goes to the same (meta-fsl-ppc) master
> branch, then the line is blurred between improving the last SDK and setting up
> the next, which isn't necessarily more stable than the previous one.
> 
> Along the same line, I ask that the community works together to develop a
> statement on a process for using the code available in the community repos to
> develop, test, and release a product.  I hope you and others believe this is an
> attainable and worthy goal.  I would hope that a single process could eventually
> apply to both QorIQ and i.MX.
> 
> >
> >> I need to start getting after some bugs on SDK1.6 related to various
> >> kernel oops that pop up inconsistently.  I would love to see an
> >> infrastructure in place to help with this.
> > [Luo Zhenhua-B19537] Can you please summarize the defects of SDK 1.6 and
> post by email before infrastructure readiness?
> 
> 
> Regarding a defect list, I'm going to start investigating a couple of them
> tomorrow.  As typical, the problems I see are inconsistent.  The two I'm going
> to try to recreate and document are i) kernel oops during user space init during;
> ii) kernel oops during nfs nework copy (of rootfs onto an SSD).  I hope to have
> some useful defect facts by next week.
> 
> During the 9/8 community call, I was asked to enter a bug report in yocto
> bugzilla as a test case.  Are you OK with me entering a new bugzilla item?
> 
> Thanks,
> 
> Bob
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >> Thanks,
> >>
> >> Bob
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> Zhenhua
> >>>
> >>
> >> --
> >> _______________________________________________
> >> meta-freescale mailing list
> >> meta-freescale@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: 9/8 community meeting, was [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 09/17/2014 01:31 AM, zhenhua.luo@freescale.com wrote:
> Hi Bob,
>
> The QorIQ SDK always bases on the stable Yocto release, e.g. SDK 1.6 uses Yocto 1.6(daisy), besides upstream all SDK recipes in master to ensure those content is included in the upcoming Yocto release(Yocto 1.7),  the SDK 1.6 release bits should also be upstreamed to Yocto 1.6(daisy), so the fixes for SDK 1.6 can be submitted against daisy branch, does this sound good for you?

Thank you for the reply Zhenhua.  I'll wait to comment further on this 
until additional pieces of the infrastructure are in place and others 
join in commenting on the community process as it applies to QorIQ devices.


>
> With regard to the bugs of QorIQ SDK, you can submit in Yocto Bugzilla until the FSL public bug report system is ready.


I'm working heavily with the T1040 with the meta-fsl-ppc master branch 
on a daily basis.  The biggest concern at this point is that a core will 
occasionally hang or oops during heavy network loading.  I'm digging 
into this, but I first need to better understand the DPAA driver code. 
You'll probably see some questions and maybe a few bug reports in the 
next couple of weeks related to the DPAA (e.g, I sent out a question 
last night about the T4240 errata being applied to the T1040, which I 
believe is a bug).

Thanks again,

Bob





>
>
> Best Regards,
>
> Zhenhua
>
>> -----Original Message-----
>> From: Bob Cochran [mailto:yocto@mindchasers.com]
>> Sent: Thursday, September 11, 2014 11:46 PM
>> To: Luo Zhenhua-B19537
>> Cc: meta-freescale@yoctoproject.org
>> Subject: Re: [meta-freescale] 9/8 community meeting, was [RFC] The proposal
>> of FSL QorIQ SDK upstream
>>
>> On 09/09/2014 09:28 AM, zhenhua.luo@freescale.com wrote:
>>> Bob,
>>>
>>> Please see my inline comments.
>>>
>>>> -----Original Message-----
>>>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>>>> bounces@yoctoproject.org] On Behalf Of Bob Cochran
>>>> Sent: Monday, September 08, 2014 9:05 AM
>>>>
>>>> On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:
>>>>>
>>>>> More to do
>>>>> • Setup public bug management system for FSL SDKs.
>>>>> • Push all modules to public git repository to ensure FSL community
>>>>> BSP
>>>> sync with FSL released SDK.
>>>>> • Setup an external mailing list for external git repository for FSL
>>>> SDK discussion, patch submission, patch review.
>>>>> • Setup an patch management tool(patchwork or gerrit) to manage
>>>>> patches
>>>> from community.
>>>>> • Enhance the commit message in patch to facilitate the patch search
>>>> for specific issue.
>>>>
>>>> Can we get an update on the items listed above during tomorrow's
>>>> community meeting (or soon afterwards)?
>>> [Luo Zhenhua-B19537] Those items are being worked on, I will send an
>> separated email when the infrastructure is available.
>>>
>>>> Also, I had previously asked about creating a branch on meta-fsl-ppc
>>>> that could be used to track patches / improvements for SDK1.6 in
>>>> addition to master, which I think is basically being used to set up 1.7.
>>> [Luo Zhenhua-B19537] Why can't those fixes be submitted to master directly?
>>
>> Hi Zhenhua,
>>
>> Thank you for the reply.
>>
>> A master branch and some documentation is great for getting a board up &
>> running, but I don't think it is sufficient for putting together a stable code base
>> (snap shot) and then working out the defects.
>>
>> I have been assuming that each FSL SDK release is a starting point for a product
>> code base, and I am hoping that the FSL Community becomes the venue where
>> each SDK (perhaps mirrored as a particular meta-fsl-ppc
>> branch) can be tested and improved to the point that it is stable & product
>> worthy for various customer targets.
>>
>> If all patches, upgrades, and new code goes to the same (meta-fsl-ppc) master
>> branch, then the line is blurred between improving the last SDK and setting up
>> the next, which isn't necessarily more stable than the previous one.
>>
>> Along the same line, I ask that the community works together to develop a
>> statement on a process for using the code available in the community repos to
>> develop, test, and release a product.  I hope you and others believe this is an
>> attainable and worthy goal.  I would hope that a single process could eventually
>> apply to both QorIQ and i.MX.
>>
>>>
>>>> I need to start getting after some bugs on SDK1.6 related to various
>>>> kernel oops that pop up inconsistently.  I would love to see an
>>>> infrastructure in place to help with this.
>>> [Luo Zhenhua-B19537] Can you please summarize the defects of SDK 1.6 and
>> post by email before infrastructure readiness?
>>
>>
>> Regarding a defect list, I'm going to start investigating a couple of them
>> tomorrow.  As typical, the problems I see are inconsistent.  The two I'm going
>> to try to recreate and document are i) kernel oops during user space init during;
>> ii) kernel oops during nfs nework copy (of rootfs onto an SSD).  I hope to have
>> some useful defect facts by next week.
>>
>> During the 9/8 community call, I was asked to enter a bug report in yocto
>> bugzilla as a test case.  Are you OK with me entering a new bugzilla item?
>>
>> Thanks,
>>
>> Bob
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> Best Regards,
>>>
>>> Zhenhua
>>>
>>>> Thanks,
>>>>
>>>> Bob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Zhenhua
>>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> meta-freescale mailing list
>>>> meta-freescale@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:

> More to do
> • Setup public bug management system for FSL SDKs.
> • Push all modules to public git repository to ensure FSL community BSP sync with FSL released SDK.
> • Setup an external mailing list for external git repository for FSL SDK discussion, patch submission, patch review.
> • Setup an patch management tool(patchwork or gerrit) to manage patches from community.
> • Enhance the commit message in patch to facilitate the patch search for specific issue.


Hi Zhenhua,

Can you please update us on the status of these work items?  As far as I 
know things like public bug management for FSL SDKs and an external mail 
list for the FSL external git repo haven't happened, but I could have 
just missed it.

I have to believe that between the FSL SDK 1.7 release data (12/18/14) 
and now, there have been numerous bugs identified in the QorIQ SDK that 
weren't reported on this yocto mail list or pushed to the meta-fsl-ppc 
repo as patches to the code hosted on the FSL git site.  Assuming this 
is true, will this be addressed in the (near) future?

Thank you,

Bob

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Luo Zhenhua]

Hi Bob, 

The external bug report system and maillist are not setup now. 

The QorIQ SDK 1.8 release is planned in this June, the recipes will be upstreamed in meta-fsl-ppc layer in July. 


Best Regards, 

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Thursday, May 14, 2015 9:27 AM
> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
> Subject: Re: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream
> 
> On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:
> 
> > More to do
> > • Setup public bug management system for FSL SDKs.
> > • Push all modules to public git repository to ensure FSL community BSP sync
> with FSL released SDK.
> > • Setup an external mailing list for external git repository for FSL SDK
> discussion, patch submission, patch review.
> > • Setup an patch management tool(patchwork or gerrit) to manage patches
> from community.
> > • Enhance the commit message in patch to facilitate the patch search for
> specific issue.
> 
> 
> Hi Zhenhua,
> 
> Can you please update us on the status of these work items?  As far as I know
> things like public bug management for FSL SDKs and an external mail list for the
> FSL external git repo haven't happened, but I could have just missed it.
> 
> I have to believe that between the FSL SDK 1.7 release data (12/18/14) and
> now, there have been numerous bugs identified in the QorIQ SDK that weren't
> reported on this yocto mail list or pushed to the meta-fsl-ppc repo as patches
> to the code hosted on the FSL git site.  Assuming this is true, will this be
> addressed in the (near) future?
> 
> Thank you,
> 
> Bob
> 
> 
> 
> 

Re: [RFC] The proposal of FSL QorIQ SDK upstream

[Bob Cochran]

On 05/20/2015 04:14 AM, Luo Zhenhua wrote:
> Hi Bob,
>
> The external bug report system and maillist are not setup now.


Is Freescale still planning on doing this? If so, please provide an idea 
when we might see it.


>
> The QorIQ SDK 1.8 release is planned in this June, the recipes will be upstreamed in meta-fsl-ppc layer in July.
>
>
> Best Regards,
>
> Zhenhua
>
>> -----Original Message-----
>> From: Bob Cochran [mailto:yocto@mindchasers.com]
>> Sent: Thursday, May 14, 2015 9:27 AM
>> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
>> Subject: Re: [meta-freescale] [RFC] The proposal of FSL QorIQ SDK upstream
>>
>> On 07/16/2014 02:00 AM, zhenhua.luo@freescale.com wrote:
>>
>>> More to do
>>> • Setup public bug management system for FSL SDKs.
>>> • Push all modules to public git repository to ensure FSL community BSP sync
>> with FSL released SDK.
>>> • Setup an external mailing list for external git repository for FSL SDK
>> discussion, patch submission, patch review.
>>> • Setup an patch management tool(patchwork or gerrit) to manage patches
>> from community.
>>> • Enhance the commit message in patch to facilitate the patch search for
>> specific issue.
>>
>>
>> Hi Zhenhua,
>>
>> Can you please update us on the status of these work items?  As far as I know
>> things like public bug management for FSL SDKs and an external mail list for the
>> FSL external git repo haven't happened, but I could have just missed it.
>>
>> I have to believe that between the FSL SDK 1.7 release data (12/18/14) and
>> now, there have been numerous bugs identified in the QorIQ SDK that weren't
>> reported on this yocto mail list or pushed to the meta-fsl-ppc repo as patches
>> to the code hosted on the FSL git site.  Assuming this is true, will this be
>> addressed in the (near) future?
>>
>> Thank you,
>>
>> Bob
>>
>>
>>
>>
>