[meta-freescale] i.mx6sl u-boot not booting when using a toolchain installed with populate_sdk

Kursad Oney Kursad.Oney at freescale.com
Thu Oct 8 13:26:34 PDT 2015


Hi,

I ran into an issue with the 1.8 fido toolchain I installed using populate_sdk
task. I noticed this issue with both warpboard and the mx6slevk.

I used the fido branch to create an SDK and used the following command to
populate a toolchain:

	bitbake core-image-base -c populate_sdk

When I compile u-boot with this toolchain, nothing appears on the console when
it is run out of eMMC. However, if I use the imx_usb_loader tool to download the
u-boot image to memory, it runs just fine.

I then installed the pre-built 1.6, 1.7, and 1.8 toolchains and to my surprise
the u-boot image I built had no issues.

Comparing the pre-built 1.8 toolchain and the one populated by populate_sdk, I
noticed this in each one's environment setup scripts:

pre-built:
	export CC="arm-poky-linux-gnueabi-gcc  [...] -mfloat-abi=softfp [...]
populate_sdk:
	export CC=="arm-poky-linux-gnueabi-gcc  [...] -mthumb-interwork -mfloat-abi=hard [...]

In addition to this, u-boot build is pulling in libgcc from the toolchain.
I'm guessing the pre-built toolchain's libgcc is soft-float while the one I
built is hard-fp. I thought "Hey maybe u-boot is overriding CC and causing a
mismatch between libgcc and the rest of the binary." However, then why does it
work when I use the imx_usb tool?

My guess is something in the DCD creation / memory initialization phase uses
soft-float *and* somehow something from libgcc. However, for my builds I'm using
u-boot.imx which does not contain an SPL.

I found this thread:

https://lists.yoctoproject.org/pipermail/meta-freescale/2014-November/011270.html

The author there also says:

	However, this had other implications.  One of them changed -mfloat-abi=soft
	to hard and, I believe, rendered the binary/imx file unusable on the target
	(it might however be for another reason that it was not booting... keep on
	reading).

He doesn't have an explanation either. What could be causing the behavior I
described? Is this a known issue? Is there a preferred method instead of using
populate_sdk? Since the yocto guide says this is the preferred method of
installing poky's toolchain, I was hoping someone else might have come across
this issue too.

Cheers,
kursad


More information about the meta-freescale mailing list