From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ptmx.org (ptmx.org [178.63.28.110]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 42835E0079B for ; Mon, 20 Jan 2014 06:41:12 -0800 (PST) Received: from [10.1.14.248] (83-64-248-68.inzersdorf.xdsl-line.inode.at [83.64.248.68]) by ptmx.org (Postfix) with ESMTPSA id D90A2225D5; Mon, 20 Jan 2014 15:41:10 +0100 (CET) Message-ID: <52DD3586.8090103@pseudoterminal.org> Date: Mon, 20 Jan 2014 15:41:10 +0100 From: Carlos Rafael Giani User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Daiane Angolini , "meta-freescale@yoctoproject.org" References: <52DCF67C.6030503@pseudoterminal.org> <52DD2EB0.5030208@freescale.com> In-Reply-To: <52DD2EB0.5030208@freescale.com> Subject: Re: About customizing the image_types_fsl class 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: Mon, 20 Jan 2014 14:41:14 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2014-01-20 15:12, Daiane Angolini wrote: > I think the question here is how "standard" will SPL be for imx. How > many boards has already SPL support *now*? > > I think it's something we need to start including, because it's the > next standard, however, we must make both working in parallel (spl and > non-spl). > > And, I would say, it's better to include the additional source code > for SPL support directly to image_types_fsl instead of derivative it > only on meta-fsl-arm-extra True. If more boards start using SPL, then it should become part of the image_types_fsl class. Also, a flag to disable writing the uImage outside of the partitions would also be useful (but not essential). > > Overall I choose u-boot mainline always. It is our default bootloader, > at least in general lines. > > The u-boot mainline hummingboard stability can be known with simple > test. And any additional support may be included. It's only a matter > of planing. > > 2014.01 is about to be released, and u-boot-fslc is about to be update > to that version. And we may thing about backport any accepted patch to > 2014.01 if it's planned only to 2014.04. > > Conclusion: I think the best is u-boot mainline, even if it need some > rework, it's the best long-term option, in my point of view. This means I should wait until 2014.01 is released and added to oe-core before I submit my cubox-i patches for meta-fsl-arm-extra ?