From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 7A215E008CE; Wed, 5 Nov 2014 07:37:13 -0800 (PST) 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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU 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.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 ecbiz156.inmotionhosting.com (ecbiz156.inmotionhosting.com [23.235.201.8]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 0EB25E00830 for ; Wed, 5 Nov 2014 07:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brioconcept.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=/t0+DTzOm9lvfJcM3exXx4947B17obCCA8GX3uK8jhs=; b=t1gM6vlzTfwfoyuF7Vn3vDJyQL1t3V91zKzGfqpyrw13M+OMmkQikauosEKqzjrSxyMU5t+EUqY6YGB/reALn13lb7IxGk4noDVeL120tY5cpG6adP0G7lkXlR/AD8BB1N2nPe6UaUmMISawTzZHKmMmRqlz5RKLG7wrGC0IAY0=; Received: from modemcable124.64-80-70.mc.videotron.ca ([70.80.64.124]:50353 helo=BRIOGFOURNIER) by ecbiz156.inmotionhosting.com with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Xm2du-0004bm-73; Wed, 05 Nov 2014 10:37:07 -0500 From: "Guillaume Fournier" To: "'Daiane Angolini'" References: <000a01cff880$d8b22690$8a1673b0$@brioconcept.com> <006601cff906$1a17a170$4e46e450$@brioconcept.com> In-Reply-To: Date: Wed, 5 Nov 2014 10:37:08 -0500 Message-ID: <008b01cff90e$5c5a8bd0$150fa370$@brioconcept.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKmmnTva9InJO+t6GG5EnVVZUvx/AJgL0tAAYIHMioB2KqVc5p3Dbqg X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz156.inmotionhosting.com X-AntiAbuse: Original Domain - yoctoproject.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brioconcept.com X-Get-Message-Sender-Via: ecbiz156.inmotionhosting.com: authenticated_id: gfournier@brioconcept.com Cc: meta-freescale@yoctoproject.org Subject: Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board 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: Wed, 05 Nov 2014 15:37:13 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-ca >> The ultimate goal is to have a cross-compiler build environment that = works for both u-boot and kernel development. For now, I used Yocto to = generate the toolchain (using meta-toolchain as specified in my first = post) as described in section 3.4 of the Yocto Project Application = Developer's Guide. Following your lead I did use "bitbake = core-image-base" to generate an image and burned = core-image-base-imx6dlsabresd.sdcard to an SD card using: >> cfimager -f core-image-base-imx6dlsabresd.sdcard -raw -d d >> >> I used cfimager which is a tool that comes with IMX_6DL_6S_MFG_TOOL = since I don't have physical access to a linux box. The board boots up = fine but this is not the goal I seek. I want to get a working = cross-compiling toolchain so I can build u-boot and the kernel outside = of Yocto. I understand the subject of this post is therefore a bit = misleading since u-boot does boot when using Yocto build output... It = just doesn't when using the cross-compiling toolchain. >> > >use the cfimage to burn the u-boot binary in your sdcard. I understand = it would be the similar to the dd command. And, at least, you're going = to test if the u-boot image is OK or not. > >mfgtool does not work the way you're expecting. You must have an u-boot = + uImage + initramfs to *start* the burning cycle of your own image. And = I have never tested to burn only one new u-boot with mfgtools. > >For me it looks like a mfgtools "misuse" or "misbehavior" more than = toolchain problem. > >Oh, and only one more thing. The shell you use to bitbake your = toolchain is not the shell you use to export that toolchain. > >Everytime you export the setup environment to use the toolchain, use a = clean shell (I faced weird errors in the past because of forgetting to = clean the environment variables) > >Daiane I have tried both the cfimager and the mfgtool with similar results but = I understand your point. I'm going to use cfimager from then on. I = tried this with the cfimager and a known-to-work u-boot.bin: cfimager -f u-boot-works.bin -raw -offset 1024 -skip 1024 -d d u-boot booted on the target. So I believe putting u-boot.bin on an SD = card is not part of the problem. Doing the same with a u-boot.bin coming from u-boot-fslc cross-compiled = with a Yocto installed toolchain doesn't (refer to my first post for = detailed info on how I performed the Yocto installation, toolchain = generation, etc). I am making sure I use a clean shell every time I cross-compile u-boot.