From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 46F3DE007B9; Fri, 10 Oct 2014 07:05:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.220.45 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 1AB02E00781 for ; Fri, 10 Oct 2014 07:04:54 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so1802235pab.32 for ; Fri, 10 Oct 2014 07:04:54 -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=WPAh6SFtyQz774PALUS79a0dPL1VB47Y8z7RrxtTOYM=; b=ZJ79LCOl3o3EAUrDUbDfMiAYiw9tkdNPMNESpW4auR8XRZsBbvvCCyW42Xc2yiSwd1 ynYeeIlgH+HIrWO0has5Vx/PObx+NJmFiz4BvvLuCK7Db2UGtwZVNqj04PiQ+sKjmUQ8 oYoAR6Ts/oQQnRaGp9br3lPdnqkk2+uq+8rm88lExvbs6Vu3WZwhcGk95Pqei2rPfind /B6lNnWX757GX9R00IGgeObjAodgJS2LOO5kxU/zsS8z0slA6tgLjqRpIkialAkaQL1+ 4vrNlV4TUlRIJ63v7yBs3MdQ1c1swygglrdo8cvgogNvzP3xDMTdbA4roP8TMLY1pzSH tlBg== X-Gm-Message-State: ALoCoQmm+6eZi6auKmmTbkPnvt2reRs1Iai9c7k6mMj7mgTEF7pO5tSjnVUaxYYKw8W1t98ENA8e X-Received: by 10.66.188.4 with SMTP id fw4mr5483795pac.67.1412949893988; Fri, 10 Oct 2014 07:04:53 -0700 (PDT) Received: from [192.168.1.7] (ip98-165-98-97.ph.ph.cox.net. [98.165.98.97]) by mx.google.com with ESMTPSA id z13sm3555235pbt.74.2014.10.10.07.04.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Oct 2014 07:04:52 -0700 (PDT) Message-ID: <5437E781.4030704@boundarydevices.com> Date: Fri, 10 Oct 2014 07:04:49 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Otavio Salvador References: <543721BA.9080804@boundarydevices.com> <54373A1C.2070701@boundarydevices.com> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" , Troy Subject: Re: Kernel 3.10.31 and SD card numbering and boot scripts 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: Fri, 10 Oct 2014 14:05:00 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Otavio, On 10/10/2014 05:23 AM, Otavio Salvador wrote: > On Thu, Oct 9, 2014 at 10:45 PM, Eric Nelson > wrote: >> Thanks for the feedback Otavio, >> >> On 10/09/2014 06:18 PM, Otavio Salvador wrote: >>> On Thu, Oct 9, 2014 at 9:00 PM, Eric Nelson >>> wrote: >>>> The 3.10.31 kernel contains a nifty bit of code from Sascha Hauer >>>> that addresses the question of SD card numbering (device naming) >>>> quite well: >>>> >>>> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/drivers/mmc/card/block.c?h=imx_3.10.31_1.1.0_beta&id=5f9447e5d97060207c4742d5a06e5548de45972d >>>> https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg26472.html >>>> >>>> Unfortunately, it also changes the requirements for the kernel >>>> command-line and breaks our boot scripts. >>> >>> Yes. >>> >>>> This is probably a good time to ask a related question about >>>> where we're keeping boot scripts. >>>> >>>> We have been compiling boot scripts out of our U-Boot tree >>>> from a Yocto-specific "6x_bootscript-yocto.txt" that implements >>>> the conventions of the Freescale Community BSP (kernel in >>>> the root of partition 1 and rootfs in partition 2). >>>> >>>> Since boot scripts have dependencies on a lot of things, it's >>>> not clear to me that they belong in the U-Boot source treet >>>> and that a Yocto-specific boot script really belongs directly >>>> in the Yocto tree somewhere. >>>> >>>> Since a Yocto build knows about the PREFERRED_VERSION of the >>>> kernel, it would be straightforward to have multiple versions >>>> of a boot script. >>>> >>>> Otherwise, we'd need to place a couple of versions in the >>>> U-Boot tree: >>>> 6x_bootscript-yocto.txt >>>> 6x_bootscript-yocto-after-3.10.17.txt >>>> and we'd also need some logic in u-boot-script-boundary.bb >>>> to choose between them. >>>> >>>> Before crafting a patch to do this, I'd like to get some feedback. >>> >>> It is harder than it seems to be. The providing system does not track >>> versions so you'd need to do some "uglyness" to make this work. >>> >> >> I haven't tried, but it seems generally useful to allow >> conditionals based on kernel versions in Yocto/OE and I'm >> surprised that there isn't a stock way of doing this. > > It would be indeed however there are some complexities as package feed > upgrade path and other details which makes this very complex. > > As I said, I think this is technically possible to be done but will > require some 'hacks'. > >>> Personally I think it is easier to address this on the bootscript >>> itself using the setexpr command in U-Boot and with the REGEX config >>> enabled. So you could try to match the kernel version on it somehow. >>> >>> Not sure if we have a command to 'ask' for the kernel version loaded though... >>> >> >> Not currently. >> >> Using a root=PARTUUID=blah would also be nice and might allow the same >> command-line on multiple kernel versions. >> >> Unfortunately, this doesn't seem to work: >> https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.10.31_1.1.0_beta/init/do_mounts.c#L213 > > The problem with the UUID is because we need to inject it during > rootfs generation and it'd not be in the initial environment, so an > 'env default -f -a' would make the system not bootable. In your case, > as you use the script in a partition it is more doable but it'd not be > an generic solution. > If the kernel could accept a PARTUUID parameter, the boot script could potentially produce it, but that doesn't seem to be an immediate option. Regards, Eric