From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A6301E0161E for ; Wed, 2 Oct 2013 09:28:48 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so1101746pbb.34 for ; Wed, 02 Oct 2013 09:28:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CB6ALW12VB4OAp++7s0s1S3LoStphG8wFnhaS3X/DQI=; b=mN3Y3SXzzOlxy2rnPLAqTOU0IkTeI899xTkyP85szfroL1/9AF/ESQr+JHLjE5HCjN UXv6SCXFURS8c1Rle54kuHx6Ueuvawoi3yUvzNZSKsWKlbDQ0833I+zjpdqdJjxtg0fv XEuaEMF3RjHm+Smf7Xu973ZC/jra/xVSj4V8iIMTJb5UdKGvfv7bZlJyhz69zU0YxCNf ZziIq3DgbGdBpbi1LYVF3WM/ZxnzJD/sW6uQgPb0+JJj50kzX2JrRw5+IufJUL08/XpN 1Si2RHtkagKEF6lZIBNXZS3zVhKrSsZwXqpuZreDKhjzSuqrGhl/Cbe9yjr8V/hDzg/M sDzA== X-Gm-Message-State: ALoCoQlwyR5fY3UvOMkLlf2f78U5Kt68JCytJOyxcTwvX9RWS71ju0rslEKxp2P6qNiq8SiRXyOL X-Received: by 10.66.65.108 with SMTP id w12mr3301851pas.183.1380731328276; Wed, 02 Oct 2013 09:28:48 -0700 (PDT) Received: from [192.168.0.15] ([70.96.116.236]) by mx.google.com with ESMTPSA id fy4sm2913848pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 09:28:47 -0700 (PDT) Message-ID: <524C49BD.3090602@boundarydevices.com> Date: Wed, 02 Oct 2013 09:28:45 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Otavio Salvador References: <2BC32295742BF14CA5950C3659567EB677A2ED@039-SN1MPN1-003.039d.mgd.msft.net> <1412123.FJqSlycNOL@localhost.localdomain> <524C2625.2000109@freescale.com> <524C330B.4020404@boundarydevices.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" , Diego Subject: Re: Request to integrate freescale i.mx 3.10.9-1.0.0 alpha release into dora branch of meta-fsl-arm X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:28:49 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks Otavio, On 10/02/2013 08:11 AM, Otavio Salvador wrote: > On Wed, Oct 2, 2013 at 11:51 AM, Eric Nelson > wrote: >> On 10/02/2013 06:56 AM, Daiane Angolini wrote: >>> >>> On 10/02/2013 10:55 AM, Otavio Salvador wrote: >>>> >>>> On Wed, Oct 2, 2013 at 10:06 AM, Diego wrote: >>>>>> >>>>>> Otavio requested for the community to approve this change since the >>>>>> dora >>>>>> branch is being finalized in next 2 weeks. I'll be upstreaming >>>>>> patches to >>>>>> master-next this week so they can be tested by end of the week. Please >>>>>> reply to this email if you have a concern with integrating 3.10.9-1.0.0 >>>>>> into the dora branch. >>>>> >>>>> >>>>> Hi Lauren. >>>>> >>>>> I think there's no objection for merge if that won't be the default. >>>>> >>>>> What would be the kernel state for dora then? >>>>> - 3.0.35 with Vivante 4.6.9p12 patches as default >>>>> - 3.5.7 alpha2 as an option >>>>> - 3.10.9 alpha as an option >>>>> >>>>> Is that what you were thinking? >>>> >>>> I'd prefer to replace 3.5.7 with 3.10.9. >>> >>> +1 >> >> -1 (comments below) >> >>>> >>>> When 3.10.9 turns GA we may make it default or not. 3.0.35 needs to be >>>> kept around due backward support. >>> >>> Do not forget that 3.10.9-1.0.0 is not only kernel. It's all BSP packages >>> >> Thanks for pointing this out. I had assumed backward-compatibility with >> 3.5.7/3.0.35_4.1.0 packages. >> >> Patches haven't yet been submitted for the other bits, have they? >> >> It would be really nice if this update came with a bit more commentary >> about ABI and functional compatibility rather than a single patch >> submission and a new branch magically appearing on git.freescale.com. > > +1 > >> I'd really like to see Dora become a stable platform for those wanting >> to test the full functionality of their boards. We never really had >> that for kernel versions 3.0.35_4.0.0, and only have that for >> 3.0.35_4.1.0 on Dora. > > +1 > >> If there isn't some form of PREFERRED_VERSION_ support for 3.0.35_4.1.0 >> that allows a stable, fully-functional build, I think that 3.10.9 should >> be pushed into either "master" or a "next" branch. > > Yes; the idea is to keep 3.0.35-4.1.0 as default until 3.10.9 turns > GA. After that I think we ought to support 3.0.35-4.1.0 for Dora along > with 3.10.9-1.0.0 (be it default or not) and for 1.6 plan to drop > 3.0.35-4.1.0. > That's a relief! I was very happy to see that things "just worked" with the latest kernel with the Dora release and twitched a bit when I thought a 3.10 upgrade was going to break things. BTW, thanks for all your efforts getting Dora ready for prime-time! >> What's more, I think it's very important for different boards to be >> able to specify which kernel version is recommended for each, since >> the efforts behind them progress along different time-lines. > > Yes; this can be done. We does it already and Bondary's boards also > use a different kernel. > Kernel, yes. But at the moment, there's no way for a board/kernel to select the revision of binaries, right? https://github.com/Freescale/meta-fsl-arm/blob/dora/recipes-multimedia/libfslvpuwrap/libfslvpuwrap_1.0.38.bb Or can we, for instance, have two recipes for the components, e.g. gpu-viv-bin-mx6q_3.5.7-1.0.0-alpha.2-hfp.bb gpu-viv-bin-mx6q_3.10.9-1.0.0-alpha-hfp.bb and express PREFERRED_VERSION_gpu-viv-bin-mx6q=3.5.7-1.0.0-alpha.2 in the linux-boundary_3.0.35.bb recipe and then set PREFERRED_VERSION_gpu-viv-bin-mx6q=3.10.9-1.0.0-alpha.2 in a linux-boundary_3.10.9.bb recipe? If this is possible, then I retract my nack and the only concern is that the patches for gstreamer/vpu/imx-lib/GPU are still missing for 3.10.9. >> If we don't have the structure to support this, each board vendor >> will (and should) probably plan on forking meta-freescale for their >> own efforts, which would be a shame. > > Please don't. Or it will turn to be LTIB 2.0 :P > I don't want to go there! Regards, Eric