[meta-freescale] Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

>> 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.