From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 3EAB6E006E7; Sat, 2 Aug 2014 07:59:51 -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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 * [74.125.82.175 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (rehsack[at]gmail.com) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B1968E004F1 for ; Sat, 2 Aug 2014 07:59:46 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so5640202wes.20 for ; Sat, 02 Aug 2014 07:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oMxDwt0bjytKd4XF2kI8TKGIrT3gFMpOOUnMfwuAbRU=; b=COZBB0yfvVeAoMLg5/+UhEp+fPf+XyBidIWRKBaXS+vVyURH2xuj3qIaBWdU7MdGaa rBnUxk9uDT30HVA7UrxxxEhbc4Km0ZvL4BUXDB0GmeKgF5LkHp50/lCuoeZ+/Kl3ZIDT WixCy7/2j42kg44YOGGmhntXO003euJQly7df29FuaVJXBladZPwWeVsbHsGHozNoxAv VIKhFk7fcRls1BJEQS1JGBiQ2faCJiwqHLcx/z293c+rEX/mt553HX3/jSEJYCmSV4k0 NNtvr9+dxiPVqh5XoXXpdaCfaRUAxyGfe4SzHf/j4A9i1uSphpQvHqxahk/kIudry6SD GdMw== X-Received: by 10.180.92.134 with SMTP id cm6mr16956807wib.72.1406991585664; Sat, 02 Aug 2014 07:59:45 -0700 (PDT) Received: from ernie.muppets.liwing.de (p578b540c.dip0.t-ipconnect.de. [87.139.84.12]) by mx.google.com with ESMTPSA id je17sm19887364wic.22.2014.08.02.07.59.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Aug 2014 07:59:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jens Rehsack In-Reply-To: Date: Sat, 2 Aug 2014 16:59:40 +0200 Message-Id: <04142B7D-669C-4114-A990-CEC915F8ECF2@gmail.com> References:

To: Daiane Angolini X-Mailer: Apple Mail (2.1878.6) Cc: "meta-freescale@yoctoproject.org" , =?iso-8859-1?Q?St=E9phan_Rafin?= Subject: Re: Right lib-imx/firmware-imx ... versions 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: Sat, 02 Aug 2014 14:59:51 -0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Am 23.07.2014 um 19:31 schrieb Jens Rehsack : It's a bit ago ... but for the records (and pay back a little bit) > Am 23.07.2014 um 17:45 schrieb Daiane Angolini = : >=20 >> On Wed, Jul 23, 2014 at 11:51 AM, Jens Rehsack = wrote: >>>=20 >>> Am 23.07.2014 um 16:19 schrieb Daiane Angolini = : >>>=20 >>>> On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack = wrote: >>>>> Hi, >>>>>=20 >>>>> as mentioned in my very first post here, we're trying to get a = board >>>>> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 = (bdde708). >>>>>=20 >>>>> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without >>>>> difference). >>>>=20 >>>> Long story short: Stick to one branch and use it, with the kernel >>>> version and the imx-lib/gpu/imx-vpu/firmware version already there. = It >>>> was what we tested someway. >>>=20 >>> But there is no Yocto support for imx-lib-3.0.35_4.1.0, neither that >>> imx-vpu nor gpu-viv-lib-mxq version. Only 3.10.9 and 3.10.17 is = included >>> (daisy has only 3.10.17). >>=20 >> I don=B4t remember exactly which version was used in each branch. = Sorry. >> I can only say to you that using the branch as-is, was enough to my >> uses. >>=20 >>=20 >>>> Or, let=B4s be more practical. Have you tested your GPU = integration? >>>> What is the GPU driver version in your kernel, and your GPU = user-space >>>> version? >>>=20 >>> Nope, how can I do that (fsl for dummies - I'm happy controlling = Yocto >>> meanwhile). Just bitbake imx-test or something more? >>=20 >>=20 >> For this kernel: >> = http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel= /linux/linux-imx_3.0.35.bb?h=3Ddora >>=20 >> Use this GPU user space >> = http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphi= cs/gpu-viv-bin-mx6q?h=3Ddora >>=20 >> hfp or sfp.... >>=20 >> The Original 3.0.35-4.0.1 is not compatible with >> gpu-viv-bin-mx6q_3.10.9-1.0.0, that=B4s why there is a patch to = upgrade >> 3.0.35 to GPU driver p13 >=20 > I didn't see that patch, digging for unless ... bsp porting isn't an = option. Found such a patch in old wandboard kernels - I reused some more of the = patches there ... >> However, it does not mean that this combination is free of bug. >>=20 >> And remember it=B4s only a hint. As you said at first, community does >> not support linux-imx-3.0.35 any more. >=20 > I took a look into differences between imx_3.10.17_1.0.0_ga and > wandboard_imx_3.10.17_1.0.0_ga to get a picture what I have to hack to > port the bsp from 3.0.35 to 3.10.17 - but I miss the place where > previously platform initialization happened = (arch/arm/mach-mx6/board-mx6q_sabresd.*) >=20 > Is there a suitable guide explaining bsp porting from imx_3.0.35_4.1.0 = to > imx_3.10.17_1.0.0? Daiane, because you also was involved into = https://community.freescale.com/thread/304414: I digged a lot deeper, tried = https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c= 84990bc69233 and debugged and proved more there ... I also tried to get a picture of vmm by browsing "Understanding The = Linux Virtual Memory Manager" by Mel Gorman. My result: When no swap is configured (and the box has none - because of = 1GB RAM and 4GB Flash there is not really space for swap), the memory = runs full by page-caching disk files. There could be several ways out to ensure system is not crashing when = pages for DMA are allocated by eg. XBMC, gplay or whatever wants to use = the VPU. 1) continuously drop page cache (our measurement tells in our = configuration every 15sec is fine even for 4K movies) 2) implement better dma page cache as v4l2 patch demonstrates (pre-alloc = 256M and serve dma pages from there, use smart allocation as SmartHeap = does and = https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c= 84990bc69233 drafts ...) 3) modify vpu dma allocator to interfere with page cache and drop oldest = cache entries 4) find a way to simulate swap-conditions without really paging out Any hints choosing the optimal decision will be appreciated :) Best regards --=20 Jens Rehsack rehsack@gmail.com