Quantcast
Channel: Boundary Devices
Viewing all 391 articles
Browse latest View live

i.MX6 Video acceleration on Ubuntu Raring (and Debian)

$
0
0
When we recently posted Linaro Raring images for i.MX6, we were surprised at the number responses regarding hardware acceleration, and especially video acceleration.

For a long time now, we’ve been saying that it could be done, but leaving it as an exercise for the reader. In other words, go read the manuals and figure it out. Based on the response, it’s probably time to show some details.

It’s not very pretty, but the following will show you how it can be done. I recommend a full cup of coffee and a SATA drive, because almost all of this will occur on the device, and native compilation is very slow on SD card.

Also note that these notes apply and have been tested on Debian Wheezy, except that the names of some of the prerequisites are different. Also note that I’m starting with raring-nano to make sure I capture all of them.

First, the pre-requisites

First, make sure your system is up-to-date:
root@linaro-nano:~# apt-get update
Then you’ll need a compiler:
root@linaro-nano:~# apt-get install build-essential
And the ability to compile gstreamer plugins:
root@linaro-nano:~# apt-get install libgstreamer-plugins-base0.10-dev
root@linaro-nano:~# apt-get build-dep gst-plugins-base0.10
During the steps above, you’re going to get messages like this:
/sbin/ldconfig.real: /usr/lib/libOpenVG.so is not a symbolic link
In English, this is a warning that the Vivante libraries we installed don’t follow proper Linux shared-library versioning standards (where .so files are supposed to be symlinks to .so.version).

You can safely ignore them.

Then get the packages

The packages required for building the gstreamer plugins are as follows:
  • A set of kernel headers
  • firmware-imx-3.5.7-1.0.0
  • imx-lib-3.5.7-1.0.0
  • fsl-alsa-plugins-3.5.7-1.0.0
  • libfslcodec-3.5.7-1.0.0
  • libfslparser-3.5.7-1.0.0
  • libfslvpuwrap-3.5.7-1.0.0
  • gst-fsl-plugins-3.5.7-1.0.0

Kernel headers

Because some of these packages use hardware-specific APIs, they expect some i.MX6-specific header files to be present in /usr/include on the build machine.

There are two simple ways to accomplish this:
  1. If you’ve already built the kernel, you can use the headers_install target in the kernel build tree to create a set of headers and simply copy them into /usr/include, or
  2. You can use the Debian approach of make-kpkg to build a linux-headers-versionnum.deb package and use dpkg -i to install it.
To make this easy, we’ve uploaded a package to our cloud storage site with a recent version of the tar-ball version that you can grab and extract as shown below. We had some difficulty with make-kpkg generating an armhf package with a cross-compiler.
root@linaro-nano:~# wget http://commondatastorage.googleapis.com/boundarydevices.com/linux-headers-3.0.35-02829-gac24896_4.1.0.tar.gz
root@linaro-nano:~# tar zxvf linux-headers-3.0.35-02829-gac24896_4.1.0.tar.gz -C /usr

Getting the other packages from Freescale – the LTIB way

There are two routes to the other packages, which are distributed by Freescale. The first is to download two packages from the Freescale 3.0.35_4.1.0 release page:

Inside the L3.0.35_4.1.0_ER_SOURCE_BSP package, you’ll find tar-balls for both the imx-lib-3.0.35-4.1.0 and firmware-imx-3.0.35-4.1.0 packages, and you’ll find tar-balls of the other packages inside L3.0.35_4.1.0_MM_CODECS package in the ltib codecs directory. Note that although there are .deb packages inside the codec package, we weren’t successful in compiling from them.

Getting the other packages from Freescale – the Yocto way

Another way to get the codec and BSP packages is to download them from the Freescale Yocto repository at http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/. This location allows for automated download, but because some of the sources require acceptance of a EULA, they’re packaged as self-extracting shell scripts (.bin files).

Getting the packages is very easy using this route:
# first, the open-source codec package:
root@linaro-nano:~# wget http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/gst-fsl-plugins-3.5.7-1.0.0.tar.gz
# then the restricted files
root@linaro-nano:~# for pkg in firmware-imx \
                             imx-lib \
                             fsl-alsa-plugins \
                             libfslcodec \
                             libfslparser \
                             libfslvpuwrap ; do \
                         wget http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/${pkg}-3.5.7-1.0.0.bin ; \
                     done
But extracting is a bit more complicated, requiring you to accept the EULA for each:
root@linaro-nano:~# tar zxf gst-fsl-plugins-3.5.7-1.0.0.tar.gz
root@linaro-nano:~# for pkg in firmware-imx \
                             imx-lib \
                             fsl-alsa-plugins \
                             libfslcodec \
                             libfslparser \
                             libfslvpuwrap ; do \
                         sh ${pkg}-3.5.7-1.0.0.bin ; \
                     done

Building the packages

Building (or installing) the packages is relatively straightforward once you know the flags required for each.

The firmware-imx package simply requires copying files to the /lib/firmware directory:
root@linaro-nano:~# cp -ravf firmware-imx-3.5.7-1.0.0/firmware/* /lib/firmware/
The imx-lib package seems to have failures building the rng library, so we’ve skipped it. It also requires the PLATFORM=IMX6Q flag:
root@linaro-nano:~# cd imx-lib-3.5.7-1.0.0/
root@linaro-nano:~/imx-lib-3.5.7-1.0.0# rm -rf rng
root@linaro-nano:~/imx-lib-3.5.7-1.0.0# make PLATFORM=IMX6Q all && make PLATFORM=IMX6Q install
The fsl-alsa-plugins package requires some autotools-fu before compilation:
root@linaro-nano:~# cd fsl-alsa-plugins-3.5.7-1.0.0/
root@linaro-nano:~/fsl-alsa-plugins-3.5.7-1.0.0# aclocal && autoconf && automake --add-missing
root@linaro-nano:~/fsl-alsa-plugins-3.5.7-1.0.0# ./configure --prefix=/usr
root@linaro-nano:~/fsl-alsa-plugins-3.5.7-1.0.0# make all && make DESTDIR=/ install
The libfslparser, libfslvpuwrap, and gst-fsl-plugins packages each have an autogen.sh script to take care of the autotools stuff:
root@linaro-nano:~# cd libfslcodec-3.5.7-1.0.0
root@linaro-nano:~/libfslcodec-3.5.7-1.0.0# ./autogen.sh --prefix=/usr && make all && make DESTDIR=/ install
root@linaro-nano:~/libfslcodec-3.5.7-1.0.0# cd ../libfslparser-3.5.7-1.0.0
root@linaro-nano:~/libfslparser-3.5.7-1.0.0# ./autogen.sh --prefix=/usr && make all && make DESTDIR=/ install
root@linaro-nano:~/libfslparser-3.5.7-1.0.0# cd ../libfslvpuwrap-3.5.7-1.0.0 
root@linaro-nano:~/libfslvpuwrap-3.5.7-1.0.0# ./autogen.sh --prefix=/usr && make all && make DESTDIR=/ install
root@linaro-nano:~/libfslvpuwrap-3.5.7-1.0.0# cd ../gst-fsl-plugins-3.5.7-1.0.0 
root@linaro-nano:~/gst-fsl-plugins-3.5.7-1.0.0# ./autogen.sh PLATFORM=MX6 --prefix=/usr 
root@linaro-nano:~/gst-fsl-plugins-3.5.7-1.0.0# make all && make DESTDIR=/ install

Testing things out

To test things out, we downloaded the Sintel 1080P video file from the Blender Foundation’s Sintel web-site and played the video using gplay. Note that before doing so, we also installed the base, good, bad, and ugly gstreamer plugins, and that we flushed the disk cache prior to starting playback:
root@linaro-nano:~# for t in base good bad ugly ; do \
         apt-get install gstreamer0.10-plugins-${t} ; \
done
root@linaro-nano:~# echo 3 > /proc/sys/vm/drop_caches
root@linaro-nano:~# gplay Sintel.2010.1080p.mkv
We also tested out camera capture for both our OV5642 5MP parallel camera and OV5640 5MP MIPI camera using the mfw_v4lsrc element:
root@linaro-nano:~# modprobe mxc_v4l2_capture
root@linaro-nano:~# gst-launch-0.10 mfw_v4lsrc capture-mode=4 ! mfw_v4lsink

Binary distribution

I’m sure a lot of you patient enough to get this far saying “I just want it to work!”.

I hear you, and I’m getting there.

If you look closely above, you’ll see that everything except firmware-imx uses make install to install things into the root filesystem, and that most of the packages specify the DESTDIR variable to say where the output should go. The one exception is imx-lib, which wants the PLATFORM=IMX6Q flag and a destination directory of DEST_DIR.

We can use this to create an overlay of the binary bits in a temporary directory:
root@linaro-nano:~# mkdir -p /root/overlay/lib/firmware/
root@linaro-nano:~# cp -ravf firmware-imx-3.5.7-1.0.0/firmware/* \
                        /root/overlay/lib/firmware/
root@linaro-nano:~# for pkg in fsl-alsa-plugins \
      gst-fsl-plugins \
      libfslcodec \
      libfslparser \
      libfslvpuwrap ; do \
      cd ${pkg}-3.5.7-1.0.0 ; \
      make DESTDIR=/root/overlay/ install ; \
      cd ../ ; \
done
root@linaro-nano:~# cd imx-lib-3.5.7-1.0.0
root@linaro-nano:~/imx-lib-3.5.7-1.0.0# make DEST_DIR=/root/overlay PLATFORM=IMX6Q install
And create a tar-ball of the result like so:
root@linaro-nano:~# cd overlay
root@linaro-nano:~/overlay# tar czvf ../imx6-gstreamer-plugins-raring-20131003.tar.gz *
We’ve uploaded the result of this, and you can grab it at: If you extract this on top of one of the previously uploaded images, you’ll need to install gstreamer and the gst-plugins- packages as described above.

Recap and commentary

To recap, this post described the steps needed to get, build, and install most of the gstreamer plugins for i.MX6.

Note that there is one component not covered: the OpenGL image sink. That will have to wait for another day.

We also haven’t yet tested all of the functionality to look for gaps between this and other platforms. It’s entirely possible that there’s some breakage because we haven’t included patches like this one to the core GStreamer build.


Jellybean 4.3 Beta on i.MX6

$
0
0
To make sure you have the best tools available, Freescale has released a Beta version of Jellybean 4.3, and we’ve updated our sources to use it.

There are some nice new features, including the Cactus Video Player, and we’ve included some fixes for issues with the 4.3 release.

For the impatient

You can grab a full SD card images from here:

The first (nitrogen6x) image is bootable on our Nitrogen6x, Nitrogen6x-SOM, or BD-SL-i.MX6 (SABRE Lite) boards and contains kernels for both the OV5640-MIPI and OV5642 parallel cameras with multiple uImage files in the /boot partition.

The second (nitrogen6x) image is for our Nitrogen6_Lite board.

As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.

Sources

The sources are available using branch boundary-imx_jb4.3_1.0.0-beta. If you currently have an Android build tree, you can switch to it using repo sync and repo init:
~/myandroid$ repo sync
~/myandroid$ repo init -b boundary-imx_jb4.3_1.0.0-beta

For the newcomers

If you haven’t built our Android software from sources, there are multiple steps to the process to fulfill some of the licensing agreements. You’ll first need to:

After that, you’ll need to install the Google repo tool, and initialize a new repository more or less as follows:

~/$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo \
    > ~/bin/repo
~/$ chmod a+x ~/bin/repo
~/$ mkdir myandroid
~/$ cd myandroid
~/myandroid$ ~/bin/repo init -u git://github.com/boundarydevices/imx-android-r13.4-ga.git \
       -b boundary-imx_jb4.3_1.0.0-beta
~/myandroid$ repo sync
Note that this will download over 15GiB of source code and tools, so it will take a while.

If you’re not familiar with repo, you should check out the notes in the AOSP documentation. It’s a very nice tool for consolidating multiple source code repositories into a single project, and has lots of features for tracking changes across the various packages. The file .repo/manifests/default.xml consolidates the almost 400 packages that comprise our Android release. You can see the structure here in our Github repository:

Building

Building the Android image involves three steps to configure the environment, choose the target board, and build. These make use of some scripts provided by the AOSP. Refer to the official documents for details:
~/myandroid$ source build/envsetup.sh
~/myandroid$ lunch
... select either "nit6xlite-eng" (5) or "nitrogen6x-eng" (7) here
~/myandroid$ m
Building from scratch will also take a while (typically several hours) and will produce a lot of output. Since you’re likely to walk away from the build window, you might want to make use of output re-direction and the tee command when building (running m):
~/myandroid$ m 2>&1 | tee build.out
If your build fails, make sure you have all of the prerequisites on your build machine as specified in the official documentation.

Prior Android releases had some issues when building on recent (Precise->Raring) versions of Ubuntu, but those don’t appear to be a problem in the JB 4.3 source base.

First impressions

Okay, so enough about the mechanics of how to get and build. Now let’s talk about how this release performs.

In broad strokes, it works very nicely!

Our updates to the Android JB4.2.2 release ported pretty easily, so this image has support for all of our displays and touch screens, and SGTL5000 audio. The camera layer is also completely functional, including support for auto-focus for both our OV5640-MIPI and OV5642 parallel cameras). Wi-Fi works on both Nitrogen6x and Nitrogen6_Lite.

Refer to the Android docs for what’s new in JB 4.3, but the most noticeable things in the image are a new video player (Cactus Player) and something called WfdSink to support Miracast.

The Cactus Player is a welcome addition, since it appears to force media scans, and has a nice Loop feature for repeated playback of videos.

We haven’t taken the time to investigate Miracast.

Not immediately noticeable is that the process for mounting external storage changed a bit in 4.3. The file /system/etc/vold.fstab has now been merged with fstab.freescale, where our enhancements allow it to move with the boot media. In English, this means that the Gallery and Camera applications will work regardless of whether you use either SD card or boot to SATA.

Fixes

We’ve fixed a couple of things in this release.

Next steps

Our next efforts will be in the areas highlighted above, notably TiWi Bluetooth, OTA updates, and fastboot support.

Additional information about this release will be available from Freescale soon.

As always, give us some feedback when you have a chance to kick the tires. At this point, we believe that this release is at least as functional as the 4.2.2 release, and we’ll use it as the basis for on-going work.

i.MX6 Linux kernel 3.10.9

$
0
0
As mentioned in our previous post about Linux kernel 3.5.7, Freescale has released an alpha version of an i.MX kernel based on 3.10.9.

We’ve taken a first pass at testing this out and adding support for Nitrogen6X into this tree and merged the results into branch boundary-imx_3.10.9_1.0.0_alpha on Github.

The test results are in the list below, and a substantial set of functionality is present.

Our intent at the moment is to perform a similar first-pass review of main-line Linux next before adding any additional support to the 3.10.9 tree.

The delta between these two is shrinking fast, and we’ll be making an effort to push our changes up-stream from this point forward.

We’ll also push updates to the meta-freescale list to make it easier for Yocto users to test things out.

3.10.9 3.10.9 3.10.9
Function 4.1.0 kernel SABRE Lite Nitrogen6Q Nitrogen6-Lite
Boots Yes Yes Yes not yet
Peripherals
SD Card Yes Yes Yes not yet
Ethernet Yes Yes Yes not yet
USB Host Yes Yes Yes not yet
USB Slave Yes Yes Yes not yet
USB OTG Yes Yes Yes not yet
Audio out Yes Yes Yes not yet
Microphone Yes Yes Yes not yet
GPIO Buttons Yes Yes Yes not yet
SATA Yes Yes Yes not yet
PCIe Yes not yet not yet not yet
Wi-Fi Yes N/A not yet not yet
BT Yes N/A not yet not yet
SPI-NOR Yes Yes Yes not yet
Uart1/2 Yes Yes Yes not yet
Displays
Hannstar LVDS Yes Yes Yes not yet
1024×600 LVDS Yes Yes Yes not yet
800×480 RGB Yes Yes Yes, pixel clockpolarity backwards not yet
HDMI Yes Yes Yes not yet
Composite video out Yes not yet not yet not yet
Backlights
LVDS Yes Yes Yes not yet
RGB Yes Yes Yes not yet
Touch screens
eGalax (Hannstar) Yes Yes Yes not yet
ft5x06 (7″ PCAP) Yes Yes Yes not yet
tsc2004 (7″ Resistive) Yes Yes Yes not yet
Cameras
OV5642 parallel Yes Yes Yes not yet
OV5640 MIPI Yes not yet Yes not yet
ADV Composite video Yes not yet not yet not yet
Internals
Thermal sensor Yes Yes Yes not yet
CPUFreq Yes Yes Yes not yet
OTP Yes Yes Yes not yet
CAAM Yes Yes Yes not yet
RNG Yes Yes Yes not yet
MTD Yes Yes Yes not yet
GPU Yes Yes Yes not yet
VPU Yes Yes Yes not yet

i.MX6 Main-line (ish) Linux kernel

$
0
0
As promised in yesterday’s post about kernel version 3.10.9, this post contains a table of functionality present on kernel based primarily on the main-line linux-next tree from 2013-11-05.

The updates to that kernel needed to get this functionality are in our boundary-imx_3.12.0 branch on Github, and at the bottom of this post, we’ll describe the changes in broad strokes.

As shown in the table, there is a substantial amount of functionality available, but some key pieces such as VPU, GPU, touch screen, and camera support are not yet available.

3.12.0 3.12.0 3.12.0
Function 4.1.0 kernel SABRE Lite Nitrogen6Q Nitrogen6-Lite
Boots Yes Yes Yes not yet
Peripherals
SD Card Yes Yes Yes not yet
Ethernet Yes Yes, sometimes stops working on nfs boot Yes, sometimes stops working on nfs boot not yet
USB Host Yes Yes Yes not yet
USB Slave Yes Yes Yes not yet
USB OTG Yes Yes Yes not yet
Audio out Yes Yes Yes not yet
Microphone Yes Yes Yes not yet
GPIO Buttons Yes Yes Yes not yet
SATA Yes Yes Yes not yet
PCIe Yes Yes Yes not yet
Wi-Fi Yes N/A not yet not yet
BT Yes N/A not yet not yet
SPI-NOR Yes Yes Yes not yet
Displays
Freescale LVDS Yes Yes Yes not yet
1024×600 LVDS Yes Yes Yes not yet
800×480 RGB Yes Yes Yes not yet
HDMI Yes Yes Yes not yet
Composite video out Yes not yet not yet not yet
Backlights
LVDS Yes Yes Yes not yet
RGB Yes Yes Yes not yet
Touch screens
eGalax (Hannstar) Yes not yet not yet not yet
ft5x06 (7″ PCAP) Yes not yet not yet not yet
tsc2004 (7″ Resistive) Yes not yet not yet not yet
Cameras
OV5642 parallel Yes not yet not yet not yet
OV5640 MIPI Yes not yet not yet not yet
ADV Composite video Yes not yet not yet not yet
Internals
Thermal sensor Yes Yes Yes not yet
CPUFreq Yes Yes Yes not yet
OTP Yes Yes Yes not yet
CAAM Yes No No not yet
RNG Yes No No not yet
MTD Yes Yes Yes not yet
GPU Yes No No not yet
VPU Yes No No not yet
If you look at the commit log for boundary-imx_3.12.0, you’ll see a commit with the comment Add linux-next specific files for 20131105. This commit represents linux-next as of November 5, 2013, and each of the commits below this in the list are staged for release into the next kernel release of the Linux kernel.

Above that, you’ll see a series of four patches by Marek Vasut regarding PCIe. These have been posted to the linux-arm mailing list, but have not yet been merged into linux-next.

As of this writing, there are 19 additional patches including three from Fabio Estevam, one from Peter Chen, and 15 by Troy Kisky. These patches have not yet been reviewed on linux-arm and have a high likelihood of changing during the process.

u-boot-2013-10-release/

$
0
0
Beginning today, we’ll start shipping boards with a new release of U-Boot, aligned with the 2013.10 release from main-line.

A binary package is available here:

If you extract the content to an SD card, you can upgrade on our standard 1GiB versions of Nitrogen6X or BD-SL-i.MX6 boards like so:
U-Boot > bootfile=u-boot.nitrogen6q ; run upgradeu
Refer to this post for more detail and this post for the list of available machine configurations.

There aren’t too many new features in this release, and no critical bug fixes for most users, so don’t feel pressured to upgrade immediately.

There are a couple of notable bug fixes though:
  • This patch to the clock startup fixed an issue for QNX users. Without it, the GPU would fail to start in around 1 of 10 boot cycles. We also noticed that it cured an occasional hang initializing the SD card and/or SATA under U-Boot, and
  • This patch from Fabio fixed the artifacts on HDMI on Dual-Lite and Solo boards.
We also added support for device-tree in the boot scripts for SABRE Lite and Nitrogen6x and added support for a couple of new 1280×800 displays with the Focaltech FT5X06 touch controller.

Finally, we removed the U-Boot (Linux penguin) logo from the splash screen. As much as we love Tux, it didn’t make a lot of sense when booting QNX or Windows CE (err. Embedded 7). Splash screen support is still present, so you can put him back.

The source code is in the normal place (“production” branch on GitHub). We’ve kept the older release in branch production-before-20131107.

In case there’s a regression, binaries of the older 2013.07 release are available here: As always, please let us know how this upgrade goes for you, and reach out if you have any trouble.

Second release of Jellybean 4.3 Beta on i.MX6

$
0
0
How’s this for timing? We just pushed a new release of the Jellybean 4.3 Beta, and immediately received a hint that the GA (General Availability) release is available.

This binary release contains some updates to our first release, largely as mentioned in the comments at the bottom of that post.

In particular, we:
  • fixed support for the early versions of i.MX6 silicon, and
  • added patches to support HDMI audio using the sys.hdmi property,
  • pulled in some patches for netfilter from the AOSP kernel,
  • added the Mozilla Fennec browser and tested WebRTC with this test page, and
  • added the Freescale Ethernet U/I application.
More detailed commentary is below, but an image for our Nitrogen6x, Nitrogen6x-SOM, or BD-SL-i.MX6 (SABRE Lite) boards is available here:

It contains kernels for both the OV5640-MIPI and OV5642 parallel (CSI) cameras with multiple uImage files in the /boot partition.

As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.

Assuming your SD card presents itself as /dev/sdc, the Linux commands to extract it would be something like this:
~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ zcat imx6-android-4.3-nitrogen6x-20131110.img.gz \
             | sudo dd of=/dev/sdc
~/Downloads$ sync

Sources

The sources are available using branch boundary-imx_jb4.3_1.0.0-beta. If you currently have an Android build tree, you can switch to it using repo sync and repo init:
~/myandroid$ repo sync
~/myandroid$ repo init -b boundary-imx_jb4.3_1.0.0-beta

Details

As you might guess above, the majority of the changes in this release have to do with audio. We’ve had several putting off HDMI audio support for quite some time, and also had several customers interested in using our boards in A/V-conferencing applications, and chased down some of the details.

Fixes for early silicon

The first release of JB 4.3-Beta would consistently reset during the startup of Android when run on i.MX6 silicon revision 1.0 (Tapeout or TO 1.0).

The problem stemmed from the fact that the JB4.3 Beta image included a watchdog timer with a 10-second refresh interval and a 30-second timeout. When looking into the issue, we found that the problem was actually much bigger. In fact, the system timer was running at 1/3 the speed that it should be, such that a 1-second sleep would wait for ~3 seconds of wall time.

The fix for it involved removing some tests for TO 1.0 in the kernel.

HDMI audio

HDMI audio has been simply missing in all of our Jellybean releases. This wasn’t because the driver or Android bindings weren’t present, but simply because we had no switch to select between it and the SGTL5000 headphone output.

As described in this comment on the previous post, we addressed this by defining a new property, sys.hdmi. If the property is set to a non-zero value, audio will be routed to the HDMI adapter. If unset or set to zero, audio output will be routed to the headphone jack.

Note that you can add this property into build.prop to force one mode or another if you know your system configuration.

Netfilter patches

When testing Skype on the Nitrogen6X, we saw lots of messages like this on the console:
qtaguid: iface_stat: stat_update() lo not found 
Looking into the problem, we found that the problem stemmed from the loopback device, and we could reproduce the error using ping:
root@nitrogen6x:/ # busybox ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 daqtaguid: iface_stat: stat_update() lo not found
ta bytes
qtaguid: iface_stat: stat_update() lo not found
qtaguid: iface_stat: stat_update() lo not found
qtaguid: iface_stat: stat_update() lo not found
64 bytes from 127.0.0.1: seq=0 ttl=64 time=20.896 ms 
The issue was caused by an incomplete patch set pulling in code from the AOSP kernel, and was addressed by simply cherry-picking patches to the netfilter drivers.

Note that these are also included in the new -GA kernel from Freescale.

Mozilla Browser

Along with Skype, we also tested out WebRTC for use in audio/video conferencing.

The stock Android browser does not yet support WebRTC, but we found that the Mozilla Firefox for Android browser does.

We used the Mozilla gUM test page (getUserMedia) to test things out, and things worked remarkably well. Audio and video latency appear to be low, and the quality high.

The Mozilla team makes it incredibly easy to pull in the latest nightly build, so we included that in this image.

Chrome was not so easy :( , so it’s not here.

Ethernet Configuration Application

Finally, we included the .apk for the Freescale ethernet U/I from i.MX Community. This allows you to configure the ethernet adapter for static IP instead of the default DHCP.

As noted in that post, this will be a standard part of the -GA source tree, and we’ll include it in our packaging.

Summary

As mentioned at the start of this post, we’ll be integrating the General Availability code from Freescale as soon as we can find it, and will publish a full release that includes support for the Nitrogen6_Lite board.

As always, let us know if you have any trouble.

Android Beta Build Breakage

$
0
0
The boundary-imx_jb4.3_1.0.0-beta branch of the Android repository has been broken for a few days, and there’s a fix here:

In English, this patch addresses a screw up in the original patch set that allowed KitKat changes from AOSP to leak into the build tree. If you look closely at the history, you’ll see that there are two new patches to accomplish the fix, but the first best highlights the cause.

You can address this by running repo sync, but we’re going to suggest that you migrate to the General Availability (-ga) branch instead. We’ve completed internal testing and this release is looking good. We haven’t posted an image yet because of those darned 24-hour days, but will do so very soon.

If you have a tree checked out, you can update it to use the -ga branch like so:
~/myandroid$ repo sync
~/myandroid$ repo init -b boundary-imx_jb4.3_1.0.0-ga
~/myandroid$ repo sync
The first sync will pull in the changes to .repo/manifests/default.xml, and the second will check out the boundary-imx_jb4.3_1.0.0-ga branch.

If you’ve been working with the -beta branch, this shouldn’t take very long (< 10 minutes).

If you want to stay on the -beta branch, a single repo sync should do the trick.

If you hit this problem (and it seems that several of you did), we apologize for making your first experience with the source tree painful.

As always, let us know if you run into any snags.

Rapping up Raring

$
0
0
Sintel-and-Jellyfish gstreamer-and-glmark2-es2
To tie a string around our post about the Linaro Raring images and the post showing how to accelerate video, we’ve put together an image based on Linaro latest Raring ALIP that contains GPU acceleration and the GStreamer binaries for accelerated video playback and camera access.

Jasbir showed that it could be done, and we wanted to make sure that you have an easy way to test things out.

For the impatient

You can download the SD card image from here:
As usual, you can write the SD card image to disk using zcat and dd under Linux. On a recent Ubuntu system with an SD card that shows up as /dev/sdc, this could be done like so:
~/$ echo ',,83,*' | sudo sfdisk /dev/sdc
~/$ sync && sudo partprobe
~/$ sudo mkfs.ext4 -L alip /dev/sdc1
~/$ udisks --mount /dev/sdc1
~/$ sudo tar zxvf alip-gpu-gstreamer-20131219.img.gz -C /media/alip/ 
You can also use Alex Page’s USB Image Tool under Windows.

The details

The photos above show gplay playing the 1080P Sintel Movie by the Blender Foundation and the glmark2-es2 benchmark application.

The image is targeted at our most popular Nitrogen6X or BD-SL-i.MX6 boards with a parallel OV5642 camera. Kernels and library trees for the OV5640 MIPI and Nitrogen6_Lite are available in directories beneath /boot/. If you copy one of these trees to the root folder, you can run with those configurations.

i.e., for nitrogen6x_mipi, you can do this:
~/$ sudo cp -ravf /media/alip/boot/nitrogen6x_mipi/* /media/alip/
~/$ sync && sudo umount /media/alip
and for Nitrogen6_Lite, you can do this:
~/$ sudo cp -ravf /media/alip/boot/nit6xlite/* /media/alip/
~/$ sync && sudo umount /media/alip

Credits

We need to give many thanks to Jasbir, who put together notes on i.MX6 GPU acceleration on his blog and helped walk us through the somewhat complicated process of patching the X Server to cooperate with the Vivante GPU. In particular, the DRM library needs patching to match the API version used on the Linaro build (it’s slightly older than what’s used in Yocto).

Jasbir is a real pro, and these are some complicated pieces. We appreciate his support.

As always, let us know how things work for you.

Android Jelly Bean 4.3 GA on i.MX6

$
0
0
In November’s image of the 4.3 Beta Android Jelly Bean image, we mentioned that the General Availability (GA) version was close to release, and we promised images.

These images are now on-line:

The first (nitrogen6x) image is bootable on our Nitrogen6x, Nitrogen6x-SOM, or BD-SL-i.MX6 (SABRE Lite) boards and contains kernels for both the OV5640-MIPI and OV5642 parallel cameras with multiple uImage files in the /boot partition.

The second (nit6xlite) image is for our Nitrogen6_Lite board.

As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.

Sources

The sources for this release are in the boundary-imx_jb4.3_1.0.0-ga branch of our Github repository, and the build steps are otherwise the same as in the second beta release.

Let us know how this image works for you.

Our experience has been that there are few differences from the beta, and that both have been solid.

Many thanks to the Freescale teams involved.

Lineo/Timesys Fast Boot on i.MX6

$
0
0
The folks over at Timesys and their partner, Lineo Solutions have been busy innovating. As a showcase of their Boot Time Optimization Services, they put together a demonstration of a very fast boot on an BD-SL-i.MX6 board:



Boot times like this present all sorts of opportunities and we encourage you to talk to the Timesys team about how this can help you make better products.

U-Boot 2013.10 Release 2 for i.MX6

$
0
0
Beginning today, we’ll start shipping a new release of U-Boot on our i.MX6 boards.

You can grab a package of binaries from the usual place:

The previous set of binaries is also still available.

If you extract the content to an SD card, you can upgrade on our standard 1GiB versions of Nitrogen6X or BD-SL-i.MX6 boards like so:
U-Boot > bootfile=u-boot.nitrogen6q ; run upgradeu
Refer to this post for more detail and this post for the list of available machine configurations.

Why you might want it

Device Tree

As with our previous release, this release is still based on the 2013.10 release from main-line, but contains some updates to allow loading Device Tree Binaries (or BLOBs) based on the machine type and processor type. We’ll elaborate on those topics in upcoming posts, but for now, suffice it to say that we need to load a different device tree for a Quad-Core Nitrogen6X and a Single-Core Nitrogen6X and this needs a bit of introspection. If you want to experiment with some of the newer kernels, including 3.10.17 or linux-next, the U-Boot changes in this release and the updated boot script will make this easier.

The majority of the other updates are for custom boards and new displays we’re supporting, but there is one other item of note.

2GiB DDR

We had reports from a handful of customers using 2GiB of DDR on Nitrogen6X, and found that our DDR calibration data was off. The original DDR calibration for 2GiB boards was produced on only a handful of boards, and we found that those were at the edge of the expected range. We recently produced a much larger batch of 2GiB boards, gathered a more representative sample, and have updated the configuration files accordingly.

In other words, if you have a 2GiB board, you should probably upgrade.

If you have unexplained kernel crashes on a 2GiB board, you should definitely upgrade to this release.

If you’re only using 512 MiB and/or 1GiB boards and will only use the 3.0.35 kernel, there’s not much reason to update and you may want to skip this release.

Branch Naming

Beginning with this release, we’re changing around our naming convention for older branches.

A more complete description is here in the U-Boot-on-i.MX6 page, but we’re starting a new practice of saving old versions with branches named vYYYY.MM-yyyymmdd so that Yocto will have branch names that live over time. Our production branch is a consistent name, and is easy to remember, but doesn’t contain a consistent history. We move it at least with each release from main-line U-Boot.

i.MX6 Linux kernel 3.10.17 – Beta

$
0
0
In case you didn’t catch it in the Freescale git repository or on the Meta-Freecale mailing list, Freescale has released a beta version of Linux 3.10.17 for i.MX6, and we’ve added support for it into our Github repository.

We’ve tested it quite a bit on our various boards, and the table shows the results. As you can see, it’s very nearly feature-complete, though not yet tested as well as the 3.0.35 versions.

We’re hoping that you can help with that, though it will likely take a while.

Otavio posted a patch set to the master-next branch of meta-fsl-arm, but some assembly is still required.

We’ll be posting updates for the kernel to the mailing list shortly.

You may also need an updated U-Boot version to support setting the cpu and board variables so that the updated boot script can load the proper DTB (Device Tree Binary or Blob) based on the processor and board type you’re using.

The change to the newer kernels will require a bit of effort, but we think the results will be well worth it.

Testing details

3.10.17 3.10.17 3.10.17
Function 4.1.0 kernel SABRE Lite Nitrogen6Q
Nitrogen6DL/S
Nitrogen6-Lite
Boots Yes Yes Yes Yes
Peripherals
SD Card Yes Yes Yes Yes
Ethernet Yes Yes Yes Yes
USB Host Yes Yes Yes Yes
USB Slave Yes Yes Yes Yes
USB OTG Yes Yes Yes Yes
Audio out Yes Yes Yes Yes
Microphone Yes Yes Yes Yes
GPIO Buttons Yes Yes Yes not yet
SATA Yes Yes Yes
N/A for DL/S
N/A
PCIe Yes Yes, gen 1 only Yes, gen 1 only Yes, gen 1 only
Wi-Fi Yes N/A Yes Yes
BT Yes N/A Yes Yes
SPI-NOR Yes Yes Yes Yes
Uart1/2 Yes Yes Yes Yes
Displays
Hannstar LVDS Yes Yes Yes N/A
1024×600 LVDS Yes Yes Yes Yes
800×480 RGB Yes Yes Yes N/A
480×272 RGB N/A N/A N/A Yes
HDMI Yes Yes Yes Yes
Composite video out Yes not yet not yet N/A
Backlights
LVDS Yes Yes Yes Yes
RGB Yes Yes Yes Yes
Touch screens
eGalax (Hannstar) Yes Yes Yes N/A
ft5x06 (7″ PCAP) Yes Yes Yes Yes
tsc2004 (7″ Resistive) Yes Yes Yes Yes, tested with 480×272 panel
Cameras
OV5642 parallel Yes Yes Yes N/A
OV5640 MIPI Yes Yes Yes N/A
ADV Composite video Yes not yet not yet N/A
Internals
Tapeout 1.0 Yes Unknown No HDMI N/A
Thermal sensor Yes Yes Yes Yes
CPUFreq Yes Yes Yes Yes
OTP Yes Yes Yes Yes
CAAM Yes Yes Yes Yes
RNG Yes Yes Yes Yes
MTD Yes Yes Yes Yes
GPU Yes Yes Yes Yes
VPU Yes Yes Yes Yes

U-Boot 2014.01

$
0
0
We’re about to start shipping U-Boot version 2014.01 in production on our i.MX6 boards. This release contains over 68000 new lines of code, so we won’t go through all of the details, but wanted to highlight a few of the things that might interest you.

  • USB OTG is now supported. Troy implemented USB Gadget support, so we can now use this high-speed link (more later in this post).
  • Updated pin-muxing constants – This release contains some broad-strokes re-naming of the mux and pad names to match the main-line Linux kernel. This, and some additional structure paves the way for boards to support both i.MX6DQ and i.MX6DLS processor variants in the same binary. If you’re building custom versions based on our designs (SOM customers?), you’ll want to schedule some time for this. Most of the changes are mechanical, but can be time consuming.
  • USB Host support is noticeably improved.
  • We patched the splash screen code for use with GCC 4.7. Refer to the notes at the beginning of this post for more detail.

For the impatient

You can grab a package of binaries from the usual place:
The previous set of binaries (described in this post) is also still available.
If you extract the content to an SD card, you can upgrade on our standard 1GiB versions of Nitrogen6X or BD-SL-i.MX6 boards like so:
U-Boot > bootfile=u-boot.nitrogen6q ; run upgradeu
Refer to this post for more detail and this post for the list of available machine configurations.

Details

USB OTG support

Enabling USB OTG support is the first step toward enabling Fastboot, something that a number of customers have requested, but it also enables a number of existing features of U-Boot, notably USB Networking, USB Net console, and the Device Firmware Upgrade (DFU) protocol.

We enabled support for the first two (Networking and Netconsole) in our default configuration, and we added a new convenience command usbrecover that is directly useful and serves as a good example of how to use USB networking.

usbrecover command

If you look at the details, you’ll see all of the details needed to perform file transfers over USB.

There are a number of environment variable assignments:
VariablePurpose
usbnet_devaddrA USB OTG port doesn’t have a unique MAC address like a network adapter generally does, since the USB channel is inherently point-to-point. This variable defines a virtual MAC address for the device side of the link.
usbnet_hostaddrThis variable defines the MAC address for the host side of the link. Note that using a constant here allows a single configuration on the host side.
ethactWith the addition of USB networking, we now have multiple network adapters available, the i.MX6 Fast Ethernet Controller (FEC) and the USB Network Adapter (usbnet). The ethact variable tells the networking commands in U-Boot which to use.
ipaddrThis variable defines a static IP address for the device.
netmaskThis variable defines a static subnet mask for the device.
serveripThis variable is used implicitly in some networking commands, and while we don’t use it, this bit of the network stack inexplicably requires it.
ncipThis variable defines the network console IP address (see doc/README.NetConsole).
These are followed by three commands to load a kernel, RAM disk and boot them:
tftpboot 10800000 10.0.0.1:uImage-${board}-recovery
&& tftpboot 12800000 10.0.0.1:uramdisk-${board}-recovery.img
&& bootm 10800000 12800000
The kernel and RAM disk file names are somewhat meaningless, but we’re using them internally with our USB mass storage images to allow easy access to SD cards, eMMC, and SATA drives.

In other words, a poor-person’s Fastboot or DFU, and rationale for future work.

Branches

As usual, the latest production version is in the production branch of our Github repository. To meet the needs of Yocto, we also have a persistent branch named v2014.01-20140228.

The previous revision is still available on branches v2013.10-20131119 and production-before-20140228.

1280×800 displays

$
0
0
LG1280x800 1280x800_2
We recently started offering a couple of new 1280×800 LCD panels with capacitive touch and have been behind in describing how to integrate them with our Nitrogen6X, Nitrogen6X-SOM, and BD-SL-i.MX6 (formerly SABRE Lite) boards.

The displays both have a resolution of 1280×800 and a 2-point capacitive multi-touch sensor (Focaltech FT5X06):
ProductResolutionBrightness (cd/m**2)ContrastScreen size
BD070LCC1-71280×8004008007-inch
BD0101LCC1-10-11280×80035050010.1-inch

Configuration

If you’ve read our post on auto-configuration of displays, you’ll know that we automatically detect the display connected to our boards by detecting the touch controller through an i2c probe.

Because the touch controllers on these new displays share the same touch controller used on our older 7-inch 1024×600 display, this scheme doesn’t work directly, and needs some assistance from you. Both U-Boot and the Linux kernel need information about these displays, and depending on your userspace, you may need additional updates.

U-Boot

Because both of these panels support the same video timings and display format, the U-Boot source code names both of these panels LDB-WXGA, and auto-detection is disabled. To choose these displays, you can set the panel environment variable as follows:
U-Boot > setenv panel LDB-WXGA
U-Boot > saveenv
U-Boot > reset
This is enough to get U-Boot to support the new display, and if you re-boot with no SD card or SATA drive connected, you’ll see the proper video output. The entry for this resolution was in June of 2013, so if you have a really old U-Boot, you’ll need to upgrade.

Linux

As discussed in this post about screen configuration, the key to display output selection in Linux is the video= clause(s) on the kernel command-line, which are specified in-directly through U-Boot’s bootargs variable.

For each of these displays, the proper setting is:
video=mxcfb#,dev=ldb,1280x800MR@60,if=RGB666
In English, this says that the panel is connected via the LVDS Display Bridge (ldb), has a resolution of 1280×800 pixels using the Coordinated Video Timing standard with reduced margins (MR), and has an 18 bit-per-pixel interface (RGB666).

To make things easy, we’ve also added support for this to our standard boot script. This support changes a test for the FT5x06 touch controller into a test for ft5x06 touch controller and panel==LDB-WXGA.

In other words, if you have an updated boot script, the setting change you made in U-Boot should be all you need.

This updated boot script (or a version of it) is present in both the Timesys and Android images we’re shipping, and is also present in the Yocto, Timesys, and Android source repositories. Other userspaces may need tweaks.

Touch screen settings

If you look closely at the boot script, you’ll also see that another kernel command-line parameter is added when the FocalTech touch controller is found.

As with most capacitive touch controllers, calibration isn’t needed in the normal case, but the FT5x06 touch controllers on each of these displays return the pixel location of each touch. Since our device driver for the touch controller used to always advertise a 1024×600 range of values, we updated the driver to allow this to be a command-line parameter.

This updated driver has been in our boundary-imx_3.0.35_4.1.0 and boundary-jb4.3_1.0.0-ga branches since October of 2013. If you’re using a kernel older than that, you’ll either need to upgrade or back-port the patches.

Contact us if you need this. We’ll be happy to help.

Finally, you may also note that there’s a calibration setting in U-Boot. As mentioned earlier, these touch screens do not require calibration, but the driver supports calibration. This is used in applications where the panels are operated in portrait mode instead of their native landscape mode.

Recap

We didn’t set out to make this complicated, but in our search to find the best displays for use with our boards, these two stood out.

They have high resolution, great brightness and contrast, are well supported by the display manufacturers, and can be very economical in production (when no plexiglass stand and daughter board is needed).

Contact us for volume pricing.

Bluetooth on Jellybean

$
0
0
Bluetooth logo

Bluetooth logo

We’ve just uploaded a new Android Jellybean image containing Bluetooth support on Nitrogen6X. Thanks to the efforts of Marc Mulcahey at Levelstar, the TiWi-BLE module is now functional. You can download the image from here:

The image is only bootable on our Nitrogen6x, Nitrogen6x-SOM, or BD-SL-i.MX6 (SABRE Lite) boards, and at the moment, only the OV5642 parallel camera is supported (more on that in coming days). As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.

Source access

The sources for this release are in the boundary-imx_jb4.3_1.0.0-ga branch of our Github repository (the main development branch), and the build steps are otherwise the same as in the second beta release. You’ll need to run repo sync to pull them in, and because we moved the hardware/ti/wpan/ repository from AOSP to our private git server, you may need to start with a fresh repository. In the mean-time, we’d like to get some feedback from early adopters, and hope the image file will make this easy.

Implementation details

The trick to making this work properly on Nitrogen6X turned out to be getting the userspace bits (hardware/ti/wpan/bluedroid_wilink) in sync with the kernel driver (drivers/misc/ti-st for Shared Transport). Because the bluedroid_wilink is another case of driver-in-userspace, there’s some tight coupling between the two. The updates consist primarily of a set of patches back-ported from the stable kernel tree (3.13) on kernel.org, and this commit from the OMAP kernel in the AOSP. Also, as mentioned before, we also had to move the hardware/ti/wpan repository out of AOSP because of a silly restriction on TARGET_DEVICE == panda.

Other features

In addition to the big-ticket item of Bluetooth on Nitrogen6x, there are a handful of other tweaks to this image:
  • Text-to-speech support – Again, thanks to Marc Mulcahy for pointing out that we didn’t have this enabled previously,
  • Power-off support – The system will now halt after Power-down is requested (more on this below), and
  • Added devregs utility – We added the devregs tool into this build.

Power-down support

Since none of our off-the-shelf boards contain support for controlling the power input to the device, what we’ve implemented is a partial solution to the problem of graceful shut-down. If you’ve ever used the Power-Down function in Android on our boards, you would have seen some power-down animation on the screen that halted after the shutdown was complete, but if you waited to actually pull power, you would also have seen the device re-start. The reason for this is that the watchdog timer would eventually time out, and restart the system. To get around this, we implemented a power_down routine to loop forever, keeping the watchdog alive. This doesn’t conserve much power, but does give you the ability to shut the system down gracefully so that you can disconnect power at your leisure.

Yocto with kernel 3.10.17-beta

$
0
0
Since publishing our post on kernel version 3.10.17-beta, we’ve had a number of requests for an easy-to-test image.

The following link contains an easy-to-test image based on the fsl-image-gui image in the master-next branch of meta-freescale:

As usual, it requires registration prior to download because it contains content based on Freescale’s EULA.

Also as usual, you can copy it to SD card using zcat and dd. Assuming your SD card shows up as /dev/sdc, you can use these commands to write it:

~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ zcat yocto-3.10.17-beta-20140303.img.gz | sudo dd of=/dev/sdc bs=1M
~/Downloads$ sync

Build details

The image was built using the standard process, just with the master-next branch instead of dora:
~/$ mkdir yocto
~/$ cd yocto
~/yocto$ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master-next
~/yocto$ repo sync
~/yocto$ MACHINE=nitrogen6x . setup-environment build
~/yocto/build$ vi conf/local.conf
      ... added these two lines:
      PREFERRED_PROVIDER_virtual/kernel = "linux-boundary"
      PREFERRED_VERSION_linux-boundary = "3.10.17"
~/yocto/build$ bitbake fsl-image-gui
The PREFERRED_VERSION_linux-boundary is needed because master-next supports both the production-ready 3.0.35 kernel version as well as the near-production-ready 3.10.17-beta.

As always, please share your experiences with this. The more eyeballs we have looking things over, the better.

Nitrogen6_MAX – i.MX6 with all the extras

$
0
0
We’re happy to announce the availability of a new product in our i.MX6 family. The Nitrogen6_MAX is a high-end version with 4GiB of RAM, dual-channel LVDS, on-board eMMC, and full mPCIE support for the most demanding applications.

Nit6Max_Top Based on your feedback about our previous designs, we’ve put together a new package providing enhanced performance in roughly the same footprint.

We’ll provide more details soon, but here are the highlights:

Full 4GiB memory

If you’re working with 1080P video for capture and/or playback, you know that memory gets used up very fast. The Nitrogen6_MAX has double the amount of RAM to provide the very best performance for your applications.

Dual-channel LVDS

1080P video also requires very high pixel clock rates, and newer displays are using two standard LVDS channels to reduce the clock rate on the cabling.

If you’re using 720P or lower resolutions, the Nitrogen6_MAX can support two independent LVDS displays.

Full, direct PCIE

PCIe connections on the SABRE Lite and Nitrogen6X are inconvenient at best. Using them requires the use of a daughter board, and even then, there were quirks like a missing PCIE RESET Pin that make them usable for preliminary testing but not for production use.

The mPCIE slot on the Nitrogen6_MAX contains the full PCIE signal set, and also supports USB signalling, allowing it to be used for 3G modems or WLAN devices that use the mPCIE form factor.

eMMC

The Nitrogen6_MAX has on-board eMMC that gives an immediate 2x boost in I/O performance compared to removable MMC/SD cards because of its 8-bit data bus. Future (software) enhancements will support increased clock rates and DDR (2 cycles per clock).

RS-485 and additional UART

We’ve heard from many of you that two UARTs for serial communication weren’t enough, so we provided a third UART on Nitrogen6_MAX that supports either RS-232 or RS-485 signalling.

Availability

Our first article boards are undergoing testing now and looking great, so we’ve begun accepting orders.

Our first production run is scheduled for the first week in June.

U-Boot 2014.04 release for i.MX6

$
0
0
We’re about to start shipping U-Boot version 2014.04 in production on our i.MX6 boards. This release contains over 66000 new lines of code but for most of our customers, these are largely structural (changes to the build process).

There aren’t any major new features for our boards, and we’re bumping the release simply to stay as close to main-line as possible.

For the impatient

You can grab a package of binaries from the usual place:
The previous set of binaries (described in the U-Boot 2014.01 post) is also still available.
If you extract the content to an SD card, you can upgrade on our standard 1GiB versions of Nitrogen6X or BD-SL-i.MX6 boards like so:
U-Boot > bootfile=u-boot.nitrogen6q ; run upgradeu
Refer to this post for more detail and this post for the list of available machine configurations.

Branches

As usual, the latest production version is in the production branch of our Github repository. To meet the needs of Yocto, we also have a persistent branch named v2014.04-20140419.

The previous revision is still available on branches v2013.10-20131119 and production-before-20140228.

Cross compiling kernels (2014 edition)

$
0
0
A while back, we posted some notes about how to cross compile an i.MX6 kernel using the LTIB toolchain. Fast forward to the middle of 2014 and these are a bit dated.

In particular:

Cross Compiler

As a result of the first two points, we now recommend these simple steps to install a cross-compiler:
~/$ sudo apt-get install gcc-arm-linux-gnueabihf
~/$ ~$ arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
...
gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) 

Compilation

This is clearly simpler than installing LTIB and configuring your PATH to point at the toolchain, and is sufficient to replace the arm-none-linux-gnueabi- from LTIB with arm-linux-gnueabihf-, but the process for a 3.0.35 kernel is essentially the same:
~/$ git clone git://github.com/boundarydevices/linux-imx6.git
~/$ cd linux-imx6
~/linux-imx6$ export ARCH=arm
~/linux-imx6$ export CROSS_COMPILE=arm-linux-gnueabihf-
~/linux-imx6$ git checkout boundary-imx-3.0.35_4.1.0 
~/linux-imx6$ make nitrogen6x_defconfig
~/linux-imx6$ make uImage modules -j4
As in the previous post, the output will be placed in ~/linux-imx6/arch/arm/boot/uImage.

Module installation

Also unchanged is the module installation process. To get a directory tree suitable for placement into a rootfs (that is, without any symlinks), you can install them into a temporary location as follows.
~/linux-imx6$ make INSTALL_MOD_PATH=~/tmp modules_install
~/linux-imx6$ find ~/tmp/lib/modules -type l -exec rm -f {} \;
~/linux-imx6$ cp -ravf ~/tmp/lib/modules/* /media/myrootfs/lib/modules/

Device Tree

For kernels after 3.0.35, a couple of other wrinkles are added:
  • You’ll need to set the LOADADDR environment variable to 10008000, and
  • You’ll need to make the dtbs target and copy the Device Tree Binary files into your boot directory.
The files *.dtb are placed in the arch/arm/boot/dts directory, so the following shows the complete process for kernel 3.10.17:
~/$ git clone git://github.com/boundarydevices/linux-imx6.git
~/$ cd linux-imx6
~/linux-imx6$ export ARCH=arm
~/linux-imx6$ export CROSS_COMPILE=arm-linux-gnueabihf-
~/linux-imx6$ export LOADADDR=10008000
~/linux-imx6$ git checkout boundary-imx_3.10.17_1.0.0_ga
~/linux-imx6$ make nitrogen6x_defconfig
~/linux-imx6$ make uImage modules dtbs -j4
~/linux-imx6$ cp -fv arch/arm/boot/uImage /media/myboot/
~/linux-imx6$ cp -fv arch/arm/boot/dts/*.dtb /media/myboot/
~/linux-imx6$ make INSTALL_MOD_PATH=~/tmp modules_install
~/linux-imx6$ find ~/tmp/lib/modules -type l -exec rm -f {} \;
~/linux-imx6$ cp -ravf ~/tmp/lib/modules/* /media/myrootfs/lib/modules/
Note that depending on your O/S distribution, the uImage and *.dtb files may go in the root of a partition (Yocto, Buildroot, Timesys, OpenWRT), or into the /boot directory (Debian, Ubuntu). The key is to match the boot script.

Notes if switching versions

If you’re switching from the 3.0.35 to 3.10.17 kernel versions within the same tree, you’ll need to delete include/linux/version.h from your tree, or you’ll get mysterious error messages about missing mach/hardware.h while compiling gc_hal_kernel_device.c.

Jellybean for i.MX6 Nitrogen6 Max

$
0
0
We’ve just uploaded a new image of Android Jellybean for our BD-SL-i.MX6, Nitrogen6x, and for the first time, our new Nitrogen6 Max board.

This will be a lengthy post because it covers the details of a number of new features, and describes in some detail how the features of the our new Nitrogen6 Max board are made available.

For the impatient

You can download the image from here:

As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.

Source access

The sources for this release are in the boundary-imx_jb4.3_1.0.0-ga branch of our Github repository (the main development branch), and the build steps are otherwise the same as in the second beta release.

We have added one additional component, the can-utils project for use in testing the CAN bus.

The highlights

The primary enhancements in this image (aside from 6 Max support) include:
  • Additional display and touch screen support.
  • Dual camera support.
  • Support for HDMI and SDI receiver inputs through the camera interfaces.
  • Updates to allow easy loading of on-board eMMC
Features that are specific to the Nitrogen6 Max board include:
  • Dual (separate) LVDS display support
  • Dual-channel LVDS display support for resolutions up to 1080P
  • RS-232/RS-485 support on UART5
  • There are some quirks related to the 4GiB of RAM on Nitrogen6 Max

Display and touch screen changes

Since the previous release of Jellybean, we’ve added support for touch controllers from Goodix and Ilitek, and increased the functionality of our FocalTech touch controllers.

Our 7″ 1024×600, 7″ 1280×800 and 10.1″ 1280×800 displays now support 12-point touch instead of the original 5-point touch in the original driver.

The Ilitek touch controller is used in our new 10.1″ sunlight-readable display.

Dual camera support

This feature has been a long time in coming, but for those of you using our 5 mega-pixel OV5640 MIPI camera, life is a bit easier.

Because our two primary camera modules shared an I2C bus and had the same address, previous releases required kernel re-compilation to swap between them. For this release, the Linux kernel drivers now reassign the I2C addresses during startup, allowing connection of both cameras simultaneously, and map the MIPI camera to the Back camera and the parallel camera to the Front camera in Android jargon.

Probably most importantly, this allows us to ship a single kernel image with both cameras enabled, so MIPI users don’t have to re-compile or re-name files before using the camera.

Additional video inputs

Beside cameras, this release contains kernel support for a number of additional video input devices: Because these devices don’t map readily to the simple Front Camera/Rear Camera model provided by Android, these devices are not currently supported by the Android HAL, and require customized Android builds in order to use them.

Recovery support

In an earlier post, we provided a customized kernel and RAM disk that turned our BD-SL-i.MX6 or Nitrogen6X boards into a very expensive SD card reader by using the g_mass_storage gadget.

This release extends that to support the Nitrogen6 Max board, and also updates the boot script to invoke this automatically if the Volume Down key on our Android button board is pressed during boot.

If you don’t have an Android button board, you can short pins 7 and 8 of J14 with a paper clip (these pins are Volume down and Ground respectively).

Note that this feature is not specific to eMMC or to the Nitrogen6 Max board. It is also very handy for loading SATA drives or even SD cards.

The /init script in the RAM disk walks through and exposes each block device found on the system, making it available over the USB OTG port

The two files involved (uImage-recovery and uramdisk-recovery.img) can also be copied to a TFTP server and loaded by U-Boot using the usbrecover command as described in the release notes for U-Boot 2014.04.

CAN bus utilities

As mentioned earlier, we’ve included the can-utils package in this release. While we don’t have a lot of experience with CAN, we have tested this by connecting multiple of our boards together, and using cansend and candump as follows:
# on both boards:
root@nitrogen6x:/ # ip link set can0 up type can bitrate 125000
root@nitrogen6x:/ # candump can0 &
root@nitrogen6x:/ # cansend can0 5A1#11.22.33.44.55.66.77.88
  can0  5A1   [8]  11 22 33 44 55 66 77 88

RS-232/RS-485

The Nitrogen6 Max board has a third serial port, which is software-selectable to support either RS-232 or RS-485 signalling. It is connected to UART5 on the processor, and exposed as /dev/ttymxc4 under Linux.

By default, the port is configured for RS-232. In order to configure it for RS-485, you can write to an entry in sysfs:
root@nitrogen6x:/ # echo 1 > /sys/devices/platform/imx-uart.4/rs485_en
If a board will be at the end of an RS-485 chain, you may also need to use SW5 to enable a termination resistor. There are silk screen labels showing the positions, and RS-485 means terminated as shown in the photo.

Dual independent LVDS

One of the primary features of the Nitrogen6 Max board is the addition of a second LVDS channel, that can be used to drive either two separate displays or a single, high-resolution display. Neither one of these is truly plug and play, and some effort is required to make use of them in this Android release.

To begin with, only a single panel (LVDS0 on the bottom side of the Nitrogen6 Max) is supported in U-Boot, and this must be defined as the primary display.

Since our boards only have a single I2C connector (J7) for use in connecting a touch screen, we can only detect one touch controller. Even if we did detect multiple displays, we have no way of knowing which you’d want to be the primary display. (You may not be aware of this, but the Android support for multiple displays uses the primary (/dev/graphics/fb0) display to define the screen resolution for applications and simply mirrors and scales the content to the secondary display)

The configuration process is simple though. You enable the second display by inserting multiple video= clauses with the dev=ldb flag to the bootargs variable in U-Boot.

For example, this fragment will configure our 1280×800 panel as the primary and a 1024×600 panel as the secondary display:
video=mxcfb0:dev=ldb,1280x800MR@60,if=RGB666,bpp=32 video=mxcfb1:dev=ldb,1024x600MR@60,if=RGB666,bpp=32
You will need a custom boot script for this.

The next issue related to dual independent LVDS displays is the backlight. The Android userspace only has support for a single brightness control, and we have this connected to PWM4 to control the brightness of the primary panel (i.e. same as BD-SL-i.MX6 and Nitrogen6x).

The second LVDS port has its’ backlight control on PWM3, and the only way you can control it is through sysfs:

full brightness
root@nitrogen6x:/ # echo 255 > /sys/class/backlight/pwm-backlight.2/brightness
minimum brightness
root@nitrogen6x:/ # echo 0 > /sys/class/backlight/pwm-backlight.2/brightness
(N.B. PWM4 maps to pwm-backlight.3 and PWM3 to pwm-backlight.2 because hardware folks start numbering at 1 for some unknown reason)

Dual-channel (bonded) LVDS

Dual-channel LVDS is much simpler, since it doesn’t involve multiple backlights, but it does have some quirks because:
  • U-Boot doesn’t yet support it, and
  • We don’t have an off-the-shelf panel to auto-configure
We tested against a 22-inch 1080p display and added support for it to our boot script. You can configure for this resolution by setting the panel variable in U-Boot in the same manner as used for our 1280×800 displays:

U-Boot > setenv panel 1080P
U-Boot > saveenv && reset
We are looking for an HD panel to offer as a companion product. Please let us know what type/size of panel you’d like to see.

4 GiB quirks

Now for the fine print.

There appear to be some bugs in the GPU acceleration when operating with more than 2GiB of RAM. As discussed in this post on i.MX Community site, we saw some very odd behavior with multiple displays when porting our Nitrogen6 Max kernel to Android.

The problems went away if we either set the max memory to 2GiB using the mem=2G kernel command-line argument or if we disabled hardware overlays in the Developer Settings panel.

When enabled, the Hardware Overlays feature allows applications to write directly to GPU surfaces, which minimizes the number of copies needed when updating graphic elements. This is speculation, but we believe that some piece of the graphics stack is seeing physical addresses > 2GiB as being invalid in a similar way these gstreamer components. The gstreamer components were using virtual addresses, but we believe the issue to be related.

Unfortunately, the setting in Developer Options is not persistent, and the problem components are closed-source, so we’ll have to defer to Freescale for a fix.

Fortunately, this is relatively easy to work around, and in this image, we’ve renamed the file /system/lib/hw/hwcomposer_viv.imx6.so to /system/lib/hw/hwcomposer_viv.imx6.so.disabled, which prevents the use of hardware overlays and doesn’t seem to have a dramatic impact on performance.

If you’re using this image on a BD-SL-i.MX6 or Nitrogen6x, you’ll want to put this file back:
root@nitrogen6x:/ # mount -o remount,rw /system
root@nitrogen6x:/ # mv /system/lib/hw/hwcomposer_viv.imx6.so.disabled /system/lib/hw/hwcomposer_viv.imx6.so
root@nitrogen6x:/ # sync && reboot 
Viewing all 391 articles
Browse latest View live