From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 862F9E0045D for ; Fri, 21 Dec 2012 12:06:17 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2939951pbc.17 for ; Fri, 21 Dec 2012 12:06:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=4e5LQGGYGji5f+hsBKtHSwVf41L3yvvn3em2JjxmAeE=; b=VyVEbBUXgnnY63+/FKcqlnPmVu9t7UhmrWHRGqVfFEn2UgaZgGyErJNFdRiH+DKIcI ORyJZo9sK1wHBnNSSfCUkKgk6U3a8b7wzueZTWvAUOoet+nlfZSFpCDbfBNYKVaBa3xz GWmC1VSA1Itg8zVGhT90RaZEURVUXPLCzmOH8/ut8jMr2SaYUxVTXogGo1u7Wkv7ht+F 2nC8UVkqxePJbWUWggXTTC7km7I/jTXjr8ckV9XKWN+4/YDFfxcT4/pFRw2bALIqBpo1 FW2+apVQwnNUvwoJ+tA2xkulBJmY9dUlYvCInffiAEJnxyuwLHgSXY+e3WWNwN1Uunxb F4Xw== X-Received: by 10.68.236.99 with SMTP id ut3mr43555911pbc.16.1356120377345; Fri, 21 Dec 2012 12:06:17 -0800 (PST) Received: from [192.168.0.55] ([70.96.116.236]) by mx.google.com with ESMTPS id kn3sm7499369pbc.3.2012.12.21.12.06.15 (version=SSLv3 cipher=OTHER); Fri, 21 Dec 2012 12:06:16 -0800 (PST) Message-ID: <50D4C136.8020607@boundarydevices.com> Date: Fri, 21 Dec 2012 13:06:14 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Otavio Salvador References: <1356107115-22099-1-git-send-email-gary@mlbassoc.com> <1356107115-22099-4-git-send-email-gary@mlbassoc.com> <50D4AC7C.80004@boundarydevices.com> <50D4B492.8020401@boundarydevices.com> In-Reply-To: X-Gm-Message-State: ALoCoQluLRTwR12Vjg6L9xXQ44bYnUbuVykjMyn2h5hA0jG5SdcusH/K7k1KP9d7hg+3tlj6+eUn Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs 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, 21 Dec 2012 20:06:17 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/21/2012 12:24 PM, Otavio Salvador wrote: > On Fri, Dec 21, 2012 at 5:12 PM, Eric Nelson > wrote: >> On 12/21/2012 11:41 AM, Otavio Salvador wrote: >>> >>> On Fri, Dec 21, 2012 at 4:37 PM, Eric Nelson >>> wrote: >>>> >>>> On 12/21/2012 10:19 AM, Otavio Salvador wrote: >>>>> >>>>> On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas wrote: >>>>>> >>>>>> Recent versions of udev (182 in OE-core) need devtmpfs to operate >>>>>> correctly >>>>>> >>>>>> Signed-off-by: Gary Thomas >>>>> >>>>> Merged to master with reworded commit log and bump PR. >>>>> >>>> Hi Otavio, >>>> >>>> I have a configuration patch to make, adding CONFIG_FEC_NAPI. >>>> >>>> Should I submit it with a bump in PR as you did, or without, so >>>> that you can coordinate that? >>> >>> >>> Please do it with bump in PR so it is easier for me. >>> >>>> The patch itself is to prevent network performance from cratering >>>> under load as discussed in this blog post: >>>> http://boundarydevices.com/i-mx6-ethernet/ >>>> >>>> And in this patch: >>>> >>>> https://github.com/boundarydevices/linux-imx6/commit/38d622938f1352a6550a5e38c624b46b6929439f >>>> >>>> Without it, network receive performance can get really bad under >>>> load. >>> >>> >>> Very nice! However you might like to simply sync the patch for your >>> boundary tree (the patch compares FSL branch with Bondary ones) so >>> this would be included. Or this should be applied in all boards? >>> >> >> Well... I was thinking that I'd just push this one, since it has a much >> bigger impact than the patches we made to flow control and error >> handling. >> >> I think I was a bit mistaken though. I didn't catch that this line was >> itself in a patch file: >> +# CONFIG_FEC_NAPI is not set >> >> I also didn't catch and don't quite understand how the defconfig file >> is applied in the build process. Is 'nitrogen6x_defconfig' even used? >> >> I don't see CONFIG_FEC in the defconfig. Does that file somehow get >> applied on top of a base configuration to apply Yocto specifics? > > The defconfig, at linux-imx- is generated using the machine > config and calling make savedefconfig; so it should be the shorter > version and produce same .config as result of dependencies. > > So the build system copy the defconfig onto .config, run "yes 'n' | > make oldconfig" and build the kernel. > > You can sync the 12.09.01 branch and update the patch at: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/sync-boundary-changes.patch > > and updated: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig > > As I did the trick of using sabrelite as fallback to nitrogen board > (check https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/nitrogen6x.conf#L6) > it will use those, except a nitrogen specific one is provided. I did > it to avoid duplicating things and easy maintenance. > I think I understand this, but will need to walk the exercise to be sure and it will likely take a couple of days before I can get to it. >> There are some things in our boundary-L3.0.35_12.09.01_GA tree that >> I was hoping to clean up before submitting >> >> In particular, we set things up to allow a single image to boot on >> Quad->Solo that the Freescale team didn't like, so we'll probably > > It'd be nice indeed. Why they didn't like it? > This is the tricky bit, with a double-include of a header: https://github.com/boundarydevices/linux-imx6/commit/a11553187650003a3d88b187fd175b963b2fa957#L0R123 It's origin is in the observation that the board defines the pins and pads, which are the same regardless of the CPU, but the addresses are different. By including it twice, you get two copies of the static mux-config arrays: https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_12.09.01_GA/arch/arm/mach-mx6/pads-mx6_sabrelite.h#L49 Then one of them is selected at run-time based on the CPU: https://github.com/boundarydevices/linux-imx6/commit/a11553187650003a3d88b187fd175b963b2fa957#L0R141 >> revert it as we migrate to the 2012-10 branch, which will take a >> couple of weeks. > > So revert back to several images depending on SoC model? > Yeah. That's certainly allows more optimization, since we can remove stuff like SATA, which only applies on 6Quad and 6Dual. > Regards, > > -- > Otavio Salvador O.S. Systems > E-mail: otavio@ossystems.com.br http://www.ossystems.com.br > Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br >