== Introduction and Preparations ==
This article provides a usage guide for the various FreeRTOS demo images that come with the CL-SOM-iMX7 BSP.<br>
To run a demo:
* Open a [[#Serial connections|serial connection]] to the A7 core.
* Open a [[#Serial connections|serial connection]] to the M4 core.
* Obtain an [[#SD-card media|SD-card]] formatted with a FAT or EXT filesystem.
* (optional) Install the [[#Linux installation|Linux BSP]].

=== Serial connections ===
The FreeRTOS demos for CL-SOM-iMX7 were setup so that the M4 serial connection is set to the P4-31 (RX) and P4-33 (TX) pins on the SB-SOM baseboard, using UART2.
The A7 core serial port is using UART1, and is located on the P8 connector of the SB-SOM baseboard.
For more information about the A7 serial port, please see the [[SB-SOM: HOWTO: RS-232 Console|SB-SOM RS-232 Console]] article.

To communicate with both the M4 and A7 cores using the serial interface, start a terminal emulation program (such as HyperTerminal) for each serial port, with the following port settings:
<blockquote>
{{:SB-SOM: serial port parameters table}}
</blockquote>

=== SD-card media ===
In this article, all the demos are loaded using U-Boot from a filesystem formatted SD-card.
The SD card must be FAT or EXT filesystems formatted.
For other methods of loading the demo images, see the [[#See also|See also section]].

=== Linux installation ===
Some of the demos require a Linux installation.
In order to boot Linux alongside FreeRTOS, a special device tree blob must be used to prevent Linux and FreeRTOS from interfering with one another.
* Follow the automatic installation procedure in the [[#See also|see also]] section.
* Copy the precompiled {{filename|imx7d-sbc-imx7-m4.dtb}} device tree blob to the SD-card (or use your own modified dtb).
* Run the following commands to make sure that U-Boot {{cmd|boot}} command will load the special device tree blob:
<pre>
CL-SOM-iMX7 # setenv fdtaddr 0x83000000
CL-SOM-iMX7 # setenv fdtfile imx7d-sbc-imx7-m4.dtb
CL-SOM-iMX7 # setenv loadfdt 'mmc rescan; load mmc 0 ${fdtaddr} ${fdtfile}'
CL-SOM-iMX7 # saveenv
</pre>

== Demos usage examples ==
=== Blinking LED with GPT demo ===
The blinking GPT demo utilizes GPT to blink the CL-SOM-iMX7 LED at variable intervals.
The length of the interval can be changed by sending anykey presses into the M4 console.
==== Example run ====
Running the demo via U-Boot:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 blinking_imx_demo_gpt.bin && dcache flush; bootaux 7F8000
</pre>

M4 serial output (key presses not echoed back):
<pre>
================= Blinking Demo ==================

====== Blinking interval 100ms ======

====== Press any key to change blinking interval ======

Wait 5 seconds to switch blinking frequency:

====== Blinking interval 200ms ======

====== Press any key to change blinking interval ======

Wait 5 seconds to switch blinking frequency:

====== Blinking interval 300ms ======

====== Press any key to change blinking interval ======

Wait 5 seconds to switch blinking frequency:

====== Blinking interval 400ms ======

====== Press any key to change blinking interval ======

Wait 5 seconds to switch blinking frequency:

====== Blinking interval 500ms ======

====== Press any key to change blinking interval ======

Wait 5 seconds to switch blinking frequency:
</pre>

=== Hello World demo ===
The various hello world demos simply output "Hello World!" on the M4 console, and echo any keypresses made by the user.

==== Example run ====
Running the demo via U-Boot:
* To run the hello_world application in TCM memory:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 hello_world.bin && dcache flush; bootaux 7F8000</pre></blockquote>
* To run the hello_world application in DDR memory:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 9FF00000 hello_world_ddr.bin && dcache flush; bootaux 9FF00000</pre></blockquote>
* To run the hello_world application in OCRAM memory:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 910000 hello_world_ocram.bin && dcache flush; bootaux 910000</pre></blockquote>

The M4 serial output:
<pre>
Hello World!

These words were typed by the user and echoed back!
</pre>

=== Rand WFI demo ===
In this demo a GPT will change the M4 Power Mode with random period.
The power mode changes do not happen until Linux boot is initiated.

==== Example run ====
Run the demo via U-Boot, and then boot linux:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 rand_wfi_imx7d.bin && dcache flush; bootaux 7F8000
...
CL-SOM-iMX7 # boot
</pre>

M4 serial output:
<pre>
************************************************************************
* i.MX 7Dual Dual Core Low Power Demo - M4 side *
* *
* A GPT will change the M4 Power Mode with random period *
* *
************************************************************************

Low Power Demo
********************************
Please wait :
1) A7 peer is ready
Then press "S" to start the demo
********************************

Press "S" to start the demo : s
GPT will triggle interrupt in 18s
go to mode WAIT
GPT Event! Total time 18s
GPT will triggle interrupt in 18s
go to mode STOP
GPT Event! Total time 36s
GPT will triggle interrupt in 17s
go to mode RUN
GPT Event! Total time 53s
GPT will triggle interrupt in 19s
go to mode WAIT
GPT Event! Total time 72s
GPT will triggle interrupt in 15s
go to mode STOP
GPT Event! Total time 87s
GPT will triggle interrupt in 18s
go to mode RUN
GPT Event! Total time 105s
GPT will triggle interrupt in 17s
go to mode WAIT
GPT Event! Total time 122s
GPT will triggle interrupt in 16s
go to mode STOP
GPT Event! Total time 138s
GPT will triggle interrupt in 16s
go to mode RUN
</pre>

=== SEMA4 demo ===
This demo demonstrates locking and unlocking of the SEMA4 lock.
The user can initiate locking manually or set M4 to lock the SEMA4 every 5 seconds.

==== Example run ====
Running the demo via U-Boot:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 sema4_demo.bin && dcache flush; bootaux 7F8000
</pre>

M4 serial output:
<pre>
================== SEMA4 demo ==================
Enter command:
----- 'm' to manually trigger a SEMA4 lock
----- 'a' to automatically trigger SEMA4 lock every 5 seconds
m
...SEMA4 mutex lock successfully!
Enter command:
----- 'm' to manually trigger a SEMA4 lock
----- 'a' to automatically trigger SEMA4 lock every 5 seconds
m
...SEMA4 mutex lock successfully!
Enter command:
----- 'm' to manually trigger a SEMA4 lock
----- 'a' to automatically trigger SEMA4 lock every 5 seconds
a
...SEMA4 mutex lock successfully!
Wait for 5 seconds......

...SEMA4 mutex lock successfully!
Wait for 5 seconds......

...SEMA4 mutex lock successfully!
Wait for 5 seconds......
</pre>

=== RPMSG ping-pong demo ===
This demo demonstrates synchronization between the A7 and M4 cores by printing a series of messages, with an incrementing index, such that even messages are printed on one core, and odd messages on another core.
This demo requires booting into Linux and loading a special driver. It is available in two configurations: the "bare metal" (bm) configuration, which implements the demo functionality without FreeRTOS kernel code, and the freertos version, which does use freertos kernel code.

==== Example run ====
Run the demo via U-Boot:
* To run the bare metal version:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 rpmsg_pingpong_bm_example.bin && dcache flush; bootaux 7F8000</pre></blockquote>
* To run the freertos kernel version:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 rpmsg_pingpong_freertos_example.bin && dcache flush; bootaux 7F8000</pre></blockquote>

...and then boot into Linux:
<pre>
CL-SOM-iMX7 # boot
</pre>

While Linux boots, the below messages can be seen on the M4 core terminal:
<pre>
RPMSG PingPong Bare Metal Demo...
RPMSG Init as Remote
</pre>

After Linux finished booting, run the ping pong rpmsg driver.
<pre>
root@cl-debian:~# modprobe imx_rpmsg_pingpong
</pre>

With both A7 and M4 terminals side by side, the following output can be observed (A7 to the left, M4 to the right):
<pre>
Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024]
get 1 (src: 0x0) Get Data From Master Side : 0
get 3 (src: 0x0) Get Data From Master Side : 2
get 5 (src: 0x0) Get Data From Master Side : 4
get 7 (src: 0x0) Get Data From Master Side : 6
get 9 (src: 0x0) Get Data From Master Side : 8
get 11 (src: 0x0) Get Data From Master Side : 10
... ...
</pre>

=== Serial communication demo ===
This demo sets up a communication channel between the A7 and M4 cores, allowing the user to type characters from the A7 core, and make them appear on M4 core.
This demo requires booting into Linux and loading a special driver, and configure the serial tty connection between the cores.
It is available in two configurations: the "bare metal" (bm) configuration, which implements the demo functionality without FreeRTOS kernel code, and the freertos version, which does use freertos kernel code.

==== Example run ====
Run the demo via U-Boot:
* To run the bare metal version:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 rpmsg_str_echo_bm_example.bin && dcache flush; bootaux 7F8000</pre></blockquote>
* To run the freertos kernel version:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 rpmsg_str_echo_freertos_example.bin && dcache flush; bootaux 7F8000</pre></blockquote>

...and then boot into Linux:
<pre>
CL-SOM-iMX7 # boot
</pre>

While Linux boots, the following will appear on the M4 core terminal:
<pre>
RPMSG String Echo Bare Metal Demo...
RPMSG Init as Remote
</pre>

After booting into Linux, load the imx_rpmsg_tty driver:
<pre>
root@cl-debian:~# modprobe imx_rpmsg_tty
imx_rpmsg_tty rpmsg0: new channel: 0x400 -> 0x0!
Install rpmsg tty driver!
</pre>

On M4 serial terminal the following output is observed:
<pre>
Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024]
</pre>

A {{filename|/dev/ttyRPMSG}} device file will appear in Linux.
Configure it for serial communication using {{cmd|stty}}:
<pre>
root@cl-debian:/# stty -F /dev/ttyRPMSG
</pre>

Send a message from Linux to M4 core:
<pre>
root@cl-debian:/# echo hello > /dev/ttyRPMSG
</pre>

On M4 serial terminal the following output is observed:
<pre>
Get Message From Master Side : "hello" [len : 5]
Get New Line From Master Side
</pre>

=== ADC driver demo ===
The demo demonstrates the usage of the ADC driver.

==== Example run ====
Run the demo via U-Boot:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 adc_imx7d_example.bin && dcache flush; bootaux 7F8000
</pre>

M4 serial output:
<pre>
-------------- ADC imx7d driver example --------------

This example demonstrates usage of ADC driver on i.MX processor.
It Continuous convert Analog Input, and print the result to terminal
Current analog value: 1.33v
Current analog value: 1.32v
Current analog value: 1.31v
Current analog value: 1.29v
Current analog value: 1.31v
Current analog value: 1.31v
Current analog value: 1.32v
Current analog value: 1.31v
Current analog value: 1.32v
Current analog value: 1.30v
Current analog value: 1.32v
Current analog value: 1.32v
Current analog value: 1.30v
Current analog value: 1.31v
Current analog value: 1.31v
Current analog value: 1.31v
Current analog value: 1.30v
</pre>

=== Flexcan loopback demo ===
This demo demonstrates the usage of the Flexcan driver, when the CAN bus is set to loopback mode.

==== Example run ====
Run the demo via U-Boot:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 flexcan_loopback_example.bin && dcache flush; bootaux 7F8000
</pre>

M4 serial output:
<pre>
********* FLEXCAN LOOPBACK TEST *********
Message format: Standard (11 bit id)
Message buffer 9 used for Rx.
Message buffer 13 used for Tx.
Interrupt Mode: Enabled
Operating Mode: TX and RX --> LoopBack
*****************************************

DLC=1, mb_idx=0x123
RX MB data: 0x0

DLC=1, mb_idx=0x123
RX MB data: 0x1

DLC=1, mb_idx=0x123
RX MB data: 0x2

DLC=1, mb_idx=0x123
RX MB data: 0x3

DLC=1, mb_idx=0x123
RX MB data: 0x4

DLC=1, mb_idx=0x123
RX MB data: 0x5

DLC=1, mb_idx=0x123
RX MB data: 0x6

DLC=1, mb_idx=0x123
RX MB data: 0x7

DLC=1, mb_idx=0x123
RX MB data: 0x8

DLC=1, mb_idx=0x123
RX MB data: 0x9

DLC=1, mb_idx=0x123
RX MB data: 0xa
</pre>

=== Flexcan network demo ===
This demo demonstrates the usage of the Flexcan driver. It is designed to be paired with another M4 core, running a modified version of this demo.

==== Preparation ====
* Prepare 2 versions of the flexcan_network_example demo image, one configured for NODE1, and another configured for NODE2:
** The precompiled image in the CL-SOM-iMX7 BSP is compiled for NODE 1. No need to do anything further.
** Set the Node configuration in main.c to NODE 2 (#define NODE 2).
** Build project with the modified NODE configuration. See [[CL-SOM-iMX7: FreeRTOS: Introduction to NXP FreeRTOS development | FreeRTOS: Introduction to NXP FreeRTOS development]] for more information.
* Obtain another CL-SOM-iMX7 eval board and connect the two boards to the CAN Bus.

==== Example run ====
Run the demo via U-Boot on both devices:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 flexcan_network_example.bin && dcache flush; bootaux 7F8000
</pre>

After boot succeeds, the serial output of M4 will display the following:
<pre>
********* FLEXCAN NETWORK TEST *********
Message format: Standard (11 bit id)
Message buffer 9 used for Rx.
Message buffer 8 used for Tx.
Interrupt Mode: Enabled
Operating Mode: TX and RX --> Normal
****************************************

NODE is 1
</pre>

After both modules loaded and booted the demo image, CAN bus communication between the boards will commence.
<pre>
DLC=1, mb_idx=0x123
RX MB data: 0x0
DLC=1, mb_idx=0x123
RX MB data: 0x1
DLC=1, mb_idx=0x123
RX MB data: 0x2
DLC=1, mb_idx=0x123
RX MB data: 0x3
DLC=1, mb_idx=0x123
RX MB data: 0x4
DLC=1, mb_idx=0x123
RX MB data: 0x5
</pre>

=== GPIO driver demo ===
This demo demonstrates the usage of the GPIO driver. It is setup to toggle a GPIO on and off using key presses into the M4 serial connection. On CL-SOM-iMX7 the GPIO controls the CL-SOM-iMX7 LED.

==== Example run ====
Run the demo via U-Boot:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 flexcan_network_example.bin && dcache flush; bootaux 7F8000
</pre>

M4 serial output (key presses are not echoed back):
<pre>
====================== GPIO Example ========================

============ Use key to simulate GPIO button ==============
Input any data from terminal 3 times to continues.

Button pressed 1 time.
Button pressed 2 time.
Button pressed 3 time.

================= GPIO Functionality==================
The button state is now polled.
Press the button to switch LED on or off
</pre>

At this point sending keypresses into the M4 terminal toggles the CL-SOM-iMX7 LED on and off.

=== GPT driver demo ===
This demo demonstrates the usage of the GPT driver.

==== Example run ====
Run the demo via U-Boot:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 gpt_example.bin && dcache flush; bootaux 7F8000
</pre>

M4 serial output:
<pre>
GPT timer will now start
counter/freq ratio should be close to 0.0 or 1.0 ...
GPT A freq 6000000, counter 6.
GPT B freq 49090907, counter 18.
GPT A freq 6000000, counter 2.
GPT B freq 49090907, counter 52.
GPT A freq 6000000, counter 1.
GPT B freq 49090907, counter 52.
GPT A freq 6000000, counter 0.
GPT B freq 49090907, counter 53.
GPT A freq 6000000, counter 6000000.
GPT B freq 49090907, counter 53.
GPT example finished...
</pre>

=== UART driver demo ===
This demo demonstrates the usage of the UART driver in both interrupt and polling modes of operation.

==== Example run ====
Run the demo via U-Boot:
* To run the interrupt driven version:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 uart_imx_interrupt_example.bin && dcache flush; bootaux 7F8000</pre></blockquote>
* To run the polling version:
<blockquote><pre>CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 uart_imx_polling_example.bin && dcache flush; bootaux 7F8000</pre></blockquote>

M4 serial output for interrupt driven example:
<pre>
++++++++++++++++ UART Send/Receive Interrupt Driven Example +++++++++++++++++

Type characters from keyboard, the board will receive and then echo them to terminal screen
This was typed by the user!
</pre>

M4 serial output for polling driven example:

<pre>
++++++++++++++++ UART Send/Receive Polling Example +++++++++++++++++

Type characters from keyboard, the board will receive and then echo them to terminal screen
This was typed by the user!
</pre>

=== Watchdog driver demo ===
This demo demonstrates the usage of the Watchdog driver.

==== Example run ====
Run the demo via U-Boot:
<pre>
CL-SOM-iMX7 # mmc rescan && load mmc 0 7F8000 wdog_imx_example.bin && dcache flush; bootaux 7F8000
</pre>

M4 serial output:
<pre>
WDOG with timeout 1.5 seconds will now start
WDOG was refreshed 4
WDOG was refreshed 3
WDOG was refreshed 2
WDOG was refreshed 1
WDOG was refreshed 0
Counter down to 0, WDOG is starved now...
WDOG with timeout 1.5 seconds will now start
WDOG was refreshed 4
WDOG was refreshed 3
WDOG was refreshed 2
WDOG was refreshed 1
WDOG was refreshed 0
Counter down to 0, WDOG is starved now...
</pre>

Transclusion: CL-SOM-iMX7: FreeRTOS: Running Demos

2017-10-23T10:09:36Z

Nikita: /* Introduction */

== Introduction ==
This article describes the process of loading FreeRTOS images into memory, and running the in-memory images. For quick evaluation, the FreeRTOS BSP comes with precompiled images that can be found under the {{filename|images}} folder.

== Loading FreeRTOS into memory ==
A FreeRTOS image must be run from TCM, DDR, or OCRAM, depending on how it was built. Consult the following table for the right <'''load_addr'''> to use:
{| cellpadding="3" border="1" style="border: 1px solid rgb(85, 85, 85); border-collapse: collapse;"
|-
! Image name
! Must run from
! load_addr
|-
| <image_name>.bin
| TCM
| 7F8000
|-
| <image_name>_ocram.bin
| OCRAM
| 910000
|-
| <image_name>_ddr.bin
| DDR
| 9FF00000
|}

* Power on the module and stop U-Boot from booting Linux by holding Ctrl-c.
* Place the demo image into USB drive or SD-card, and connect it into the evaluation board.
* Use the following U-Boot commands to load the demo image from USB storage:
<pre>
CL-SOM-iMX7 # usb start
CL-SOM-iMX7 # load usb 0 <load_addr> <image_name>
</pre>
* Use the following U-Boot commands to load the demo image from SD-card:
<pre>
CL-SOM-iMX7 # mmc dev 0
CL-SOM-iMX7 # mmc rescan
CL-SOM-iMX7 # load mmc 0 <load_addr> <image_name>
</pre>

== Booting FreeRTOS from memory ==
* Run the image using the following commands:
<pre>
CL-SOM-iMX7 # dcache flush
CL-SOM-iMX7 # bootaux <load_addr>
</pre>

Nikita: New page: FreeRTOS related pages

FreeRTOS related pages

CL-SOM-iMX7: FreeRTOS: Known Issues

2017-07-11T15:29:16Z

Nikita: New page: {{IssueCategory|Booting multiple images| * Booting more than one FreeRTOS image in the same power-on session will likely not work, with only the first boot being successful. Occasionally, ...

CM-T43: Linux: Debian

2016-06-29T12:33:44Z

Nikita: /* Overview */

== Overview ==
The example run-time Linux filesystem image for the CompuLab CM-T43 System-on-Module / Computer-on-Module is based on Debian GNU/Linux Jessie.
The CompuLab Linux package for CM-T43 includes ready to run Linux kernel binary, root filesystem demo image archive, Linux kernel configuration and source code patches.

The default Debian Jessie Linux image includes more than 400 software packages. Among them:

* Core system
* Debian package management system
* X11 Windowing System
* Fluxbox desktop manager
* Netsurf browser
* Samba connectivity suite
* SSH server and client
* ALSA configuration and usage utilities
* Bluetooth 5.0 tools and daemons

The [[CM-T43: Linux: Manual Installation]] page provides a brief introduction on how to install the run-time Linux image.

== Using Debian Linux on CM-T43 ==

=== Connection and Logging In ===
Use the following username and password to login:

Account with administrative privileges:
<pre>
cm-debian login: root
Password: 111111
</pre>

Regular user account:
<pre>
cm-debian login: user
Password: 111111
</pre>

To login into the Linux system, you may use a serial console (ttyO0) at 115200 bps, or connect through the network.

=== Networking ===
CM-T43 can operate in two modes: dual MAC mode, or as a 3 port ethernet switch. The default mode of operation is dual MAC mode.
A user guide for both operation modes can be found in the [http://processors.wiki.ti.com/index.php/Linux_Core_CPSW_User%27s_Guide Linux Core CPSW User's Guide] article in the TI wiki.
To configure networking, edit {{filename|/etc/network/interfaces}}, {{filename|/etc/resolv.conf}}, {{filename|/etc/hostname}} and {{filename|/etc/hosts}}. For more information about Debian Linux network configuration read [http://www.debian.org/doc/manuals/reference/ch05.en.html Network setup] chapter in the [http://www.debian.org/doc/manuals/reference/index.en.html Debian Reference].

==== Switching to 3-port switch mode ====
To enable 3-port switch mode, the device tree blob must be modified to remove the dual_emac property before Linux boots. This can be done using the following U-Boot commands:
<pre>
# fdt addr <address fdt was loaded to>
# fdt rm /ocp/ethernet@4a100000 dual_emac
</pre>

=== X Windows system ===
CompuLab Debian Jessie Linux demo image contains full featured X Windows system with Fluxbox window manager.
Before starting X Windows, connect USB mouse and keyboard to the system.
You can run X Windows by typing {{cmd|startx}}.

=== Fluxbox window manager ===

CM-T43 Debian Linux features installed Fluxbox package - a lightweight window manager for the X Windowing System.

* Fluxbox provides configurable window decorations, a root menu to launch applications and a toolbar that shows the current workspace name, a set of application names and the current time. There is also a workspace menu which allows you to add or remove workspaces. The {{parameter|slit}} can be used to dock small applications, e.g. most of the bbtools can use slit.
* Fluxbox can iconify windows to the toolbar, in addition to adding the window to the Icons submenu of the workspace menu.

Visit [http://fluxbox-wiki.org Fluxbox Wiki] and [http://fluxbox.org/ Official home page] for more details.

=== Software Management ===

Debian Linux image for CM-T43 includes all the information required to use Debian package management utilities. You can use [http://linux.die.net/man/8/apt-get apt-get] and [http://www.wlug.org.nz/dpkg(8) dpkg] out of the box.

=== MMC/SD ===
The support for MMC/SD card on CM-T43 is built into the Linux kernel.
To mount the memory card, monitor ''/proc/partitions'' to see what partitions were detected on the MMC/SD card. For example, suppose MMC/SD partition you'd like to mount is ''mmcblk0p1'' then:
<pre>
mkdir -p /mnt/mmcblk0p1 && mount /dev/mmcblk0p1 /mnt/mmcblk0p1
</pre>

=== Display options ===
CM-T43 evaluation platform has three video output interfaces: LCD, DVI, and LVDS. Default configuration of Debian Linux for CM-T43 uses LCD as primary video output.

=== USB Dual-Role-Device ===

CM-T43 has USB DWC3 based controller. It features USB 2.0 Dual-Role-Device (DRD) subsystem with integrated HS/FS (USB2.0) PHY.
CM-T43 DRD port is USB host and USB device (gadget) capable. USB Device Gadget drivers are compiled as modules with default CM-T43 kernel configuration.
Current Linux kernel support of DWC3 features does not allow dynamic role (host/device) switching during runtime. By default, ''host'' role is assigned to CM-T43 DRD port.

Device mode can be enabled by running the following U-Boot commands before boot:
<pre>
# fdt addr <address fdt was loaded to>
# fdt resize
# fdt set /ocp/omap_dwc3@48380000/usb@48390000 dr_mode peripheral
</pre>

==== Testing Device (gadget) mode ====

Default CM-T43 kernel configuration enables {{filename|g_serial}}, {{filename|g_mass_storage}}, {{filename|g_ether}}, {{filename|g_audio}}, and {{filename|g_hid}} gadget drivers.
More gadget drivers can be enabled in the kernel configuration.

* Connect USB OTG micro B-cable (ID pin Float) to P3 USB DRD port of SB-SOM baseboard.
* Connect other side Standard-A connector to Linux Host PC USB Host port.

===== Emulate a serial link =====

* Load gadget driver on CM-T43 Eval board:
<pre>
root@cm-debian:~# modprobe g_serial
[ 114.805045] g_serial gadget: Gadget Serial v2.4
[ 114.809968] g_serial gadget: g_serial ready
[ 115.306074] g_serial gadget: high-speed config #2: CDC ACM config
</pre>

* Ensure the connection is established on the Host PC:
<pre>
user@linux-host:~$ dmesg
...
[72415.607738] cdc_acm 2-1.8.2:2.0: ttyACM0: USB ACM device
[72415.608446] usbcore: registered new interface driver cdc_acm
[72415.608447] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
</pre>

* Receive data on CM-T43 Eval board:
<pre>
root@cm-debian:~# cat /dev/ttyGS0
</pre>

* Send data from Host PC:
<pre>
user@linux-host:~$ echo "Test message" > /dev/ttyACM0
</pre>

=== Bluetooth ===
==== Host Controller Interface (HCI) Initialization ====
* HCI requires no user interaction for being configured. The driver gets loaded automatically unless this option has been disabled by putting a black list rule for this device.<br>
Make sure that the Bluetooth driver is loaded:
<pre>
# lsmod | grep btmrvl
btmrvl_sdio 14294 0
btmrvl 9612 1 btmrvl_sdio
bluetooth 304454 22 bnep,btmrvl,btmrvl_sdio
</pre>

* HCI device configuration utility can be run to retrieve detailed information about the Bluetooth interfaces:
<pre>
# hciconfig -a
hci0: Type: BR/EDR Bus: SDIO
BD Address: 4C:AA:16:66:C4:E0 ACL MTU: 1021:7 SCO MTU: 120:6
UP RUNNING PSCAN
RX bytes:1136 acl:0 sco:0 events:40 errors:0
TX bytes:1546 acl:0 sco:0 commands:39 errors:0
Features: 0xff 0xee 0x8f 0xfe 0x9b 0xff 0x79 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV3
Link policy: RSWITCH HOLD SNIFF
Link mode: SLAVE ACCEPT
Name: 'cm-debian-0'
Class: 0x4a0100
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Uncategorized
HCI Version: 2.1 (0x4) Revision: 0x8300
LMP Version: 2.1 (0x5) Subversion: 0x810
Manufacturer: Marvell Technology Group Ltd. (72)
</pre>

* If the HCI device is not running, use the below command to enable the HCI device:
<pre>
# hciconfig hci0 up
</pre>

==== Bluez5 & PulseAudio ====
Debian jessie is using BlueZ 5 and PluseAudio 5, which are fairly new.<br>
BlueZ 5 dropped support for alsa, so the solution for now is to use PulseAudio.<br>
PulseAudio 5 only supports the A2DP profile and not HSP/HFP. <br>
* Software to install {{filename|'''pulseaudio'''}}, {{filename|'''pulseaudio-module-bluetooth'''}}
<pre>
# apt-get install --no-install-recommends pulseaudio pulseaudio-module-bluetooth
</pre>
* Create a systemd service for running pulseaudio as the pulse user.
<pre>
# cat << eof > /etc/systemd/system/pulseaudio.service
[Unit]
Description=Pulse Audio

[Service]
Type=simple
ExecStart=/usr/bin/pulseaudio --system --disallow-exit --disable-shm

[Install]
WantedBy=multi-user.target
eof

# chown pulse:pulse /etc/systemd/system/pulseaudio.service
</pre>

* Create a dbus configuration file for running pulseaudio. Give the pulse user permission to use Bluetooth.
<pre>
# cat << eof > /etc/dbus-1/system.d/pulseaudio-bluetooth.conf
<busconfig>

<policy user="pulse">
<allow send_destination="org.bluez"/>
</policy>

</busconfig>
eof
# chmod 0666 /etc/dbus-1/system.d/pulseaudio-bluetooth.conf
</pre>
* Paste the following lines to the end of /etc/pulse/system.pa:
<pre>
# cat << eof >> /etc/pulse/system.pa
### Automatically load driver modules for Bluetooth hardware
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif
eof
</pre>
* Create {{filename|/var/run/pulse/.config/pulse}} directory. Change its ownership.
<pre>
# mkdir -p /var/run/pulse/.config/pulse
# chown -R pulse:pulse /var/run/pulse
</pre>
* Make the root belong to the pulse-access,audio groups
<pre>
# usermod -a -G pulse-access,audio root
</pre>
* Start PulseAudio service
<pre>
# systemctl daemon-reload
# systemctl start pulseaudio.service
</pre>
* Make sure that the service is active, running and reports no errors.
<pre>
# systemctl status pulseaudio.service
Loaded: loaded (/etc/systemd/system/pulseaudio.service; disabled)
Active: active (running) since Mon 2015-07-20 12:00:13 UTC; 1min 34s ago
Main PID: 805 (pulseaudio)
CGroup: /system.slice/pulseaudio.service
└─805 /usr/bin/pulseaudio --system --disallow-exit --disable-shm
</pre>

==== Bluez5 pairing ====
PulseAudio 5.x supports A2DP per default.<br>
Make sure the following packages are installed:
pulseaudio pulseaudio-module-bluetooth pulseaudio-utils, bluez, bluez-tools.
{{Note|Without {{filename|pulseaudio-module-bluetooth}} package it will be impossible to connect after the next pairing and there will be no usable error messages.}}

* Start the Bluetooth system:
<pre>
# systemctl start bluetooth
</pre>
Now we can use the {{filename|bluetoothctl}} command line utility to pair and connect. Run
<pre>
# bluetoothctl
</pre>
to be greeted by its internal command prompt. Then enter:
<pre>
# power on
# agent on
# default-agent
# scan on
</pre>
Now make sure that the headset is in pairing mode. It should be discovered shortly. For example,
<pre>
[NEW] Device 00:07:A4:F2:B3:CB Motorola HT820
</pre>
shows a device that calls itself "Motorola HT820" and has MAC address 00:07:A4:F2:B3:CB.
We will now use that MAC address to initiate the pairing:
<pre>
# pair 00:07:A4:F2:B3:CB
</pre>
After pairing, connect to the device explicitly:
<pre>
# connect 00:07:A4:F2:B3:CB
</pre>
A new PulseAudio output device is ready.<br>
Disable the scanning and exit the program:
<pre>
# scan off
# exit
</pre>

==== Playback using PulseAudio ====
{{Note|Next examples assume that the device mac address is '''00_07_A4_F2_B3_CB'''}}
* Show the PulseAudio device
<pre>
# pactl list cards | awk '/00_07_A4_F2_B3_CB/' RS=""
Card #1
Name: bluez_card.00_07_A4_F2_B3_CB
Driver: module-bluez5-device.c
Owner Module: 16
Properties:
device.description = "Motorola HT820"
device.string = "00:07:A4:F2:B3:CB"
device.api = "bluez"
device.class = "sound"
device.bus = "bluetooth"
device.form_factor = "headset"
bluez.path = "/org/bluez/hci0/dev_00_07_A4_F2_B3_CB"
bluez.class = "0x240404"
bluez.alias = "Motorola HT820"
device.icon_name = "audio-headset-bluetooth"
device.intended_roles = "phone"
Profiles:
a2dp: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes)
off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
Active Profile: a2dp
Ports:
headset-output: Headset (priority: 0, latency offset: 0 usec)
Part of profile(s): a2dp
headset-input: Headset (priority: 0, latency offset: 0 usec, not available)

</pre>
* Switch the active card profile to A2DP
<pre>
# pactl set-card-profile 1 a2dp_sink
</pre>
* Show the PulseAudio sink
<pre>
# pactl list sinks | awk '/00_07_A4_F2_B3_CB/' RS=""
Sink #2
State: SUSPENDED
Name: bluez_sink.00_07_A4_F2_B3_CB
Description: Motorola HT820
Driver: module-bluez5-device.c
Sample Specification: s16le 2ch 44100Hz
Channel Map: front-left,front-right
Owner Module: 16
Mute: no
Volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor Source: bluez_sink.00_07_A4_F2_B3_CB.monitor
Latency: 0 usec, configured 0 usec
Flags: HARDWARE DECIBEL_VOLUME LATENCY
Properties:
bluetooth.protocol = "a2dp_sink"
device.description = "Motorola HT820"
device.string = "00:07:A4:F2:B3:CB"
device.api = "bluez"
device.class = "sound"
device.bus = "bluetooth"
device.form_factor = "headset"
bluez.path = "/org/bluez/hci0/dev_00_07_A4_F2_B3_CB"
bluez.class = "0x240404"
bluez.alias = "Motorola HT820"
device.icon_name = "audio-headset-bluetooth"
device.intended_roles = "phone"
Ports:
headset-output: Headset (priority: 0)
Active Port: headset-output
Formats:
pcm
</pre>
* Play sound using {{filename|paplay}}. Example:
<pre>
# paplay -d bluez_sink.00_07_A4_F2_B3_CB /mnt/media/vegas.wav
</pre>

==== ObexFTP transfers ====

* To transfer files between CM-T43 and a remote device, make sure that the remote device supports ObexFTP transfers by running the ObexFTP daemon on the remote device:
<pre>
user@linux-host:~$ obexftpd -b
</pre>

* To send a file from CM-T43 to a target device, run the following command:
<pre>
root@cm-debian:~# obexftp -b <MAC_address_of_device> -p <filename>
</pre>

* To download a file from a target device to CM-T43, run the following command:
<pre>
root@cm-debian:~# obexftp -b <MAC_address_of_device> -g <filename>
</pre>

=== Touchscreen ===

CM-T43 Evaluation Kit is equipped with Startek KD050C LCD 800x480 LCD touch panel.

The X Windows system of CM-T43 uses EVDEV X server input driver to get the input from the touchscreen.

==== Touchscreen calibration ====
A touchscreen device can be calibrated using {{cmd|xinput_calibrator}} utility.

To calibrate the touchscreen:
* Run X Server by issuing {{cmd|startx}} command
* Make sure the touchscreen driver is loaded as described in [[CM-T54: Linux: Debian#Touchscreen|Touchscreen]] section
* Set the {{parameter|DISPLAY}} environment variable: <pre> export DISPLAY=:0</pre>
* Run {{cmd|xinput_calibrator}} utility. For proper calibration you are required to touch the touchscreen at the displayed markers.
* Create a file {{filename|/usr/share/X11/xorg.conf.d/99-calibration.conf}} and paste there a snippet with the calibration results:
<pre>
xinput_calibrator
Calibrating EVDEV driver for "ti-tsc" id=6
current calibration values (from XInput): min_x=0, max_x=4095 and min_y=0, max_y=4095

Doing dynamic recalibration:
Setting calibration data: 105, 3975, 3763, 174
--> Making the calibration permanent <--
copy the snippet below into '/etc/X11/xorg.conf.d/99-calibration.conf' (/usr/share/X11/xorg.conf.d/ in some distro's)
Section "InputClass"
Identifier "calibration"
MatchProduct "ti-tsc"
Option "Calibration" "105 3975 3763 174"
Option "SwapAxes" "0"
EndSection
</pre>

=== RTC ===
==== Accessing and setting the RTC ====
To access the RTC time and date run:
<pre>
root@cm-debian:~# hwclock
Sat Jan 1 00:00:00 2000 -10.011159 seconds
</pre>

To set the date and write it into the RTC do the following:
<pre>
root@cm-debian:~# date -s "31 JUL 2015 10:00:00"
Fri Jul 31 10:00:00 UTC 2015
root@cm-debian:~# hwclock -w
root@cm-debian:~# hwclock
Fri Jul 31 10:00:13 2015 -1.066224 seconds
</pre>

=== CAN bus ===

Install can-utils using:
<pre>
# apt-get install can-utils
</pre>

==== CAN interface configuration ====
* Load the can bus modules:
<pre>
# modprobe can-raw
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
# modprobe can-bcm
can: broadcast manager protocol (rev 20120528 t)
</pre>

It is recommended configure the CAN interface, with the {{filename|iproute2}} utilities.

* To make sure the right {{filename|ip}} utility is used, run:
<pre>
# ip -V
ip utility, iproute2-ss140804
</pre>

* Configure the CAN interface bit-rate to 125 Kbits/sec (values of up to 1Mbit/sec are supported):
<pre>
# ip link set can0 type can bitrate 125000
</pre>

* Enable the CAN interface:
<pre>
# ip link set can0 up
c_can_platform 481d0000.can can0: setting BTR=0518 BRPE=0000
</pre>

===== Send/Receive packets =====

Use {{filename|cansend}} and {{filename|candump}} utilities to send and receive packets via CAN interface.

* Send standard CAN frame (on the first device):
<pre>
# cansend can0 111#1122334455667788
</pre>

* Send extended CAN frame (on the first device):
<pre>
# cansend can0 11111111#1122334455667788
</pre>

* Dump all received data frames as well as error frames (on the second device):
<pre>
# candump any,0:0,#FFFFFFFF
can0 111 [8] 11 22 33 44 55 66 77 88
can0 11111111 [8] 11 22 33 44 55 66 77 88
</pre>

=== GPIO ===

To use a GPIO:
* Select a pin you wish to use as GPIO by consulting the [http://www.compulab.co.il/wp-content/uploads/2016/02/cm-t43_reference-guide_2016-02-17.pdf CM-T43 reference manual]. The reference manual contains a list of pins and the possible functions each pin can support, many of which include GPIO signals as one of the possible functions.
* Setup the pinmux so that the GPIO function is selected for the pin you chose in the previous step. This may require you to edit the device tree for CM-T43. Consult the [[Linux: Introduction to device trees | device tree article]] in the CM-T43 Linux wiki.
* Export the GPIO in Linux sysfs and cd into it
<pre>
# echo <gpio_num> > /sys/class/gpio/export
# cd gpio<gpio_num>
</pre>
* Select GPIO input/output function:
<pre>
# echo in > direction
</pre>
or
<pre>
# echo out > direction
</pre>
* To read GPIO input (or determine what value is being output):
<pre>
# cat value
0
</pre>
* To output a value on the GPIO pin:
<pre>
# echo 1 > value
</pre>

== See also ==

* [[CM-T43: Linux: Manual Installation]]
* [[CM-T43: Linux: Kernel]]
* [[Linux: Development for ARM modules]]
* [[Linux: Debian: Minimal ARM filesystem]]
* [http://www.debian.org/doc/manuals/reference/index.en.html Debian Reference].

[[Category:Linux|Debian]]
[[Category:CM-T43|Linux: Debian]]

CM-T43: Linux: Kernel

2016-06-29T11:27:23Z

Nikita: /* See also */

== Overview ==
Linux kernel for the CompuLab CM-T43 System-on-Module / Computer-on-Module provides support for on-board peripherals and abstracts the functionality provided by the hardware.
CompuLab provides ready-to-run binary kernel images, and source code of the modifications and additions made to the Linux kernel to work properly with CM-T43 modules.

== Building kernel for CM-T43 ==

=== Getting kernel sources ===
There are various ways to get Linux kernel sources that can be used as a baseline for CM-T43 kernel.
For instance, a copy of linux-stable git tree can be created or a Linux kernel sources snapshot can be downloaded.

Assuming that the {{filename|/home/development/cm-t43/kernel}} directory structure has been created for CM-T43 kernel development.

==== Snapshot download ====
* Download [https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.13.tar.gz v4.4.13] snapshot with a web browser.
* Extract the downloaded archive {{filename|linux-4.4.13.tar.gz}}
<pre>
cd /home/development/cm-t43/kernel
tar xvf /path/to/downloaded/linux-4.4.13.tar.gz
mv linux-4.4.13 linux-cm-t43
</pre>
: This will create {{filename|/home/development/cm-t43/kernel/linux-cm-t43}} directory containing linux kernel tree.
* Apply the CM-T43 patch
<pre>
cd /home/development/cm-t43/kernel/linux-cm-t43
patch -p1 < /path/to/cm-t43-linux/kernel/linux-4.4.13-cm-t43-5.patch
</pre>

==== Git clone ====
* Install [http://git-scm.com/ git] version control system.
* Create a clone of linux kernel tree
<pre>
cd /home/development/cm-t43/kernel
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-cm-t43
</pre>
* Create a branch for CM-T43 development. The CM-T43 patches are generated vs. v4.4.13 tag (ba760d4302e4fce130007b8bdbce7fcafc9bd9a9 commit) in the Linux tree. It is recommended to use exactly the same baseline to avoid merge conflicts.
<pre>
cd /home/development/cm-t43/kernel/linux-cm-t43
git checkout -b cm-t43-dev v4.4.13
</pre>
* Apply the CM-T43 patch
<pre>
git apply /path/to/cm-t43-linux/kernel/linux-4.4.13-cm-t43-5.patch
</pre>

{{Note|Future stable kernel versions of 4.4.13 can also be used by adding the Linux kernel stable repository as a remote and checking out any later tag of the v4.4.y stable kernel branch.}}

=== Building the kernel ===
* Run the following commands:
<pre>
export ARCH=arm
export CROSS_COMPILE=arm-none-linux-eabi-
make cm_t43_defconfig && make menuconfig
make && INSTALL_MOD_PATH=/home/development/cm-t43/rootfs make modules_install
</pre>

In the example above:

* The Linux kernel image {{filename|zImage}} will be created in {{filename|/home/development/cm-t43/kernel/linux-cm-t43/arch/arm/boot}}
* The Device Tree binary {{filename|am437x-sb-som-t43.dtb}} will be created in {{filename|/home/development/cm-t43/kernel/linux-cm-t43/arch/arm/boot/dts}}
* The loadable kernel modules will be installed into the {{filename|/home/development/cm-t43/rootfs/lib/modules}} directory.

When the CM-T43 is booted with the kernel image and Device Tree binary created as described above and with networked root filesystem at {{filename|/home/development/cm-t43/rootfs/}}, the system will be able to load the kernel modules properly, thus avoiding module version problems.

== Basic platform support ==
The CM-T43 basic platform support is implemented in device tree files located in {{filename|arch/arm/boot/dts/}} folder of Linux kernel source tree.

=== Device Tree ===
Device Tree (DT), is a data structure and language for describing hardware. More specifically, it is a description of hardware that is readable by an operating system so that the operating system doesn't need to hard code details of the machine.

A device tree file, named *.dts, is a text file that describes the hardware platform. It is compiled into a device tree blob, *.dtb, which is loaded into memory before the Linux kernel is started. The Linux kernel then uses that device tree blob to initialize itself at runtime.

==== CM-T43 device tree organization ====
The SBC-T43 product is built from 3 major components:
<pre>
┌───────────────────────────────┐
│ SB-SOM baseboard │
│ │
│ ┌─────────────────────┐ │
│ │ CM-T43 SoM │ │
│ │ │ │
│ │ ┌─────────────┐ │ │
│ │ │TI AM437x SoC│ │ │
│ │ └─────────────┘ │ │
│ └─────────────────────┘ │
└───────────────────────────────┘
</pre>
The SB-SOM baseboard is a general purpose baseboard, capable of supporting multiple CompuLab SoMs, including: CM-T43, CM-T54, CM-QS600. This leads us to the following device tree division:
<pre>
am4372.dtsi
∧
│
│
am437x-cm-t43.dts compulab-sb-som.dtsi
∧ ∧
│ │
└───────┐ ┌───────┘
│ │
am437x-sb-som-t43.dts
</pre>

* {{filename | am4372.dtsi}} is the SoC vendor device tree describing the AM437x SoC.
* {{filename | am437x-cm-t43.dts}} is the SoM vendor device tree describing the CM-T43 SoM.
* {{filename | compulab-sb-som.dtsi}} describes the SB-SOM baseboard. Only hardware properties that remain constant regardless of which SoM is installed on the baseboard are described here.
* {{filename | am437x-sb-som-t43.dts}} describes the integration between CM-T43 SoM and the SB-SOM baseboard. Everything that is related to the SB-SOM baseboard and would change if we were to swap the CM-T43 module with another SoM is described here. For example: SB-SOM contains TFP410, an RGB-to-DVI encoder. The encoder is located on an I2C bus, but depending on the installed SoC it might be i2c1, i2c2, or i2c3. Therefore, it is not described in the generic {{filename | compulab-sb-som.dtsi}} device tree, but in the device tree describing the SB-SOM/CM-T43 combination. On the other hand, in order to describe the DVI connector on SB-SOM, there is no need to reference any SoM specific information, and therefore it is described in the generic {{filename | compulab-sb-som.dtsi}} file.

For more details visit official [http://devicetree.org/Device_Tree_Usage Device Tree WiKi] pages and make an overview of a [http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf Device Tree tutorial]

=== Kernel configuration ===

==== USB support ====
CM-T43 features a DRD USB 2.0 controller. A DRD (Dual Role Device) controller is similar to an OTG controller in the sense that it supports both host and slave modes, but it lacks the ability to dynamically switch between them based on which USB plug is connected to it. CM-T43 defaults to running the USB controller as a host, but enables support for both so that a switch to device mode could be accomplished by editing the device tree.

In the kernel configuration menu choose '''Device Drivers ---> USB support''' submenu and enable:
* Support for Host-side USB
* EHCI HCD (USB 2.0) support
* DesignWare USB3 DRD Core Support
** Set DWC3 Mode Selection to Dual Role mode
* Texas Instruments OMAP5 and similar Platforms
┌───────────────────────────────────── USB support ──────────────────────────────────────┐
│ ┌────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ --- USB support │ │
│ │ <*> Support for Host-side USB │ │
│ │ [*] USB announce new devices │ │
│ │ *** Miscellaneous USB options *** │ │
│ │ [*] Enable USB persist by default │ │
│ │ [ ] Dynamic USB minor allocation │ │
│ │ [*] OTG support │ │
│ │ [ ] Rely on OTG and EH Targeted Peripherals List │ │
│ │ [ ] Disable external hubs │ │
│ │ < > USB 2.0 OTG FSM implementation │ │
│ │ < > USB ULPI PHY interface support │ │
│ │ < > USB Monitor │ │
│ │ < > Support WUSB Cable Based Association (CBA) │ │
│ │ *** USB Host Controller Drivers *** │ │
│ │ < > Cypress C67x00 HCD support │ │
│ │ <*> xHCI HCD (USB 3.0) support │ │
│ │ <*> EHCI HCD (USB 2.0) support │ │
│ │ [*] Root Hub Transaction Translators │ │
│ │ [*] Improved Transaction Translator scheduling │ │
│ │ < > EHCI support for OMAP3 and later chips │ │
│ │ <*> Generic EHCI driver for a platform device │ │
│ │ < > OXU210HP HCD support │ │
│ │ < > ISP116X HCD support │ │
│ │ < > ISP1362 HCD support │ │
│ │ < > FUSBH200 HCD support │ │
│ │ < > FOTG210 HCD support │ │
│ │ < > MAX3421 HCD (USB-over-SPI) support │ │
│ │ < > OHCI HCD (USB 1.1) support │ │
│ │ < > SL811HS HCD support │ │
│ │ < > R8A66597 HCD support │ │
│ │ [ ] HCD test mode support │ │
│ │ *** USB Device Class drivers *** │ │
│ │ < > USB Modem (CDC ACM) support │ │
│ │ < > USB Printer support │ │
│ │ < > USB Wireless Device Management support │ │
│ │ < > USB Test and Measurement Class support │ │
│ │ *** NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may *** │ │
│ │ *** also be needed; see USB_STORAGE Help for more info *** │ │
│ │ <*> USB Mass Storage support │ │
│ │ [ ] USB Mass Storage verbose debug │ │
│ │ < > Realtek Card Reader support │ │
│ │ < > Datafab Compact Flash Reader support │ │
│ │ < > Freecom USB/ATAPI Bridge support │ │
│ │ < > ISD-200 USB/ATA Bridge support │ │
│ │ < > USBAT/USBAT02-based storage support │ │
│ │ < > SanDisk SDDR-09 (and other SmartMedia, including DPCM) support │ │
│ │ < > SanDisk SDDR-55 SmartMedia support │ │
│ │ < > Lexar Jumpshot Compact Flash Reader │ │
│ │ < > Olympus MAUSB-10/Fuji DPC-R1 support │ │
│ │ < > Support OneTouch Button on Maxtor Hard Drives │ │
│ │ < > Support for Rio Karma music player │ │
│ │ < > SAT emulation on Cypress USB/ATA Bridge with ATACB │ │
│ │ < > USB ENE card reader support │ │
│ │ < > USB Attached SCSI │ │
│ │ *** USB Imaging devices *** │ │
│ │ < > USB Mustek MDC800 Digital Camera support │ │
│ │ < > Microtek X6USB scanner support │ │
│ │ < > USB/IP support │ │
│ │ < > Inventra Highspeed Dual Role Controller (TI, ADI, ...) │ │
│ │ <*> DesignWare USB3 DRD Core Support │ │
│ │ DWC3 Mode Selection (Dual Role mode) ---> │ │
│ │ *** Platform Glue Driver Support *** │ │
│ │ <*> Texas Instruments OMAP5 and similar Platforms │ │
│ │ *** Debugging features *** │ │
│ │ [ ] Enable Debugging Messages │ │
│ └───────┴(+)─────────────────────────────────────────────────────────────────────────┘ │
├────────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└────────────────────────────────────────────────────────────────────────────────────────┘

In the kernel configuration menu choose '''Device Drivers ---> PHY subsystem''' submenu and enable:
* OMAP USB2 PHY Driver
<pre>
┌────────────────────────────── PHY Subsystem ──────────────────────────────┐
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ -*- PHY Core │ │
│ │ < > TI dm816x USB PHY driver │ │
│ │ < > Marvell USB HSIC 28nm PHY Driver │ │
│ │ < > Marvell USB 2.0 28nm PHY Driver │ │
│ │ -*- OMAP CONTROL PHY Driver │ │
│ │ <*> OMAP USB2 PHY Driver │ │
│ │ < > TI PIPE3 PHY Driver │ │
│ │ < > Broadcom Kona USB2 PHY Driver │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────────────┘
</pre>

==== MMC/SDIO support ====
In the kernel configuration menu choose '''Device Drivers ---> MMC/SD/SDIO card support''' submenu and enable:
* TI OMAP High Speed Multimedia Card Interface support
<pre>
┌─────────────────────────────── MMC/SD/SDIO card support ───────────────────────────────┐
│ ┌────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ --- MMC/SD/SDIO card support │ │
│ │ [ ] MMC debugging │ │
│ │ [ ] MMC host clock gating │ │
│ │ *** MMC/SD/SDIO Card Drivers *** │ │
│ │ <*> MMC block device driver │ │
│ │ (8) Number of minors per block device │ │
│ │ [*] Use bounce buffer for simple hosts │ │
│ │ <*> SDIO UART/GPS class support │ │
│ │ < > MMC host test driver │ │
│ │ *** MMC/SD/SDIO Host Controller Drivers *** │ │
│ │ < > Secure Digital Host Controller Interface support │ │
│ │ < > TI OMAP Multimedia Card Interface support │ │
│ │ <*> TI OMAP High Speed Multimedia Card Interface support │ │
│ │ < > Synopsys DesignWare Memory Card Interface │ │
│ │ < > VUB300 USB to SDIO/SD/MMC Host Controller support │ │
│ │ < > USB SD Host Controller (USHC) support │ │
│ │ < > Renesas USDHI6ROL0 SD/SDIO Host Controller support │ │
│ │ < > MediaTek SD/MMC Card Interface support │ │
│ │ │ │
│ └────────────────────────────────────────────────────────────────────────────────────┘ │
├────────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└────────────────────────────────────────────────────────────────────────────────────────┘
</pre>

==== NAND support ====
In the kernel configuration menu choose '''Device Drivers ---> Memory Technology Device (MTD) support ---> NAND Device Support''' submenu and enable:
* NAND Flash device on OMAP2, OMAP3 and OMAP4
* Support hardware based BCH error correction
* Support software BCH ECC
<pre>
┌─────────────────────────── NAND Device Support ───────────────────────────┐
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ --- NAND Device Support │ │
│ │ [*] Support software BCH ECC │ │
│ │ < > Support Denali NAND controller │ │
│ │ < > GPIO assisted NAND Flash driver │ │
│ │ <*> NAND Flash device on OMAP2, OMAP3 and OMAP4 │ │
│ │ [*] Support hardware based BCH error correction │ │
│ │ < > DiskOnChip 2000, Millennium and Millennium Plus (NAND reimple│ │
│ │ < > Support for DiskOnChip G4 │ │
│ │ < > Support for NAND Flash Simulator │ │
│ │ < > Broadcom STB NAND controller │ │
│ │ < > Support for generic platform NAND driver │ │
│ │ < > Support for NAND controller on Hisilicon SoC Hip04 │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────────────┘
</pre>

==== SPI support ====
In the kernel configuration menu choose '''Device Drivers ---> SPI support''' submenu and enable:
* McSPI driver for OMAP
<pre>
┌─────────────────────────────── SPI support ───────────────────────────────┐
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ --- SPI support │ │
│ │ *** SPI Master Controller Drivers *** │ │
│ │ < > Altera SPI Controller │ │
│ │ < > Utilities for Bitbanging SPI masters │ │
│ │ < > Cadence SPI controller │ │
│ │ < > GPIO-based bitbanging SPI Master │ │
│ │ < > Freescale SPI controller and Aeroflex Gaisler GRLIB SPI contr│ │
│ │ < > OpenCores tiny SPI │ │
│ │ <*> McSPI driver for OMAP │ │
│ │ < > DRA7xxx QSPI controller support │ │
│ │ < > Rockchip SPI controller driver │ │
│ └────┴(+)───────────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────────────┘
</pre>

===== SPI-flash support =====
In the kernel configuration menu choose '''Device Drivers ---> Memory Technology Device (MTD) support''' submenu and enable:
* SPI-NOR device support
<pre>
┌───────────────── Memory Technology Device (MTD) support ──────────────────┐
│ ┌────^(-)───────────────────────────────────────────────────────────────┐ │
│ │ [ ] Retain master device when partitioned │ │
│ │ RAM/ROM/Flash chip drivers ---> │ │
│ │ Mapping drivers for chip access ---> │ │
│ │ Self-contained MTD device drivers ---> │ │
│ │ [ ] NAND ECC Smart Media byte order │ │
│ │ <*> NAND Device Support ---> │ │
│ │ <*> OneNAND Device Support ---> │ │
│ │ LPDDR & LPDDR2 PCM memory drivers ---> │ │
│ │ <*> SPI-NOR device support ---> │ │
│ │ <*> Enable UBI - Unsorted block images ---> │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────────────┘
</pre>

In the kernel configuration menu choose '''Device Drivers ---> Memory Technology Device (MTD) support ---> Self-contained MTD device drivers''' submenu and enable:
* Support most SPI Flash chips (AT26DF, M25P, W25X, ...)
<pre>
┌──────────────────── Self-contained MTD device drivers ────────────────────┐
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ < > Support for AT45xxx DataFlash │ │
│ │ <*> Support most SPI Flash chips (AT26DF, M25P, W25X, ...) │ │
│ │ < > Support SST25L (non JEDEC) SPI Flash chips │ │
│ │ < > Uncached system RAM │ │
│ │ < > Physical system RAM │ │
│ │ < > Test driver using RAM │ │
│ │ < > MTD using block device │ │
│ │ *** Disk-On-Chip Device Drivers *** │ │
│ │ < > M-Systems Disk-On-Chip G3 │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────────────┘
</pre>

==== UART support ====
In the kernel configuration menu choose '''Device Drivers ---> Character devices ---> Serial drivers''' submenu and enable:
* OMAP serial port support
* Console on OMAP serial port
<pre>
┌─────────────────────────────────── Serial drivers ───────────────────────────────────┐
│ ┌──────^(-)────────────────────────────────────────────────────────────────────────┐ │
│ │ < > MAX3100 support │ │
│ │ < > MAX310X support │ │
│ │ <*> Serial port on Open Firmware platform bus │ │
│ │ <*> OMAP serial port support │ │
│ │ [*] Console on OMAP serial port │ │
│ │ < > SCCNXP serial port support │ │
│ │ < > SC16IS7xx serial support │ │
│ │ < > Broadcom BCM63xx/BCM33xx UART support │ │
│ │ < > Altera JTAG UART support │ │
│ │ < > Altera UART support │ │
│ │ < > SPI protocol driver for Infineon 6x60 modem (EXPERIMENTAL) │ │
│ │ < > Cadence (Xilinx Zynq) UART support │ │
│ │ < > ARC UART driver support │ │
│ │ < > Freescale lpuart serial port support │ │
│ │ < > Conexant Digicolor CX92xxx USART serial port support │ │
│ │ < > ST ASC serial port support │ │
│ │ < > STMicroelectronics STM32 serial port support │ │
│ └──────────────────────────────────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└──────────────────────────────────────────────────────────────────────────────────────┘
</pre>

==== Ethernet support ====
CM-T43 features an ethernet controller that can operate as a Layer-2 3-port ethernet switch. Alternatively, the ethernet controller can be setup in dualEMAC mode, which is the default on CM-T43. The mode of operation can be changed to ethernet switch by editing the device tree.

In the kernel configuration menu choose '''Device Drivers ---> Network device support ---> Ethernet driver support''' submenu and enable:
* Texas Instruments (TI) devices
* TI DaVinci MDIO Support
* TI DaVinci CPDMA Support
* TI CPSW Switch Phy sel Support
* TI CPSW ALE Support
* TI CPSW Switch Support
<pre>
┌────────────────────────────── Ethernet driver support ───────────────────────────────┐
│ ┌──────^(-)────────────────────────────────────────────────────────────────────────┐ │
│ │ [*] Rocker devices │ │
│ │ [ ] Samsung Ethernet devices │ │
│ │ [ ] SEEQ devices │ │
│ │ [*] SMC (SMSC)/Western Digital devices │ │
│ │ <*> SMC 91C9x/91C1xxx support │ │
│ │ < > SMSC LAN911[5678] support │ │
│ │ <*> SMSC LAN911x/LAN921x families embedded ethernet support │ │
│ │ [ ] STMicroelectronics devices │ │
│ │ [*] Texas Instruments (TI) devices │ │
│ │ -*- TI DaVinci MDIO Support │ │
│ │ -*- TI DaVinci CPDMA Support │ │
│ │ -*- TI CPSW Switch Phy sel Support │ │
│ │ -*- TI CPSW ALE Support │ │
│ │ <*> TI CPSW Switch Support │ │
│ │ [ ] TI Common Platform Time Sync (CPTS) Support │ │
│ │ [ ] VIA devices │ │
│ │ [ ] WIZnet devices │ │
│ └──────────────────────────────────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└──────────────────────────────────────────────────────────────────────────────────────┘
</pre>

In the kernel configuration menu choose '''Device Drivers ---> Network device support ---> PHY Device support and infrastructure''' submenu and enable:
* Drivers for Atheros AT803X PHYs
<pre>
┌────────────── PHY Device support and infrastructure ──────────────┐
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ --- PHY Device support and infrastructure │ │
│ │ *** MII PHY device drivers *** │ │
│ │ <*> Drivers for Atheros AT803X PHYs │ │
│ │ < > Drivers for the AMD PHYs │ │
│ │ < > Drivers for Marvell PHYs │ │
│ │ < > Drivers for Davicom PHYs │ │
│ │ < > Drivers for Quality Semiconductor PHYs │ │
│ │ < > Drivers for the Intel LXT PHYs │ │
│ │ < > Drivers for the Cicada PHYs │ │
│ │ < > Drivers for the Vitesse PHYs │ │
│ └────┴(+)───────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────┘
</pre>

==== Display support ====
CM-T43 has a single parallel RGB display interface which drives multiple display connectors, including: a parallel RGP LCD + touchscreen connector, a DVI connector, and an LVDS connector. Since all 3 connectors are driven by the same interface, they cannot simultaneously output images at different resolutions.

In the kernel configuration menu choose '''Device Drivers ---> Graphics support ---> Frame buffer Devices ---> OMAP2+ Display Subsystem support''' submenu and enable:
* DPI support
* OMAP2+ frame buffer support
<pre>
┌──────────────────── OMAP2+ Display Subsystem support ─────────────────────┐
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ --- OMAP2+ Display Subsystem support │ │
│ │ [ ] Debug support │ │
│ │ [*] Debugfs filesystem support │ │
│ │ [ ] Collect DSS IRQ statistics │ │
│ │ [*] DPI support │ │
│ │ [ ] VENC support │ │
│ │ [ ] HDMI support for OMAP4 │ │
│ │ [ ] HDMI support for OMAP5 │ │
│ │ [ ] SDI support │ │
│ │ [ ] DSI support │ │
│ │ (0) Minimum FCK/PCK ratio (for scaling) │ │
│ │ [ ] Sleep 20ms after VENC reset │ │
│ │ <M> OMAP2+ frame buffer support ---> │ │
│ │ OMAP Display Device Drivers (new device model) ---> │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────────────┘
</pre>

In the kernel configuration menu choose '''Device Drivers ---> Graphics support ---> Frame buffer Devices ---> OMAP2+ Display Subsystem support --- OMAP Display Device Driver''' submenu and enable:
* TFP410 DPI to DVI Encoder
* DVI Connector

<pre>
┌───────────── OMAP Display Device Drivers (new device model) ──────────────┐
│ ┌───────────────────────────────────────────────────────────────────────┐ │
│ │ < > OPA362 external analog amplifier │ │
│ │ <M> TFP410 DPI to DVI Encoder │ │
│ │ < > TPD12S015 HDMI ESD protection and level shifter │ │
│ │ <M> DVI Connector │ │
│ │ < > HDMI Connector │ │
│ │ < > Analog TV Connector │ │
│ │ <M> Generic DPI panel │ │
│ │ < > Generic DSI Command Mode Panel │ │
│ │ <M> ACX565AKM Panel │ │
│ │ <M> LG.Philips LB035Q02 LCD Panel │ │
│ │ <M> Sharp LS037V7DW01 LCD Panel │ │
│ │ <M> TPO TD028TTEC1 LCD Panel │ │
│ │ <M> TPO TD043MTEA1 LCD Panel │ │
│ │ <M> NEC NL8048HL11 Panel │ │
│ └───────────────────────────────────────────────────────────────────────┘ │
├───────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└───────────────────────────────────────────────────────────────────────────┘
</pre>

==== Wifi support ====
The WiFi chip is connected to the SoC via SDIO interface, so make sure you have MMC support turned on. Also, make sure wireless support is turned on under '''Network support'''.

In the kernel configuration menu choose '''Device Drivers ---> Network device support ---> Wireless LAN''' submenu and enable:
* Marvell WiFi-Ex Driver
* Marvell WiFi-Ex Driver for SD8786/SD8787/SD8797/SD8887/SD8897
<pre>
┌─────────────────────────────────────── Wireless LAN ───────────────────────────────────────┐
│ ┌─────────^(-)───────────────────────────────────────────────────────────────────────────┐ │
│ │ <M> Marvell 8xxx Libertas WLAN driver support │ │
│ │ <M> Marvell Libertas 8388 USB 802.11b/g cards │ │
│ │ <M> Marvell Libertas 8385/8686/8688 SDIO 802.11b/g cards │ │
│ │ < > Marvell Libertas 8686 SPI 802.11b/g cards │ │
│ │ [*] Enable full debugging output in the Libertas module. │ │
│ │ [ ] Enable mesh support │ │
│ │ < > Softmac Prism54 support │ │
│ │ < > Ralink driver support ---- │ │
│ │ [ ] Mediatek Wireless LAN support ---- │ │
│ │ <M> Realtek rtlwifi family of devices ---> │ │
│ │ [*] TI Wireless LAN support ---> │ │
│ │ < > ZyDAS ZD1211/ZD1211B USB-wireless support │ │
│ │ <M> Marvell WiFi-Ex Driver │ │
│ │ <M> Marvell WiFi-Ex Driver for SD8786/SD8787/SD8797/SD8887/SD8897 │ │
│ │ <M> Marvell WiFi-Ex Driver for USB8766/8797/8897 │ │
│ │ < > CW1200 WLAN support │ │
│ │ < > Redpine Signals Inc 91x WLAN driver support │ │
│ └────────────────────────────────────────────────────────────────────────────────────────┘ │
├────────────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└────────────────────────────────────────────────────────────────────────────────────────────┘

</pre>

==== Bluetooth support ====
The Bluetooth chip is connected to the SoC via SDIO interface, so make sure you have MMC support turned on. Also, make sure bluetooth support is turned on under '''Network support ---> Bluetooth subsystem support'''.

In the kernel configuration menu choose '''Networking support ---> Bluetooth subsystem support ---> Bluetooth device drivers''' submenu and enable:
* HCI SDIO driver
* HCI UART driver
* Marvell Bluetooth driver support
* Marvell BT-over-SDIO driver
<pre>
┌───────────────────────────── Bluetooth device drivers ──────────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ <M> HCI USB driver │ │
│ │ [*] Broadcom protocol support │ │
│ │ [*] Realtek protocol support │ │
│ │ <M> HCI SDIO driver │ │
│ │ <M> HCI UART driver │ │
│ │ [*] UART (H4) protocol support │ │
│ │ [*] BCSP protocol support │ │
│ │ [ ] Atheros AR300x serial support │ │
│ │ [*] HCILL protocol support │ │
│ │ [ ] Three-wire UART (H5) protocol support │ │
│ │ [ ] Intel protocol support │ │
│ │ [ ] Broadcom protocol support │ │
│ │ <M> HCI BCM203x USB driver │ │
│ │ <M> HCI BPA10x USB driver │ │
│ │ < > HCI BlueFRITZ! USB driver │ │
│ │ < > HCI VHCI (Virtual HCI device) driver │ │
│ │ <M> Marvell Bluetooth driver support │ │
│ │ <M> Marvell BT-over-SDIO driver │ │
│ │ <M> Atheros firmware download driver │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└─────────────────────────────────────────────────────────────────────────────────────┘
</pre>

==== Audio support ====
In the kernel configuration menu choose '''Device Drivers ---> Sound card support ---> Advanced Linux Sound Architecture ---> ALSA for SoC audio support''' submenu and enable:
* SoC Audio for Texas Instruments chips using eDMA
* Multichannel Audio Serial Port (McASP) support
* SoC Audio for the Texas Instruments OMAP chips
* ASoC Simple sound card support
<pre>
┌──────────────────────────── ALSA for SoC audio support ─────────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ --- ALSA for SoC audio support │ │
│ │ < > SoC Audio for the Atmel System-on-Chip │ │
│ │ <M> SoC Audio for Texas Instruments chips using eDMA │ │
│ │ <M> Multichannel Audio Serial Port (McASP) support │ │
│ │ < > SoC Audio for the AM33XX chip based boards │ │
│ │ < > Synopsys I2S Device Driver │ │
│ │ SoC Audio for Freescale CPUs ---> │ │
│ │ <M> SoC Audio for the Texas Instruments OMAP chips │ │
│ │ < > HDMI audio support for OMAP4+ based SoCs │ │
│ │ < > SoC Audio support for Nokia N900 (RX-51) │ │
│ │ <M> SoC Audio support for TI SoC based boards with twl4030 codec │ │
│ │ < > ASoC support for QCOM platforms │ │
│ │ < > XTFPGA I2S master │ │
│ │ CODEC drivers ---> │ │
│ │ <M> ASoC Simple sound card support │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└─────────────────────────────────────────────────────────────────────────────────────┘
</pre>

Under the '''CODEC drivers''' submenu of the same section enable:
* Wolfson Microelectronics WM8731 CODEC
<pre>
┌─────────────────────────────────── CODEC drivers ───────────────────────────────────┐
│ ┌─────^(-)────────────────────────────────────────────────────────────────────────┐ │
│ │ < > Wolfson Microelectronics WM8523 CODEC │ │
│ │ < > Wolfson Microelectronics WM8711 CODEC │ │
│ │ < > Wolfson Microelectronics WM8728 DAC │ │
│ │ <M> Wolfson Microelectronics WM8731 CODEC │ │
│ │ < > Wolfson Microelectronics WM8737 ADC │ │
│ │ < > Wolfson Microelectronics WM8737 DAC │ │
│ │ < > Wolfson Microelectronics WM8750 CODEC │ │
│ │ < > Wolfson Microelectronics WM8753 CODEC │ │
│ │ < > Wolfson Microelectronics WM8770 CODEC │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└─────────────────────────────────────────────────────────────────────────────────────┘
</pre>

==== CAN bus support ====
Make sure to enable generic CAN bus support under '''Networking support ---> CAN bus subsystem support'''.

In the kernel configuration menu choose '''Networking support ---> CAN bus subsystem support ---> CAN Device Drivers''' submenu and enable:
* Platform CAN drivers with Netlink support
* Bosch C_CAN/D_CAN devices
** Generic Platform Bus based C_CAN/D_CAN driver
<pre>
┌──────────────────────────────── CAN Device Drivers ─────────────────────────────────┐
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ < > Virtual Local CAN Interface (vcan) │ │
│ │ < > Serial / USB serial CAN Adaptors (slcan) │ │
│ │ <M> Platform CAN drivers with Netlink support │ │
│ │ [*] CAN bit-timing calculation │ │
│ │ [ ] Enable LED triggers for Netlink based drivers │ │
│ │ < > TI High End CAN Controller │ │
│ │ < > Support for Freescale FLEXCAN based chips │ │
│ │ < > Aeroflex Gaisler GRCAN and GRHCAN CAN devices │ │
│ │ < > Renesas R-Car CAN controller │ │
│ │ < > Philips/NXP SJA1000 devices ---- │ │
│ │ <M> Bosch C_CAN/D_CAN devices ---> │ │
│ │ < > Bosch M_CAN devices │ │
│ │ < > Bosch CC770 and Intel AN82527 devices ---- │ │
│ │ CAN SPI interfaces ---> │ │
│ │ CAN USB interfaces ---> │ │
│ │ < > Softing Gmbh CAN generic support │ │
│ │ [ ] CAN devices debugging messages │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────────────────────┤
│ <Select> < Exit > < Help > < Save > < Load > │
└─────────────────────────────────────────────────────────────────────────────────────┘
</pre>

== See also ==
* [[CM-T43: Linux: Manual Installation]]
* [[CM-T43: Linux: Debian]]

[[Category:Linux]]
[[Category:CM-T43]]

CM-T43: Linux: Package contents

2016-06-29T11:26:09Z

Nikita: /* utilities */

== Layout ==
<pre>
cm-t43-linux
├── images
│ ├── bootscr.img
│ ├── debian-image.tar.bz2
│ ├── am437x-sb-som-t43.dtb
│ ├── kernel.img
│ ├── ramdisk.img
│ └── zImage-cm-t43
├── kernel
│ ├── linux-4.4.13-cm-t43-5.config
│ ├── linux-4.4.13-cm-t43-5.patch
│ ├── modules-4.4.13-cm-t43-5.tar.bz2
│ ├── zImage-4.4.13-cm-t43-5.bin
│ ├── patches
│ │ ├── 0001-ARM-dts-cm-t43-add-support-for-cm-t43.patch
│ │ ├── ...
│ │ └── 0027-Linux-v4.4.13-cm-t43-5.patch
│ └── zImage-4.1.15-cl-som-imx7-2.0.bin
├── README.txt
├── utilities
│ ├── bootscr.src
│ ├── eeprom-util
│ │ ├── eeprom-util
│ │ ├── eeprom-util-static
│ │ └── eeprom-util-v2.1-sources.tar.gz
│ └── tftpd32.zip
└── version.txt
</pre>

== version.txt ==
The contents of the {{filename|version.txt}} identifies the package version.

== images ==
* {{filename|debian-image.tar.bz2}} - archive of the Debian root file system
* {{filename|bootscr.img}} - U-Boot script used for image installation
* {{filename|am437x-sb-som-t43.dtb}} - SB-SOM-T43 Device Tree binary
* {{filename|kernel.img}} - Kernel image required for installation onto the eMMC
* {{filename|ramdisk.img}} - Ramdisk image required for installation onto the eMMC
* {{filename|zImage-cm-t43}} - ready to run Linux kernel image binary for CM-T43

== kernel ==
* {{filename|linux-4.4.13-cm-t43-5.config}} - Linux kernel 4.4.13-cm-t43-5 configuration file
* {{filename|linux-4.4.13-cm-t43-5.patch}} - patch vs. [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=ba760d4302e4fce130007b8bdbce7fcafc9bd9a9 Linux kernel 4.4.13] with support for CM-T43 peripherals
* {{filename|modules-4.4.13-cm-t43-5.tar.bz2}} - archive of pre-compiled modules for Linux kernel version 4.4.13-cm-t43-5
* {{filename|zImage-4.4.13-cm-t43-5.bin}} - ready to run Linux kernel version 4.4.13-cm-t43-5 for CM-T43
* {{filename|patches}} - ordered collection of patches, that form the single patch above ({{filename|linux-4.4.13-cm-t43-5.patch}})

== utilities ==
The {{filename|utilities}} directory contains miscellaneous utilities useful for development
* {{filename|bootscr.src}} - U-Boot script source used for loading kernel and ramdisk images from MMC/SD card or USB storage device
* {{filename|eeprom-util}} - CompuLab EEPROM utility for reading information found inside the EEPROM on CompuLab boards
* {{filename|tftpd32.zip}} - TFTP server for Windows users

[[Category:Linux|Getting started]]
[[Category:CM-T43|Linux: Getting started]]

CM-T43: Linux: Getting started

2016-06-29T11:23:02Z

Nikita: CM-T43: Linux: Getting started moved to CM-T43: Linux: Manual Installation

#REDIRECT [[CM-T43: Linux: Manual Installation]]

CM-T43: Linux: Manual Installation

2016-06-29T11:23:02Z

Nikita: CM-T43: Linux: Getting started moved to CM-T43: Linux: Manual Installation

== Introduction ==
This article provides an introduction on how to install the Debian example root filesystem image on the CompuLab CM-T43 System-on-Module / Computer-on-Module internal storage.

== Preparation steps ==
* Obtain a PC workstation with a serial communication port.
* For networked installation you need to install a TFTP server on the host PC. For Windows machines we recommend [http://tftpd32.jounin.net/ TFTPD32] included in the Linux package for CM-T43 (link below).
* Download the Linux package for CM-T43 from [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres CompuLab website]. Unzip the package to a directory on your host workstation.
* All image files mentioned below can be found in the {{filename|images}} subdirectory.
* Connect the host PC to the SB-SOM-T43 base-board (connector P8) via the serial cable supplied with the evaluation kit.
* Start terminal emulation software on your PC. Set baud rate to 115200 bps, 8 bit per frame, 1 stop bit, no parity, no flow control.
* Turn on the CM-T43 evaluation system. The U-Boot boot-loader will start and you will get a command prompt.
*: {{Note|If the boot settings of your CM-T43 are different than default, you may need to press and hold '''Ctrl-C''' while turning the CM-T43 on, in order to get command prompt.}}

== Boot into the installation environment (ramdisk) ==
The first step in CM-T43 Linux installation is starting the installation environment (Linux kernel and Ramdisk image).
This can be done using one of the following media:
* [[#Using installation environment on MMC/SD card|MMC/SD card]]
* [[#Using installation environment from USB storage device|USB storage device]]
* [[#Using installation environment from TFTP server|Network TFTP server]]

=== Using installation environment on MMC/SD card ===
* Copy {{filename|kernel.img}}, {{filename|am437x-sb-som-t43.dtb}}, {{filename|ramdisk.img}} and {{filename|bootscr.img}} from [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres Linux package for CM-T43] to the root directory on the first partition of the MMC/SD card.
* Insert the MMC/SD card into the MMC/SD socket (P9) on the SB-SOM-T43 baseboard.
Use the following U-Boot commands to start installation environment boot:
<pre>
CM-T43 # mmc dev 0
CM-T43 # mmc rescan
CM-T43 # load mmc 0 0x82000000 bootscr.img
CM-T43 # source 0x82000000
</pre>
* Continue to the [[#Install Kernel and Debian Linux Images | Install Kernel and Debian Linux Images]] section.

=== Using installation environment from USB storage device ===
* Copy {{filename|kernel.img}}, {{filename|am437x-sb-som-t43.dtb}}, {{filename|ramdisk.img}} and {{filename|bootscr.img}} from [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres Linux package for CM-T43] to the root directory on the first partition of the USB storage device.

* Insert USB storage device into SB-SOM-T43 USB port (P6 or P26).
* Remove MMC/SD card from the MMC/SD socket (P9) on the SB-SOM-T43 baseboard.
* Use the following U-Boot commands to start installation environment boot:
<pre>
CM-T43 # usb start
CM-T43 # load usb 0 0x88000000 am437x-sb-som-t43.dtb
CM-T43 # load usb 0 0x82000000 kernel.img
CM-T43 # load usb 0 0x88080000 ramdisk.img
CM-T43 # setenv bootargs "root=/dev/ram0 rw ramdisk_size=16384 console=ttyO0,115200n8 vram=16M ip=dhcp"
CM-T43 # bootz 0x82000000 0x88080000 0x88000000
</pre>

* Continue to the [[#Install Kernel and Debian Linux Images | Install Kernel and Debian Linux Images]] section.

=== Using installation environment from TFTP server ===
* Connect the SB-SOM-T43 Ethernet port (P21) to your local network.
* Put {{filename|kernel.img}}, {{filename|am437x-sb-som-t43.dtb}}, and {{filename|ramdisk.img}} from [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres Linux package for CM-T43] to a location accessible by the TFTP server:
*: - On Windows machine: copy {{filename|kernel.img}}, {{filename|am437x-sb-som-t43.dtb}}, and {{filename|ramdisk.img}} to the same folder and point the TFTP server to that folder.
*: - On Linux machine: copy {{filename|kernel.img}}, {{filename|am437x-sb-som-t43.dtb}}, and {{filename|ramdisk.img}} to TFTP server root directory, usually {{filename|/tftpboot}} or {{filename|/tftproot}}.

* You can use U-Boot {{cmd|dhcp}} command to obtain IP address
<pre>
CM-T43 # dhcp
</pre>
:or manually set {{parameter|ipaddr}} environment variable:
<pre>
CM-T43 # setenv ipaddr <CM-T43 ip address>
</pre>
* Use the following U-Boot commands to start installation environment boot:
<pre>
CM-T43 # setenv bootargs "root=/dev/ram0 rw ramdisk_size=16384 console=ttyO0,115200n8 vram=16M ip=dhcp"
CM-T43 # tftpboot 0x88000000 am437x-sb-som-t43.dtb
CM-T43 # tftpboot 0x82000000 kernel.img
CM-T43 # tftpboot 0x88080000 ramdisk.img
CM-T43 # bootz 0x82000000 0x88080000 0x88000000
</pre>

* Continue to the [[#Install Kernel and Debian Linux Images | Install Kernel and Debian Linux Images]] section.

=== Install Kernel and Debian Linux Images ===
After the ramdisk image is loaded the Linux login prompt will appear. Login as {{parameter|root}} into the system.
<pre>
compulab login: root
</pre>

==== Mount the installation source media ====

The next step is installing the kernel and Debian Linux images.
One of the following media can be used as a source for installation:
* [[#Mount an MMC/SD Card|MMC/SD Card]]
* [[#Mount a USB Storage Device|USB storage device]]
* [[#Mount an NFS drive|NFS drive]]

===== Mount an MMC/SD Card =====
* Copy the {{filename|zImage-cm-t43}}, {{filename|am437x-sb-som-t43.dtb}} and the {{filename|debian-image.tar.bz2}} from the [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres Linux package for CM-T43] to the root directory of any partition on the MMC/SD card. The partition can be formatted either ext2/3/4 or FAT file system.
* Insert the MMC/SD card into the SD socket (P9) on the SB-SOM-T43.
* The MMC/SD card is mounted automatically under /media/mmcblk0pX. Where X is the partition number.
* If for some reason the MMC/SD card hasn't been mounted automatically, use the following mount command:
<pre>
root@compulab:~# mkdir -p /media/mmcblk0pX && mount /dev/mmcblk0pX /media/mmcblk0pX
</pre>
* Continue to the [[#Install Images on eMMC | Install Images on eMMC]] section.

===== Mount a USB Storage Device =====
* Copy the {{filename|zImage-cm-t43}}, {{filename|am437x-sb-som-t43.dtb}} and the {{filename|debian-image.tar.bz2}} from [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres Linux package for CM-T43] to the root directory of any partition on the USB storage device.
* Plug the USB storage device to any USB host port (P6 or P26) on the SB-SOM-T43.
* The USB device is mounted automatically under /media/sdXY. Where X is the device letter and Y is the partition number.
* If for some reason the USB storage device hasn't been mounted automatically, use the following mount command:
<pre>
root@compulab:~# mkdir -p /media/sdXY && mount /dev/sdXY /media/sdXY
</pre>
* Continue to the [[#Install Images on eMMC | Install Images on eMMC]] section.

===== Mount an NFS drive =====
* Connect the SB-SOM-T43 Ethernet port (P21) to your local network.
* Copy the {{filename|zImage-cm-t43}}, {{filename|am437x-sb-som-t43.dtb}} and the {{filename|debian-image.tar.bz2}} from the [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres Linux package for CM-T43] to a directory exported through NFS.
* During Ramdisk image booting the CM-T43 attempts to obtain an IP address using DHCP. If from some reason the IP address has not been obtained, use the following commands to obtain IP address for the CM-T43:
** Obtain IP using DHCP:<pre>root@compulab:~# ifup eth0</pre>
** If there is no DHCP server on the network, you can set a static IP address using {{cmd|ifconfig}}:<pre>root@compulab:~# ifconfig eth0 <ip address></pre>
* Mount the NFS share containing the {{filename|zImage-cm-t43}}, {{filename|am437x-sb-som-t43.dtb}} and the {{filename|debian-image.tar.bz2}} files:
<pre>
root@compulab:~# mount -o nolock <host ip>:/path/to/nfs/share /mnt/net
</pre>

==== Install Images ====
* In this subsection the term {{filename|/mount/point}} can be:
** {{filename|/mnt/net}} if NFS is used
** {{filename|/media/mmcblk0pY}} if an MMC/SD card is used, where Y is the partition number.
** {{filename|/media/sdXY}} if USB storage is used, where X is the USB drive letter and Y is the partition number.

===== Install Images on eMMC =====
* Create two partitions for the Linux kernel (FAT32 100M) and root file system (EXT4 the rest of the disk) on the eMMC.
*: {{note|If an SD-Card is inserted in the SD card socket, eMMC will be enumerated as /dev/mmcblk1.<br>If an SD-Card is not inserted in the SD card socket, eMMC will be enumerated as /dev/mmcblk0. In the following instructions /dev/mmcblkX(p1,p2) refers to the eMMC.}}
<pre>
root@compulab:~# echo -e "n\np\n1\n2048\n204800\na\n1\nt\nc\nn\np\n2\n204801\n\nw\neof\n" | fdisk -u /dev/mmcblkX
</pre>
* Refresh the device nodes:
<pre>
root@compulab:~# mdev -s && umount /dev/mmcblkXp1 && umount /dev/mmcblkXp2
</pre>
* Format the first partition with FAT32 file system:
<pre>
root@compulab:~# mkfs.vfat -n boot /dev/mmcblkXp1
</pre>
* Format the second partition with EXT4 file system:
<pre>
root@compulab:~# mkfs.ext4 /dev/mmcblkXp2
</pre>
* Mount both partitions:
<pre>
root@compulab:~# mkdir -p /media/mmcblkXp1 && mount /dev/mmcblkXp1 /media/mmcblkXp1
root@compulab:~# mkdir -p /media/mmcblkXp2 && mount /dev/mmcblkXp2 /media/mmcblkXp2
</pre>
* Copy the {{filename|zImage-cm-t43}} and the {{filename|am437x-sb-som-t43.dtb}} to the first (FAT) partition:
<pre>
root@compulab:~# cp /mount/point/zImage-cm-t43 /mount/point/am437x-sb-som-t43.dtb /media/mmcblkXp1 && sync
</pre>
* Extract the content of {{filename|debian-image.tar.bz2}} onto the second partition:
<pre>
root@compulab:~# tar --numeric-owner -xvpjf /mount/point/debian-image.tar.bz2 -C /media/mmcblkXp2 && sync
</pre>
* Remove MMC/SD card from SB-SOM-T43 MMC/SD card socket (if used for installation) and reboot the module.

===== Install Images on NAND =====
* Format the NAND flash kernel partition and write the kernel image onto it:
<pre>
root@compulab:~# flash_erase /dev/mtd3 0 0
root@compulab:~# nandwrite -p /dev/mtd3 /mount/point/zImage-cm-t43
</pre>
* Format the NAND flash dtb partition and write the device tree image onto it:
<pre>
root@compulab:~# flash_erase /dev/mtd4 0 0
root@compulab:~# nandwrite -p /dev/mtd4 /mount/point/am437x-sb-som-t43.dtb
</pre>
* Format the NAND flash root filesystem partition:
<pre>
root@compulab:~# ubiformat /dev/mtd5
</pre>
* Attach the NAND flash root filesystem partition:
<pre>
root@compulab:~# ubiattach -m 5 -d 0
</pre>
* Create a ubi volume and name it "rootfs":
<pre>
root@compulab:~# ubimkvol /dev/ubi0 -m -N rootfs
</pre>
* Mount the ubi volume:
<pre>
root@compulab:~# mkdir -p /media/rootfs && mount -t ubifs ubi0:rootfs /media/rootfs
</pre>
* Extract the content of {{filename|debian-image.tar.bz2}} onto the /media/rootfs:
<pre>
root@compulab:~# tar --numeric-owner -xpf /mount/point/debian-image.tar.bz2 -C /media/rootfs && sync
</pre>
* Unmount the ubi volume:
<pre>
root@compulab:~# umount /media/rootfs
</pre>
* Reboot the CM-T43 Evaluation system.

== After Installation ==

=== Boot from eMMC ===
* Set the {{parameter|bootargs}} environment variable:
<pre>
CM-T43 # setenv bootargs "root=/dev/mmcblkXp2 rw rootfstype=ext4 rootwait console=ttyO0"
</pre>
* Set the {{parameter|bootcmd}} environment variable and save the environment:
<pre>
CM-T43 # setenv bootcmd 'mmc dev 1 && mmc rescan && load mmc 1 ${loadaddr} zimage-cm-t43 && load mmc 1 ${fdtaddr} am437x-sb-som-t43.dtb && bootz ${loadaddr} - ${fdtaddr}'
CM-T43 # saveenv
</pre>
* To boot Linux, type:
<pre>
CM-T43 # boot
</pre>

=== Boot from NAND ===
* Set the {{parameter|bootargs}} environment variable:
<pre>
CM-T43 # setenv bootargs "console=ttyO0,115200n8 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=rootfs"
</pre>
* Set the {{parameter|bootcmd}} environment variable and save the environment:
<pre>
CM-T43 # setenv bootcmd 'nand read ${loadaddr} 0 980000 && nand read ${fdtaddr} 980000 80000 && bootz ${loadaddr} - ${fdtaddr}'
CM-T43 # saveenv
</pre>
* To boot Linux, type:
<pre>
CM-T43 # boot
</pre>

== See also ==

* [[CM-T43: Linux: Debian]]
* [[CM-T43: Linux: Kernel]]
* [[Linux: Development for ARM modules]]

[[Category:Linux|Getting started]]
[[Category:CM-T43|Linux: Getting started]]

CM-T43: Linux: Known Issues

2016-06-29T08:27:25Z

Nikita:

{{IssueCategory|Package Manager|
* Public key problem is reported while retrieving new lists of packages:
<pre>
root@cm-debian:~# apt-get update
Get:1 http://ftp.debian.org jessie Release.gpg [2390 B]
Get:2 http://ftp.debian.org jessie Release [168 kB]
...
Fetched 16.0 MB in 24s (662 kB/s)
Reading package lists... Done
W: There is no public key available for the following key IDs:
7638D0442B90D010
</pre>
:'''Solution :''' Install ''debian-keyring'' and ''debian-archive-keyring'' packages.
: '''Note :''' This operation requires ~50MB of additional disk space.
<pre>
root@cm-debian:~# apt-get install debian-keyring debian-archive-keyring
</pre>
}}

[[Category:Linux]]
[[Category:CM-T43]]

CM-T43: U-Boot: Firmware Overview

2016-02-23T08:34:48Z

Nikita: /* Introduction */

== Introduction ==
This article describes the firmware for CM-T43 system-on-module.
CM-T43 firmware consists of two components: Secondary Program Loader (SPL) and U-Boot.
SPL is the bootstrap utility invoked by the CPU internal boot ROM code of the AM437x SoC.
The AM437x boot ROM tries to boot SPL from either SD card, or SPI flash, as determined by the hardware boot selector).
SPL performs minimal hardware initializations and loads U-Boot from the same boot storage device.
U-Boot initializes hardware modules necessary for system boot and loads the operating system.

=== Package contents ===

==== images ====
* {{filename|cm-t43-firmware}} - U-Boot and SPL (normal and byteswapped) binaries combined to a single binary
* {{filename|MLO}} - SPL binary
* {{filename|u-boot.img}} - U-Boot binary

==== u-boot ====
* {{filename|spl-2016.01-cm-t43-1.bin}} - SPL binary
* {{filename|spl-2016.01-cm-t43-1.bin.byteswap}} - Byteswapped SPL binary for SPI-flash installation
* {{filename|u-boot-2016.01-cm-t43-1.bin}} - U-Boot binary
* {{filename|u-boot-2016.01-cm-t43-1.patch}} - patch vs. v2016.01 mainline U-Boot
* {{filename|patches}} - ordered collection of patches, that form the single patch above (u-boot-2016.01-cm-t43-1.patch)

== SPL ==
SPL is responsible for initial clock setup, DDR initialization and boot media controller initialization.
It is loaded into the CPU internal SRAM immediately after system reset.
After basic hardware setup, SPL loads the U-Boot bootloader into the system RAM and transfers control to the U-Boot bootloader.
SPL resides at offsets 0x0, 0x10000, 0x20000, (a total of 3 copies) from the start of the SPI flash, and at offset 0x80000 from the start of an SD-card.

== U-Boot ==
U-Boot is the bootloader used on CM-T43. It allows flexible selection of operating system boot modes, provides scripting facilities and command line interface through a serial port.
U-Boot allows booting operating system from the on-board NAND flash, the on-board eMMC, or the network (TFTP/NFS server).
U-Boot resides at offset 0x40000 from the start of the SPI flash, and at offset 0x80000 from the start of an SD-card.

Please consult [[U-Boot quick reference]] and [http://www.denx.de/wiki/U-Boot/Documentation U-Boot project documentation] for U-Boot features and commands description.

=== U-Boot environment ===
U-Boot environment resides on the SPI flash, regardless of the boot source. The environment resides at offset 0xC0000 from the start of SPI flash, and its size is 16KiB.

== Boot sources ==
CM-T43 can boot from either a micro SD card, or the on-board SPI flash.

The following sections describe the layout of each storage type.

=== Default SPI flash mapping ===
{| cellpadding="3" border="1" style="border: 1px solid rgb(85, 85, 85); border-collapse: collapse;"
! Offset
! Description
! Size
|-
| 0KB
| SPL
| 256KB
|-
| 256KB
| U-Boot
| 448KB
|-
| 704KB
| Reserved
| 64KB
|-
| 768KB
| U-Boot environment
| 256KB
|-
| 1MB
| Splash image
| Remaining SPI flash space
|}

=== Default SD card mapping ===
{| cellpadding="3" border="1" style="border: 1px solid rgb(85, 85, 85); border-collapse: collapse;"
! Offset
! Description
! Size
|-
| 0KB
| Reserved/MBR
| 512KB
|-
| 512KB
| SPL
| 64KB
|-
| 576KB
| U-Boot
| 448KB
|-
| 1MB
| Remaining SD-card space
| Remaining SD-card space
|}

== See also ==

* [[CM-T43: U-Boot: Firmware Update]]
* [[U-Boot quick reference]]
* [[U-Boot images]]
* [http://www.denx.de/wiki/U-Boot/Documentation U-Boot documentation]

[[Category:U-Boot|U-Boot]]
[[Category:CM-T43]]

CM-T43: U-Boot: Firmware Update

2016-02-18T13:01:12Z

Nikita: /* Flashing images */

== Introduction ==
The CM-T43 firmware consists of two components: Secondary Program Loader (SPL) and U-Boot, both provided on a single binary image {{filename|cm-t43-firmware}}.
This article describes the firmware update process for CM-T43 system-on-module product.

== Preliminary setup ==
* Make sure to power off the CM-T43 evaluation platform.
* Connect the host PC to the SB-SOM-T43 base-board (connector P8) via the serial cable supplied with the evaluation kit.
* Start terminal emulation software on your PC. Set baud rate to 115200 bps, 8 bit per frame, 1 stop bit, no parity, no flow control.
* Turn on the CM-T43 evaluation system. The U-Boot boot-loader will start and you will get a command prompt in the terminal window.
{{Note|If the boot settings of your CM-T43 are different than default, you may need to press and hold ^C while turning the CM-T43 on, in order to get command prompt.}}

== Updating Firmware on the SPI flash ==
CM-T43 firmware can be updated from an SD card, usb storage, or using network TFTP download.
Both methods are performed from the U-Boot command line and include following common steps:
# Loading binary image from the selected media to the CM-T43 DRAM
# Flashing image to the on-board SPI flash

=== Updating from SD card ===
* Copy the firmware binary image {{filename|cm-t43-firmware}} from [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres U-Boot package for CM-T43] to the root directory of the SD card.
* Insert the SD card into the P9 socket on SB-SOM-T43.
* Start the U-Boot MMC subsystem:
<pre>
# mmc dev 0
# mmc rescan
</pre>
* Check that the storage device is ready:
<pre>
# ls mmc 0
</pre>
* Load the firmware binary into the memory:
<pre>
# load mmc 0 80a00000 cm-t43-firmware
</pre>
* Proceed to [[#Flashing images|Flashing images]] section

=== Updating from USB storage ===
* Copy the firmware binary image {{filename|cm-t43-firmware}} from [http://compulab.co.il/products/computer-on-modules/cm-t43/#devres U-Boot package for CM-T43] to the root directory of the USB storage device.
* Plug the USB storage device into the USB host connector (P6) on SB-SOM-T43.
* Start the U-Boot USB subsystem:
<pre>
# usb start
</pre>
* Check that the storage device is ready:
<pre>
# ls usb 0
</pre>
* Load the firmware binary into the memory:
<pre>
# load usb 0 80a00000 cm-t43-firmware
</pre>
* Proceed to [[#Flashing images|Flashing images]] section

=== Updating from TFTP server ===
* Setup a TFTP server
* Put the firmware binary image {{filename|cm-t43-firmware}} in the root directory of the TFTP server
* Setup U-Boot networking:
: for dynamic IP configuration:
<pre>
# dhcp
</pre>
: or for static IP configuration:
<pre>
# setenv ipaddr <ip address>
</pre>
* Setup the TFTP server ip address:
<pre>
# setenv serverip <server ip>
</pre>
* Download the firmware binary into the memory:
<pre>
# tftp 80a00000 cm-t43-firmware
</pre>
* Proceed to [[#Flashing images|Flashing images]] section

=== Flashing images ===
* Make U-Boot probe the on-board SPI flash:
<pre>
# sf probe 0
</pre>
* Erase the on-board SPI flash:
<pre>
# sf erase 0 c0000
</pre>
* Write the firmware image into the on-board SPI flash:
<pre>
# sf write 80a00000 0 c0000
</pre>
* Reset the CM-T43 evaluation platform.

== Installing firmware on an SD card ==
CM-T43 system-on-module uses SPI flash as its main boot storage.
In addition to the on-board SPI flash, the CM-T43 can also boot from an SD-card.
The firmware can be installed as either raw data written into the SD-card, or as a file located in a FAT formatted partition.

=== Installing firmware as raw data ===
* Make sure that the SD card partitions do not start in the first 1MB of the SD card. Otherwise, the partitions may be overwritten by this procedure.
* Insert the SD card into the workstation card reader
* The SD card will be identified as {{filename|/dev/sdX}}, where X is the SD card drive letter.
* Run the following command:
<pre>
dd if=cm-t43-firmware of=/dev/sdX bs=1K seek=320 oflag=dsync
</pre>

=== Installing firmware as files in a FAT formatted partition ===
* Copy the file {{filename|MLO}} located in the images folder into the SD-card partition.
* Copy the file {{filename|u-boot.img}} located in the images folder into the SD-card partition.

== See also ==

* [[CM-T43: U-Boot: Firmware Overview]]
* [[U-Boot quick reference]]
* [[U-Boot images]]
* [[CM-T43: Linux: Getting started|Getting started with Linux on CM-T43]]
* [http://www.denx.de/wiki/U-Boot/Documentation U-Boot documentation]
* [http://processors.wiki.ti.com/index.php/SD/MMC_format_for_OMAP3_boot SD/MMC format for OMAP3 boot]

[[Category:U-Boot]]
[[Category:CM-T43]]

CM-T43: Linux: Known Issues

2016-02-14T14:35:24Z

Nikita:

{{IssueCategory|RTC|
* RTC time and date is not maintained when unit is unplugged from power supply, even if an RTC backup battery is installed.
:'''Fixed in U-Boot v2016.01-cm-t43-1'''
}}

{{IssueCategory|OPP|
* U-Boot versions 0.97 and below do not modify the PMIC voltages. The PMIC retains its settings between resets, and as a result if CM-T43 is switched to a low performance OPP (below 800 Mhz), on reset U-Boot will be using low performance voltage settings for a high performance CPU frequency and may not finish booting.
:'''Fixed in U-Boot v2016.01-cm-t43-1'''
}}

[[Category:Linux]]
[[Category:CM-T43]]

CM-T43: U-Boot: Building Images

2016-02-14T14:23:02Z

Nikita: /* Snapshot download */

== Overview ==
CM-T43 firmware consists of two components: Secondary Program Loader (SPL) and U-Boot.
Both components are based on [http://www.denx.de/wiki/U-Boot/WebHome U-Boot] source code.
SPL is the bootstrap utility invoked by the CPU internal boot ROM code of the AM437x SoC.
SPL performs minimal hardware initialization and loads U-Boot from the same boot device.
U-Boot initializes hardware modules necessary for system boot and loads the operating system.

== Building Firmware images for CM-T43 ==
=== Getting U-Boot sources ===
There are various ways to get U-Boot sources that can be used as a baseline for CM-T43 SPL and U-Boot.
For instance, a copy of the U-Boot mainline git tree can be created or a the sources snapshot can be downloaded.
We assume that you have created {{filename|/home/development/cm-t43/u-boot}} directory for CM-T43 U-Boot development.

==== Snapshot download ====
* Download [http://git.denx.de/?p=u-boot.git;a=snapshot;h=fa85e826c16b9ce1ad302a57e9c4b24db0d8b930 v2016.01] snapshot with your web browser.
* Extract the downloaded archive {{filename|u-boot-fa85e82.tar.gz}}
<pre>
cd /home/development/cm-t43/u-boot
tar xvf /path/to/downloaded/u-boot-fa85e82.tar.gz
mv u-boot u-boot-cm-t43
</pre>
: This will create {{filename|/home/development/cm-t43/u-boot/u-boot-cm-t43}} directory containing U-Boot source code tree.
* Apply the CM-T43 patch
<pre>
cd /home/development/cm-t43/u-boot/u-boot-cm-t43
patch -p1 < /path/to/cm-t43-u-boot-package/u-boot/u-boot-v2016.01-cm-t43-1.patch
</pre>

==== Git clone ====
* Install [http://git-scm.com/ git] version control system.
* Create a clone of U-Boot tree
<pre>
cd /home/development/cm-t43/u-boot
git clone git://git.denx.de/u-boot.git u-boot-cm-t43
cd /home/development/cm-t43/u-boot/u-boot-cm-t43
</pre>
* Create a branch for CM-T43 development. The CM-T43 patches are generated vs. v2016.01 tag (fa85e826c16b9ce1ad302a57e9c4b24db0d8b930 commit) in the U-Boot tree. It is recommended to use exactly the same baseline to avoid merge conflicts.
<pre>
git checkout -b cm-t43-dev v2016.01
</pre>
* Apply the CM-T43 patch
<pre>
git apply /path/to/cm-t43-u-boot-package/u-boot/u-boot-v2016.01-cm-t43-1.patch
</pre>

=== Building the firmware images ===
* First, compile both SPL and U-Boot. The following commands create the {{filename|MLO}}, {{filename|MLO.byteswap}}, and {{filename|u-boot.img}} binaries (along with other image types):
<pre>
export ARCH=arm
export CROSS_COMPILE=arm-none-linux-eabi-
make mrproper
make cm_t43_defconfig && make
</pre>
* Create the combined image for SPI-flash installation by creating a 0xFF initialized 768KB {{filename|cm-t43-firmware-sf}} file, and writing the {{filename|MLO.byteswap}}, {{filename|MLO}}, and {{filename|u-boot.img}} data to the appropriate offsets within the {{filename|cm-t43-firmware}} file. The {{filename|MLO.byteswap}} file will be written into the first 3 64KB segments to allow the bootROM to find it in 3 different places, thus improving reliability. The non-byteswapped {{filename|MLO}} will occupy the 4th 64KB segment, thus allowing the same {{filename|cm-t43-firmware}} to be written into SD-card, for which the bootROM requires non-byteswapped data. Finally, {{filename|u-boot.img}} is written to the 256KB offset, right at the end of the 4 MLO segments.
<pre>
dd if=/dev/zero count=768 bs=1K | tr '\000' '\377' > cm-t43-firmware
dd if=MLO.byteswap of=cm-t43-firmware bs=1k seek=0 conv=notrunc
dd if=MLO.byteswap of=cm-t43-firmware bs=1k seek=64 conv=notrunc
dd if=MLO.byteswap of=cm-t43-firmware bs=1k seek=128 conv=notrunc
dd if=MLO of=cm-t43-firmware bs=1k seek=192 conv=notrunc
dd if=u-boot.img of=cm-t43-firmware bs=1k seek=256 conv=notrunc
</pre>
* You can now install the {{filename|cm-t43-firmware}} file into the CM-T43 SPI flash or SD-card.

== See also ==

* [[CM-T43: U-Boot: Firmware Overview]]
* [[CM-T43: U-Boot: Firmware Update]]
* [[U-Boot quick reference]]
* [[U-Boot images]]
* [http://www.denx.de/wiki/U-Boot/Documentation U-Boot documentation]

[[Category:U-Boot]]
[[Category:CM-T43]]

CM-T43: U-Boot: Firmware Overview

2016-02-14T13:30:18Z

Nikita: /* See also */

== Introduction ==
This article describes the firmware for CM-T43 system-on-module.
CM-T43 firmware consists of two components: Secondary Program Loader (SPL) and U-Boot.
SPL is the bootstrap utility invoked by the CPU internal boot ROM code of the AM437x SoC.
The AM437x boot ROM tries to boot SPL from either SD card, or SPI flash, as determined by the hardware boot selector).
SPL performs minimal hardware initializations and loads U-Boot from the same boot storage device.
U-Boot initializes hardware modules necessary for system boot and loads the operating system.

=== Package contents ===

==== images ====
* {{filename|cm-t43-firmware}} - U-Boot and SPL (normal and byteswapped) binaries combined to a single binary

==== u-boot ====
* {{filename|spl-2016.01-cm-t43-1.bin}} - SPL binary
* {{filename|spl-2016.01-cm-t43-1.bin.byteswap}} - Byteswapped SPL binary
* {{filename|u-boot-2016.01-cm-t43-1.bin}} - U-Boot binary
* {{filename|u-boot-2016.01-cm-t43-1.patch}} - patch vs. v2016.01 mainline U-Boot
* {{filename|patches}} - ordered collection of patches, that form the single patch above (u-boot-2016.01-cm-t43-1.patch)

== SPL ==
SPL is responsible for initial clock setup, DDR initialization and boot media controller initialization.
It is loaded into the CPU internal SRAM immediately after system reset.
After basic hardware setup, SPL loads the U-Boot bootloader into the system RAM and transfers control to the U-Boot bootloader.
SPL resides at offsets 0x0, 0x10000, 0x20000, (a total of 3 copies) from the start of the SPI flash, and at offset 0x80000 from the start of an SD-card.

== U-Boot ==
U-Boot is the bootloader used on CM-T43. It allows flexible selection of operating system boot modes, provides scripting facilities and command line interface through a serial port.
U-Boot allows booting operating system from the on-board NAND flash, the on-board eMMC, or the network (TFTP/NFS server).
U-Boot resides at offset 0x40000 from the start of the SPI flash, and at offset 0x80000 from the start of an SD-card.

Please consult [[U-Boot quick reference]] and [http://www.denx.de/wiki/U-Boot/Documentation U-Boot project documentation] for U-Boot features and commands description.

=== U-Boot environment ===
U-Boot environment resides on the SPI flash, regardless of the boot source. The environment resides at offset 0xC0000 from the start of SPI flash, and its size is 16KiB.

== Boot sources ==
CM-T43 can boot from either a micro SD card, or the on-board SPI flash.

The following sections describe the layout of each storage type.

=== Default SPI flash mapping ===
{| cellpadding="3" border="1" style="border: 1px solid rgb(85, 85, 85); border-collapse: collapse;"
! Offset
! Description
! Size
|-
| 0KB
| SPL
| 256KB
|-
| 256KB
| U-Boot
| 448KB
|-
| 704KB
| Reserved
| 64KB
|-
| 768KB
| U-Boot environment
| 256KB
|-
| 1MB
| Splash image
| Remaining SPI flash space
|}

=== Default SD card mapping ===
{| cellpadding="3" border="1" style="border: 1px solid rgb(85, 85, 85); border-collapse: collapse;"
! Offset
! Description
! Size
|-
| 0KB
| Reserved/MBR
| 512KB
|-
| 512KB
| SPL
| 64KB
|-
| 576KB
| U-Boot
| 448KB
|-
| 1MB
| Remaining SD-card space
| Remaining SD-card space
|}

== See also ==

* [[CM-T43: U-Boot: Firmware Update]]
* [[U-Boot quick reference]]
* [[U-Boot images]]
* [http://www.denx.de/wiki/U-Boot/Documentation U-Boot documentation]

[[Category:U-Boot|U-Boot]]
[[Category:CM-T43]]

Linux: Introduction to device trees

2016-02-08T09:34:11Z

Nikita: /* Cross referencing with SoC manual */

= What are device trees? =
A device tree is a data structure that describes the System-on-Module (SoM) hardware: its various hardware components, and their relationship with one another. In the past, such information was hardcoded into the kernel for each SoM, and device trees were invented to curb this practice by providing a standard way to pass hardware description to the kernel. Much like source code, device trees can exist as human readable source files (.dts, .dtsi), or as compiled blobs (.dtb). Before a device tree is passed to the kernel, its source must be compiled into a blob. This compilation happens automatically as part of building the kernel.

= How are device trees structured? =
Device trees contain segments called "nodes". Each node contains information about a hardware component. The contents of each node are dictated by the driver that is responsible for handling the hardware component. The various nodes are organized in a tree-like hierarchy, which reflects the relationship between the hardware components. For example, if we have an i2c bus with multiple devices, the nodes that represent these devices will be sub nodes of the i2c bus node. (NOTE: device nodes can also make direct references to other nodes in the system, so in practice the device tree is more like a device graph).

Device trees can include other device trees. This facilitates modularity of the hardware representation. A common pattern in the ARM world is for the SoC vendor (e.g. TI) to define a device tree that describes the SoC (e.g. AM437x), and the SoM vendor (e.g. CompuLab) would include it in the device tree of a product that is based on the SoC (e.g. CM-T43). The inclusion works in a cascading fashion: if device tree B includes device tree A, the result will have the content of both device trees. However, if both A and B happen to define the same property, the value in device tree B will override the value provided by device tree A. In the opposite case (device tree A includes device tree B), the value from A woulde override the value from B.

* For more information about device tree syntax, visit the official [http://devicetree.org/Device_Tree_Usage Device Tree WiKi] pages and make an overview of a [http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf Device Tree tutorial]
* For information about what content (bindings) should appear in various nodes, see Documentation/devicetree/bindings/ folder in the Linux kernel source code.

= Device tree software support =
In order to use device tree blobs, the kernel must have device tree support compiled in, and the bootloader must have support for passing device tree blobs to the kernel.
In modern Linux kernels, device tree support is ubiquitous. When configuring the kernel for the ARM architecture, the relevant CONFIG options (specifically CONFIG_USE_OF) is selected automatically by the kernel config system.
Device tree support in U-Boot, the bootloader of choice for CompuLab SoMs, can be enabled by defining the CONFIG option CONFIG_OF_LIBFDT in the board config file (usually include/configs/board_name.h).

== Passing device tree blobs to the kernel ==
Passing device tree blobs to the kernel is done using the U-Boot commands bootz (for zImages) and bootm (for uImages). For example:

<pre>
U-Boot# help bootz
bootz - boot Linux zImage image from memory

Usage:
bootz [addr [initrd[:size]] [fdt]]
- boot Linux zImage stored in memory
The argument 'initrd' is optional and specifies the address
of the initrd in memory. The optional argument ':size' allows
specifying the size of RAW initrd.
When booting a Linux kernel which requires a flat device-tree
a third argument is required which is the address of the
device-tree blob. To boot that kernel without an initrd image,
use a '-' for the second argument. If you do not pass a third
a bd_info struct will be passed instead
</pre>

== Modifying device tree blobs ==

Sometimes, a device tree cannot simultaneously represent different versions of the same hardware product. In that case, a choice is made to represent one of the hardware variations, and the bootloader is expected to adjust the device tree before passing it on to the kernel. U-Boot has dedicated commands for modifying the device tree:

<pre>
U-Boot# help fdt
fdt - flattened device tree utility commands

Usage:
fdt addr [-c] <addr> [<length>] - Set the [control] fdt location to <addr>
fdt move <fdt> <newaddr> <length> - Copy the fdt to <addr> and make it active
fdt resize - Resize fdt to size + padding to 4k addr
fdt print <path> [<prop>] - Recursive print starting at <path>
fdt list <path> [<prop>] - Print one level starting at <path>
fdt get value <var> <path> <prop> - Get <property> and store in <var>
fdt get name <var> <path> <index> - Get name of node <index> and store in <var>
fdt get addr <var> <path> <prop> - Get start address of <property> and store in <var>
fdt get size <var> <path> [<prop>] - Get size of [<property>] or num nodes and store in <var>
fdt set <path> <prop> [<val>] - Set <property> [to <val>]
fdt mknode <path> <node> - Create a new node after <path>
fdt rm <path> [<prop>] - Delete the node or <property>
fdt header - Display header info
fdt bootcpu <id> - Set boot cpuid
fdt memory <addr> <size> - Add/Update memory node
fdt rsvmem print - Show current mem reserves
fdt rsvmem add <addr> <size> - Add a mem reserve
fdt rsvmem delete <index> - Delete a mem reserves
fdt chosen [<start> <end>] - Add/update the /chosen branch in the tree
<start>/<end> - initrd start/end addr
NOTE: Dereference aliases by omiting the leading '/', e.g. fdt print ethernet0.
</pre>

= Configuring pinmux settings in device tree =
One of the most common tasks in embedded development is configuring the pinmux settings for the SoC. This task requires cross referencing the SoM manual with the SoC manual, and editing the pinmux section of the SoM device tree. The following instructions describe the process step-by-step for TI SoCs. Adjustments may be needed when dealing with SoCs manufactured by other companies, but the general process is similar.

== Selecting pins for use ==
Compulab provides a detailed reference manual for its SoMs. One of the chapters in each such manual describes the pins which are exported via the SoM connector, listing all of their possible functions, as well as availability (some pins are not usable when certain manufacturing options are selected for the SoM). For example, on the [http://www.compulab.co.il/products/computer-on-modules/cm-t43/#devres CM-T43 reference manual], this information is detailed in chapter 5.5 "Signal Multiplexing Characteristics".

== Cross referencing with SoC manual ==
Having chosen the pins to configure, the next step is to find the address of the register that controls the pins. This is necessary because the way we reference the pin in the kernel is with the address of the register that controls it. On TI SoCs, each pin is named after its mode 0 function. To find the register that controls it, open the SoC TRM, and search for a register called CTRL_CONF_<mode_0_function_name>. The page that describes the register will also list its offset relative to the base address of the control module. This value will be used in the device tree to refer to the pin control register.

== Modifying the device tree ==
The device tree segment that controls the pin mux will look something like this:
<pre>
&am43xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&cm_t43_led_pins>;

spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins = <
AM4372_IOPAD(0x950, PIN_INPUT | MUX_MODE0) /* spi0_sclk.spi0_sclk */
AM4372_IOPAD(0x954, PIN_INPUT | MUX_MODE0) /* spi0_d0.spi0_d0 */
AM4372_IOPAD(0x958, PIN_OUTPUT | MUX_MODE0) /* spi0_d1.spi0_d1 */
AM4372_IOPAD(0x95C, PIN_OUTPUT | MUX_MODE0) /* spi0_cs0.spi0_cs0 */
>;
};
...
}
</pre>

Add a new node for your custom pinmux configuration, and populate it with pinmux settings. For example:

<pre>
&am43xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&cm_t43_led_pins>;

spi0_pins: pinmux_spi0_pins {
pinctrl-single,pins = <
AM4372_IOPAD(0x950, PIN_INPUT | MUX_MODE0) /* spi0_sclk.spi0_sclk */
AM4372_IOPAD(0x954, PIN_INPUT | MUX_MODE0) /* spi0_d0.spi0_d0 */
AM4372_IOPAD(0x958, PIN_OUTPUT | MUX_MODE0) /* spi0_d1.spi0_d1 */
AM4372_IOPAD(0x95C, PIN_OUTPUT | MUX_MODE0) /* spi0_cs0.spi0_cs0 */
>;
};

custom_pins: pinmux_custom_pins {
pinctrl-single,pins = <
/* some pin settings */
/* some other pin settings */
>;
};

...
}
</pre>

=== Specifying pinmux settings ===
The general format for specifying pinmux settings is that each line starts with the pin register offset, and ends with the pin settings. The syntax for specifying this information changes somewhat between SoCs, and even between kernel versions. Because of these differences, the best practice for determining how to specify a custom pinmux configuration is to look at existing examples, such as the pinmux segment in the device tree for your chosen Compulab SoM. The following example describes the pinmux settings format for cm-t43 on a v4.4 kernel, and points out the possible differences that may exist in other SoMs.

The pinmux setting:
<pre>AM4372_IOPAD(0x950, PIN_INPUT | MUX_MODE0)</pre>
This line consists of the following sections:
* AM4372_IOPAD() macro. As the name suggests, this macro is specific to AM4372 SoCs. Other SoCs will have a differently named macro. If a SoC is fairly new, there may not be a macro for it yet, and then the pin configuration will be just the offset and pinmux settings, like so:
<pre>
0x950 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
</pre>
* The pin register offset (0x950). This offset may or may not correspond to the register offset described in the SoC TRM. For example, before the AM4372_IOPAD() macro was defined for the AM437x SoC, it was necessary to subtract 0x800 from the offset listed in the TRM in order to refer to the pin register. For example, if the TRM listed the offset as 0x950, the device tree line controlling the pin actually looked like this:
<pre>
0x150 (PIN_OUTPUT_PULLDOWN | MUX_MODE2)
</pre>
Once the AM4372_IOPAD() macro was defined, this subtraction was no longer necessary, and the value from the TRM had to be used, like so:<pre>
AM4372_IOPAD(0x950, PIN_OUTPUT_PULLDOWN | MUX_MODE2)
</pre>
* Pin settings (PIN_OUTPUT_PULLDOWN | MUX_MODE2). These macros may be named differently in device trees for non-TI SoCs.

[[Category:Linux]]
[[Category:U-Boot]]

CM-T43 TI AM437x Linux

2016-02-07T11:43:53Z

Nikita:

{{summary|
This page contains links to information about Linux kernels, packages and software development for the CompuLab CM-T43 System-on-Module / Computer-on-Module.

CompuLab Linux support for CM-T43 includes modifications of [[CM-T43: Linux: Kernel|Linux kernel]] and [http://www.debian.org/ports/arm/ ARM Debian] port. It is possible to use other embedded Linux distributions and environments with CM-T43.
|Cm-t43-top.jpg|thumb}}
{{Resources Linux
|* [[CM-T43: Linux: Getting started|Getting started with Linux on CM-T43]]
* [[CM-T43: Linux: Debian|Debian Linux for CM-T43]]
* [[CM-T43 TI AM437x Yocto Linux|Yocto Linux for CM-T43]]
|* [[ Linux: Setting up a development environment | Setting up a development environment]]
* [[ Linux: Introduction to Linux development | Introduction to Linux development]]
* [[Linux: Introduction to device trees | Introduction to device trees]]
* [[CM-T43: Linux: Kernel|Linux Kernel for CM-T43]]
* [[Linux: Debian: Minimal ARM filesystem | Minimal Debian ARM filesystem]]
|*[[Support]]
* [[CM-T43: Linux: Known Issues|Known Issues]]
}}

__NOTOC__

{{ChangelogRss| content=
===== 01-Feb-2016, CM-T43 Linux release =====
: Linux kernel 4.2-cm-t43-4 for CM-T43 updates
:- Add CAN bus support
:- Add DVI support
:- Improve WiFi operation
: Documentation
:- Updated multiple articles to comply with the new Linux package

===== 07-Dec-2015, CM-T43 Linux release =====
: Linux kernel 4.2-cm-t43-3.2 for CM-T43 updates
:- Add audio support
:- Add OPP support
:- Update kernel base code to version 4.2
:- Improve Ethernet operation
:- Fix RTC
:- Fix WiFi/Bluetooth start up
: Documentation
:- Updated multiple articles to comply with the new Linux package

===== 06-Jul-2015 =====
: Linux kernel 3.19-cm-t43-2 for CM-T43 updates
:- Added 2nd Ethernet port support
:- Added NAND support
:- Added USB device mode support
:- Added Touchscreen support
:- Added EEPROM support
:- Fix Heartbeat Green LED
: Documentation
:- Added Bluetooth documentation
:- Updated multiple articles to comply with the new Linux package

===== 19-Apr-2015 =====
: Initial release of Linux kernel and Debian Linux Demo image for CM-T43
:- Basic support for the CM-T43 module
:- Green LED support
:- MMC/SD card support
:- eMMC internal storage support
:- USB 2.0 host ports support
:- Ethernet support
:- RTC support
:- Parallel LCD output support
:- WiFi support
}}

[[Category:Linux]]
[[Category:CM-T43]]