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

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

[Guillaume Fournier]

Hello,

I am new to Yocto and I am having a hard time getting a basic environment
setup.  I have read a lot of documentation but I'm still stock so I'd like
to seek your help.

Problem: I can't get u-boot to start on my evaluation board.  No output
whatsoever on the UART.
Board used: i.MX6 Series SABRE for Smart Devices (MCIMX6DL-SDP)

Here are the steps I followed to get to the point where I am:
***********************************************************************
BSP setup on a Ubuntu 12.04.5 LTS
***********************************************************************
1) Made sure following required packages were installed
   $ sudo apt-get install gawk wget git-core diffstat unzip texinfo
build-essential chrpath libsdl1.2-dev xterm curl
2) Created a working directory
   $ mkdir ~/axion-dev
3) CD to that directory
4) Installed the REPO tool
   $ mkdir ~/axion-dev/bin
   $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo >
~/axion-dev/bin/repo
   $ chmod a+x ~/axion-dev/bin/repo
5) Downloaded BSP source code
   $ PATH=${PATH}:~/axion-dev/bin
   $ mkdir ~/axion-dev/fsl-community-bsp
   $ cd ~/axion-dev/fsl-community-bsp
   $ git config --global user.email "gfournier@brioconcept.com"
   $ git config --global user.name "Guillaume Fournier"
   $ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b
daisy
   $ repo sync
   $ repo start axion --all

***********************************************************************
Built and installed cross development toolchain
***********************************************************************
1) Setup the build environment (this changes the current working directory)
   $ source ./setup-environment build
   Accepted the EULA
2) Choose "imx6dlsabresd" as the machine.
3) Modified ~/axion-dev/fsl-community-bsp/build/conf/local.conf to change
   the MACHINE parameter with the name of the selected machine.  For
instance:
   MACHINE ??= 'imx6dlsabresd'
4) Launched the build
   $ bitbake meta-toolchain
5) Grabbed a coffee and waited...
6) Launched
~/axion-dev/fsl-community-bsp/build/tmp/deploy/sdk/poky-eglibc-x86_64-meta-t
oolchain-cortexa9hf-vfp-neon-toolchain-1.6.1.sh
   When asked where to install, I choose ~/axion-dev/toolchain
   
***********************************************************************
Got and built u-boot
***********************************************************************
1) Got Freescale u-boot
   $ cd ~/axion-dev
   $ git clone https://github.com/Freescale/u-boot-fslc.git
2) Ran toolchain environment script.  This sets all relevant environment
variables for cross-compilation
   $
~/axion-dev/toolchain/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnuea
bi
3) Built u-boot
   $ cd ~/axion-dev/u-boot-fslc
   $ make LDFLAGS="" CC="$CC" mrproper
   $ make LDFLAGS="" CC="$CC" mx6dlsabresd_config
   $ make LDFLAGS="" CC="$CC"
   
   The reason behind the [LDFLAGS="" CC="$CC"] is this:
   
   u-boot top level Makefile contains:
   PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS)
-print-libgcc-file-name`) -lgcc
   The above call gets resolved to "-L ."  Doing ${CC}
-print-libgcc-file-name shows the proper value. The reason
   for this is that U-Boot does not pickup $CC from our environment (which
is including the --sysroot option). Without this
   option -print-libgcc-file-name resolve to a simple file name without a
path. And thus dirname resolve it further to "."
   So the fix is to do: make LDFLAGS="" CC="$CC"
   This passes the ${CC} environment variable to the Makefile which in turns
resolve the PLATFORM_LIBGCC correctly

   As read here:
https://lists.yoctoproject.org/pipermail/yocto/2013-October/016385.html

***********************************************************************
Flashed an SD card with u-boot
***********************************************************************
1) Downloaded Mfgtools-Rel-4.1.0_130816_MX6DL_UPDATER.gz from Freescale onto
a Windows machine
   Also called IMX_6DL_6S_MFG_TOOL: Tool and documentation for downloading
OS images to the i.MX 6DualLite and i.MX6Solo. 
   Size (K): 73917 Format: gz Rev #: L3.0.35_4.1.0 Modified: 9/5/2013
 
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=RDIMX6SABREPL
AT&fpsp=1&tab=Design_Tools_Tab
2) Uncompressed it
3) Modified {INSTALL_FOLDER}\cfg.ini so it looks like this:
   [profiles]
   chip = MX6DL Linux Update

   [platform]
   board = SabreSD

   [LIST]
   name = AXION-i.MX6DL-SABRESD-SD
4) Modified {INSTALL_FOLDER}\Profiles\MX6DL Linux Update\OS
Firmware\ucl2.xml to add this list entry:
   <LIST name="AXION-i.MX6DL-SABRESD-SD" desc="Choose SD as media">  
        <CMD state="BootStrap" type="boot" body="BootStrap" file
="u-boot-mx6dl-sabresd.bin" >Loading U-boot</CMD>
        <CMD state="BootStrap" type="load" file="uImage"
address="0x10800000" loadSection="OTH" setSection="OTH"
HasFlashHeader="FALSE" >Loading Kernel.</CMD>
        <CMD state="BootStrap" type="load" file="initramfs.cpio.gz.uboot"
address="0x10C00000" loadSection="OTH" setSection="OTH"
HasFlashHeader="FALSE" >Loading Initramfs.</CMD>
        <CMD state="BootStrap" type="jump" > Jumping to OS image. </CMD>

        <CMD state="Updater" type="push" body="send"
file="mksdcard.sh.tar">Sending partition shell</CMD>
        <CMD state="Updater" type="push" body="$ tar xf $FILE ">
Partitioning...</CMD>
        <CMD state="Updater" type="push" body="$ sh mksdcard.sh
/dev/mmcblk1"> Partitioning...</CMD>
        <CMD state="Updater" type="push" body="send"
file="axion/u-boot.bin">Sending u-boot.bin</CMD>
        <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk1
bs=1k seek=1 skip=1 conv=fsync">write u-boot.bin to sd card</CMD>
        <CMD state="Updater" type="push" body="send"
file="files/uImage">Sending kernel uImage</CMD>
        <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk1
bs=1M seek=1 conv=fsync">write kernel image to sd card</CMD>
        <CMD state="Updater" type="push" body="$ mkfs.ext3 -j
/dev/mmcblk1p1">Formatting rootfs partition</CMD>
        <CMD state="Updater" type="push" body="$ mkdir -p /mnt/mmcblk1p1"/> 
        <CMD state="Updater" type="push" body="$ mount -t ext3
/dev/mmcblk1p1 /mnt/mmcblk1p1"/>
        <CMD state="Updater" type="push" body="pipe tar -jxv -C
/mnt/mmcblk1p1" file="files/rootfs.tar.bz2">Sending and writing rootfs</CMD>
        <CMD state="Updater" type="push" body="frf">Finishing rootfs
write</CMD>
        <CMD state="Updater" type="push" body="$ umount
/mnt/mmcblk1p1">Unmounting rootfs partition</CMD>
        <CMD state="Updater" type="push" body="$ echo Update
Complete!">Done</CMD>
   </LIST>
5) Created a directory under {INSTALL_FOLDER}\Profiles\MX6DL Linux Update\OS
Firmware\ named "axion"
6) Copied u-boot.bin from Linux box ~/axion-dev/u-boot-fslc to Windows box
{INSTALL_FOLDER}\Profiles\MX6DL Linux Update\OS Firmware\axion
7) Connected eval board to the Windows box using USB cable (on USB OTG
connector)
8) Set all DIP switches on the eval board to OFF (SW6)
9) Powered the board
10)Ran MfgTool2.exe and hit Start
11)Once done, unpowered the board
12)Flip SW6 to '01000010'
13)Connected eval board to the Windows box using USB cable (USB TO UART
connector)
14)Launched a terminal (I used PuTTY) on the virtual com port created
(115200 N81)
15)Powered the board

I would expect u-boot to come up here and it doesn't.  I don't have anything
output on the serial port.  I have tried with supplied i.MX6DL-SABRESD-SD
profile in IMX_6DL_6S_MFG_TOOL and it works fine, I get the expected u-boot
printouts.

What am I doing wrong ?

Guillaume Fournier
Hardware Designer
Brioconcept Consulting Inc.

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Fabio Estevam]

On Tue, Nov 4, 2014 at 8:44 PM, Guillaume Fournier
<gfournier@brioconcept.com> wrote:
> Hello,
>
> I am new to Yocto and I am having a hard time getting a basic environment
> setup.  I have read a lot of documentation but I'm still stock so I'd like
> to seek your help.
>
> Problem: I can't get u-boot to start on my evaluation board.  No output
> whatsoever on the UART.
> Board used: i.MX6 Series SABRE for Smart Devices (MCIMX6DL-SDP)

Could you try to flash the .sdcard image directly to the SD card and
boot from there? That would be a quicker method.

There are some pre-built .sdcard images available at
http://ci.ossystems.com.br/public/fsl-community-bsp/ that you could
quickly try.

Regards,

Fabio Estevam

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

Fabio,

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.

As a side note, I have also downloaded fsl-image-multimedia-imx6dlsabresd.sdcard from http://ci.ossystems.com.br/public/fsl-community-bsp/daisy/76/framebuffer/imx6dlsabresd and burned it to an SD card and it too works fine.

Guillaume Fournier, ing.
Concepteur matériel / Hardware Designer
Brioconcept Consulting Inc.
450.681.2779 x2388

-----Original Message-----
From: Fabio Estevam [mailto:festevam@gmail.com] 
Sent: November 4, 2014 7:03 PM
To: Guillaume Fournier
Cc: meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

On Tue, Nov 4, 2014 at 8:44 PM, Guillaume Fournier <gfournier@brioconcept.com> wrote:
> Hello,
>
> I am new to Yocto and I am having a hard time getting a basic 
> environment setup.  I have read a lot of documentation but I'm still 
> stock so I'd like to seek your help.
>
> Problem: I can't get u-boot to start on my evaluation board.  No 
> output whatsoever on the UART.
> Board used: i.MX6 Series SABRE for Smart Devices (MCIMX6DL-SDP)

Could you try to flash the .sdcard image directly to the SD card and boot from there? That would be a quicker method.

There are some pre-built .sdcard images available at http://ci.ossystems.com.br/public/fsl-community-bsp/ that you could quickly try.

Regards,

Fabio Estevam

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Wally Yeh]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

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

Um... sometimes I just download the cross-compiler from linaro homepage and
build the u-boot, works fine as usual.
if you want build your own cross-compiler from yocto, just bitbake
meta-toolchain,
and execute <yocto path>/build/tmp/deploy/sdk/
poky-eglibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.6.1.sh

I even use a sfp cross-compiler to build u-boot and booting hfp uImage, and
still can boot into linux system.

[-- Attachment #2: Type: text/html, Size: 1672 bytes --]

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

>>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.
>
>Um... sometimes I just download the cross-compiler from linaro homepage
>and build the u-boot, works fine as usual. if you want build your own cross-compiler
>from yocto, just bitbake meta-toolchain, and execute <yocto path>/build/tmp/deploy
>/sdk/poky-eglibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.6.1.sh

I just did that (bitbake meta-toolchain + install script) and I can get u-boot to build without errors but the u-boot.bin is not booting on the target.

>I even use a sfp cross-compiler to build u-boot and booting hfp uImage, and still can boot into linux system.
I downloaded the little-endian linaro toochain binaries v4.9 (gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz) and installed it.  I was able to compile u-boot without errors.  When I try the output u-boot.bin, it does not boot on the target.

I'm starting to think something with my u-boot configuration is wrong.  Could the "make LDFLAGS="" CC="$CC" mx6dlsabresd_config" be the culprit ?

Guillaume

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Daiane Angolini]

On Wed, Nov 5, 2014 at 12:38 PM, Guillaume Fournier
<gfournier@brioconcept.com> wrote:
> Fabio,
>
> 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

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

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Otavio Salvador]

On Wed, Nov 5, 2014 at 1:37 PM, Guillaume Fournier
<gfournier@brioconcept.com> wrote:
...
> 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.

Did you read the README.imximage file?

Check it here:

https://github.com/Freescale/u-boot-fslc/blob/patches-2014.10/doc/README.imximage

Short version:

make u-boot.imx

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

>Did you read the README.imximage file?
>
>Check it here:
>
>https://github.com/Freescale/u-boot-fslc/blob/patches-2014.10/doc/README.imximage
>
>Short version:
>
>make u-boot.imx
>
I have read the document and burned the resulting .imx file to my SD card like this:
cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d

It doesn't boot on the target.

What am I missing ?  I had a look at the .sdcard generated by Yocto that does work on the target to look at the binary content.  When comparing it to a working .imx file, they are the same starting at offset 0x400.  This makes sense.  When I compare my non-working .imx file with the working .imx file (binary wise), I can see there are slight differences.

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Otavio Salvador]

On Wed, Nov 5, 2014 at 12:38 PM, Guillaume Fournier
<gfournier@brioconcept.com> wrote:
> 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.

I am failing to see what is missing? I use the toolchain for kernel
and  u-boot development with no issues. What problems you are facing?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: 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.
>
>I am failing to see what is missing? I use the toolchain for kernel and  u-boot development with no issues. What problems you are facing?
>
>-- 
>Otavio Salvador                             O.S. Systems

I know it is a long post but could you read the first email I sent to the mailing list? I think this will sum it up for you.  Except for the last bit where I used the mfgtools instead of the cfimager (I changed after Daiane suggestion), everything is still relevant.  Thanks for stepping in Otavio.

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Otavio Salvador]

On Wed, Nov 5, 2014 at 1:50 PM, Guillaume Fournier
<gfournier@brioconcept.com> wrote:
>>> 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.
>>
>>I am failing to see what is missing? I use the toolchain for kernel and  u-boot development with no issues. What problems you are facing?
>>
>>--
>>Otavio Salvador                             O.S. Systems
>
> I know it is a long post but could you read the first email I sent to the mailing list? I think this will sum it up for you.  Except for the last bit where I used the mfgtools instead of the cfimager (I changed after Daiane suggestion), everything is still relevant.  Thanks for stepping in Otavio.

As I said on the other e-mail you need to use the u-boot.imx file, not
the u-boot.bin one. Another change needed for mfgtool xml file is the
dd command which needs the removal of 'seek=2' as it has no padding..


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Wally Yeh]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

>As I said on the other e-mail you need to use the u-boot.imx file, not
>the u-boot.bin one. Another change needed for mfgtool xml file is the
>dd command which needs the removal of 'seek=2' as it has no padding..

Otavio is correct, I use u-boot.imx to boot my board. and must wirte it
into my eMMC at 0x2 by uboot mmc write command.
so if you using dd, make sure bs=512 seek=2 appended.

Wally


2014-11-05 23:54 GMT+08:00 Otavio Salvador <otavio@ossystems.com.br>:

> On Wed, Nov 5, 2014 at 1:50 PM, Guillaume Fournier
> <gfournier@brioconcept.com> wrote:
> >>> 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.
> >>
> >>I am failing to see what is missing? I use the toolchain for kernel and
> u-boot development with no issues. What problems you are facing?
> >>
> >>--
> >>Otavio Salvador                             O.S. Systems
> >
> > I know it is a long post but could you read the first email I sent to
> the mailing list? I think this will sum it up for you.  Except for the last
> bit where I used the mfgtools instead of the cfimager (I changed after
> Daiane suggestion), everything is still relevant.  Thanks for stepping in
> Otavio.
>
> As I said on the other e-mail you need to use the u-boot.imx file, not
> the u-boot.bin one. Another change needed for mfgtool xml file is the
> dd command which needs the removal of 'seek=2' as it has no padding..
>
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

[-- Attachment #2: Type: text/html, Size: 3764 bytes --]

Re: 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.
>>>
>>>I am failing to see what is missing? I use the toolchain for kernel and  u-boot development with no issues. What problems you are facing?
>>>
>>>--
>>>Otavio Salvador                             O.S. Systems
>>
>> I know it is a long post but could you read the first email I sent to the mailing list? I think this will sum it up for you.  Except for the last bit where I used the mfgtools instead of the cfimager (I changed after Daiane suggestion), everything is still relevant.  Thanks for stepping in Otavio.
>
>As I said on the other e-mail you need to use the u-boot.imx file, not the u-boot.bin one. Another change needed for mfgtool xml file is the dd command which needs the removal of 'seek=2' as it has no padding..

I'm now using the cfimager instead of the mfgtool as suggested by Daiane.  I am using u-boot.imx as follow:
cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d

If I use an .sdcard file from a Yocto build like this:
cfimager -f core-image-base-imx6dlsabresd.sdcard -raw -d d

That works.  If I'm using, *from the same build*, the u-boot.imx like this:
cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d

It doesn't!  Of course, if I use my custom built u-boot, it doesn't either.  I'm starting to believe that cfimager parameter are the culprit.

Guillaume Fournier

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Gary Thomas]

On 2014-11-05 09:15, Guillaume Fournier wrote:
>>>>> 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.
>>>>
>>>> I am failing to see what is missing? I use the toolchain for kernel and  u-boot development with no issues. What problems you are facing?
>>>>
>>>> --
>>>> Otavio Salvador                             O.S. Systems
>>>
>>> I know it is a long post but could you read the first email I sent to the mailing list? I think this will sum it up for you.  Except for the last bit where I used the mfgtools instead of the cfimager (I changed after Daiane suggestion), everything is still relevant.  Thanks for stepping in Otavio.
>>
>> As I said on the other e-mail you need to use the u-boot.imx file, not the u-boot.bin one. Another change needed for mfgtool xml file is the dd command which needs the removal of 'seek=2' as it has no padding..
>
> I'm now using the cfimager instead of the mfgtool as suggested by Daiane.  I am using u-boot.imx as follow:
> cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d
>
> If I use an .sdcard file from a Yocto build like this:
> cfimager -f core-image-base-imx6dlsabresd.sdcard -raw -d d
>
> That works.  If I'm using, *from the same build*, the u-boot.imx like this:
> cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d
>
> It doesn't!  Of course, if I use my custom built u-boot, it doesn't either.  I'm starting to believe that cfimager parameter are the culprit.

I'd be suspicious of '-offset 1024' - I doubt that you need both.
Give it a try - leave out either the 'offset' or 'skip' options

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Otavio Salvador]

On Wed, Nov 5, 2014 at 2:21 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2014-11-05 09:15, Guillaume Fournier wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> I am failing to see what is missing? I use the toolchain for kernel and
>>>>> u-boot development with no issues. What problems you are facing?
>>>>>
>>>>> --
>>>>> Otavio Salvador                             O.S. Systems
>>>>
>>>>
>>>> I know it is a long post but could you read the first email I sent to
>>>> the mailing list? I think this will sum it up for you.  Except for the last
>>>> bit where I used the mfgtools instead of the cfimager (I changed after
>>>> Daiane suggestion), everything is still relevant.  Thanks for stepping in
>>>> Otavio.
>>>
>>>
>>> As I said on the other e-mail you need to use the u-boot.imx file, not
>>> the u-boot.bin one. Another change needed for mfgtool xml file is the dd
>>> command which needs the removal of 'seek=2' as it has no padding..
>>
>>
>> I'm now using the cfimager instead of the mfgtool as suggested by Daiane.
>> I am using u-boot.imx as follow:
>> cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d
>>
>> If I use an .sdcard file from a Yocto build like this:
>> cfimager -f core-image-base-imx6dlsabresd.sdcard -raw -d d
>>
>> That works.  If I'm using, *from the same build*, the u-boot.imx like
>> this:
>> cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d
>>
>> It doesn't!  Of course, if I use my custom built u-boot, it doesn't
>> either.  I'm starting to believe that cfimager parameter are the culprit.
>
>
> I'd be suspicious of '-offset 1024' - I doubt that you need both.
> Give it a try - leave out either the 'offset' or 'skip' options

Yes; the offset or the skip are not needed; I use dd so I cannot
advice on the param.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

>> I'm now using the cfimager instead of the mfgtool as suggested by Daiane.
I am using u-boot.imx as follow:
>> cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d
>>
>> If I use an .sdcard file from a Yocto build like this:
>> cfimager -f core-image-base-imx6dlsabresd.sdcard -raw -d d
>>
>> That works.  If I'm using, *from the same build*, the u-boot.imx like
this:
>> cfimager -f u-boot.imx -raw -offset 1024 -skip 1024 -d d
>>
>> It doesn't!  Of course, if I use my custom built u-boot, it doesn't
either.  I'm starting to believe that cfimager parameter are the culprit.
>
>I'd be suspicious of '-offset 1024' - I doubt that you need both.
>Give it a try - leave out either the 'offset' or 'skip' options

Ok, there was a problem with the -skip option.  Removing it altogether
solves the problem for the u-boot.imx coming from a Yocto build:
cfimager -f u-boot-from-Yocto-build.imx -raw -offset 1024 -d d

However, the u-boot.imx coming from u-boot-fslc cross-compiled with a Yocto
installed toolchain doesn't.  Back to square one...

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Eric Bénard]

Hi Guillaume,

Le Tue, 4 Nov 2014 17:44:08 -0500,
"Guillaume Fournier" <gfournier@brioconcept.com> a écrit :
>         <CMD state="Updater" type="push" body="send"
> file="axion/u-boot.bin">Sending u-boot.bin</CMD>
>         <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk1
> bs=1k seek=1 skip=1 conv=fsync">write u-boot.bin to sd card</CMD>

-> seek & skip is wrong with u-boot.imx you should use with
u-boot-fslc : you only need seek=1

.../...

> 6) Copied u-boot.bin from Linux box ~/axion-dev/u-boot-fslc to Windows box
> {INSTALL_FOLDER}\Profiles\MX6DL Linux Update\OS Firmware\axion

--> I think you should take u-boot.imx and not u-boot.bin

a far simpler way if you have a SD slot on your Linux host should be :
dd if=u-boot.imx of=/dev/mmcblk0 conv=notrunc seek=2 bs=512
replace mmcblk0 by the right device (and take care to not erase your
hard drive ;-)

Eric

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

Éric,

Since I'm using u-boot.BIN, I believe the seek=1 and skip=1 are fine.  I
have tried this method with a "known-to-work" u-boot.bin and u-boot boots up
fine on the board.  So the SD card u-boot.bin write part should work as
expected.  As suggested, I tried it using the .IMX file using :

    <CMD state="Updater" type="push" body="send"
file="axion/u-boot.imx">Sending u-boot.imx</CMD>
    <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk1
bs=1k seek=1 conv=fsync">write u-boot.imx to sd card</CMD>

u-boot does not boot on the board either using this method.

I do not have physical access to the linux box so I need to use my Windows
box to burn the image.  This does not seem to be part of the problem for now
since I have proven that I can get a known-to-work image to boot fine on the
board.

Guillaume

---
Sent: November 4, 2014 7:24 PM

Hi Guillaume,

Le Tue, 4 Nov 2014 17:44:08 -0500,
"Guillaume Fournier" <gfournier@brioconcept.com> a écrit :
>         <CMD state="Updater" type="push" body="send"
> file="axion/u-boot.bin">Sending u-boot.bin</CMD>
>         <CMD state="Updater" type="push" body="$ dd if=$FILE
of=/dev/mmcblk1
> bs=1k seek=1 skip=1 conv=fsync">write u-boot.bin to sd card</CMD>

-> seek & skip is wrong with u-boot.imx you should use with
u-boot-fslc : you only need seek=1

.../...

> 6) Copied u-boot.bin from Linux box ~/axion-dev/u-boot-fslc to Windows
box
> {INSTALL_FOLDER}\Profiles\MX6DL Linux Update\OS Firmware\axion

--> I think you should take u-boot.imx and not u-boot.bin

a far simpler way if you have a SD slot on your Linux host should be :
dd if=u-boot.imx of=/dev/mmcblk0 conv=notrunc seek=2 bs=512 replace mmcblk0
by the right device (and take care to not erase your hard drive ;-)

Eric

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Eric Bénard]

Hi Guillaume,

Le Wed, 5 Nov 2014 09:51:08 -0500,
"Guillaume Fournier" <gfournier@brioconcept.com> a écrit :
> Since I'm using u-boot.BIN, I believe the seek=1 and skip=1 are fine.  I
> have tried this method with a "known-to-work" u-boot.bin and u-boot boots up
> fine on the board.  So the SD card u-boot.bin write part should work as
> expected. 

no u-boot.bin won't work when using a recent version of u-boot, you
_must_ use u-boot.imx

> As suggested, I tried it using the .IMX file using :
> 
>     <CMD state="Updater" type="push" body="send"
> file="axion/u-boot.imx">Sending u-boot.imx</CMD>
>     <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mmcblk1
> bs=1k seek=1 conv=fsync">write u-boot.imx to sd card</CMD>
> 
> u-boot does not boot on the board either using this method.
> 
maybe you can try to build u-boot with an older toolchain from Linaro to
be sure you don't hit a toolchain problem.
And if you can try to use dd on a Linux box at least you will be sure
that it's not a configuration problem with the windows tools and
u-boot.imx.

Eric

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

To try and figure out where the problem resides, I started from scratch.

1) got latest BSP: repo init -u
https://github.com/Freescale/fsl-community-bsp-platform -b dizzy
2) modified local.conf so MACHINE is imx6dlsabresd
3) On "bitbake meta-toolchain", I got these QA warnings:
WARNING: QA Issue: gcc-cross-canadian-arm: found library in wrong location:
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnuea
bi/gcc/arm-poky-linux-gnueabi/4.9.1/liblto_plugin.so
gcc-cross-canadian-arm: found library in wrong location:
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnuea
bi/gcc/arm-poky-linux-gnueabi/4.9.1/liblto_plugin.so.0.0.0
gcc-cross-canadian-arm: found library in wrong location:
/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnuea
bi/gcc/arm-poky-linux-gnueabi/4.9.1/liblto_plugin.so.0 [libdir]

I'm not sure these are relevant to my problem so I kept on going.

4) got latest u-boot: git clone https://github.com/Freescale/u-boot-fslc.git
5) started a fresh shell, ran toolchain environment script, cd to
u-boot-fslc
6) make LDFLAGS="" CC="$CC" mx6dlsabresd_config
7) make LDFLAGS="" CC="$CC" u-boot.imx
8) Programmed u-boot.imx on SD card: cfimager -f u-boot.imx -raw -offset
1024 -d d
9) Try to boot target -> not booting, no UART output

Could the problem be related to the Device Configuration Data since u-boot
spits out something on the UART pretty early ?

Guillaume Fournier
Brioconcept Consulting Inc.

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Otavio Salvador]

Hello,

On Wed, Nov 5, 2014 at 6:43 PM, Guillaume Fournier
<gfournier@brioconcept.com> wrote:
> To try and figure out where the problem resides, I started from scratch.
>
> 1) got latest BSP: repo init -u
> https://github.com/Freescale/fsl-community-bsp-platform -b dizzy
> 2) modified local.conf so MACHINE is imx6dlsabresd
> 3) On "bitbake meta-toolchain", I got these QA warnings:
> WARNING: QA Issue: gcc-cross-canadian-arm: found library in wrong location:
> /opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnuea
> bi/gcc/arm-poky-linux-gnueabi/4.9.1/liblto_plugin.so
> gcc-cross-canadian-arm: found library in wrong location:
> /opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnuea
> bi/gcc/arm-poky-linux-gnueabi/4.9.1/liblto_plugin.so.0.0.0
> gcc-cross-canadian-arm: found library in wrong location:
> /opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnuea
> bi/gcc/arm-poky-linux-gnueabi/4.9.1/liblto_plugin.so.0 [libdir]
>
> I'm not sure these are relevant to my problem so I kept on going.

Nothing to worry much above.

> 4) got latest u-boot: git clone https://github.com/Freescale/u-boot-fslc.git
> 5) started a fresh shell, ran toolchain environment script, cd to
> u-boot-fslc

Run the environment script raises an alarm... did you use:

source environment-...?

> 6) make LDFLAGS="" CC="$CC" mx6dlsabresd_config
> 7) make LDFLAGS="" CC="$CC" u-boot.im

Please try:

unset LDFLAGS
make mx6dlsabresd_config
make u-boot.imx

> 8) Programmed u-boot.imx on SD card: cfimager -f u-boot.imx -raw -offset
> 1024 -d d

I never used cfimager (as I mainly use Linux for development) so it is
a guess, please check:

cfimager -f u-boot.imx -raw -offset 0x400 -d d

It might be using hexa by default. Total guess so if you tried before,
just ignore it.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

>> 4) got latest u-boot: git clone 
>> https://github.com/Freescale/u-boot-fslc.git
>> 5) started a fresh shell, ran toolchain environment script, cd to 
>> u-boot-fslc
>
>Run the environment script raises an alarm... did you use:
>
>source environment-...?

Yes I ran:
source ./environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi
which is located in the toolchain directory.  This sets a bunch of environment variables needed to cross-compile.

>> 6) make LDFLAGS="" CC="$CC" mx6dlsabresd_config
>> 7) make LDFLAGS="" CC="$CC" u-boot.im
>
>Please try:
>
>unset LDFLAGS
>make mx6dlsabresd_config
>make u-boot.imx

From a fresh shell, I ran the toolchain environment script, cd to u-boot-fslc and then typed:
unset LDFLAGS
make mrproper
make mx6dlsabresd_config
make u-boot.imx

Result:
arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc
make[2]: *** [examples/standalone/hello_world] Error 1
make[1]: *** [examples/standalone] Error 2
make: *** [examples] Error 2

That error is the reason I was using LDFLAGS="" CC="$CC" on the command line to build.
See : https://lists.yoctoproject.org/pipermail/yocto/2013-October/016385.html

BTW the cfimager works with decimal and hex.  I have read back the SD card using Win32DiskImager (raw reader) and I can confirm this.  Since so many people were doubtful of this cfimager, I used a VM to dd my u-boot onto the SD card as such:
dd if=u-boot.imx of=/dev/sda bs=512 seek=2

This does not solve my problem.  It behaves exactly as the cfimager.  I'm pretty sure now that SD card issues are solved.  I can write a known to work version of u-boot.imx to an SD card and the target boots up fine.

I still do not have a u-boot.imx that can boot with my eval board and this is the main issue.

Guillaume

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Guillaume Fournier]

I was able to get the board to boot this morning.

The problem had to do with this error message I got when building u-boot
with my Yocto generated toolchain:
"arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc"

To solve this problem, I initially went looking on the web and found this:
https://lists.yoctoproject.org/pipermail/yocto/2013-October/016385.html

Basically u-boot top level Makefile contains:
PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS)
-print-libgcc-file-name`) -lgcc
The above call gets resolved to "-L ."  Doing ${CC} -print-libgcc-file-name
shows the proper value. The reason for this is that U-Boot does not pickup
$CC from our environment (which is including the --sysroot option). Without
this option -print-libgcc-file-name resolve to a simple file name without a
path. And thus dirname resolve it further to "."  So the fix suggested was
to do: make LDFLAGS="" CC="$CC" This passes the ${CC} environment variable
to the Makefile which in turns resolve the PLATFORM_LIBGCC correctly.

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

A better solution is to add the following line in the
environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi script:
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"

This KCFLAGS gets appended to the CFLAGS in the top level Makefile of
u-boot.  PLATFORM_LIBGCC now returns a valid lgcc path and no other flags
are modified (-mfloat-abi remains soft).



So, here is a build command before any modifications:

arm-poky-linux-gnueabi-gcc -Wp,-MD,fs/fat/.fat.o.d  -nostdinc -isystem
/media/sdb/gfournier/axiondev/toolchain/sysroots/x86_64-pokysdk-linux/usr/bi
n/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux
-gnueabi/4.9.1/include -Iinclude
-I/media/sdb/gfournier/axiondev/u-boot-fslc/arch/arm/include -include
/media/sdb/gfournier/axiondev/u-boot-fslc/include/linux/kconfig.h
-D__KERNEL__ -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0x17800000 -Wall
-Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os
-fno-stack-protector -g -fstack-usage -Wno-format-nonliteral
-Werror=date-time -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux
-mword-relocations -march=armv7-a -mno-unaligned-access -ffunction-sections
-fdata-sections -fno-common -ffixed-r9 -msoft-float -pipe
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fat)"
-D"KBUILD_MODNAME=KBUILD_STR(fat)" -c -o fs/fat/fat.o fs/fat/fat.c

The previous build without any modifications was not finding lgcc (it's
missing the --sysroot argument).



Here is a build command after the KCFLAGS modification in
environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi.  Not the added
--sysroot:

arm-poky-linux-gnueabi-gcc -Wp,-MD,net/.arp.o.d  -nostdinc -isystem
/media/sdb/gfournier/axiondev/toolchain/sysroots/x86_64-pokysdk-linux/usr/bi
n/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux
-gnueabi/4.9.1/include -Iinclude
-I/media/sdb/gfournier/axiondev/u-boot-fslc/arch/arm/include -include
/media/sdb/gfournier/axiondev/u-boot-fslc/include/linux/kconfig.h
-D__KERNEL__ -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0x17800000 -Wall
-Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os
-fno-stack-protector -g -fstack-usage -Wno-format-nonliteral
-Werror=date-time
--sysroot=/media/sdb/gfournier/axiondev/toolchain/sysroots/cortexa9hf-vfp-ne
on-poky-linux-gnueabi -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux
-mword-relocations -march=armv7-a -mno-unaligned-access -ffunction-sections
-fdata-sections -fno-common -ffixed-r9 -msoft-float -pipe
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(arp)"
-D"KBUILD_MODNAME=KBUILD_STR(arp)" -c -o net/arp.o net/arp.c

The previous build with the KCFLAGS modification is performing as expected
and binary is usable and boots fine.



Here is a build command when calling make LDFLAGS="" CC="$CC" without the
KCFLAGS modification:

arm-poky-linux-gnueabi-gcc  -march=armv7-a -mthumb-interwork
-mfloat-abi=hard -mfpu=neon -mtune=cortex-a9
--sysroot=/media/sdb/gfournier/axiondev/toolchain/sysroots/cortexa9hf-vfp-ne
on-poky-linux-gnueabi -Wp,-MD,net/.bootp.o.d  -nostdinc -isystem
/media/sdb/gfournier/axiondev/toolchain/sysroots/x86_64-pokysdk-linux/usr/bi
n/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux
-gnueabi/4.9.1/include -Iinclude
-I/media/sdb/gfournier/axiondev/u-boot-fslc/arch/arm/include -include
/media/sdb/gfournier/axiondev/u-boot-fslc/include/linux/kconfig.h
-D__KERNEL__ -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0x17800000 -Wall
-Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os
-fno-stack-protector -g -fstack-usage -Wno-format-nonliteral
-Werror=date-time -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux
-mword-relocations -march=armv7-a -mno-unaligned-access -ffunction-sections
-fdata-sections -fno-common -ffixed-r9 -pipe    -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(bootp)"  -D"KBUILD_MODNAME=KBUILD_STR(bootp)"
-c -o net/bootp.o net/bootp.c

Note the huge difference in the build line (and hard vs soft).
The previous build with the make LDFLAGS="" CC="$CC" command line was
creating an unusable binary although it did compile fine.


Long story short, to solve my problem:
Add the following line in the
environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi script:
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"

May I suggest future releases include this modification in the script ?

Thanks guys for all the support!

Guillaume Fournier, eng.
Hardware Designer
Brioconcept Consulting Inc.

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Otavio Salvador]

On Thu, Nov 6, 2014 at 3:31 PM, Guillaume Fournier
<gfournier@brioconcept.com> wrote:
...
> Long story short, to solve my problem:
> Add the following line in the
> environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi script:
> export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
>
> May I suggest future releases include this modification in the script ?

Awesome! Thanks for sharing all this background information.

I will prepare a patch for the environment script and propose it in OE-Core.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Gary Thomas]

On 2014-11-06 10:47, Otavio Salvador wrote:
> On Thu, Nov 6, 2014 at 3:31 PM, Guillaume Fournier
> <gfournier@brioconcept.com> wrote:
> ...
>> Long story short, to solve my problem:
>> Add the following line in the
>> environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi script:
>> export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
>>
>> May I suggest future releases include this modification in the script ?
>
> Awesome! Thanks for sharing all this background information.
>
> I will prepare a patch for the environment script and propose it in OE-Core.

This is fallout of the recent change in OE-core to "poison the GCC sysroot"

   commit 678e8798ebe0f4fd1bd347db136f1499b8fe00c9
   Author: Richard Purdie <richard.purdie@linuxfoundation.org>
   Date:   Fri Oct 24 15:10:25 2014 +0100
     gcc: poison default sysroot path

I suspect to be 100% correct, the KCFLAGS may need other settings
besides the --sysroot, e.g. -march or -mtune

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Unable to get u-boot running on i.MX6 SABRE for Smart Devices Eval Board

[Otavio Salvador]

On Thu, Nov 6, 2014 at 3:53 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2014-11-06 10:47, Otavio Salvador wrote:
>>
>> On Thu, Nov 6, 2014 at 3:31 PM, Guillaume Fournier
>> <gfournier@brioconcept.com> wrote:
>> ...
>>>
>>> Long story short, to solve my problem:
>>> Add the following line in the
>>> environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi script:
>>> export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
>>>
>>> May I suggest future releases include this modification in the script ?
>>
>>
>> Awesome! Thanks for sharing all this background information.
>>
>> I will prepare a patch for the environment script and propose it in
>> OE-Core.
>
>
> This is fallout of the recent change in OE-core to "poison the GCC sysroot"
>
>   commit 678e8798ebe0f4fd1bd347db136f1499b8fe00c9
>   Author: Richard Purdie <richard.purdie@linuxfoundation.org>
>   Date:   Fri Oct 24 15:10:25 2014 +0100
>     gcc: poison default sysroot path
>
> I suspect to be 100% correct, the KCFLAGS may need other settings
> besides the --sysroot, e.g. -march or -mtune

I don't think so. The Linux Kernel and U-Boot are expected to have the
'better' knowledgement about the build flags and it is advised to let
them to handle it.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750