From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 05077E007A0; Sat, 4 Oct 2014 19:21:37 -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: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.223.182 listed in list.dnswl.org] Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id C2053E00566 for ; Sat, 4 Oct 2014 19:21:29 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id rp18so1640711iec.41 for ; Sat, 04 Oct 2014 19:21:28 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6RiOCZnTNafqfwoJcP3+tOrwD3N49ZVm7Q8p8djSpqA=; b=TP93jKGkViFrjoAEVfserfmx1wQF9T5p7YRdixJspiWET5y07lyB7CpfI6pnwvwd1R L/JNBzhTLAfTTWUjIzUrohIOQJ37uZz0b8g1KNMBY4ky90J1s51mz1BCX+8dvjk0dVGM +TGZ0qV5Umvt49ZtRzXXw3S8m5Xm+H4yI4FruXgKvyu/m+a35+JXA9ykXcj9gj7r+X2N VL04YeCF5nxU9OZvS6Dqn7MSZxPXTg9vQm1ObEsYUcavS2YDAAKYbVHMsvsRa5cUe7cN npwnxYrHqVxkMKpEYmSFEW+UiAGhJlTqcdV8eKRy607QRWi8TyyruGZUcqAcRqNKa5MI RaWA== X-Gm-Message-State: ALoCoQnyI7VzeQ2BbB40ZZy10a7Lohp8OvuQKemYXbBluvarhipHELr1OWQ0ugqexb7UzpfRmWSH X-Received: by 10.43.82.66 with SMTP id ab2mr23509824icc.56.1412475688793; Sat, 04 Oct 2014 19:21:28 -0700 (PDT) Received: from [192.168.141.122] (dsl-67-204-52-1.acanac.net. [67.204.52.1]) by mx.google.com with ESMTPSA id p10sm462659igx.2.2014.10.04.19.21.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Oct 2014 19:21:28 -0700 (PDT) Message-ID: <5430AB26.100@linaro.org> Date: Sat, 04 Oct 2014 22:21:26 -0400 From: Trevor Woerner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Gunnar Roth , "meta-freescale@yoctoproject.org" References: In-Reply-To: Subject: Re: imxq6 sabre sd locks up when starting Qt5_Cinematic experience 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: Sun, 05 Oct 2014 02:21:37 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit (old thread... sorry, just catching up) On 08/02/14 04:00, Gunnar Roth wrote: > Btw how can i define the size of the rootfs , so to have more space available? Right now i always did a resize of the partition afterwards, > but somehow i must be able to give the size of the roots including free space. There are a couple variables you can play with in your conf/local.conf to affect the size of the final image. First off you can set "IMAGE_OVERHEAD_FACTOR" to a number, say 20 (IMAGE_OVERHEAD_FACTOR = "20"). This will ask that an extra 20% size be added to your final image. You can also specify a size (in KB) for your image using IMAGE_ROOTFS_SIZE. In my experience, however, sometimes these variables get ignored. Sometimes they're ignored because the code that is used to calculate these sizes (for the specific build you're doing) doesn't take these variables into account. If the size you specify is too small, the build will ignore your request and make the output the size it would have anyway without any input from you. Sometimes different types of output will ignore the suggestions you make in your configuration file (e.g. vmdk versus hddimage). Nominally you could look in poky/meta/classes/image_types.bbclass and see how things are calculated. You could also make use of "bitbake -e | grep " to see what your build thinks of the various things calculated in this bbclass file. But at the end of the day, unless you have a specific need for the extra space, all you're doing is increasing the time it takes your "dd" command to write your cfcard. If you have a 2GB card and are only using 200MB the "dd" will only take one tenth the time it would take to write out the entire 2GB card... and all you're doing with all that extra time is writing empty file space! There are some intelligent tools [1] that can help you write a 2GB card with a 200MB image and only take the amount of time that it would take to write a 200MB card, but those tools aren't integrated into the build system (yet?). But they certainly work/help if you use them manually after your build completes but before you write your cfcard (if your image has lots of empty space added to it, otherwise there's no savings). Best regards, Trevor [1] https://source.tizen.org/documentation/reference/bmaptool