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

Thu, 18 Sep 2014 16:56:22 -0700 

On 09/17/2014 01:31 AM, [email protected] 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:[email protected]]
Sent: Thursday, September 11, 2014 11:46 PM
To: Luo Zhenhua-B19537
Cc: [email protected]
Subject: Re: [meta-freescale] 9/8 community meeting, was [RFC] The proposal
of FSL QorIQ SDK upstream

On 09/09/2014 09:28 AM, [email protected] wrote:

Bob,

Please see my inline comments.


-----Original Message-----
From: [email protected] [mailto:meta-freescale-
[email protected]] On Behalf Of Bob Cochran
Sent: Monday, September 08, 2014 9:05 AM

On 07/16/2014 02:00 AM, [email protected] 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
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale




--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale

Reply via email to