For the impatient

• 20140729-nitrogen-3.10.17_1.0.0_ga-trusty-en_US-lxde_armhf.img.gz

2014-07-30: N.B.: We updated this image from the original 20140727 version.

Programming the image

~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ zcat 20140729-nitrogen*.img.gz | sudo dd of=/dev/sdc bs=1M
~/Downloads$ sync

Source code access

Highlights

• Based on Ubuntu 14.04.1 (Trusty Tahr) release, which is a long-term-support version, so it will have a three year life span.
• Based on LXDE – The “Lightweight X11 Desktop Environment” (as was the previous Raring image).
• Has a fully GPU-accelerated X-Windows stack.
• Includes accelerated gstreamer plugins for video encode and decode.
• Includes support for simultaneous access to both our 5 mega-pixel OV5640 MIPI and OV5642 parallel (CSI) cameras in the same kernel image.
• Includes a packaged kernel, so you can use apt-get to upgrade without worries about breaking things.
• Boots to a RAM disk (/initrd.img) instead of directly to the rootfs.
• Boots to a zImage in normal Ubuntu fashion.
• Includes all components needed for Wi-Fi, Bluetooth, and CAN bus access (including can-utils).
• Includes the Onboard on screen keyboard to allow use without a physical keyboard (i.e. with just a touch screen).

Display setup

U-Boot > setenv panel 1080P
U-Boot > saveenv && reset

Usernames and passwords

ubuntu@nitrogen:~$ sudo mkdir /root/.ssh
[sudo] password for ubuntu: 
ubuntu@nitrogen:~$ sudo nano /root/.ssh/authorized_keys
... paste content of $HOME/.ssh/id_rsa.pub here
ubuntu@nitrogen:~$ sudo chmod 600 /root/.ssh/auth*
ubuntu@nitrogen:~$ sudo chmod 600 /root/.ssh/

Desktop shortcuts

• A link to the Boundary Devices web-site,
• The glmark2 OpenGL benchmark program,
• One of the Vivante GPU demonstration programs, and
• A video link that will play Tears of Steel at full 1080P resolution over the Internet

• usbwriter-nitrogen6x-20140727.zip

root@nitrogen:~# rfkill block bluetooth
root@nitrogen:~# rfkill unblock bluetooth
root@nitrogen:~# hciattach -t 30 /dev/ttymxc2 texas 115200 flow
root@nitrogen:~# hciconfig  hci0 up
root@nitrogen:~# hcitool scan
... nearby devices listed here

CAN bus testing

root@nitrogen:~# ip link set can0 up type can bitrate 125000
root@nitrogen:~# candump can0 &
root@nitrogen:~# cansend can0 5A1#11.22.33.44.55.66.77.88
  can0  5A1   [8]  11 22 33 44 55 66 77 88

root@nitrogen:/ # echo 1 > /sys/devices/platform/imx-uart.4/rs485_en

root@nitrogen:~# apt-get install microcom
Reading package lists... Done
Building dependency tree        
Reading state information... Done
The following NEW packages will be installed:
  microcom
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 13.9 kB of archives.
After this operation, 64.5 kB of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports/ trusty/universe microcom armhf 2012.06.0-3ubuntu1 [13.9 kB]
Fetched 13.9 kB in 0s (28.7 kB/s)  
Selecting previously unselected package microcom.
(Reading database ... 104564 files and directories currently installed.)
Preparing to unpack .../microcom_2012.06.0-3ubuntu1_armhf.deb ...
Unpacking microcom (2012.06.0-3ubuntu1) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up microcom (2012.06.0-3ubuntu1) ...
root@nitrogen:~# microcom -s 115200 -p /dev/ttymxc4

Camera testing

root@nitrogen: ~/$ gst-launch mfw_v4lsrc device=/dev/video0 \
                       ! mfw_v4lsink disp-width=640 disp-height=480

root@nitrogen: ~/$ gst-launch mfw_v4lsrc device=/dev/video2 \
                       ! mfw_v4lsink disp-width=640 disp-height=480

Onboard on screen keyboard

For the impatient

• kk-nitrogen6x-20140911.img.gz

Source code access

What’s new

Why a pre-release?

• The Nitrogen6_Lite board has not yet been tested.
• The browser cache is back in the /data partition, which will cause things to be slow, and
• We’ve seen some issues with video formats which were previously supported. Notably, the AAC audio encoder seems to be broken.

What’s included

What we’ve tested

What’s the fate of JB?

• u-boot-production.tar.gz

U-Boot > bootfile=u-boot.nitrogen6q ; run upgradeu

U-Boot > ums 0 mmc 0

1. ums only supports a single block device, so we’ll need to determine which to use when invoking it, and
2. It’s slower. U-Boot is a single-tasker and doesn’t support asynchronous writes to block devices, so ums will toggle between USB transfers and disk transfers. Our testing shows that this results in transfer times that are 3x longer.

for dtype in sata mmc usb ; do 
    for disk in 0 1 ; do
        try to load and source 6x_bootscript

setenv stdout serial,vga
echo ; echo 6x_bootscript not found
echo ; echo serial console at 115200, 8N1
echo details at http://boundarydevices.com/6q_bootscript
setenv stdin serial,usbkbd

for dtype in sata mmc ; do
    for disk in 1 0 ; do
        ums 0 $dtype $disk

Availability

• u-boot-production.tar.gz

U-Boot > bootfile=u-boot.nitrogen6q ; run upgradeu

• Hans de Goede’s fixes for USB (including keyboards), and
• Masahiro Yamada’s addition of Kconfig

• 20140925-nitrogen-3.10.17_1.0.1_ga-trusty-en_US-lxde_armhf.img.gz

Programming the image

~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ zcat 20140925-nitrogen*.img.gz | sudo dd of=/dev/sdc bs=1M
~/Downloads$ sync

• The Chromium web browser is now accelerated (WebGL and preliminary video decode).
• Now supports WiFi and Bluetooth (with some caveats) on Nitrogen6 Lite.
• Includes the latest GPU patches from the Freescale 3.10.17_1.0.1 release.
• It boots faster through the use of allow-hotplug for the ethernet device
• Full BlueZ (and GUI) support for Bluetooth on Nitrogen6x and Nitrogen6_Max boards.

• The boot script requires variable dtbname in order to identify the board as a Nitrogen6_Lite,
• The default settings of 128MiB of GPU memory are excessive, since the Nitrogen6_Lite board only has 512MiB, and
• The Bluetooth stack is not fully integrated, and conflicts with the Nitrogen6X/6Max boards because a different chip is used.

gpumem=67108864
dtbname=imx6dl-nit6xlite.dtb

U-Boot > setenv gpumem 67108864
U-Boot > setenv dtbname imx6dl-nit6xlite.dtb
U-Boot > saveenv

root@nitrogen:~# apt-get install brcm-patchram-plus-boundary 
root@nitrogen:~# sync && reboot
...

root@nitrogen:~# hciconfig hci0
hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 1021:8  SCO MTU: 64:1
	DOWN 
	RX bytes:574 acl:0 sco:0 events:27 errors:0
	TX bytes:411 acl:0 sco:0 commands:27 errors:0

root@nitrogen:~# hciconfig hci0 up
root@nitrogen:~# hcitool -i hci0 scan
Scanning ...
	C4:85:08:01:FB:E3	devicename

Keep in touch

For the impatient

• kk-nitrogen6x-20141007.img.gz for Nitrogen6X, SABRE Lite and Nitrogen6_Max
• kk-nit6xlite-20141007.img.gz for Nitrogen6_Lite

Source code access

For the newcomers

• Register with our web-site, and
• Send us your SSH public key

~/$ 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/android-manifest.git \
       -b boundary-kk4.4.2_1.0.0-ga
~/myandroid$ repo sync

• default.xml for KK 4.4.2

~/myandroid$ source build/envsetup.sh
~/myandroid$ lunch
... choose Nitrogen6x or Nit6xlite from the list of boards and then build
~/myandroid$ make 2>&1 | tee build-kk.out

root@nitrogen6x:# mount -o remount,rw /system

~/myandroid$ adb sync

root@nitrogen6x:# stop && start

What’s missing?

• Testing time, and
• Browser cache optimization

If you didn’t catch the announcement on the meta-freescale mailing list, or the one on i.MX Community, the Yocto 1.7 release (code name Dizzy) is now officially out for Freescale-based boards and it’s time to toot some horns!

This release is much more polished than previous releases, and we’d like to express our thanks to all of those involved, especially to Otavio Salvador at O.S. Systems for his stewardship of the project, Carlos Rafael Giani for his Chromium acceleration work, and Daiane Angolini for producing some great release notes and documentation. Great job folks!

Since the documentation is quite complete, this will be a short post, but we do want to encourage the use of this code base, so we put together a couple of quick images for our boards:

• For Nitrogen6X, BD-SL-i.MX6 (SABRE Lite), and Nitrogen6_Max boards:
  core-image-sato-nitrogen6x-20141107205431.rootfs.sdcard.gz
• For Nitrogen6_Lite boards:
  core-image-sato-nitrogen6x-lite-20141108050022.rootfs.sdcard.gz

We missed doing this during the daisy release cycle and have had some customers reaching all the way back to our Dora image or our 3.10.17-beta image.

No mas! The current iteration supports a lot more features and is much more stable.

The images themselves are fairly mundane copies of core-image-sato, but we’ve placed the configuration on-line for reference:

• local.conf
• bblayers.conf

You can installing these images to SD card using zcat and dd under Linux. Assuming your SD card shows up as /dev/sdc, you can use these commands to write it:

~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ sudo dd if=core-image-sato-nitrogen6x-*.sdcard.gz of=/dev/sdc bs=1M
~/Downloads$ sync

You can also use Alex Page’s USB Image Creator under Windows.

As always, give us some feedback about your experience with Yocto in general, or with this release.

The post Dizzy release of Yocto appeared first on Boundary Devices.

The upcoming 3.10.31 release of the Linux kernel for our i.MX6 boards will be introducing a slight incompatibility regarding the naming of SD card devices. Because of this, the root= clause in the kernel command line will need to change, and some background information is in order.

How it was broken

How this is fixed in new kernels

How we’ll handle the transition

U-Boot > setenv sdphys 1U-Boot > saveenvU-Boot > boot

For images that support RAM disks

What about Android?

The post root equals what? appeared first on Boundary Devices.

What exactly do we mean by the word board? While we sometimes use the word to refer to a printed circuit board with a specific configuration, we also use the term to mean something less concrete. This post will describe the flexible bits and hopefully give you a better understanding of how our standard boards can and should be customized to meet your needs. If you’re a customer designing a SOM carrier, it will also provide some tips on how to create and maintain your designs. A follow-up post will give a concrete example of how you can use device trees to re-map our LCD interface.

As Alvin Toffler predicted in The Third Wave, the era of mass customization is upon us, and we hope this set of notes will help you deal with the specifics.

For the impatient

For any given PCB, a number of things can be customized in the boot process, and the following lists the highlights in order of frequency.

Thankfully, the order listed above is also roughly sorted by ease of implementation, since programmers have a way of making the common stuff easy.

The rest of this post will walk through the details of each of these items.

Boot Scripts

Our current boot script consists of around 150 lines of text, up from around 60 when we first pushed to main-line U-Boot.

Most of this is meaningless for any given application. The bulk of the script is made up of conditionals that try to determine what type of display(s) you have connected and whether or not you have a RAM disk or Device Tree Blob. Once you’ve settled on a configuration, you can simplify all of this to around five lines and two statements (one of them a compound statement using the && operator):

setenv bootargs "stuff copied from /proc/cmdline";
load mmc 0 10800000 /path/to/my/uImage &&
load mmc 0 13000000 /path/to/my/dtb &&
load mmc 0 12a00000 /path/to/my/ramdisk &&
bootm 10800000 12a00000 13000000

After all, the primary purpose of U-Boot is to load and launch the kernel with proper parameters, and all of the variables live in the bootargs variable and the three files listed above (kernel, device tree and RAM disk).

Pay close attention to the first line above. If our standard boot script works for you, the pre-computed kernel command line is available to you in /proc/cmdline, all ready for cutting and pasting:

root@nitrogen6x:~# cat /proc/cmdline
enable_wait_mode=off video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:dev=lcd,CLAA-WVGA,if=RGB666 video=mxcfb2:off video=mxcfb3:off fbmem=10M,10M console=ttymxc1,115200 vmalloc=400M consoleblank=0 vt.global_cursor_default=0 rootwait root=/dev/mmcblk0p2 mxc_hdmi.only_cea=1

When you combine this with our on-line boot script compiler, it’s really pretty simple to create your own boot script.

Kernel configuration

Our Linux kernel configuration file (nitrogen6x_defconfig) defines the set of device drivers available to the running kernel. We use this to select most of the options we support, including all of the core features of the i.MX6, as well as our touch screen displays and camera modules.

We also include support for some frequently used peripherals like USB sticks, and serial adapters, but our driver set is quite limited.

If you need additional drivers, you’ll need to use make menuconfig to customize the kernel build.

You may also want to remove drivers for parts you’re not using both to save space and time during the boot process, but also to prevent drivers like the Ilitek touch screen from trying to probe needlessly:

ili210x_i2c 2-0041: i2c transfer failed
ili210x_i2c 2-0041: Failed to get firmware version, err: -5
ili210x_i2c: probe of 2-0041 failed with error -5

The details of how to do this vary quite a bit between Yocto, Ubuntu, Android and other userspaces, but the process isn’t difficult and is generally worth some effort.

Kernel Device Trees

We’ll be following this post with another that delves deeply into device trees, but some fairly easy changes to the device tree descriptions of our boards can speed up the boot and free up pins for other uses.

In some cases, the changes can be as minor as changing this “okay” to “disabled”“.

Boot command line

We try not to impose restrictions on you, and allow booting to SATA, either SD card, or even USB stick by default. Our default bootcmd variable is what defines this through the use of the bootdevs variable and a couple of nested for loops.

If you know that you’re booting to SATA, you can speed up the boot process by over-riding this without re-compilation like so:

U-Boot > setenv bootcmd 'disk=0; dtype=sata; 
   load 10008000 sata 0 /6x_bootscript 
   && source 10008000'
U-Boot > saveenv && boot

Note that the dtype and disk variables are only here in case you try this with our standard boot script. If you have already done away with that, this isn’t needed.

Note that you can also do away with the boot script entirely by simply saving your bootargs and setting bootcmd to load and launch your kernel:

U-Boot > setenv bootargs "copied from /proc/cmdline"
U-Boot > setenv bootcmd 'load mmc 0 10800000 /path/to/my/uImage &&
load mmc 0 13000000 /path/to/my/dtb &&
load mmc 0 12a00000 /path/to/my/ramdisk &&
bootm 10800000 12a00000 13000000'
U-Boot > saveenv && boot

U-Boot configuration

Our current U-Boot binaries are around 350 KiBytes, and that size can be reduced by tweaking the board’s header file. If you look at nitrogen6x.h, you’ll find a number of macro definitions of the form CONFIG_FEATURE that enable features of U-Boot. Judicious selection of the features you need can result in a smaller image and a faster boot.

The U-Boot variable panel can also be defined at compile time to select from the list of supported displays and bypass probing for the display type. This not only speeds the boot, it also removes a potential source of failure.

Defining other things like the new sdphys variable in the board’s header file can remove the need to configure boards after shipment.

U-Boot source code

Our U-Boot doesn’t currently support using device trees for its’ own use, and pin definitions are defined in the U-Boot source files. If you want to re-purpose these, and especially if you’re designing a SOM carrier board, you may need to update the U-Boot sources directly.

Recent enhancements to U-Boot, especially Masahiro Yamada’s addition of Kconfig offers the prospect of lighter-weight modifications down the road.

Kernel sources

When all else fails, you (or we) may need to hack update the kernel sources.

If you’re using some newly released peripheral, it’s common to need a new device driver to support it.

If the device is supported in newer (or older) kernels, you may need to back-port it from another tree.

Even things as simple as connecting up a new display might involve the addition of a GPIO like our oddly-named DISP0_CONTRAST pin to enable and disable a backlight.

Summary

Remember that our requirements tend to be broad because we don’t know exactly how you’ll use our boards. Once they’re in your hands, the needs tend to be much more specific, and we’re here to help you reach your targets.

The post What’s a board (and where are the knobs)? appeared first on Boundary Devices.

Starting with the release of Linux 3.5.7, a new feature known as Device Trees has fundamentally changed the way that boards are represented by the kernel. The “C” modules used in earlier kernels has been replaced with Device Tree Blobs (DTBs) as a way of representing the structure and connections for a particular board.

There’s a great deal of documentation on-line, including this set at elinux.org, so we won’t sweat the details.Instead, this post will explain how you can create device trees that change our standard boards to over-ride their normal functionality. An example will be presented that re-purposes the parallel LCD port as a set of SPI, GPIO, I2C, and PWM ports.

For the impatient

• We’ve created three new device trees that re-purposes the parallel LCD port (J15) on our Nitrogen6x, BD-SL-i.MX6 and Nitrogen6_Max boards.
• If you’re not using this port, you can configure U-Boot to load the alternate DTB and gain additional I/O.
• We’ve created a break-out board to make it easier to connect to these pins.
• You can use the same approach to build your own Device Trees and customize the kernel for your own purposes.
• The easiest functions to re-map are the Parallel LCD port (J15), the Parallel Camera port (J5), the Android Button connector (J14) and the Boot mode/EIM connector (J12).

Background

There’s a great description about the rationale for the usage of Device Trees here on the Ubuntu Wiki.

To quote:

As the number of chip-sets increase, so too does the software needed to support them at the kernel level.

To elaborate on Ubuntu’s comment:

As the number of boards increases, so too does the software…

When you add in the specific requirements for even standard boards as discussed in our earlier post, things get out of control quickly.

The Flattened Device Tree specification helps to bring some order to this.

Immediate (and visible) impact

As a practical matter, the first thing you’ll need to know about device trees is that we’re packaging them separately from the kernel.

In earlier kernels, we’ve booted by simply loading a kernel (generally uImage), setting bootargs to point at a root filesystem and launching with a single-argument bootm command.

With device-tree enabled kernels, we also need to load a .dtb file and pass an additional argument to bootm or bootz.

We’ve updated our boot scripts to do this, and even to compute the file name based on the CPU and board type but haven’t commented much about it in the blog.

Note that if you set the dtbname environment variable, the boot script will bypass the test of board and cpu type.

U-Boot > setenv dtbname "my-custom.dtb"
U-Boot > saveenv

Division of labor

The key point in the separation of Device Tree and kernel is that:

• The kernel and any loadable modules defines the potential set of drivers supported, and
• The Device Tree defines the specific bindings for things that aren’t on enumerable busses like PCIe or USB

Note that the kernel and DTB can be bound together as described here, but this sacrifices much of the feature of device trees. This type of binding can be useful in speeding the boot, and securing an image, but it’s something that should happen late in the development process.

Our specifics

If you compare the file arch/arm/boot/dts/Makefile in our the boundary-imx_3.10.17_1.0.2_ga branch of our kernel repository against the Freescale release, you’ll see that we’ve added 19 different targets to represent our standard boards and custom designs using 3.10.17.

~/linux-imx6$ git diff --stat origin/imx_3.10.17_1.0.2_ga arch/arm/boot/dts/Makefile
 arch/arm/boot/dts/Makefile | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

If you look closely at the details, you’ll see that some boards have multiple variants for the Quad/Dual (q) and Dual-Lite/Solo processor variants to support the entire processor lineup:

~/linux-imx6$ git diff origin/imx_3.10.17_1.0.2_ga arch/arm/boot/dts/Makefile \
    | grep nitrogen6x
+	imx6dl-nitrogen6x.dtb \
+	imx6q-nitrogen6x.dtb \

This is done because the device tree bindings contain precise memory addresses for various peripherals and registers, and many of those addresses differ between the two processor variants.

To avoid duplication of the common parts, we’ve split the definition of our device trees into a common include file with the prefix imx6qdl- and a file extension of .dtsi and variant-specific files with the prefix of imx6q- and imx6dl- that #include the .dtsi file.

For example, take a look at the Device Tree Source (dts) files for the BD-SL-i.MX6:

~/linux-imx6$ ls arch/arm/boot/dts/imx6*sabrelite*.dts* | grep -v nolcd
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
arch/arm/boot/dts/imx6q-sabrelite.dts
~/linux-imx6$ head -n 20 arch/arm/boot/dts/imx6q-sabrelite.dts
...
#include 
#include "imx6q.dtsi"
#include "imx6qdl-sabrelite.dtsi"

/ {
	model = "Freescale i.MX6 Quad SABRE Lite Board";

Notice that the file imx6q-sabrelite.dts uses the #include directive to pull in both the imx6q.dtsi and imx6qdl-sabrelite.dtsi headers. Also note that the imx6q.dtsi and imx6dl.dtsi files in turn #include the file imx6qdl.dtsi, which is a Freescale-maintained header defining common parts of the entire family. Most of the components in the common header are disabled by default, so the board-level files need to enable them explicitly.

This pattern is repeated for all of our boards, and if we’re offering options for other processors, you’ll see a imx6dl- and imx6q- version
as with the Nitrogen6X:

~/linux-imx6$ ls arch/arm/boot/dts/imx6*nitrogen6x*.dts* | grep -v nolcd
arch/arm/boot/dts/imx6dl-nitrogen6x.dts
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
arch/arm/boot/dts/imx6q-nitrogen6x.dts

Structure of DTS

The structure of a Device tree file (after the preprocessor runs) is

/dts-v1/;

/ {
 #address-cells = ;
 #size-cells = ;
 chosen { };
 aliases { };
 memory { device_type = "memory"; reg = ; };
};
/ {
    additional declarations
};

&alias {
    override or augmentation of declaraion
};

The declarations section will define the CPU, RAM, busses, and peripherals connected to the CPU, and the references that follow may augment or override components declared previously through the use of aliases.

Okay or disabled

Components default to enabled (status="ok" or status="okay", but may be disabled explicitly by setting the status property to "disabled". For instance, if a particular board has a SATA bus defined, it might be disabled through a fragment like this:

&sata {
 status = "disabled";
};

Drivers and Pin Control blocks

One of the coolest features of i.MX processors is the ability to re-map the functionality of individual pins through a technique called pin muxing. Through this feature, a huge number of the 624 balls on the bottom of an i.MX6 can be re-purposed to as many as five different functions.

Refer to Chapter 36 of the i.MX6DQ Reference Manual for details.

This pin-muxing is common enough in ARM SOCs that it has direct support in the device tree implementation (for most drivers) and is generally implemented by
having a driver block like the LCD driver refer to a pinctrl block.

In the Nitrogen6x DTS file, you’ll find this:

	lcd0: lcd@0 {
		compatible = "fsl,lcd";
...
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_ipu1_4>;
		status = "okay";
	};

The declaration of pinctrl-0 is in the general

	pinctrl_ipu1_4: ipu1grp-4 {
		fsl,pins = <
			MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
			MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15       0x10
			MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02        0x10
			MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03        0x10
			MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00   0x10
        ...

Some of the details are omitted, but the key concept is that the LCD driver refers to the pinctrl block, which defines the configuration of the balls or pads which carry the signals.

Note that the references to the constants MX6QDL_PAD_... above have two parts, separated by double-underscores. The left-hand side is a reference to the pad name (the ball on the BGA). The right hand side is a reference to the chosen function. In the lines shown above, the mapping of the DI0 pads is made to their primary function as IPU_DI functions (short-hand for Image Processing Unit Display Interface, or parallel display).

If the lcd0 driver is instantiated, the pins will be configured, but not otherwise.

You may now be figuring out that we can prevent this mapping by setting the status of the lcd0 element to "disabled":

&lcd0 {
    status="disabled";
};

This is exactly what we've done on our way to re-mapping the functionality of J15 (the parallel display connector). You can see this in the device tree include file imx6qdl-boundary-nolcd.dtsi.

Looking further into that file, you'll also see that we've disabled the backlight driver:

&backlight_lcd {
	status = "disabled";
};

And the following bits disable or define some new functions of the pins on the display connector.

The new function(s) of J15

At this point, it's time to start describing the precise functionality for the new device tree configuration on ourNitrogen6x, BD-SL-i.MX6 and Nitrogen6_Max boards.

The following table shows the Voltage, pin numbers (for the breakout board and i.MX6 board), pad name, and function of each pin:

To summarize this, we've added:

• Two PWM outputs
• Three SPI ports. Two of these have a single chip-select. The third (SPI3) has four chip-selects, and
• Thirteen bi-directional GPIO ports, and
• We also retained the I2C3 functions on pins 35 and 36. These are used for a touch-screen controller in our normal use with our Nit6X_800x480 display

This is not bad for the addition of a single .dtsi file. Note that we've #include'd that file in three distinct device trees, and that these will be included in future images based on kernel 3.10.17+:

imx6q-sabrelite.dtb
imx6q-nitrogen6x.dtb
imx6q-nitrogen6_max.dtb

To re-iterate what was said above, you can use these functions by simply setting the dtbname variable in U-Boot. For example if you're running on a Nitrogen6_Max board, you'd enter these commands:

U-Boot > setenv dtbname imx6q-nitrogen6_max.dtb
U-Boot > saveeenv
U-Boot > boot

Note that neither the I2C nor SPI drivers have any kernel drivers associated with them, so you'll need to use the /dev/i2c or spidev interfaces to access them.

You can access the GPIO pins through /sys/class/gpio. For example, to toggle pin 16 (GP5:05), you can do this:

root@nitrogen6x:~# echo 133 > /sys/class/gpio/export
root@nitrogen6x:~# echo out > /sys/class/gpio/gpio133/direction
root@nitrogen6x:~# echo 1 > /sys/class/gpio/gpio133/value
root@nitrogen6x:~# echo 0 > /sys/class/gpio/gpio133/value

The GPIO numbers are calculated as ((bank-1)*32)+pin.

Other re-mapping possibilities

If you have other drivers to attach to the I2C bus, you can add them in this file, or even over-ride the file with your own overlay.

The primary reason we chose to build a break-out board for the LCD connector is that it contains a lot of pins. As mentioned in the For the impatient section above, there are other high pin count connectors that aren't often used.

• The parallel camera connector (J5). This connector contains 33 pins, and 20 un-buffered signals. It also contains 2.5V power supplies and ground.
• The Android button connector (J14). This connector contains 6 usable, un-buffered signals, plus a ground.
• The Boot mode/EIM connector (J12). This 40-pin connector contains 32 un-buffered signals, plus 3.3V and ground.

If you're designing a SOM carrier and need some additional I/O, you'll also find that the pins on these connectors are the easiest to re-map in software, since their primary functionality can be removed in large sets with a minimum of code change.

Summary

We do hope that this post gives you some encouragement and a better understanding of how device trees can help you either use our standard boards, or define your own variants and deliver better product faster.

As always, let us know if this is helpful, and where (not if) there are confusing bits.

The post i.MX6 Device Tree customization appeared first on Boundary Devices.

In our "What’s a board?" post, we described various ways that a board could be customized, and in the follow up " i.MX6 Device Tree customization", we showed how we created variants of our boards that re-purpose the parallel LCD pins. We also suggested the use of three common connectors when looking for additional I/O in a custom application.

This post contains the details of the functions available on those three most commonly replaced peripherals (parallel LCD, parallel camera, and Android buttons), and details the functions available on each.

If you’re designing a SOM carrier, or looking to enhance one of our standard boards, we strongly suggest that you look here first to see if these pins will provide what you need. Doing so will simplify your software development and may allow you to test the functionality before spinning a full custom board or SOM carrier.

Android button connector

J15 (Parallel RGB display)

J5 (CSI0 parallel camera interface)

The post Commonly replaced peripherals appeared first on Boundary Devices.

It’s the middle of December and time for an updated image with Ubuntu 14.04 (code name Trusty) for our i.MX6 boards. It’s also time that we pushed a console-only image for those using our boards in applications that don’t require X.

You can download the images from here:

• 20141215-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-lxde_armhf.img.gz
• 20141215-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-console_armhf.img.gz

In addition to general updates to our kernel and other packages, the LXDE image contains support for semi-accelerated Qt5. Note that this is based on Ubuntu’s release of Qt 5.2.1+dsfg. If you want the best-performing Qt5 release, please check out The Qt Company’s product.

The detailed description of our changes is here:

• 20141215-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-lxde_armhf.description

2014-12-16: N.B.: We updated these images from the original 20141205 and 20141212 versions. We upgraded the bluetooth firmware to the newest one.

Programming the image

The images are slightly-less-than-4GiB image files containing the partition table, so you can copy it to an SD card or SATA drive on /dev/sdc using zcat and dd like so:

~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ zcat 201412*.img.gz | sudo dd of=/dev/sdc bs=1M
~/Downloads$ sync

Or you can use Alex Page’s USB Image Tool under Windows.

If you’re using our latest U-Boot and a Nitrogen6 Max board, you can use the new USB Mass Storage Gadget to program the eMMC. If not, there were some notes in our first release that describe a more complicated way of programming eMMC.

The post Ubuntu Trusty December 2014 release appeared first on Boundary Devices.

The post Protected: Qt for Device Creation appeared first on Boundary Devices.

Every so often, we’re asked about accessing the Boot ROM (flash) from Linux. Sometimes it’s related to the question of upgrading U-Boot. Other times the question surrounds changing U-Boot environment variables or simply using the flash EEPROM to store some board-specific data.

In this post, we’ll describe the basics of how this work and give some examples of how the pieces of software fit together.

Quick reference for the impatient

• The MTD (Memory Technology Device) driver is used to map the serial EEPROM to devices
• The devices involved are named /dev/mtd*:

  root@trusty-dev:~# ls -l /dev/mtd*
  crw------- 1 root root 90, 0 Jan  9 11:13 /dev/mtd0
  crw------- 1 root root 90, 1 Jan  9 11:13 /dev/mtd0ro
  crw------- 1 root root 90, 2 Jan  9 11:13 /dev/mtd1
  crw------- 1 root root 90, 3 Jan  9 11:13 /dev/mtd1ro
  crw------- 1 root root 90, 4 Jan  9 11:13 /dev/mtd2
  crw------- 1 root root 90, 5 Jan  9 11:13 /dev/mtd2ro
  brw-rw---- 1 root disk 31, 0 Jan  9 11:13 /dev/mtdblock0
  brw-rw---- 1 root disk 31, 1 Jan  9 11:13 /dev/mtdblock1
  brw-rw---- 1 root disk 31, 2 Jan  9 11:13 /dev/mtdblock2
  

• The primary utilities used to read and write to these devices are in the mtd-utils package and are maintained at http://www.linux-mtd.infradead.org/
• The U-Boot utilities fw_printenv and fw_setenv as described by the Wiki at Denx Software Engineering
• We store our environment variables in the second partition of the flash:

  root@trusty-dev:~# cat /etc/fw_env.config 
  /dev/mtd1	0x00000	0x2000	0x1000	2
  

• You can override our default partitioning by adding a clause mtdparts= to your kernel command line in your boot script. The full documentation is here in the Kconfig file
• The name of the MTD partition will vary by kernel version, and is spi32766.0 in kernels 3.10.17 and 3.10.31.
• This example will reserve 16k for a splash screen, 4k for a data partition, and leave the rest unidentified:

  mtdparts=spi32766.0:768k(U-Boot),8k(Env),16k(splash),4k(mydata),-(rest)
  

• The file /proc/mtd can be used to see the current partitioning:

  root@trusty-dev:~# cat /proc/mtd    
  dev:    size   erasesize  name
  mtd0: 000c0000 00001000 "U-Boot"
  mtd1: 00002000 00001000 "Env"
  mtd2: 00001000 00001000 "mydata"
  mtd3: 0013d000 00001000 "rest"
  

• Our standard serial EEPROM is 2MiBytes.
• We reserve 768k for the U-Boot boot loader, and 8k for the U-Boot environment block, so there’s a little over 1MiB available for other uses
• U-Boot versions before 2014.07 didn’t properly handle this. A patch from Dustin Byford may be needed if you’re using an old version of fw_setenv.

Maybe that wasn’t such a quick reference.

There are a lot of details to consider when describing things, but the basics are fairly simple. The mtd device driver(s) provide access to the serial EEPROM through a set of character devices, each of which corresponds to a region of the 2MiB of storage.

Background

• EEPROM == Electrically Erasable Programmable Read Only Memory
• NOR = Not OR – refers to the way that the memory is stored and this has implications on the characteristics of the memory. In particular, NOR flash is very reliable and doesn’t require error correction. Refer to this Wikipedia entry for more details about flash memory
• SPI NOR/serial EEPROM – refers to the fact that we use the Serial Peripheral Interface (SPI) bus to communicate with the ROM. This is a serial bus, with a clock, two data lines (MOSI and MISO) and a chip select.
• Boot ROM – We program the fuses on our i.MX6-based boards to point at the serial EEPROM, so we refer to it as the Boot ROM

Simplest usage

root@trusty-dev:~# hexdump -C /dev/mtd1ro  | head
00000000  9d 6d 56 c6 62 61 75 64  72 61 74 65 3d 31 31 35  |.mV.baudrate=115|
00000010  32 30 30 00 62 6f 61 72  64 3d 6e 69 74 72 6f 67  |200.board=nitrog|
00000020  65 6e 36 78 00 62 6f 6f  74 63 6d 64 3d 66 6f 72  |en6x.bootcmd=for|
00000030  20 64 74 79 70 65 20 69  6e 20 24 7b 62 6f 6f 74  | dtype in ${boot|
00000040  64 65 76 73 7d 3b 20 64  6f 20 69 66 20 69 74 65  |devs}; do if ite|
00000050  73 74 2e 73 20 22 78 75  73 62 22 20 3d 3d 20 22  |st.s "xusb" == "|
00000060  78 24 7b 64 74 79 70 65  7d 22 20 3b 20 74 68 65  |x${dtype}" ; the|
00000070  6e 20 75 73 62 20 73 74  61 72 74 20 3b 66 69 3b  |n usb start ;fi;|
00000080  20 66 6f 72 20 64 69 73  6b 20 69 6e 20 30 20 31  | for disk in 0 1|
00000090  20 3b 20 64 6f 20 24 7b  64 74 79 70 65 7d 20 64  | ; do ${dtype} d|

The simplest way to program the serial EEPROM is to use the flash_erase tool to erase a partition and flashcp to program it.

root@trusty-dev:~# flash_erase /dev/mtd1 0 0
Erasing 4 Kibyte @ 1000 -- 100 % complete

root@trusty-dev:~# hexdump -C /dev/mtd1ro  | head
00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00002000

root@trusty-dev:~# flashcp u-boot-env /dev/mtd1
root@trusty-dev:~# hexdump -C /dev/mtd1ro  | head
00000000  fe 4c 3c e6 62 61 75 64  72 61 74 65 3d 31 31 35  |.L<.baudrate=115|
00000010  32 30 30 00 62 6f 61 72  64 3d 6e 69 74 72 6f 67  |200.board=nitrog|
00000020  65 6e 36 78 00 62 6f 6f  74 32 71 74 5f 75 70 64  |en6x.boot2qt_upd|
00000030  61 74 65 5f 73 74 61 74  65 3d 76 61 6c 69 64 00  |ate_state=valid.|
00000040  62 6f 6f 74 61 72 67 73  3d 65 6e 61 62 6c 65 5f  |bootargs=enable_|
00000050  77 61 69 74 5f 6d 6f 64  65 3d 6f 66 66 20 63 6f  |wait_mode=off co|
00000060  6e 73 6f 6c 65 3d 74 74  79 6d 78 63 31 2c 31 31  |nsole=ttymxc1,11|
00000070  35 32 30 30 20 76 6d 61  6c 6c 6f 63 3d 34 30 30  |5200 vmalloc=400|
00000080  4d 20 63 6f 6e 73 6f 6c  65 62 6c 61 6e 6b 3d 30  |M consoleblank=0|
00000090  20 76 69 64 65 6f 3d 6d  78 63 66 62 30 3a 64 65  |video=mxcfb0:de|

U-Boot environment access

The tools fw_printenv and fw_setenv can be used to get and set environment variables:

root@trusty-dev:~# fw_printenv | head -n 3
baudrate=115200
board=nitrogen6x
boot2qt_update_state=valid

root@trusty-dev:~# fw_printenv board
board=nitrogen6x

root@trusty-dev:~# fw_setenv board myboard
root@trusty-dev:~# fw_printenv board
board=myboard

root@trusty-dev:~# fw_setenv blah BLAH
root@trusty-dev:~# fw_printenv blah
blah=BLAH
root@trusty-dev:~# fw_setenv blah 
root@trusty-dev:~# fw_printenv blah
## Error: "blah" not defined

These utilities require a configuration file in /etc/fw_env.config:

root@trusty-dev:~# fw_printenv
Cannot parse config file: No such file or directory
root@trusty-dev:~# cat > /etc/fw_env.config
/dev/mtd1	0x00000	0x2000	0x1000	2
^D
root@trusty-dev:~# fw_printenv board
board=nitrogen6x

As mentioned above, they also require a patch for versions that pre-date U-Boot 2014.07:

root@trusty-dev:~# fw_setenv board myboard
End of range reached, aborting
Error: can't write fw_env to flash

Other uses

We mentioned splash screens, which are a natural fit, since they can provide a polished output even if no bootable SD card is present.

They can be used to store other things as well, as long as you keep a handful of things in mind:

• Flash is quick to write, but slow to erase
• Flash EEPROM wears out based on erase cycles
• The parts we use are rated to 100,000 erase cycles
• Erasing a sector sets all bits to 1's

This form of storage is especially suitable for things that are small and infrequently written such as serial numbers, machine configuration, maintenance logs and the like.

We hope this helps you understand how to get the most out of your Boundary Devices board.

As always, contact us if you have questions or concerns.

The post Boot flash access from Linux appeared first on Boundary Devices.

We’ve had lots of customers ask about cellular modem support on our i.MX6 boards, and in the past, have mostly just shrugged.

Since most cell modems are USB or PCIe devices, configuration is a software task, and mostly done in userspace. The steps are also different for Android, embedded Linux and desktop distributions.

In other words, its complicated.

In this post, we’ll walk through all of the steps needed to configure a specific set of modems under Ubuntu as a reference. If you’re using another modem or another userspace, the details may be different, but the fundamentals will be the same.

We used the Huawei E3131 USB dongle , and Huawei MU609 Mini-PCIe during this process, and will be adding them to our default kernels going forward.

As you can see in this patch, we did have to add some USB device ids and make minor updates to the kernel as provided by the vendor. In the process, we should now also support the following Huawei models for various regions and carriers:

• MC323   CDMA: Downlink:153.6 kbps, Uplink: 153.6 kbps
• MU509   WDCMA: Downlink:3.6 Mbps, Uplink: 384 kbps
• MC509   EVDO: Downlink:3.1 Mbps, Uplink: 1.8 Mbps
• MU609   HSPA+: Downlink:14.4 Mbps, Uplink: 5.76 Mbps
• MU709   HSPA+: Downlink:21.6 Mbps, Uplink: 5.76 Mbps
• ME906   LTE: Downlink:100 Mbps, Uplink: 50 Mbps
• ME909   LTE: Downlink:100 Mbps, Uplink: 50 Mbps
• ME936   LTE: Downlink:100 Mbps, Uplink: 50 Mbps

For the impatient

These images contain Freescale-licensed content, so you will need to register on our web-site and log in before you can accept the license agreement and download the images from here:

• 20150122-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-lxde_armhf.img.gz
• 20150122-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-console_armhf.img.gz

The detailed description of our changes is here:

• 20150122-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-lxde_armhf.description
• 20150122-nitrogen-3.10.17_1.0.2_ga-trusty-en_US-console_armhf.description

Programming the image

The images are slightly-less-than-4GiB image files containing the partition table, so you can copy it to an SD card or SATA drive on /dev/sdc using zcat and dd like so:

~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ zcat 201501*.img.gz | sudo dd of=/dev/sdc bs=1M
~/Downloads$ sync

Or you can use Alex Page’s USB Image Tool under Windows.

If you’re using our latest U-Boot and a Nitrogen6 Max board, you can use the new USB Mass Storage Gadget to program the eMMC. If not, there were some notes in our first release that describe a more complicated way of programming eMMC.

Contents

In the rest of this post we’ll walk through the following:

• Hardware installation
  • MU609 modem installation on a Nitrogen6_Max board (mPCIE interface)
  • MU609 modem installation on BD-SL-i.MX6, Nitrogen6X, or Nitrogen6_Lite boards (USB dongles)

• Software configuration for a headless (No GUI) Ubuntu system
  • Testing whether the system recognizes the modem
  • Finding the optimal antenna position
  • Checking the subscriber information
  • Connecting to the internet

• Software configuration for an Ubuntu LXDE desktop

Hardware Installation

Installing MU609 modem on Nitrogen6-Max board

The Nitrogen6_Max board has a PCI Express Mini Card slot and a built-in SIM card socket, so installation of the MU-609 is very straightforward.

Insert the modem in the PCI-e socket as shown below.

Nitrogen-Max board, top, MU609 modem inserted to the PCI-e socket.

Connect the antennas to the modem card, as follows :

• M – MAIN GSM antenna
• G – GPS antenna
• A – AUX GSM antenna

If you have only one GSM antenna, connect it to the M mini coax connector.

Then insert your SIM card to the socket in the bottom side of the board as shown in the figure below. 

Nitrogen-Max board, bottom, SIM card inserted to the socket.

Installing MU609 modem on BD-SL-i.MX6, Nitrogen6X, or Nitrogen6_Lite boards

These boards require a mini PCI-e to USB adapter to connect the modem. They’re cheap and easy to find (Search eBay for “mini PCI-e USB wireless SIM” keywords).

If you need a free USB port, install a USB HUB, and problem solved.

Mini PCI-e to USB Adapter, top with PCI-e MU609 modem

Mini PCI-e to USB Adapter, bottom, loaded with SIM card

Using modem on a headless (No GUI) Ubuntu system

Software prerequisites

Make sure you have the latest kernel installed, but at least the ABI >= 34 :

ubuntu@trusty-dev:/$ uname -r
3.10.17-34-boundary-4t3
ubuntu@trusty-dev:/$

If this is not the case, please type :

ubuntu@trusty-dev:/$ sudo apt-get update && sudo apt-get dist-upgrade

We will solve the modem handling tasks with the modemmanager package. This package provides a unified high level API for communicating with (mobile broadband) modems. ModemManager is a daemon that gets started at boot time.

The modemmanager package provides a command line tool, named mmcli, to control the ModemManager daemon. That will be the tool used below.

We will solve the connection handling tasks with the network-manager package. We can use the NetworkManager’s huge database to use the cellular service provider data and settings. With the NetworkManager we can create connection configuration files, with specific parameters, that makes internet connection handling very easy.

Make sure you have installed modemmanager , networkmanager 1.4.0 and uuid packages :

ubuntu@trusty-dev:/$ dpkg -l | grep -e modemmanager -e network-manager -e uuid
ii libossp-uuid16              1.6.2-1.3ubuntu1             armhf        OSSP uuid ISO-C and C++ - shared library
ii libuuid1:armhf              2.20.1-5.1ubuntu20.3         armhf        Universally Unique ID library
ii modemmanager                1.4.0-1                      armhf        D-Bus service for managing modems
ii network-manager             0.9.8.8-0ubuntu7             armhf        network management framework (daemon and userspace tools)
ii uuid                        1.6.2-1.3ubuntu1             armhf        the Universally Unique Identifier Command-Line Tool

If these packages are not installed, please type the following and then restart the system:

ubuntu@trusty-dev:/$ sudo apt-get install modemmanager network-manager uuid

We back-ported modemmanager 1.4.0-1 and libmbim 1.10.0-2.1 and libqmi 1.10.2-2 to Ubuntu Trusty Tahr to support the latest modems and service providers.

If everything went well, your ModemManager and NetworkManager will start at boot time. You can check it like so:

ubuntu@trusty-dev:/$ ps -A | grep Manager
 662 ? 00:00:01 ModemManager
 722 ? 00:00:56 NetworkManager

When ModemManager starts it scans the serial ports for modems and it tries to recognize them. It takes quite long, 20-30 seconds (!!!) after the login prompt, so you’ll need to be patient.

Testing whether the system recognizes the modem

You can check the presence of the USB modem device using lsusb:

ubuntu@trusty-dev:/$ lsusb
Bus 001 Device 006: ID 12d1:1573 Huawei Technologies Co., Ltd. 
Bus 001 Device 005: ID 1c4f:0002 SiGma Micro Keyboard TRACER Gamma Ivory
Bus 001 Device 004: ID 1bcf:0005 Sunplus Innovation Technology Inc. 
Bus 001 Device 003: ID 05e3:0605 Genesys Logic, Inc. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp. 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The first one with 12d1:1573 key, that is the Huawei MU609 modem.

You can check the modem’s serial ports :

ubuntu@trusty-dev:/$ ls -a1 /dev/ttyU*
/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2
/dev/ttyUSB3
/dev/ttyUSB4

The Huawei modem creates five USB serial ports. Others may create fewer.

At this point, you can see if modemmanager detects the modem with mmcli -L:

ubuntu@trusty-dev:/$ mmcli -L
Found 1 modems:
 /org/freedesktop/ModemManager1/Modem/0 [Huawei Technologies Co., Ltd.] MU609
ubuntu@trusty-dev:/$ 

And you can see more details of the modem with mmcli -m:

ubuntu@trusty-dev:/$ mmcli -m 0
/org/freedesktop/ModemManager1/Modem/0 (device id '2431657b772fc128a660f7b8c0587c213129ca8f')
 -------------------------
 Hardware | manufacturer: 'Huawei Technologies Co., Ltd.'
 | model: 'MU609'
 | revision: '12.105.29.00.00'
 | supported: 'gsm-umts'
 | current: 'gsm-umts'
 | equipment id: '357784046035976'
 -------------------------
 System | device: '/sys/devices/soc0/soc.1/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3'
 | drivers: 'option1, cdc_ether'
 | plugin: 'Huawei'
 | primary port: 'ttyUSB2'
 | ports: 'eth1 (net), ttyUSB1 (qcdm), ttyUSB2 (at), ttyUSB3 (gps), ttyUSB4 (at), ttyUSB0 (at)'
 -------------------------
 Numbers | own : 'unknown'
 -------------------------
 Status | lock: 'none'
 | unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)'
 | state: 'disabled'
 | power state: 'on'
 | access tech: 'unknown'
 | signal quality: '0' (cached)
 -------------------------
 Modes | supported: 'allowed: 3g; preferred: none
 | allowed: 2g; preferred: none
 | allowed: 2g, 3g; preferred: none'
 | current: 'allowed: 2g, 3g; preferred: none'
 -------------------------
 Bands | supported: 'unknown'
 | current: 'unknown'
 -------------------------
 IP | supported: 'ipv4'
 -------------------------
 3GPP | imei: '357784046035976'
 | enabled locks: 'none'
 | operator id: 'unknown'
 | operator name: 'unknown'
 | subscription: 'unknown'
 | registration: 'unknown'
 -------------------------
 SIM | path: '/org/freedesktop/ModemManager1/SIM/0'
-------------------------
 Bearers | paths: 'none'

Finding the optimal antenna position

Now we stop NetworkManager and ModemManager temporarily, because we want to run some more tests:

ubuntu@trusty-dev:/$ sudo stop network-manager
network-manager stop/waiting
ubuntu@trusty-dev:/$ ps -A | grep Manager
 3215 ? 00:00:00 ModemManager
ubuntu@trusty-dev:/$ sudo killall ModemManager 
ubuntu@trusty-dev:/$ ps -A | grep Manager
ubuntu@trusty-dev:/$ 

 And we start screen serial console to communicate with modem on ttyUSB2 (primary port of the modem, as shown above).

ubuntu@trusty-dev:/$ screen /dev/ttyUSB2 115200

Now you get an empty console screen. If local echo is not set, then type ATZ for the modem blindly, and that will reset it.

Now type :

ATI
Manufacturer: Huawei Technologies Co., Ltd.
Model: MU609
Revision: 12.105.29.00.00
IMEI: 357784046035976
+GCAP: +CGSM,+DS,+ES
OK

This tells us that the modem is present and working. Now type the following command, to check if your GSM antenna is set properly:

AT+CSQ
+CSQ: 29,99
OK

This is the GSM signal quality in +CSQ: RSSI, BER format, where

RSSI = Received Signal Strength Indication, and

BER = Bit Error Rate, currently unsupported, always 99

The RSSI = 99 (+CSQ: 99,99) means an unknown or undetectable signal level.

Here is a table to calculate the signal levels from RSSI :

Move/rotate your antenna and repeat the command above until you find the antenna’s optimal position. In general, values below 10 will not work, values between 10 and 15 will have many disconnections, values between 15 and 20 are weak, but could work, values between 20 and 25 are good, and values above 25 are excellent. For LTE 100Mbps connections (Huawei ME906, ME909 modem) you’ll need excellent signal quality, RSSI > 25 for reliable service.

Checking the subscriber information 

You should check your SIM card, since it provides a lot of information:

AT+CIMI
3100262475092493
OK

This command will query your SIM card’s IMSI number ( International Mobile Subscriber Identity )

The first 3 digits of IMSI number is MCC ( Mobile Country Code )

The following 2 (Europe) or 3 (North America) digits of the IMSI is the MNC ( Mobile Network Code )

The remaining digits is the MIN ( Mobile Identification Number )

You can check your MCC/MNC code in the following page :

Mobile Country Codes

For example if your MCC is 310 and your MNC is 026 then you are a T-Mobile subscriber in USA .

Why is this important ? Because on this page :

Mobile Broadband Service Providers

You can find your APN number based on you MCC and MNC number, and that is necessary, when you want to create a connection setup,  to dial up your service provider. Of course you may ask your service provider about these datas.

If you get an error :

AT+CIMI
+CME ERROR: Sim failure

Then your SIM card is not inserted properly, or it is locked by the CardLock feature, or its broken.

If the tests above pass, you can exit the screen console application ( <ctrl+A> Q, then Y ) .

Connecting to the internet

For doing that, you have to create a connection setup file as user “root” in the /etc/NetworkManager/system-connections directory, with the following content :

ubuntu@trusty-dev:/$ sudo cat /etc/NetworkManager/system-connections/MyModem
[connection]
id=MyMU609
uuid=15d742f1-2b5a-421e-9f27-fcb1fc26d72d
type=gsm
autoconnect=false

[ipv4]
method=auto

[gsm]
number=*99#
#username=blahblah
#password=blehbleh
apn=epc.tmobile.com
[serial]
baud=115200

The username and the password  are usually not necessary, or can be anything. The uuid is a unique identifier you can create with the uuid command (which installed earlier) :

ubuntu@trusty-dev:~$ uuid
15d742f1-2b5a-421e-9f27-fcb1fc26d72d
ubuntu@trusty-dev:~$

The id can be anything that you can memorize easily (“MyMU609″ is not mandatory). The same goes to for the file name “MyModem”. It can be anything. You have to get the apn from your service provider, or from HERE , as described above, earlier.

This is a minimal connection setup file. For detailed instructions, type :

ubuntu@trusty-dev:/$ man nm-settings

When finished, set the connection setup file’s attribute to 0600 :

ubuntu@trusty-dev:/$ sudo chmod 600 /etc/NetworkManager/system-connections/MyModem

And make sure that the file’s owner:group is root. If the owner is not root, then the Network Manager will ignore the connection setup.

ubuntu@trusty-dev:/$ sudo chown root:root /etc/NetworkManager/system-connections/MyModem

Now reboot, and wait for modemmanager to recognize the modem.

Then enable modem :

ubuntu@trusty-dev:/$ sudo mmcli -m 0 -e
successfully enabled the modem
ubuntu@trusty-dev:/$

And check the connections :

ubuntu@trusty-dev:~$ sudo nmcli con list
NAME                   UUID                                  TYPE             TIMESTAMP-REAL 
Wired connection 1     a66c3504-504a-4da8-8c1d-de9a80097367  802-3-ethernet   Wed Jan 21 12:49:14 2015 
MyMU609                15d742f1-2b5a-421e-9f27-fcb1fc26d72d  gsm              Wed Jan 21 12:58:39 2015 

Then you can dial (connect) to any of them :

ubuntu@trusty-dev:/$ sudo nmcli con up id MyMU609
ubuntu@trusty-dev:/$

You can see the status of the active connections like this :

ubuntu@trusty-dev:/$ sudo nmcli con status
NAME                   UUID                                   DEVICES  DEFAULT VPN  MASTER-PATH 
Wired connection 1     a66c3504-504a-4da8-8c1d-de9a80097367   eth1     no      no   -- 
MyMU609                15d742f1-2b5a-421e-9f27-fcb1fc26d72d   ttyUSB2  yes     no   -- 

You can use the internet now, download, upload, browse, launch wget, as you like it. When finished, you can disconnect with the following command. You don’t need to be in a hurry, service providers usually bill for data traffic and not connection time.

ubuntu@trusty-dev:/$ sudo nmcli con down id MyMU609
ubuntu@trusty-dev:/$

Pay close attention to the commands above, since we show both mmcli (modem manager) and nmcli (network manager).

Using modem on Ubuntu LXDE desktop

LXDE makes things much simpler.

As above, make sure modemmanager 1.4.0 is installed. It should recognize the modem as described earlier:

ubuntu@nitrogen:/$ mmcli -L
Found 1 modems:
 /org/freedesktop/ModemManager1/Modem/0 [Huawei Technologies Co., Ltd.] MU609
ubuntu@nitrogen:/$ 

Fine.

Now start the Network Manager via the menu:

Main-Menu -> Preferences -> Network Connections

A window pops up. Push [+Add] button. Choose Mobile Broadband as connection type, then push [Create…] . Select Huawei Technologies HUAWEI Mobile as your cellular device, and push [Continue] : 

Adding Huawei Mobile broadband device

Now select your country, your service provider, your billing plan, and confirm with the [Apply] button and [Save…].

It’s that simple. You can close the Network Connections window.

Now you can click on your network icon in the task bar with right mouse button. Select Enable Mobile Broadband . A window will pop up with a message that you were registered on your network. That is not yet a connection. Now click on the network icon with left mouse button and select your Mobile Broadband connection. The name depends on your provider. It will connect to your GSM network and you can unplug your ethernet cable if you want.

Of course you can use the same terminal commands on LXDE as you used in headless linux. As you like it.

As always please tell us how this works for you. Contact us if you have any trouble or ask a question by posting a reply below.

The post Cellular modems on i.MX6 boards under Ubuntu appeared first on Boundary Devices.

Timesys has expanded its LinuxLink offering for the popular Freescale i.MX6 Series processor to include support for the Boundary Devices Nitrogen6_MAX. This offering expands the already supported Boundary Devices boards which include the Nitrogen6X, Nitrogen6_Lite, and BD-SL-i.MX6.

Featuring a Quad-Core i.MX6 ARM Cortex A9 processor, the Nitrogen6_MAX single board computer features high-end performance, making it ideal for consumer, automotive and industrial multimedia applications.

With support for Linux kernel version 3.10 , the following are enabled:

o Audio
o Bluetooth
o CSI Camera
o Ethernet
o GPU Vivante
o I2C
o IPU
o LCD Connector
o MIPI Camera
o PWM Backlight
o RS485
o RTC
o SATA
o SD/MMC
o USB Host
o USB OTG
o Uart Driver
o VPU
o Watchdog Timer
o Weston/Wayland
o Wireless Networking
o eMMC
o HDMI
o mPCIe

 LinuxLink for Nitrogen6_MAX enables developers to leverage the high-performance multimedia processing power of the i.MX 6 series processor. LinuxLink users can customize their feature-rich application by choosing from the hundreds of packages/middleware offered through the award-winning LinuxLink Factory cloud-based and desktop-hosted build tools which facilitate the process of building and integrating a custom Linux platform. Using the LinuxLink web UI, developers can quickly and easily build a custom BSP and matching SDK for their Nitrogen6_MAX platform.

For developers/teams requiring access to expert engineering support, Timesys offers project-based support. Engaging with Timesys for support gives you access to help at any phase of your product development, whether you’re using the Timesys Factory (http://www.timesys.com/embedded-l=inux/platform-builder) or Yocto Project build system. In addition, developers engaging with Timesys for project-based support get access to LinuxLink desktop tools which enable maximum flexibility and customization of the platform and application.

- Learn more about LinuxLink for Nitrogen6_MAX and other Boundary Devices i.MX 6 processor based platforms at http://www.timesys.com/embedded-linux/resources/dev-center/imx6#nitrogen6ma=x.

- Build a custom BSP / SDK for your Freescale i.MX 6 processor-based Boundary Devices platform at https://linuxlink.timesys.com/build * NOTE: Existing users, please visit https://linuxlink.timesys.com/register=/factory to add the Boundary Devices Nitrogen6_MAX platform to your account.

The post Timesys Expands i.MX6 board support to include Nitrogen6_MAX appeared first on Boundary Devices.

Our i.MX6 Nitrogen6x and especially Nitrogen6_Max boards have great connectivity options and can be useful in server applications as well as the more typical client uses. In this post, we’ll describe how to use the built-in WiFi adapter to create a WiFi hotspot and router under Ubuntu.

The process involves configuration of three primary components:

1. hostapd to provide access point software,
2. dnsmasq to supply IP addresses to clients through DHCP, and
3. iptables to provide routing and NAT support

For the impatient

If you just want to boot up with this functionality, we’ve uploaded an image that will run on either our Nitrogen6x or Nitrogen6_Max board and provide AP support as described below.

The image contains Freescale-licensed content, so you will need to register on our web-site and log in before you can accept the license agreement and download the image from here:

• 20150211-hotspot-3.10.17_1.0.2_ga-trusty-en_US-console_armhf.img.gz

The detailed description of our changes is here:

• 20150211-hotspot-3.10.17_1.0.2_ga-trusty-en_US-console_armhf.description

Programming the image

The images are slightly-less-than-4GiB image files containing the partition table, so you can copy it to an SD card or SATA drive on /dev/sdc using zcat and dd like so:

~/Downloads$ sudo umount /dev/sdc*
~/Downloads$ zcat 201501*.img.gz | sudo dd of=/dev/sdc bs=1M
~/Downloads$ sync

Or you can use Alex Page’s USB Image Tool under Windows.

If you’re using our latest U-Boot and a Nitrogen6 Max board, you can use the new USB Mass Storage Gadget to program the eMMC. If not, there were some notes in our first release that describe a more complicated way of programming eMMC. 

Configuring this in your own image

The image above contains things pre-configured for immediate use. The steps below describe how you can add this functionality into your own image.

Make sure you have installed the latest kernel, but at least ABI >=36 :

ubuntu@trusty-dev:/$ uname -r
3.10.17-36-boundary-4t3
ubuntu@trusty-dev:/$

If this is not the case, please type :

ubuntu@trusty-dev:/$ sudo apt-get update && sudo apt-get dist-upgrade
ubuntu@trusty-dev:~$ sync
ubuntu@trusty-dev:~$ sudo reboot

 Now you need to install the packages listed above:

ubuntu@trusty-dev:/$ sudo apt-get install hostapd dnsmasq iptables

The package hostapd is a user space daemon for access point and authentication servers. It implements IEEE 802.11 access point management, and IEEE 802.1X/WPA/WPA2/EAP Authenticators . The package dnsmasq is a small DHCP server and DNS forwarder, exactly what we need.  The package iptables is a user-space application program that allows a system administrator to configure the tables provided by the Linux kernel firewall (implemented as different netfilter modules) and the chains and rules it stores. The necessary netfilter modules were added to our kernel in this patch.

Configuring hostapd

 Let us start with the hostapd configuration file. Create a hostapd.conf file with the following contents :

ubuntu@trusty-dev:/$ sudo cat /etc/hostapd/hostapd.conf
interface=wlan0
driver=nl80211
ssid=BoundaryDevices
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=3
wpa_passphrase=Boundary
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
ubuntu@trusty-dev:/$

Of course ssid (the name of the wifi network appears for the wifi devices scanning for available networks) and the password (wpa_passphrase) can be anything what you prefer, its your choice. The password must be at least 8 characters long.

Make sure you have set the defaults of hostapd :

ubuntu@trusty-dev:~$ cat /etc/default/hostapd | grep DAEMON_CONF
# Uncomment and set DAEMON_CONF to the absolute path of a hostapd configuration
DAEMON_CONF="/etc/hostapd/hostapd.conf"
ubuntu@trusty-dev:~$ 

Now you need to edit the interfaces file and you need to add wlan0 (thats the onboard WiFi) interface :

ubuntu@trusty-dev:~$ sudo cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
#auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

auto lo
iface lo inet loopback

auto wlan0
iface wlan0 inet static
hostapd /etc/hostapd/hostapd.conf
address 192.168.10.1
netmask 255.255.255.0

This sets the WiFi hotspot IP address to 192.168.10.1. You may want to use something else to match your local network.

Configuring dnsmasq

Now you need to add the following lines to /etc/dnsmasq.conf file to provide DHCP services to WiFi clients:

ubuntu@trusty-dev:~$ sudo cat /etc/dnsmasq.conf | tail -n3
interface=lo,wlan0
no-dhcp-interface=lo
dhcp-range=192.168.10.10,192.168.10.254,255.255.255.0,12h
ubuntu@trusty-dev:~$

This provides a 192.168.10.10 … 192.168.10.254 DHCP IP pool for the WiFi clients.

IP forwarding

Now you need to edit the file /etc/sysctl.conf . Make sure this line is added to the end :

ubuntu@trusty-dev:~$ sudo cat /etc/sysctl.conf | tail -n1
net.ipv4.ip_forward=1
ubuntu@trusty-dev:~$

Configuring IP tables

Now you need to activate NAT in the built-in firewall of linux, you have to edit the file /etc/rc.local:

ubuntu@trusty-dev:~$ sudo cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

iptables -t nat -A POSTROUTING -s 192.168.10.0/24 ! -d 192.168.10.0/24 -j MASQUERADE

exit 0
ubuntu@trusty-dev:~$

Thats it! Now you have to to reboot the system.

Configure cellular networking

If you want to use a cell modem as your up-stream Internet connection as described in our earlier post, you may need to disable ethernet.

root@trusty-dev:~# nmcli con status
NAME UUID DEVICES DEFAULT VPN MASTER-PATH
Wired connection 1 93b31726-2a2b-4559-a637-bef1ca0d2371 eth1 no no --

root@trusty-dev:~# ifdown eth0
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/00:19:b8:01:5d:f9
Sending on LPF/eth0/00:19:b8:01:5d:f9
Sending on Socket/fallback
DHCPRELEASE on eth0 to 192.168.0.1 port 67 (xid=0x51d23a2c)
root@trusty-dev:~# nmcli con status
NAME UUID DEVICES DEFAULT VPN MASTER-PATH
root@trusty-dev:~#

Now we connect with the MU609 modem as usual, as described in the cell post:

root@trusty-dev:~# nmcli con up id MyMU609
root@trusty-dev:~#

Now login from your smartphone/tablet android device to this Wifi nitrogen-hotspot, (by selecting BoundaryDevices network to connect to, and give Boundary as password) and do your internet business.

Disconnecting GSM internet is the usual, as described in the cell post :

root@trusty-dev:~# nmcli con down id MyMU609
root@trusty-dev:~#

This is how the Nitrogen6x or Nitrogen6_Max board can be turned into a WiFi-hotspot and internet gateway to share internet with the WiFi devices around it:

Figure 1: Creating Wifi Hotspot using i.MX6 boards

As always please tell us how this works for you. Contact us if you have any trouble or ask a question by posting a reply below.

The post Wifi Hotspot on i.MX6 boards (through cellular or ethernet) appeared first on Boundary Devices.