On 07/16/2014 08:20 AM, [email protected] wrote:
-----Original Message-----
From: [email protected] [mailto:meta-freescale-
[email protected]] On Behalf Of [email protected]
Sent: Wednesday, July 16, 2014 3:01 AM
To: [email protected]
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
[email protected]
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
--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
