U-Boot on i.MX6

There are a lot of posts in this blog that describe the state of U-Boot for our i.MX6 boards, but most of them describe the history. They were designed to help the early adopters make transitions as we switched from the Freescale U-Boot 2009.08 to main-line and added display support.

Things have stabilized, and in this post, we’ll recap the current state of affairs to provide the new user a quick Getting started guide.

Here are some things you should know about the U-Boot that we ship with our i.MX6 boards:
  • Our boards boot to a serial EEPROM. The i.MX6 processor has a set of internal fuses that control the boot device, and we program these for SPI-NOR. There are a variety of ways to over-ride this, but we don’t recommend them except for very specific needs.
  • The primary U-Boot console is the serial port on a DB-9 labelled console. It’s configured for direct connection to common USB serial adapters (i.e. as DCE). The baud rate is 115200. 8 data bits, no parity, no flow control. If you hit the any key right after power-on, you’ll abort the automatic boot process and get a U-Boot prompt on the serial port.
  • Very new U-Boot images have support for USB keyboard. See this post for details. If you boot without a working 6x_bootscript on SD card or SATA, you’ll get a prompt on the display and USB keyboard in addition to the serial port.
  • Our images will boot from either SD card slot or SATA. The default bootcmd string is set to iterate through all of the boot media on your board, looking for the file 6x_bootscript in partition 1. If found, the script will be run (and won’t return if successful). Note that some userspaces may require the use of a certain boot media. Consult the corresponding documentation for details.
  • Our images will boot from FAT, ext2, ext3, or ext4 filesystems. The default bootcmd variable will try FAT first, then ext2 (which supports ext3 and ext4).
  • If you power-on a device with one of our displays connected, you should get an on-screen image. Display support has been in U-Boot for a while now, and you should see a display without any SD card present.
  • Our default bootcmd is set to run 6x_bootscript. To elaborate, we leave the precise boot instructions to the userspace image itself, since different distributions package things differently and require at least different kernel command-lines. We accomplish this by having a bootcmd which simply loads a distribution-specific startup script (6x_bootscript) from the first partition of either SD card or SATA drive.
  • We provide sample boot scripts for Android and typical non-Android use. You can find these in the directory corresponding to your board in files named 6x_bootscript*. These are just samples though. You will likely need to tailor then for your use in production, because
  • The default boot scripts try to detect your display. There are some notes in this post but from a high-level, suffice it to say that these boot scripts try to provide an easy out-of-the-box experience.
  • Boot scripts are compiled text files consisting of a series of U-Boot commands. The language supports the use of conditionals, so you can test for the presence of files, environment variables, and the like.
  • We have an online tool for compiling boot scripts here that takes care of the arcane mkimage command-line and removes carriage-returns, which the U-Boot hush parser doesn’t like.
  • Don’t assume that you need to re-compile and re-install U-Boot to match your userspace. We routinely boot Linaro, Buildroot, LTIB, Ubuntu, Debian, Timesys, Android, QNX, and Windows Embedded Compact 7 operating systems without re-programming U-Boot. You should only need to re-install U-boot to take advantage of a new feature or to fix a bug. The U in U-Boot stands for Universal and it comes pretty darn close. Many userspace builders will build a U-Boot image for you, but that’s primarily because other platforms are configured for boot to raw SD card and require it. Our boards don’t.
  • Use the 6x_upgrade script and the upgradeu environment variable if you do need an upgrade. You can copy 6x_upgrade and u-boot.imx to an SD card, and upgrade like this:
    U-Boot > run upgradeu
    check U-Boot
    320748 bytes read in 145 ms (2.1 MiB/s)
    read 0x4e4ec bytes from SD card
    SF: Detected SST25VF016B with page size 4 KiB, total 2 MiB
    probed SPI ROM
    byte at 0x1200000d (0xf0) != byte at 0x1240000d (0xfc)
    Total of 13 byte(s) were the same
    Need U-Boot upgrade
    Program in 5 seconds
    Total of 320748 byte(s) were the same
    ---- U-Boot upgraded. reset
  • U-Boot packages – The example of upgradeu above works when you’re compiling U-Boot yourself, as it makes reference to u-boot.imx. If you’re using our production binary package, you’ll either need to re-name one of the files in the package to u-boot.imx or over-ride the boot file like so:
    U-Boot > bootfile=u-boot.nitrogen6q ; run upgradeu
    check U-Boot
    Total of 320748 byte(s) were the same
    ---- U-Boot upgraded. reset
    The following is a list of the image file names for our standard products:

    Nitrogen6 Maxi.MX6Quad/Dual4GBu-boot.nitrogen6_max
    Nitrogen6 Litei.MX6Solo512MBu-boot.nit6xlite
    Nitrogen6 Litei.MX6Solo1GBu-boot.nit6xlite1g
  • If you’re booting to SD card or SATA, you shouldn’t need to set any environment variables before booting. Our sample boot scripts configure most things automatically, and you should generally do the same. If you need to customize the boot environment (usually the bootargs variable), you’ll generally want to hack the boot script instead. This is easier to copy to other machines, and fits nicely into a source repository.
  • If you’re booting over NFS during development, you should hack your environment variables. See the notes below for typical usage.
  • Restore your factory defaults with clearenv.
    U-Boot > run clearenv
    Or better yet, use env default -f -a. We only learned of this nice feature recently, and will likely discard clearenv in the future.

    U-Boot > env default -f -a
  • Our U-Boot source code is on Github. We aim to have all of the code for our standard products in main-line U-Boot, but generally have at least a few patches in flight.
  • Our production branch contains the version that we’re currently shipping for new orders and is typically the most stable and recommended branch.
  • Our staging branch contains the version that we’re prepping for the next release. It may have some bugs, but also may have some new features of interest.

Boot flow

The process of booting an i.MX6 involves multiple steps:
  1. At power-on or reset, the processor starts executing code from on-chip ROM. This code reads the Boot Mode switches, and if they’re in the normal position (Boot from fuses), goes on to read the fuses to find out which media to search for a bootable image.
    In our case, it will see that we have the fuses programmed for serial EEPROM, and should find a U-Boot image at offset 0x400 in that device.
  2. The code in on-chip ROM will read the U-Boot preamble, configuring registers for DDR, then copy U-Boot into DDR and begin U-Boot execution.
  3. U-Boot will wait for bootdelay seconds for a user to abort the boot with a keystroke on the console (the serial port).
  4. If no keystroke is present, U-Boot will execute a set of commands stored in the environment variable bootcmd.
  5. As mentioned above, our default bootcmd is configured to iterate through all bootable media (SATA and both SD cards), looking for 6x_bootscript. If found, the commands inside are executed. In the normal case, these commands will never return because an O/S will be launched.


If step 1 above sees the Boot mode pins in the Serial Boot position, or doesn’t find a valid image in the serial EEPROM, the code in the on-chip ROM will enter serial download mode.

This mode allows a user to download a valid boot image over the USB OTG port, providing a robust means of recovery.

If you connect the USB OTG port to a Linux-based machine (including i.MX6 devices), you can see this in the output of lsusb:
~/$ lsusb
Bus 001 Device 009: ID 15a2:0054 Freescale Semiconductor, Inc. i.MX6Q SystemOnChip in RecoveryMode
We wrote a Linux-based tool called imx_usb that supports this protocol, so you can supply a U-Boot image to the device from the command-line like so:
~/imx_usb_loader$ sudo ./imx_usb u-boot.imx
The sudo is needed to provide access to the raw USB device, and the command-line parameter can be any fully-formed i.MX6 image. In the example above, we’re supplying the U-Boot binary.

You can find more details in the our post on un-bricking an i.MX6.

The Freescale Manufacturing tool does something similar in the first stage, but requires USB OTG support in U-Boot itself, and this is not yet supported in the main-line code base.

The notes below provide some additional details for advanced users. Most users can ignore them.

How to build

Assuming that you have a cross-compiler for armv7 named arm-none-linux-gnueabi-gcc, you can get and compile U-Boot like this:
~$ git clone git://github.com/boundarydevices/u-boot-imx6.git
Resolving deltas: 100% (156593/156593), done.
~$ cd u-boot-imx6
~/u-boot-imx6$ git checkout origin/production -b production
~/u-boot-imx6$ export ARCH=arm
~/u-boot-imx6$ export CROSS_COMPILE=arm-none-linux-gnueabi-
~/u-boot-imx6$ make nitrogen6q_config 
Configuring for nitrogen6q - Board: nitrogen6x, Options: IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024
~/u-boot-imx6$ make all
Generating include/autoconf.mk
~/u-boot-imx6$ ls -l u-boot.imx 
-rw-rw-r-- 1 user group 312572 Nov 26 11:48 u-boot.imx
Key bits embedded in the snippet above include:
  • We selected nitrogen6q_config.
    This is used for both of our most popular boards, the Nitrogen6X and SABRE Lite.
  • We selected the production branch.
  • The output is in the file u-boot.imx
Refer to this post for more detail.

Details about branches on Github

In general, our U-Boot Github repository is used to contain our additions to the upstream U-Boot repository at Denx. Our aim is to stay as close to main-line as possible for our standard boards, and we submit changes whenever we can for those boards.

A number of custom boards aren’t suitable for up-streaming though, and we do generally have additions in our repository that either aren’t worth the noise of pushing up-stream (notably boot script updates) or have not yet made their way through the approval process into the main-line U-Boot code base.

We try to update our repository with the latest from up-stream as quickly as possible after each release cycle, so you’ll have access to all of the efforts by others in the community. This process largely entails moving or re-basing our branch onto the latest version from Denx, but we do usually take steps to reduce the patch set (and clean things up) during those efforts, so we lose a little of the history.

Because many of our customers (especially customers using Nitrogen6X-SOM) create their own branches based on our versions, we’ll keep each of of our branches indefinitely, but they might be re-named. Please shoot us an e-mail if you do this.

Our production branch will move with each official release from us. If you’re trying to decide what branch to build, this is always the one you want. It should represent the most stable, most full-featured code base at any time. As a consequence, the branch name is also unstable. In other words, it will move over time as we jump from one version of U-Boot to the next.

To provide more stable branch names, we’ll also create branches named vYYYY.MM-yyyymmdd each time we complete a re-base. The YYYY.MM will represent the U-Boot version number and yyyymmdd will represent the date on which we re-based. If you need a stable branch name, as the Yocto Project does, you’ll want to use these instead of production. Additional patches may be added to a vYYYY.MM-yyyymmdd branch, but the history won’t be lost.

Basics of launching Linux

In order to boot Linux using U-Boot, you usually need only two things:
  • A working kernel, and
  • A filesystem containing init
But you’ll generally need a third:
  • A set of kernel parameters passed via the bootargs environment variable in U-Boot.
The kernel image is typically stored in a file named uImage and is most commonly stored in the /boot directory of a filesystem, but these are guidelines, not rules. The only important thing is that U-Boot is able to load the kernel into RAM.

The filesystem used at startup (generally referred to as the root filesystem) could be a typical ext2, ext3, ext4 filesystem on SD card or SATA, an accessible NFS share, or a RAM disk image. The only important piece is that you can tell the kernel how to find it at startup time.

Kernel startup is almost always invoked using the bootm command under U-Boot. The first parameter to bootm is the address of a kernel as shown in this example:

U-Boot > mmc dev 0
U-Boot > ext2load mmc 0 10800000 /boot/uImage
U-Boot > bootm 10800000
This simple example shows how to load /boot/uImage into memory address 0x10800000 and launch it.

But wait. We haven’t provided a filesystem reference in this example.

When you invoke bootm using a single parameter, you’ll need to specify the root filesystem indirectly through the bootargs environment variable as shown below. This example tells the kernel to wait for the root filesystem to become available, and that the root filesystem is the partition /dev/mmcblk0p1 (the first partition of the first SD card enumerated on the system).

U-Boot > setenv bootargs $bootargs rootwait root=/dev/mmcblk0p1
U-Boot > mmc dev 0
U-Boot > ext2load mmc 0 10800000 /boot/uImage
U-Boot > bootm 10800000
This is precisely what’s done in the default boot script board/boundary/nitrogen6x/6x_bootscript.txt.

To boot a RAM disk for the root filesystem, you add a second parameter to the bootm command with the load address of the RAM disk and omit the root= clause from bootargs. The following example illustrates this:

U-Boot > mmc dev 0
U-Boot > ext2load mmc 0 10800000 /boot/uImage
U-Boot > ext2load mmc 0 12800000 /boot/uramdisk.img
U-Boot > bootm 10800000 12800000
RAM disks are used in the default Android boot script (board/boundary/nitrogen6x/6x_bootscript_android.txt), but are also useful for other distributions. We used one to put together this image for exposing storage across USB.

Note that there is a third parameter for bootm that’s required for use of the main-line Linux kernel. It supplies something called a device tree, which is used to make the kernel a bit more generic. If you’re working with main-line, it’s likely that you have access to this, so we won’t go into the details here.

How to boot over NFS

Booting over NFS is a straightforward extension of this that simply replaces the root= clause in bootargs with root=/dev/nfs. It does require a couple of additional parameters to the kernel, though:
parametertypical value
The first parameter, nfsroot= tells the kernel where to find a root filesystem and what options to pass to the NFS mount process. A typical value for the entire clause might be nfsroot=,v3,tcp.

The second parameter, ip= is needed because the kernel needs to have an IP address in order to access the network. An IP address is normally done as a part of the userspace startup, but in the case of an NFS root, we can’t wait for that because of the chicken-and-egg problem.

Putting it all together, we can boot over NFS like this:
U-Boot > setenv bootargs $bootargs rootwait root=/dev/nfs
U-Boot > setenv bootargs $bootargs nfsroot=,v3,tcp
U-Boot > setenv bootargs $bootargs ip=dhcp
U-Boot > mmc dev 0
U-Boot > ext2load mmc 0 10800000 /boot/uImage
U-Boot > bootm 10800000
Note that this example doesn’t completely boot over the network, though. The kernel is still loaded from an ext2/3/4 filesystem on partition 1 of the SD card. This brings up the next question:

Loading a file over TFTP

U-Boot contains a number of networking commands, and support for a number of protocols.

The most common are the dhcp and tftp commands, and we generally use the dhcp command to acquire an IP address and transfer a file in a single command like so:
U-Boot > dhcp 10800000
This command will acquire an IP address using DHCP, then request a file named uImage and load it into memory address 0x10800000.

When used in conjunction with the NFS boot arguments, this provides a single, relatively command line to be used for booting:
U-Boot > dhcp 10800000 && bootm 10800000
You may now be understanding why I mentioned the saving of environment variables when booting NFS. There are a number of parameters to provide, including
  • the IP address of the TFTP server, and
  • the IP address and path to the NFS filesystem
If you’re going to save all of these, you might as well just over-write the bootargs variable entirely, and the bootcmd variable while you’re at it.

You can always run clearenv when you’re done.

Important clauses for bootargs:

To recap and expand on the notes above, here are a set of known variables that you might want to set in bootargs under U-Boot:
nametypical valueNotes
consolettymxc1,115200This tells the kernel to send kernel messages to /dev/ttymxc1, the serial console port. You almost always want this set during development, though you might consider turning it off in production, since it can slow the boot process.
enable_wait_modefalseThis variable controls the behavior of the idle loop in the Linux kernel and you may see system stalls without this value set.
See notes above
Defines the display(s). These should be numbered starting at mxcfb0 through mxcfb2 and will translate into a number of device nodes as described in this post.
consoleblank0This variable controls the amount of idle time before the console device goes to sleep. Use consoleblank=0 to disable blanking on idle.
vmalloc400MThis controls the amount of memory available to the kernel for dynamic allocation. You’ll normally want this to be 400M or so on a system running a graphical U/I with accelerated video and graphics.
fbmem28MThis controls the amount of memory allocated for each frame-buffer.
Refer to the documentation for details.
nfsroot192.168.0.62:/path/to/rootfsRefer to the documentation for details.
androidboot.consolettymxc1Tells Android about the console
androidboot.hardwarefreescaleAndroid needs this. Details elsewhere

Booting Yocto

Thanks largely to the efforts of the team at O.S. Systems, the current builds of Yocto using the meta-fsl repositories have a custom boot script that specifies partition 2 for the root filesystem instead of partition 1.

Their efforts show the right thing to do: have the boot script built as a part of the userspace, but not U-Boot itself.

Booting Windows Embedded Compact 7

Coming soon

Booting QNX

Details coming soon, but the general process involves the use of the gocommand:
mmc dev ${disk} && ext2load mmc ${disk} 10800000 /path/to/ifs.ifs && go 10800000

Booting Debian

Details coming soon, but also available on eewiki.



81 Responses to “U-Boot on i.MX6”

  1. ssinfod June 29, 2013 9:41 am #

    Hello, can you please give more instructions on how to boot Yocto and/or Debian for the Sabrelite.
    Right now, I am having problem trying to boot yocto on the SabreLite board.

    Here is the output from the console:

    U-Boot 2009.08 (Aug 16 2012 - 10:06:42)
    CPU:   Freescale i.MX 6 family 0.0V at 792 MHz
    Temperature:   49 C, calibration data 0x5774ed7d
    mx6q pll1: 792MHz
    mx6q pll2: 528MHz
    mx6q pll3: 480MHz
    mx6q pll8: 50MHz
    ipg clock     : 66000000Hz
    ipg per clock : 66000000Hz
    uart clock    : 80000000Hz
    cspi clock    : 60000000Hz
    ahb clock     : 132000000Hz
    axi clock   : 264000000Hz
    emi_slow clock: 29333333Hz
    ddr clock     : 528000000Hz
    usdhc1 clock  : 200000000Hz
    usdhc2 clock  : 200000000Hz
    usdhc3 clock  : 200000000Hz
    usdhc4 clock  : 200000000Hz
    nfc clock     : 24000000Hz
    Board: MX6Q-SABRELITE:[ POR]
    Boot Device: I2C
    I2C:   ready
    DRAM:   1 GB
    JEDEC ID: 0xbf:0x25:0x41
    Reading SPI NOR flash 0xc0000 [0x2000 bytes] -> ram 0x276009b8
    In:    serial
    Out:   serial
    Err:   serial
    Net:   got MAC address from IIM: 00:00:00:00:00:00
    FEC0 [PRIME]
    Hit any key to stop autoboot:  3     2     1     0
    Card did not respond to voltage select!
    mmc0(part 0) is current device
    MMC: block number 0x1 exceeds max(0x0)
    ** Can't read from device 0 **
    ** Unable to use mmc 0:1 for fatload **
    ** Bad partition 1 **
    mmc1 is current device
    reading /6q_bootscript
    ** Unable to read "/6q_bootscript" from mmc 1:1 **
    Loading file "/6q_bootscript" from mmc device 1:1 (xxb1)
    Failed to mount ext2 filesystem...
    ** Bad ext2 partition or disk - mmc 1:1 **


    • ssinfod June 29, 2013 10:50 am #

      Did you change the bootscript filename in recent U-Boot ? (/6q_bootscript vs /6x_bootscript)
      Do I have to update U-Boot if I want to use Yocto on the Sabrelite.
      The current U-Boot on my board is “U-Boot 2009.08 (Aug 16 2012 – 10:06:42)”

      I downloaded the file “u-boot-2013-6-19.tar.gz”.
      Which file is the U-Boot for the Sabrelite. Do I have to rename one of the file to “u-boot.imx” and copy it to the SD card ?


      • ericn June 29, 2013 11:36 am #

        Yes, no, and “no, but recommended”.

        Yes we changed the boot script from 6q_bootscript to 6x_bootscript when we switched to main-line U-Boot. See this post for background about why (essentially incompatibilities in some commands).

        No, it wasn’t recent (November of 2012).

        No, it’s technically not necessary to switch U-Boot versions to run any O/S unless you’re using the main-line kernel, which needs device-tree support. That said, you should upgrade because we’ve fixed some critical bugs, and we recommend switching to the main-line based U-Boot (2013.x) if you want to run any of our images or things like Yocto, because we’re really only providing boot scripts for that platform.

        See this this backgrounder about U-Boot for more details.

      • ericn June 29, 2013 11:39 am #

        Sorry, I forgot to answer the other question.

        The file u-boot.nitrogen6q is the U-Boot for stock (1GB) SABRE Lite and Nitrogen6X boards.

        You can either rename this to u-boot.imx, or use a new feature of the upgradeu command to specify the filename:

        U-Boot > bootfile=u-boot.nitrogen6q && run upgradeu
        • ssinfod June 29, 2013 4:08 pm #

          I did the “Switching U-Boot versions on i.MX6″ explains in this page:

          The update was successful.

          However, it is still looking for the “6q_bootscript” after the update.
          Do I have to clear the env variable after the update ? (run clearenv)

          How do I change the bootloader (U-Boot) or it settings to call “6x_bootscript instead of 6q_bootscript” ?

          See log:

          U-Boot 2013.01-rc1-00120-g7c28db0 (Nov 12 2012 - 09:15:04)
          arm-none-linux-gnueabi-gcc (4.4.4_09.06.2010) 4.4.4
          GNU ld (GNU Binutils)
          U-Boot > 
          U-Boot > pprriinntteennvv
          bootargs=console=ttymxc1,115200 root=/dev/mmcblk0p2 rootwait video=mxcfb0:dev=hdmi,1280x800M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-SVGA,if=RGB666
          bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
          bootcmd=run bootcmd_mmc
          bootcmd_mmc= for disk in 0 1 ; do mmc dev ${disk} ;for fs in fat ext2 ; do ${fs}load mmc ${disk}:1 10008000 /6q_bootscript && source 10008000 ; done ; done
          bootcmd_net=run bootargs_nfs;tftpboot ${loadaddr} ${kernel}; bootm
          clearenv=sf probe 1 && sf erase 0xc0000 0x2000 && echo restored environment to factory default
          mmcargs=setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24
          upgradeu=for disk in 0 1 ; do mmc dev ${disk} ;for fs in fat ext2 ; do ${fs}load mmc ${disk}:1 10008000 /6q_upgrade && source 10008000 ; done ; done
          Environment size: 1178/8188 bytes
          U-Boot > rruunn  uuppggrraaddeeuu
          Card did not respond to voltage select!
          mmc0(part 0) is current device
          Card did not respond to voltage select!
          ** Bad device mmc 0 **
          Card did not respond to voltage select!
          ** Bad device mmc 0 **
          mmc1 is current device
          reading /6q_upgrade
          ** Unable to read file /6q_upgrade **
          Failed to mount ext2 filesystem...
          ** Unrecognized filesystem type **
          U-Boot > 
          U-Boot > 


          • ericn June 29, 2013 8:10 pm

            Yep. You need to run clearenv && reset or env default -a && saveenv && boot.

            Your environment (and bootcmd) was saved by the previous version.

  2. ssinfod June 30, 2013 6:51 am #

    It works now.
    I have yocto running on the Sabrelite after I updated U-Boot and clear the env variables.


  3. Andrew July 12, 2013 7:46 am #

    Is it possible to use the unused memory of the spi-nor on the sabrelite as scratchpad memory? Would you be able to provide a memory map of this device including the unused portion? I’d like to experiment with freescale’s kernel level spi driver for reading and writing to this scratchpad memory. Thanks!

  4. Bill Yang July 22, 2013 1:37 pm #

    Hi Eric,

    I have followed “How to Build” section above, but when I “make all” , it pop up error messages as below listings. Can you comment this problem for me? Note: the ARCH=arm and CROSS_COMPILE=arm-none-linux-gnueabi- have been exported.

    byang@byang-EP45T-UD3P:~/u-boot-imx6$ sudo make all
    /bin/bash: arm-linux-gcc: command not found
    /bin/bash: arm-linux-gcc: command not found
    dirname: missing operand
    Try `dirname –help’ for more information.
    Generating include/autoconf.mk
    /bin/bash: line 3: arm-linux-gcc: command not found
    Generating include/autoconf.mk.dep
    /bin/bash: line 3: arm-linux-gcc: command not found
    /bin/bash: arm-linux-gcc: command not found
    /bin/bash: arm-linux-gcc: command not found
    dirname: missing operand
    Try `dirname –help’ for more information.
    /bin/bash: arm-linux-gcc: command not found
    /bin/bash: arm-linux-ld: command not found
    arm-linux-gcc -DDO_DEPS_ONLY \
    -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -I/home/byang/u-boot-imx6/include -fno-builtin -ffreestanding -nostdinc -isystem -pipe -DCONFIG_ARM -D__ARM__ -march=armv5 -Wall -Wstrict-prototypes \
    -o lib/asm-offsets.s lib/asm-offsets.c -c -S
    /bin/bash: arm-linux-gcc: command not found
    make: *** [lib/asm-offsets.s] Error 127

    • ericn July 22, 2013 2:41 pm #

      Hi Bill,

      You need a cross-compiler for ARMv7

      • Bill Yang July 23, 2013 8:16 am #

        Hi Eric,

        How to install the cross-compile ARMv7?

        My linux machine (ubuntu and LTIB) was working every demo on Nitrogen6x board, e.g. build u-boot-2009-8 and rebuilding Boundary’s kernel/modules. Everything was good. Since I tried to build Yocto image for Qt. I found something broken that I could not go back to re-build any demo on LTIB. I tried to build u-boot.imx, it pop up the error “/bin/bash: arm-linux-gcc: command not found”.

        I tried to re-bould u-boot-2009.8 and got the same error. Eventhough I cannot build kernel and modules now. I hope someone may help me to figure out what was happened in my senario.


      • Bill Yang July 23, 2013 11:17 am #


        What means needing a cross-compiler for ARMv7? I have used CROSS_COMPILE=arm-fsl-linux-gnueabi- to make u-boot. But it still gets error. Please help me to fix this issue.

        /bin/bash: arm-fsl-linux-gnueabi-gcc: command not found
        /bin/bash: arm-fsl-linux-gnueabi-gcc: command not found
        dirname: missing operand

  5. Bill Yang July 25, 2013 9:05 am #

    Hi Eric,

    I need to modify the pin definitions in the file, nitrogen6x.c under u-boot-imx6, to meet our application. But it failed to compile. e.g.
    Original is from:
    Need to be changed to:

    I tried to locate the header file like, nitrogen6x.h. But I could not find it. I wonder if you know where or which file has the definitions of those pins?

  6. shniew August 8, 2013 10:13 pm #

    Hi Eric,

    Is there support GPT partition? I’m using version 2013.04-00316-g1903727, it failed.
    Any chance? Please help.

  7. Pratik August 20, 2013 5:22 am #

    Hi all,
    I am having sabrelite board.I have upgraded uboot on it to support android jelly bean.
    I am having questions regarding fastboot. when i connect board to linux pc using usb & run fastboot command. It only shows .
    As i am new to android I am having some simple questions like

    How can i solve this?
    Is it necessary to have fastboot compatible bootloader on board?
    Is host(pc) need to have specific driver for each board?

    thanks in advanced,

  8. ahmad August 29, 2013 12:53 pm #

    hi all ,
    when i start my kit it starts ok and runs the u-boot after that i made debugging on it with test example that run on ram at add 0x900000 and it’s debug ok .
    when i reset the kit it doesn’t boot and when i make debugging with another example it return cable not found or

    • ericn August 29, 2013 12:59 pm #

      Are you using an ARM DStream debugger by chance?

  9. ahmad August 29, 2013 1:16 pm #

    i used macriagor (http://www.macraigor.com/)tools

  10. David W September 3, 2013 4:19 pm #

    I’m having a problem compiling U-Boot for a Nitorgen6x board. I downloaded the code with the following command:

    git clone git://git.denx.de/u-boot-imx.git

    Then I tried to compile with the following two commands:

    make nitrogen6q_config

    On a Red Hat machine I get File format not recognized errors. If I enter make I get beyond the error and on to another. The last error I get is “strip:proftool: File format not recognized”. I cannot get past this error. On an Ubuntu machine the linker gets undefined references for all the function calls to functions defined in common/iomux.c, then the linker gets a segmentation fault. The cause of the former is that arch/arm/imx-common.c, rather than common/iomux.c, is included and that doesn’t have the missing needed functions defined.

    • ericn September 3, 2013 5:28 pm #

      Hi David,

      You’re going to need to set the “ARCH=arm” and “CROSS_COMPILE=/path/to/cross-compiler…” environment variables.

      I’d also suggest that you use our git repository instead of the main-line (there are a few enhancements that haven’t made
      their way into the head).

      There are some notes in this post.

      • David W September 9, 2013 7:20 am #


        Thanks. I had CROSS_COMPILE set, but not ARCH, so I set that, and I still get the same errors on the Red Hat and Ubuntu machines

        • ericn September 9, 2013 8:27 am #

          Hi David,

          Can you re-run with V=1 and find out which strip is being invoked?

          • David W September 9, 2013 8:50 am


            Running with or without V=1 the following line is output:

            strip proftool

          • ericn September 9, 2013 9:39 am

            Do you have ‘strip’ installed? It looks like it’s being invoked
            through the HOSTSTRIP environment variable on tools/proftool.

            Can you run which strip and file tools/proftool?

          • David W September 9, 2013 12:30 pm

            On the Red Hat machine:

            which strip yields:
            file tools/proftool yields:
            tools/proftool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

            On the Ubuntu machine
            which strip yields:
            file tools/proftool yields:
            tools/proftool: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x9a77a5584eb4f590e81fb102955c55c6cf22ce13, stripped

          • ericn September 9, 2013 1:58 pm

            Ahah!… I’ve seen this before with the Timesys package. They seem to put the cross-compiler version ahead of the native version. If you swap around your path on the Red-Hat machine, such that /usr/bin comes before /opt/armv71-timeys…, you should be able to build successfully.

            I’m stumped by why your Ubuntu machine isn’t working. Can you run strip tools/proftool by hand?

          • David W September 9, 2013 3:03 pm

            Voilà, I was able to compile on the Red Hat machine. Thanks. As to the Ubuntu machine, I should be compiling on the Red Hat machine. I only switched to the Ubuntu machine when I couldn’t compile on the Red Hat machine. So now I’m back on the Red Hat machine, and I won’t worry about compiling on the Ubuntu machine. Now I have one more question. Since I’m fairly new with U-Boot, how exactly do I get the code from your git repository?

          • ericn September 9, 2013 3:32 pm

            Hi David,

            The recommended method is git:

            ~/$ git clone git://github.com/boundarydevices/u-boot-imx6.git
            ~/$ cd u-boot-imx6
            ~/u-boot-imx6$ git checkout origin/production -b production
          • David W September 24, 2013 2:09 pm

            Thanks. I build with the latest code now. However, upgradeu has stopped working. I can run U-Boot using sb_loader, but when I enter run upgradeu I get the following:

            U-Boot > run upgradeu
            SATA device 0: Model:  Firm:  Ser#:
                        Type: Hard Disk
                        Capacity: not available
            ... is now current device
            ** Bad device size - sata 0 **
            ** Bad device size - sata 0 **
            SATA device 1: unknown device
            ** Bad device sata 1 **
            ** Bad device sata 1 **
            mmc0 is current device
            ** Unrecognized filesystem type **
            1744 bytes read in 73 ms (22.5 KiB/s)
            ## Executing script at 10008000
            check U-Boot
            336016 bytes read in 72 ms (4.4 MiB/s)
            read 52090 bytes from SD card
            SF: Detected SST25VF016B with page size 4 KiB, total 2 MiB
            probed SPI ROM
            SF: 336016 bytes @ 0x400 Read: OK
            byte at 0x1204fc00 (0xc0) != byte at 0x1244fc00 (0x0)
            Total of 326656 byte(s) were the same
            Need U-Boot upgrade
            Program in 5 seconds
            SF: 327680 bytes @ 0x0 Erased: OK
            SF: 336016 bytes @ 0x400 Written: OK
            SF: 336016 bytes @ 0x400 Read: OK
            byte at 0x1204fc00 (0xc0) != byte at 0x1244fc00 (0x0)
            Total of 326656 byte(s) were the same
            Read verification error
            MMC: no card present
            mmc1(part 0) is current device
            MMC: no card present
            ** Bad device mmc 1 **
            MMC: no card present
            ** Bad device mmc 1 **
            U-Boot >

            Please let me know if you have any idea what the problem might be.

          • ericn September 24, 2013 2:20 pm

            Hi David,

            Unfortunately, I know exactly what the problem is (since we’ve hit this before). The 6x_upgrade script originally only erased 0x50000 bytes, and U-Boot grew bigger than that. Note that the offset above is 0x50000-0x400 bytes into the image.

            Please use the boot script that’s part of the latest production package:

            Can you tell me where you got your existing one? We’ll need to make sure it’s fixed at the source.

          • David W September 26, 2013 8:26 am


            Thanks. The new upgradeu works. I think the version we were using came with the board.

            Meanwhile I have a question about the code. In nitrogen6x.c here are lines 744-748:

            /* Turn on LDB0,IPU,IPU DI0 clocks */
            reg = __raw_readl(&mxc_ccm->CCGR3);
            reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET
            writel(reg, &mxc_ccm->CCGR3);

            Isn’t MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET the amount the value put in that field of the register should be shifted by?

          • ericn September 26, 2013 8:32 am

            You’re absolutely right David.

            We should pull in this patch, but haven’t yet.

          • David W September 26, 2013 8:43 am

            I had made that change myself. But shouldn’t MXC_CCM_CCGR3_LDB_DI0_MASK also be or’ed in?

          • ericn September 26, 2013 9:30 am

            Hi David,

            That part’s done in the board file (nitrogen6x.c) in the setup_display() function. It probably doesn’t make sense to enable the LDB clock except on boards that expose LDB…

          • David W September 26, 2013 11:03 am


            The code I referred to is in the setup_display() function. I’ve added or’ing in MXC_CCM_CCGR3_LDB_DI0_MASK, but I still haven’t gotten the LVDS display to work with U-Boot.

          • ericn September 26, 2013 11:34 am

            Hi David,

            I think you may be looking in the wrong place. The bug (and patches) mentioned don’t appear to have any effect, since a value of 2 in CCGR3 bits 0 and 1 appears to have the same function as 01 and 03. You can test this by hand using the mm command to access the register:

            U-Boot > mm 0x020C4074
            020c4074: 3ff0300e ? 0x3ff0300d

            I just ran the command above with a 10.1″ LVDS panel and things worked with either setting.

            What kind of display are you connecting?

          • David W September 26, 2013 12:00 pm


            I found the same thing with CCGR3 bits 0 and 1. However, when I didn’t set anything in the register, U-Boot didn’t come up.

            Thanks for telling me about the mm command. I can check all the registers now without using debug code.

            The display I’m using is an 800 x 480 RGB Tianma, connected through an FPD-Link board.

  11. David W September 27, 2013 8:33 am #

    I’ve given up trying to get the LVDS display to work in U-Boot for now and have moved on to Linux. But now, U-Boot has stopped booting Linux. I get the message, “6x_bootscript not found”, but when I do an ls mmc 0, it’s there.

    • David W September 27, 2013 2:10 pm #

      I found the problem occurred when I complile 6x_bootscript.txt, but it went away when I compiled with the Boundary Devices web-based tool.

      • ericn September 27, 2013 3:45 pm #

        Note that the web-based tool also removes DOS-style line-ends if you happen to be using a Windows-based editor.

  12. phil October 1, 2013 8:26 am #

    I’m having an issue loading a u-boot binary that I compiled onto my 6x (I want to have a 2G version of production). I keep getting a “Read verification error”. Trying out the binary – gives, no surprise, a bricked board. The issue though seems to be with the ‘upgradeu’ command not writing to the flash correctly. I’m not sure how to debug this…. Here’s the output I get:

    ## Executing script at 10008000
    check U-Boot
    335056 bytes read in 185 ms (1.7 MiB/s)
    read 51cd0 bytes from SD card
    SF: Detected SST25VF016B with page size 4 KiB, total 2 MiB
    probed SPI ROM
    byte at 0x1200002e (0x18) != byte at 0x1240002e (0x10)
    Total of 46 byte(s) were the same
    Need U-Boot upgrade
    Program in 5 seconds

    byte at 0x12051c00 (0xa4) != byte at 0x12451c00 (0x4)
    Total of 334848 byte(s) were the same
    Read verification error

    • phil October 1, 2013 8:44 am #

      Sorry I should have read all the comments better – this was already answered… I used the 6x_upgrade from production and it worked. I suspected that not enough flash was being erased. I got my version 6x_upgrade from the Ubuntu 4.0.0 build – the tar.gz file linked to on this page: http://boundarydevices.com/freescale-ubuntu-image-with-4-0-0-kernel/. Updating this build with the production 6x_upgrade would be good.

      • ericn October 1, 2013 9:01 am #

        Thanks for the link.

        I’ll update that image.

    • ericn October 1, 2013 9:00 am #

      Hi Phil,

      I think you have an old version of 6x_upgrade. Please use the latest from
      this tar-ball:

      If you look at yours, you’ll find that it only erases 0x50000 bytes, and U-Boot has grown bigger than that:

      ~/$ strings 6x_upgrade | grep erase
  13. digbyt November 11, 2013 12:59 pm #

    I just tried to upgrade my u-boot to the production version ‘u-boot-production.tar.gz’…

    My board is a ‘saber lite’ quad core, so the most appropriate image seemed to be ‘u-boot.mx6qsabrelite’. I followed the instructions, which seemed to work successfully. But on rebooting, I didn’t see all the usual default environment settings, such as the upgradeu command… even after resetting to defaults. So I am not bricked, but I don’t seem to have the standard environment for booting these boards.

    I also just noticed a comment above stating:
    The file u-boot.nitrogen6q is the U-Boot for stock (1GB) SABRE Lite and Nitrogen6X boards.

    Did I use the wrong image? If so, what is the u-boot.mx6qsabrelite for? I assume I now need to do something like:
    mmc dev 1
    fatload mmc 1:1 10008000 /6q_upgrade && source 10008000
    to install a different u-boot. Is that right? I can see the files with ‘fatls mmc 1:1′ so at least I seem to be reading the micro sd card ok.

    I assume I can use the files from ‘6xupgrade’ from ‘6x_downgrade-20121109.zip’ to return to the original u-boot (6q_) image my board shipped with. But the 6q_script that came with ‘6q_upgrade-20121109.zip’ wont be usable from where I am.

    Which script should I use to go from a 6x_.. u-boot to another 6x_… u-boot? the one which came with the 6x_downgrade, or the one that came with the production set? The former is 2012 bytes, and the latter is 1401, so there seems to be a significant difference.

    Any advice appreciated.


    • ericn November 11, 2013 1:11 pm #

      Hi Digby,

      Yeah. The ‘mx6qsabrelite’ configuration is in the list primarily for Freescalers who do things differently than we do, so our documentation (and boot script) doesn’t apply to that image.

      I’ll walk through the steps needed to get you back on track shortly.

      You’ll have to perform a couple of steps by hand, but they aren’t too difficult…

    • ericn November 11, 2013 1:21 pm #

      Here you go Digby.

      These steps should put you back in business:

      U-Boot > mmc dev 1
      mmc1 is current device
      U-Boot > fatload mmc 1:1 10800000 /u-boot.nitrogen6q
      reading /u-boot.nitrogen6q
      330752 bytes read in 33 ms (9.6 MiB/s)
      U-Boot > sf probe
      SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB
      U-Boot > sf erase 0 0xc0000
      SF: 786432 bytes @ 0x0 Erased: OK
      U-Boot > sf write 10800000 0x400 $filesize
      SF: 330752 bytes @ 0x400 Written: OK
      U-Boot > reset
      resetting ...

      You may also want/need to clear out your environment if you saved anything:

      U-Boot 2013.10-00049-ge2ee7f4 (Nov 07 2013 - 10:50:45)
      CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
      Reset cause: POR
      Board: SABRE Lite
      DRAM:  1 GiB
      MMC:   FSL_SDHC: 0, FSL_SDHC: 1
      SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB
      auto-detected panel HDMI
      Display: HDMI (1024x768)
      In:    serial
      Out:   serial
      Err:   serial
      Net:   using phy at 6
      FEC [PRIME]
      Hit any key to stop autoboot:  0 
      U-Boot > 
      U-Boot > 
      U-Boot > run clearenv
      SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB
      SF: 8192 bytes @ 0xc0000 Erased: OK
      restored environment to factory default
      U-Boot > 
  14. digbyt November 11, 2013 1:48 pm #

    Thanks Eric! That worked like a charm!

    Its a great little board, and the support is excellent judging by how quickly you responded. But I am still finding all the image choices quite confusing.

    Closest I have been to a stable system so far was the oneiric-imx6-20120626.gz image which I started with because I could use it without tackling a u-boot upgrade. I was stable, but I never got the display to work, and I read that the can bus I was having trouble with wouldnt work till I upgraded.

    I next tried oneiric-imx6-20130307.tar.gz after getting up the courage to run 6q_upgrade-20121109.zip,
    but I kept getting kernel panics whenever I did anything which caused a lot of writes to the micro sd. I read something about some timing fixes is the latest u-boot, and the description of being ‘production’ made it sound worth another go at bootloader upgrade. The only other idea I had of why the newer image wasn’t stable for me was that the SD card I am using has some compatability issue. It is slower than the one with my older system on it (only class 4), but it seems to work ok on the host system that wrote the image.

    I was thinking of trying one of the newer images, but they look a lot smaller, and I am behind a firewall which doesn’t let me use apt, so I have been having to manually locate and download .deb files and any related dependencies, which is tedious.

    Anyway, if you have any suggestions of what might be going wrong, or the best image to start with, please let me know. I’ll do some testing to see if the u-boot upgrade makes any difference (although I think it is a long shot).

    Thanks again,

    • ericn November 11, 2013 2:49 pm #

      Hi Digby,

      Thanks for the feedback. As I think you’ve figured out, we struggle with the question of userspaces (images).

      Every one of the projects behind a userspace is much bigger than our primary role of kernel and boot loader (the hardware-specific bits).

      For desktop-oriented systems (i.e. native build environments), we recommend either the Linaro Ubuntu or Debian images as a starting point. The Freescale Oneiric images are quite old by now, and won’t get proper package updates.

      Some users have also reported good results with ArchLinuxArm, but we don’t have any experience in that area.

  15. digbyt November 11, 2013 2:33 pm #


    The release u-boot did seem to make a difference! It took a number of attempts to get it to boot (kept getting stuck at ‘Freeing init memory: 200K’, but once it did boot, it has been stable and I havn’t seen any of the kernel crashes I was getting before. The display even came up!!


    • ericn November 11, 2013 2:43 pm #

      I’m glad to hear that, Digby.

  16. Arun December 4, 2013 3:15 am #

    Hi Eric ,

    Can we keep U-boot image in SD Card and boot from SD Card?

    Thanking you,

  17. Arun December 4, 2013 3:18 am #

    Hi Eric ,

    Can we keep U-boot image in SD Card partition and boot(U-Boot to Ram) from SD Card in Nitrogen6X board with i.Mx6 solo processor?

    Thanking you,

    • ericn December 4, 2013 7:00 am #

      Hi Arun,

      Our boards are configured (fuses blown) to boot from SPI-NOR, so U-Boot should be loaded there.

  18. David W February 27, 2014 9:44 am #

    I’m trying to build U-Boot and I get the following error: cc1: error: unrecognized command line option ‘-mno-unaligned-access’. Please let me know what might cause that.

    • ericn February 27, 2014 9:46 am #

      Hi David,

      Did you export “ARCH=arm” and “CROSS_COMPILE=arm-linux-gnueabihf-” or somesuch?

      It sounds as if you’re trying to build with your native compiler.

      • David W February 27, 2014 9:53 am #

        I first put my response in the wrong place.


        I have the following:


        • ericn February 27, 2014 10:00 am #

          Hi David,

          That should work.

          Can you post the command-line used when the error is produced (use ‘make V=1′)?

          • David W February 27, 2014 12:15 pm


            Here it is:

            make[1]: Entering directory `/home/david.wald/ray_uboot/u-boot-imx-patches-2013.10/common’
            armv7l-timesys-linux-gnueabi-gcc -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x17800000 -I/home/david.wald/ray_uboot/u-boot-imx-patches-2013.10/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/armv71-timesys/nitrogen6x/toolchain/bin/../lib/gcc/armv7l-timesys-linux-gnueabi/4.6.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -o cmd_version.o cmd_version.c -c
            armv7l-timesys-linux-gnueabi-gcc -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x17800000 -I/home/david.wald/ray_uboot/u-boot-imx-patches-2013.10/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/armv71-timesys/nitrogen6x/toolchain/bin/../lib/gcc/armv7l-timesys-linux-gnueabi/4.6.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv7-a -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage -mno-unaligned-access -o fdt_support.o fdt_support.c -c
            cc1: error: unrecognized command line option ‘-mno-unaligned-access’

          • ericn February 27, 2014 12:26 pm

            Hi David,

            It looks like an update is needed for the Timesys toolchain.

            Are you running Ubuntu on your dev machine? If so, can you switch to arm-linux-gnueabihf- provided by the gcc-arm-linux-gnueabihf package?

            ~/$ sudo apt-get install gcc-arm-linux-gnueabihf
          • David W February 27, 2014 12:51 pm


            Thanks. We’re developing on Redhat, but it turned out we had a newer toolchain, so I switched to that and the problem went away.

  19. Paul M March 16, 2014 4:51 am #

    Is it possible to know which is the on-chip ROM code and, in case, is it possible to change it?

  20. David April 15, 2014 8:25 pm #

    I purchased a sabre-lite board. Boots ok. On the hdmi — there is the timesys demo.
    On the serial console I can see quite a bit.
    I need to disable the demo and make the hdmi/usb kbd the console.
    How do I do this?

    • ericn April 19, 2014 1:26 pm #

      Hi David,

      The short answer is to use Timesys’ LinuxLink tools to create an image that matches your needs.

      You can also hand-edit the image startup scripts (/etc/init.d/) and execute a getty on /dev/tty0, but there aren’t many tool installed inside the demo image.

  21. Peter April 27, 2014 9:47 pm #

    Hey, I was wondering if you would be able to tell me how I would find out if I need to upgrade u-boot. I am currently using a utilite pro with: (see below) I do not want Ubuntu on the SSD I would rather have Kali or Debian Linux. But, I recently have had some issues with nand and booting. Went in and fixed the env to be able to boot to sdcard. Before I get an OS installed I would like to make sure that I have the latest boot files needed to utilize the most from the imx6 and board. All help welcome. =)


    CPU Freescale i.MX6 quad-core Cortex-A9 @ 1.2GHz
    Memory 2GB DDR3-1066 (soldered on-board)
    Storage SATA SSD 32GB
    Micro-SD socket

    Display and Graphics

    GPU Graphics Processing Unit supporting OpenGL ES 1.1 and 2.0, OpenVG 1.1 and OpenCL EP
    Video Processing Unit supporting multi-stream 1080p H.264, VC1, RV10, DivX HW decoding
    Primary Display HDMI 1.4 max resolution 1920 x 1200
    Secondary Display DVI-D max resolution 1920 x 1200

    Network LAN Two 1000 BaseT Ethernet ports
    WiFi 802.11b/g/n Wi-Fi, single antenna
    Bluetooth Bluetooth 3.0


    Audio S/PDIF 5.1 (electrical through 3.5mm jack)
    Stereo line-out, Stereo line-in
    USB Four USB 2.0 standard A type connector – max current 1A per port
    USB OTG micro-USB connector
    Serial Two RS232 serial ports, ultra mini serial connector

    Mechanical and

    Dimensions 135mm x 100mm x 21mm
    5.3″ x 3.9″ x 0.8″
    Power Supply Unregulated 10 to 16 volt input
    Power 4W – 8W (depending on system load)
    Operating Temperature Commercial: 0C – 45C
    Extended: -20C – 60C

    • ericn April 28, 2014 7:23 am #

      Hi Peter,

      Please contact the folks at Utilite for answers to this question.

  22. jcd May 10, 2014 9:25 am #


    I am looking for a way to get u-boot to pass a pointer to a flattened device tree blob as a third argument.

    unfortunately the usual command (see below) does not work.

    bootm 0x10200000 – 0x10800000

    0x10200000 is a pointer to my kernel file brought to memory with fatload
    0x10800000 is a pointer to my dtb file brought to memory with fatload

    The 3rd argument seems to be ignored by u-boot on the saberlite (while this same command is OK on other ARM based boards.

    What do I miss?



    • ericn May 11, 2014 7:30 am #

      Hi JC,

      I’d suggest that you use the same addresses as in our standard 6x_bootscript. If you look in that script, you’ll see that we:

      • load the DTB at address 0x12000000
      • set fdt_addr to 0x11000000, and
      • set fdt_high to 0xffffffff
  23. freewaymad May 23, 2014 12:39 am #


    I wanted to if there was a way to open a u-boot.bin file after it was already compiled? In other words I have an actual tablet with a sabrelite board in it, but I cannot get it to even come on when the rom is flashed. I know the bootloader where this code is run. I have opened the tablet up figuring I could go the USB to TTL route but nothing is marked for that. I was referred here from Freescale Community because of your work with u-boot. It would be really cool to see the jb4.3 rom on an actual tablet. Everything else is exactly the same except for the u-boot. Maybe there is a script that cold be run to tell me the information needed. Any help would be greatly appreciated.

    Thank you,

    • ericn May 23, 2014 7:16 am #

      I don’t understand the question.

      You can open files in all sorts of ways (gedit, objdump, hexdump).

      • freewaymad May 23, 2014 12:48 pm #

        Hi Eric,

        From the other post, you determined the uImage_update is a wrapper. I guess then my question would be do I need to extract the u-boot off my tablet, or can I get the information I need from the uImage_update? I am lost. I cannot get the tablet to even come on when I flash the new rom.


        • ericn May 23, 2014 6:00 pm #

          Hello freewaymad (Dave?),

          We don’t produce a tablet. Are you trying to hack a third-party device?

          If so, have you asked the vendor for the sources? Both the Linux kernel and U-Boot are GPL’d, so there’s a legal requirement to provide that.

          • freewaymad May 23, 2014 6:52 pm

            Hi Eric,

            Yeah it’s me Dave. I replied about getting the sources. Yes it is a tablet with a reference SABRE Lite board . Getting the sources has been a challenge.

  24. tsheffield July 17, 2014 1:28 pm #

    Hi Eric,
    Here’s a question for you – we’d like to put Uboot on an SD card and boot that way, because our on-the-way HW has no SPI flash and we’re counting on that method. You mention it’s not recommended, but that you may have some hints at making the change. Can you enlighten us? We’re having problems writing the lock bits with our debugger that would in theory lock the BOOT_CFG bits into SD mode instead of serial ROM mode.

  25. ericn July 18, 2014 11:57 am #

    You can use the bmode mmc0 command. You can even save it in the bootcmd variable, so it happens at every boot cycle.

    U-Boot > setenv bootcmd "bmode mmc0"
    U-Boot > saveenv

    Note that this will still load our U-Boot first, but will reset upon execution so you can test your card.

    • tsheffield July 18, 2014 12:36 pm #

      Thanks Eric. If I understand correctly, the best we can do with this HW is boot ROM-> spi flash uboot -> sd card uboot to test the sd card version, but we can’t actually set it for sd card Uboot direct. Is this because of blown fuses?

      • ericn July 18, 2014 12:54 pm #

        Right. We can’t unblow a fuse.

  26. Helbirah August 30, 2014 5:50 pm #

    I erased /dev/mtd0, and now I can’t see any response in console. Is there a way to recover the bootloader?

    • ericn August 30, 2014 6:08 pm #

      Hi Helbirah,

      You can use the steps in this post to get U-Boot running, and then use upgradeu to re-flash.

Leave a Reply