wiki.emacinc.com - User contributions [en]

Installing EMAC OE 5.0 SDK

2021-07-28T15:53:01Z

Mgloff:

==Prerequisites==
If you are installing the SDK using the ADT Installer (Automatic Install), dependencies will be automatically installed for the supported distributions: Debian/Ubuntu, Fedora, CentOS, openSUSE. EMAC also provides a [ftp://ftp.emacinc.com/EMAC_Linux/Virtual_LDCs/EMAC_Virtual_LDC.ova pre-configured virtual machine image.]
{{note | Currently the version of Qt Creator installed during the automatic installation does not work on Debian 8}}

If you are installing the SDK manually or using a non-supported distribution, you will have to install the dependencies manually.
==Procedure (Automatic Install)==
<cl>
1. Download the ADT Installer. (Right click, save link as)
* [http://ftp.emacinc.com/EMAC_Linux/SDK/emac_adt_installer EMAC ADT Installer].

* Change to the directory where the ADT Installer was downloaded from the command line:
{{cli | username=developer | hostname=ldc |cd ~/Downloads }}

* Make the file executable:
{{cli | username=developer | hostname=ldc | chmod +x emac_adt_installer }}

* Run ADT Installer script:
{{cli | username=developer | hostname=ldc |./emac_adt_installer }}
The installer will start.

* Watch for errors:
{{clo}}######################################################################### # Met Errors when installing EMAC ADT! Please check log file for details. ######################################################################### {{clos}}

* Enter the development user's password if prompted. Allow the installer to install dependencies.

* Select your board's architecture. Enter '1' for Arm or '2' for x86.
{{clo}}
Please enter the target architecture: 
1. Arm 
2. x86 
board: 
{{clos}}

* The ADT Installer will then display what is to be installed. You may now choose to exit the installation, or continue if the displayed information is correct.

* Once the installation of the sdk completes, the ADT Installer will ask whether or not to install Qt Creator.

{{clo}}

Would you like to install Qt Creator? [y/N]?
{{clos}}
* Qt Creator is the IDE that EMAC provides with our SDK to allow users to easily cross compile projects and upload them to their boards.
* If you chose to install Qt creator, the installer will then ask you whether or not you would like to place the icon on the desktop.

* If the installation finishes, status text will appear:{{clo}}############################################################# # EMAC ADT has been successfully installed. ############################################################# {{clos}}

</cl>

==Procedure (Manual Install)==
<cl>
1. Download the SDK. The latest version can be found on the EMAC FTP site. Download the SDK that matches the architecture of your target system. (Right click, save link as)

* SDK for x86: [http://ftp.emacinc.com/EMAC_Linux/SDK/emac-x86-toolchain.sh emac-x86-toolchain.sh]
* SDK for ARM: [http://ftp.emacinc.com/EMAC_Linux/SDK/emac-arm-toolchain.sh emac-arm-toolchain.sh]

* Change to the directory where the SDK was downloaded from the command line:
{{cli | username=developer | hostname=ldc |cd ~/Downloads }}
* Run SDK installer script:
{{cli | username=developer | hostname=ldc |./emac-ARCH-toolchain.sh }}
The installer will start. It is recommended to select the default target directory for the SDK: <code>/opt/emac/5.X</code>
* Press enter to proceed.
* Enter your password if prompted.
* Status text will appear:
{{clo}}
Extracting SDK...done 
Setting it up...done 
SDK has been successfully set up and is ready to be used. 
{{clos}}
</cl>

== Next Steps ==

* [[Getting_Started_with_the_EMAC_OE_SDK | Getting Started with the EMAC OE SDK ]]
* [[Getting_Started_With_Qt_Creator |Getting Started With Qt Creator]]

Getting Started with the EMAC OE SDK

2021-07-23T15:28:31Z

Mgloff:

{{todo| Complete (03.31.2015-13:42->BS+);(04.08.2015-15:00->BS+);(04.09.15-14:00->MD+);(04.21.2015-10:15->BS+);(04.24.2015-20:00->MD-);(04.28.2015-12:20->MD+);(04.29.2015-16:00->BS+);(04.29.2015-17:30->MD+);(04.30.2015-15:30->KY+); (07.22.2015-11:00->BS+)(10.07.2015-16:32->KY+)|Brian Serrano| project=OE 5.0,BS,MD,Complete,KY}}
{{#seo:
|title=Getting Started with the EMAC OE SDK
|titlemode=append
|keywords=EMAC SDK,Cross compiling, ARM Target Compiling, CMake Build System, CMake Cross Compiling, CMake, CMake Arm
|description=A basic tutorial for using the EMAC OE SDK.
}}






The EMAC OE SDK is distributed with a set of example projects intended to demonstrate how to use the EMAC OE toolchain and libraries. This page demonstrates the process of compiling an example project and running it on the target machine. Also, it provides a straightforward guide to the essential steps you need to follow to get started with cross compiling a simple program with gcc and running the program on your embedded machine.

__TOC__




{{:Templateimpl:using | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}

=== Installing EMAC SDK ===
A Linux developer system is required to install the EMAC software development kit.

For those without a Linux developer system we recommend downloading Oracle VM VirtualBox and installing EMAC's pre-configured Linux Ubuntu virtual machine. All steps involved can be found here: 
[[Getting_Started_With_EMAC_Virtual_LDC | Set up virtual machine with EMAC_OE_SDK pre-installed ]] 
'''OR''' 
Those with a Linux developer system already configured can follow the below steps: 
[[Installing_EMAC_OE_5.0_SDK | SDK Install]] 

{{note|The most current EMAC_OE_SDK release is version 5.1, all higher versions should be disregarded.}}
=== Connecting to a Target Board ===

Primarily a board is connected to through it's debug serial port. If it also connected to a network and the IP address is known, ssh can be used to connect as well. More information on establishing a physical connection to a board is available on the [[Serial_Connections |Serial Connections]] and [[Network_Connections |Network Connections]] page.

The next step after establishing a physical connection to the board is logging in. For more information visit the [[System_Log_In | System Log In]] page.

=== Setting the Filesystem to Read-Write ===
The root filesystem on a machine running EMAC OE Linux is mounted read-only by default. In order to put files on the board, you may need to make the filesystem read-write. The [[Linux_Filesystem_Organization|Linux Filesystem Organization page]] has more information regarding which parts of the filesystem are mounted read-only by default versus which parts are always writeable. Note that EMAC recommends installing your program into a read-only portion of the filesystem (according to the guide) to safeguard it from filesystem corruption (such as may be caused by removing power from the board without shutting down the operating system first, which is normal in embedded systems).

To remount the root filesytem in read-write mode, enter the following into the terminal:
{{cli | oemntrw | hostname=ipac9x25}}

{{note|This will only change the root filesystem to read-write for the current boot. When the system is rebooted, the root filesystem will once again be mounted read-only.}}

=== Transferring Files ===
The command line syntax for transferring a file using the SSH protocol is <code>scp file user@host:/directory</code>. SCP, or Secure Copy, is a way of securely transferring files between a local and remote host. For example, to send the file ''example.text'' to the <code>/usr/bin</code> directory of a system with the IP address 10.0.6.221, enter the following command:
{{cli | username=developer | hostname=ldc | scp example.text root@10.0.6.221:/usr/bin/ }}

Alternatively, you can leave off the path after the colon if you want the file to go directly into the root user's home directory.

{{cli | username=developer | hostname=ldc | scp example.text root@10.0.6.221: }}

=== Remote Execution ===
SSH can also be used to execute programs on remote systems without logging in. The syntax for SSH remote execution is <code>ssh user@host "my_command -args file"</code>. The following is an example of a command to run a program on a board with the IP address ''10.0.6.221''.

{{cli | username=developer | hostname=ldc | ssh root@10.0.6.221 "/path/to/executable -args" }}

=== Basic Compiling ===
The two subsections below show the two common options for how to compile source code. The first subsection demonstrates how to use the EMAC [[ #CMake_Compiling| CMake ]] tool, while the second subsection demonstrates how to compile c code [[ #Manual_Compiling | manually ]]. Another helpful link if you are looking to create a new project with CMake: [[ Creating_a_New_EMAC_OE_SDK_Project_with_CMake | Creating a New EMAC OE SDK Project with CMake ]]

==== CMake Compiling ====
===== Host Machine Compiling =====

This section demonstrates how to use the EMAC CMake tool to generate CMake files automatically for a project. When using the EMAC SDK there are currently two options for cross compiling:
* arm
* x86
For the purposes of this guide, the <tt>arm</tt> option will be used for the listed examples.

Navigate to the directory where the project will be located. Then run the CMake new project script.
{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ |cd projects }}
{{clio | username=developer | hostname=ldc | pwd=~/projects | 1 = export PATH=/opt/emac/5.1/bin:$PATH}}
{{clio | username=developer | hostname=ldc | pwd=~/projects |oe_init_project -n hello.c }}
If desired, please enter a name for this project, otherwise press Enter to use the default: hello_emac 

-- Creating new project directory... 
-- Creating new source file... 
-- Building custom CMakeLists.txt file... 
-- Done. 

Do you want to create a build directory for this project? (y/n) y 

-- Creating build directory... 

Do you want to run cmake for this project? (y/n) y 

-- Using system compiler 
-- The C compiler identification is GNU 4.8.2 
-- The CXX compiler identification is GNU 4.8.2 
-- Check for working C compiler: /usr/bin/cc 
-- Check for working C compiler: /usr/bin/cc -- works 
-- Detecting C compiler ABI info 
-- Detecting C compiler ABI info - done 
-- Check for working CXX compiler: /usr/bin/c++ 
-- Check for working CXX compiler: /usr/bin/c++ -- works 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done 
-- Configuring done 
-- Generating done 
-- Build files have been written to: /home/developer/projects/hello_emac/hello_emac-build 

Do you want to compile this project? (y/n) y

Scanning dependencies of target hello_emac 
[100%] Building C object CMakeFiles/hello_emac.dir/hello.c.o 
Linking C executable hello_emac 
[100%] Built target hello_emac 
{{clos}}

The executable, in this case, is now inside the <code> hello_emac/hello_emac-build </code> directory.

===== Target Machine Compiling =====

The CMake project script has now made a project directory that contains the following:
* CMakeLists.txt
* Source code file (''hello.c'' in this case)
* ''README'' file
* Desktop Build Directory (''hello_emac-build'' in this case)

The ''CMakeLists.txt'' contains the required information to automatically create a ''Makefile'' for a given architecture. This was created by the EMAC <tt>oe_init_project</tt> script, and will need to be modified over time as a project grows. The comments in the file generated by the EMAC tool will provide a good starting point for how to add additional source files and how to perform other common tasks related to maintaining your CMake build system as your project grows. The CMake project provides extensive documentation on how to work with these files.

The source code file generated by the script (''hello.c'') contains a basic Hello World style program.

The ''README'' file contains more information on using ''CMake'' with the EMAC 5.X SDK.

The Desktop Build Directory (''hello_emac-build'') contains the executable ''hello_emac'', the ''Makefile'', and various cache files. These were automatically created by CMake and by the build system, and can be recreated at any time.

It is useful to have a Desktop Build Directory because it is easier (in the beginning) to use the desktop to verify all code changes before cross-compiling for a target board. This will be useful until the application under development depends upon resources which are only available on the target hardware, such as certain devices drivers or the touchscreen (if so equipped).

Use the following steps to cross-compile the project and send it to a target board.
 
 
<cl>
1. In a terminal, navigate to the base directory of the project.
{{note | If the target board being used is <tt>x86</tt>, then change all occurrences of <tt>arm</tt> in the following sections below to <tt>x86</tt>.}}
* Create a build directory for cross compiling.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm }}
* Change directories into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm }}
* Run cmake using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm }}
* Compile the code using make.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}

The <code> make </code> command creates the target executable in the <code> hello_emac-build-arm </code> directory.
* Now copy the executable to the target board. Use any of the options listed under the [[ #Transferring_Files | Transferring Files ]] section.

The executable is now located on the target device at the designated transfer directory. It now can be run remotely (covered [[#Remote_Execution | here]]) OR from the target device by navigating to the transfer directory and issuing the run command (./executable_name).
</cl>
 
 

==== Manual Compiling ====
===== Host Machine Compiling =====
 {{note|In these examples we are using the Ipac-9x25 board. Your board's processor's architecture will determine which file needs to be sourced. These files come from the EMAC SDK toolchain.}}

Create a file called hello.c using a text editor such as vi, nano, or gedit. Then copy and paste the source code from the [[ #Hello_World_System_Log_Example | Hello World System Log Example ]] section in the text editor of your choice.

Once you've created and saved the file with the source code, use the following syntax to compile the program called hello.c:
{{cli | username=developer | hostname=ldc | gcc -o hello hello.c }}

If there is no error in your code then the compiler will successfully create an executable file called hello in the current directory.

To verify this, enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | ls -l hello* }}
-rwxrwxr-x 1 bserrano bserrano 9583 Apr 6 12:45 hello 
-rwxr-xr-x 1 bserrano bserrano 129 Apr 6 12:28 hello.c
{{clos}}

To run the program, enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | ./hello }}
Hello EMAC OE!
{{clos}}

OR
{{clo}}
{{clio | username=developer | hostname=ldc | /path/to/hello }}
Hello EMAC OE!
{{clos}}
 
 

===== Target Board Compiling =====

To compile for the target board, you must <code>source</code> the <code>environment-setup-armv5e-emac-linux-gnueabi</code> file in /opt/emac/5.X where 5.X is the SDK version.
{{cli | username=developer | hostname=ldc | source /opt/emac/5.X/environment-setup-armv5e-emac-linux-gnueabi }}

Once you are in the directory with the source file, enter the following command:
{{cli | username=developer | hostname=ldc | $CC -o hello hello.c }}

{{note|Once you source the file in your current terminal, you can only use it to cross-compile your program for the target board. You can no longer compile it for your host machine. To compile it to your host machine, simply open a new terminal.}}

After sourcing the file, copy the program over to the target board using <code>scp</code>. Enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | scp hello root@10.0.6.221: }}
root@10.0.6.221's password:

hello 100% 9583 9.4KB/s 00:00
{{clos}}

After copying the program, you can now execute the program on the target board. Enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | ssh root@10.0.6.221 ./hello}}
root@10.0.6.221's password: 
Hello EMAC OE!
{{clos}}
 
 

=== Remote Debugging ===

When working with embedded systems the binary is usually compiled on a development machine with a different CPU architecture than what is on the target machine. This can be a problem when, as is typically the case, the target machine lacks the system resources to run a debugger. In these cases, it is possible to use the GNU debugger (<tt>gdb</tt>) on the development machine to remotely debug the target machine provided it has a flavor-matched version of a program named <tt>gdbserver</tt>. All EMAC OE builds are packaged with a flavor-matched <tt>gdbserver</tt> to simplify the setup process for developers.

{{note | A flavor-matched <tt>gdbserver</tt> is one which is built against the same source code revision as the <tt>gdb</tt> client for your desktop, because <tt>gdb</tt> does not have a stable interface for attaching to the <tt>gdbserver</tt>. In fact, the interface changes slightly with almost every release, so if you find yourself having difficulty getting <tt>gdb</tt> and <tt>gdbserver</tt> to communicate with each other, make sure they're the exact same version before trying any other debugging steps.}}

For more information visit the [[Remote_Debugging_EMAC_OE_SDK_Projects_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver]] page.




{{:Templateimpl:examples | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}

=== Hello World System Log Example ===
This example will print <code>Hello EMAC OE!</code> to the syslog facility as well as the console. This will allow you to log, debug, and send status messages to the system logger.

To compile and run this program, see the sections above.

<syntaxhighlight lang="c">
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <syslog.h>

int main(int argc, char** argv)
{
char message[] = "Hello EMAC OE!";

openlog("slog", LOG_PID|LOG_CONS, LOG_USER);
syslog(LOG_INFO, "%s", message);
closelog();

printf("%s\n", message);

return 0;
}
</syntaxhighlight>

This is extremely useful because it allows you to save a record of the output that you might not see first hand.

To verify the output of the program went into syslog, enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | tail /var/log/syslog}}
Apr 7 14:10:06 ENG-26-LX dhclient: DHCPACK of 10.0.6.237 from 10.0.2.1 
Apr 7 14:10:06 ENG-26-LX dhclient: bound to 10.0.6.237 -- renewal in 3306 seconds. 
Apr 7 14:17:01 ENG-26-LX CRON[21193]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 
Apr 7 14:54:41 ENG-26-LX hpcups[21266]: prnt/hpcups/HPCupsFilter.cpp 689: First raster data plane.. 
Apr 7 14:55:31 hpcups[21266]: last message repeated 3 times 
Apr 7 15:05:12 ENG-26-LX dhclient: DHCPREQUEST of 10.0.6.237 on eth0 to 10.0.2.1 port 67 
Apr 7 15:05:12 ENG-26-LX dhclient: DHCPACK of 10.0.6.237 from 10.0.2.1 
Apr 7 15:05:12 ENG-26-LX dhclient: bound to 10.0.6.237 -- renewal in 3559 seconds. 
Apr 7 15:17:01 ENG-26-LX CRON[21302]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 
Apr 7 15:27:08 ENG-26-LX slog[21375]: Hello EMAC OE!
{{clos}}

As you can see on the bottom line, your program output has been recorded and date stamped in syslog.

For more information on system logging visit the [[System_Logging| System Logging ]] page.




{{:Templateimpl:moreinfo | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}
* [[Getting_Started_With_Qt_Creator |Getting Started With Qt Creator]]

{{:Templateimpl:whatnext | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}
* [[ Creating_a_New_EMAC_OE_SDK_Project_with_CMake | Creating a New EMAC OE SDK Project with CMake ]]
* [[EMAC_Example_Projects | EMAC Example Projects]]
* [[Serial_Connections | Serial Connections ]]
* [[Network_Connections | Network_Connections ]]
* [[Remote_Debugging_EMAC_OE_SDK_Projects_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver ]]
* [[Linux_Filesystem_Organization | Linux Filesystem Organization]]
* [[System_Log_In | System Log In]]
* [[System_Logging | System Logging ]]

Loading Images with U-Boot

2021-04-15T18:32:15Z

Mgloff:

{{#seo:
|title=Loading Images with U-Boot
|titlemode=append
|keywords=U-Boot,OS Image,TFTP Server
|description=This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process.
}}
While U-Boot is used to load and execute the OS after initial programming, it can also be used to program the OS images to the local flash. This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process. Review the [[U-Boot Overview]] page for an introduction to U-Boot before continuing.

== Requirements ==
A TFTP server must be accessible on the local network. The specific details of TFTP server setup and configuration can be found on the [[Installing TFTP server]] page. Alternatively, NFS can be used in place of TFTP but will require an NFS server. Information on how to set up an NFS server [[Setting_up_an_NFS_File_Server | can be found here]]. Please contact EMAC if you need details on how to use NFS instead of TFTP to load images.

== Configuration ==
In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration or DHCP can be used on some systems (requires DHCP server). Typically, the IP address of the board and the IP address of the TFTP server are the only settings that need to be defined. The network mask and broadcast address will be determined automatically from these settings, and no default gateway setting is required if the server is on the same subnetwork as the board. Before continuing, determine a valid static network address for your local network; contact your IT department for more information on what address to use if required. The example below shows the use of DHCP and setting the TFTP server IP address to 192.168.2.1
{{clop}}<nowiki>U-Boot> dhcp
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.2.2 (3007 ms)
U-Boot> setenv serverip 192.168.2.1</nowiki>{{closp}}

The example below shows how to set a static IP address of the board to 192.168.2.2 and the TFTP server IP address to 192.168.2.1:
{{clop}}<nowiki>U-Boot> setenv ipaddr 192.168.2.2
U-Boot> setenv serverip 192.168.2.1</nowiki>{{closp}}

Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:
{{clop}}<nowiki>U-Boot> ping 192.168.2.1
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
host 192.168.2.1 is alive</nowiki>{{closp}}

== Loading Images to RAM ==
Files are loaded directly into RAM through TFTP. In order to load the image, you must know the physical address of the RAM device on the system. Refer to the documentation for your target board if you are unsure what value to use. The U-Boot environment variable <code>loadaddr</code> should already be set and can be used in place of the hex addresses below. The standard addresses for some common EMAC systems are shown in Table 1 below.

{| class="wikitable"
! colspan="2"|Table 1: Physical RAM Addresses
|-
! Product !! RAM Start Address
|-
| SoM-9260M || 0x20000000
|-
| SoM-9G20M || 0x20000000
|-
| SoM-9G45M || 0x70000000
|-
| SoM-3517M || 0x82000000
|-
| SoM-9x25M || 0x22000000
|-
| Ipac-9x25M || 0x22000000
|-
| SoM-9G25M || 0x22000000
|-
| SoM-A5D35M || 0x22000000
|-
| SoM-A5D36M || 0x22000000
|-
| SoM-3354M || 0x82000000
|-
| SoM-iMX6M || 0x12000000
|-
| SoM-iMX6UL || 0x82000000
|}

{{ warning | Before transferring a file to the system, make sure that it does not exceed the size of the available RAM. }}

The <code>tftp</code> U-Boot command is used to transfer files to the system. The command requires two arguments: the address to load the file into and the filename of the image on the TFTP server. The example below demonstrates loading a kernel image named <code>uImage-2.6.30</code> to RAM on an SoM-9G45M.
{{clop}}<nowiki>U-Boot> tftp ${loadaddr} uImage-2.6.30
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage-2.6.30'.
Load address: 0x70000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
############################
done
Bytes transferred = 1472456 (1677c8 hex)
U-Boot> printenv filesize
filesize=1677C8</nowiki>{{closp}}

{{ note | Note that the <code>filesize</code> variable has been automatically updated to the size of the file that was loaded.}}

== Executing kernel from RAM ==
In some situations, it is advantageous to execute the image directly from RAM after loading with TFTP rather than saving to flash. This is especially helpful when testing new Linux kernel images. Furthermore, the boot command can be set such that the image is automatically downloaded and executed on each boot, making testing more efficient.

After loading a bootable image to RAM, you can execute it directly using the <code>bootm</code> command for a uImage kernel or <code>bootz</code> for a zImage kernel. For example, after loading the kernel image above, running <code>bootm 0x70000000</code> would boot the board using the new image without making any changes to the images stored on the flash.

To update the <code>bootcmd</code> variable to download the image on each boot, simply replace the command used to load the image from flash with the TFTP download command. The following example illustrates this process on an SoM-9G45M module.
{{clop}}<nowiki>U-Boot> printenv bootcmd
bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000
U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000'
U-Boot> saveenv
Saving Environment to dataflash...</nowiki>{{closp}}

== Copying to Flash ==
The process of copying an image from RAM to flash memory differs depending on what type of flash storage devices are available on the system. Many systems have more than one device, such as serial DataFlash and NAND flash. This section explains the process of storing an image to non-volatile storage.

=== NOR Flash ===
A combination of the <code>erase</code> and <code>cp</code> commands are used to program an image to a NOR flash device. NOR flash is directly memory-mapped to the system at a physical address. Also, each image (U-Boot, bootstrap, kernel, filesystem) must be stored at the correct offset for the system to operate correctly. Refer to the documentation for your hardware for more information on the correct address ranges to use. The <code>flinfo</code> command can be used to display the addressing of available flash devices on the system.

After loading the image to RAM, the flash device should be erased followed by copying the image to the appropriate offset in the flash. The example below illustrates the commands used to program a new kernel image to a SoM-9260M module. Note the use of the <code>protect off all</code> command, which is required to unlock the flash on some systems.
{{clop}}<nowiki>U-Boot> protect off all
U-Boot> tftp 0x20000000 ${kernel_name}
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}</nowiki>{{closp}}

{{ note | Note that NOR flash can take a significant amount of time to program if the image size is large.}}

=== Serial DataFlash ===
Serial DataFlash is an SPI-based NOR flash device that is used on many systems that employ NAND flash as the primary storage device. On these systems, low-level boot code such as the bootstrap, U-Boot, and OS kernel are typically stored on the DataFlash device. As with NOR flash, the <code>flinfo</code> command can be used to determine the memory addressing layout of the DataFlash device. The <code>erase</code> command does not support the DataFlash devices and should not be used before programming an image. The <code>cp</code> command is capable of copying an image from RAM to DataFlash.

The example below illustrates the commands used to copy a kernel image to the DataFlash device on a SoM-9G45M module.
{{clop}}<nowiki>U-Boot> tftpboot 0x70000000 ${kernel_name}
U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}</nowiki>{{closp}}

=== NAND Flash ===
Generally, NAND flash is used to store only the root filesystem and auxiliary storage partitions of the OS. Storing an image to NAND flash under U-Boot uses a different set of commands than NOR or DataFlash devices. See <code>help nand</code> for more information on the available commands for examining and manipulating NAND flash devices. To gain information on what NAND devices are available on the system, use the command <code>nand info</code>. In general, programming a NAND flash device is much faster than programming NOR or DataFlash devices.

The example below illustrates the process of loading the root JFFS2 filesystem onto an SoM-9G45M device. Note that the device is erased prior to programming it.
{{clop}}<nowiki>U-Boot> nand erase
U-Boot> tftp 0x70000000 ${rootfs_name}
U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}</nowiki>{{closp}}

=== SPI NOR/eMMC Flash ===
Most of EMAC's newer SoM offerings utilize an eMMC flash for filesystem and auxiliary storage partitions of the OS and an SPI flash to store the bootloader and kernel. To reprogram the eMMC, see [[Loading_Images_onto_eMMC_Devices|Loading Images onto eMMC Devices]]. Be sure that the <code>loadaddr</code> variable is set and matches the table above. The example below illustrates the commands used to program a new kernel image to a SoM-9x25M module.
{{clop}}<nowiki>U-Boot> pri loadaddr
U-Boot> tftp ${loadaddr} zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize}
U-Boot> setenv kernelsize ${filesize};saveenv</nowiki>{{closp}}

Note: the "pri loadaddr" step above is not required it is just entered to make sure the variable is set.

== Scripting ==
U-Boot also includes a scripting feature that allows a script file with U-Boot commands to be loaded and executed. This can make the task of programming multiple systems much more efficient. The <code>mkimage</code> utility is required on a Linux development system in order to create a valid U-Boot image from a script. This section gives a brief example of a U-Boot script for programming a Linux kernel and filesystem.

Creating a text file with all of the desired commands is the first step in creating a U-Boot script. The example below is a script file used by EMAC to program SoM-9260M modules:
<syntaxhighlight lang=php>
echo ===== Setting Environment =====
setenv bootdelay 1
setenv rev sl013-aon-30010
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
setenv kernel_name ${rev}-uImage
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
saveenv
echo ===== Loading Kernel =====
protect off all
tftpboot 0x20000000 ${kernel_name}
erase 0x10100000 0x103fffff
cp.b 0x20000000 0x10100000 ${filesize}
setenv kernelsize ${filesize}
echo ===== Loading Root Filesystem =====
tftpboot 0x20000000 ${rootfs_name}
erase 0x10400000 0x11ffffff
cp.b 0x20000000 0x10400000 ${filesize}
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
saveenv
echo ===== DONE! =====
</syntaxhighlight>

Once the file has been created and saved, the <code>mkimage</code> utility must be used to create a U-Boot script image. A shell script such as the one shown below may be used to aid in this process:
<syntaxhighlight lang="bash">
#!/bin/sh

if [ ! -f "$1" ] || [ $# -lt 2 ]
then
echo "Usage: $0 SCRIPTNAME OUTPUTNAME"
exit 1
fi

mkimage -T script -C none -A arm -n 'SoM9260 Load Script' -d $1 $2
</syntaxhighlight>

Note that the script assumes that <code>mkimage</code> is installed in the user's PATH. The script should be run with the name of the existing file as the first argument and the desired output filename as the second argument:
{{cli|username=developer|hostname=ldc|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it should be copied to the TFTP server root directory, in this example <code>/srv/tftp</code> is used.
{{cli|username=developer|hostname=ldc|sudo cp sl013-aon-30010-flash-script.img /srv/tftp/}}

The image file can now be transferred to the board and executed as illustrated below:
{{clop}}<nowiki>U-Boot> tftp 0x20000000 sl013-aon-30010-flash-script.img
U-Boot> source 0x20000000</nowiki>{{closp}}

{{ note | Note that the U-Boot command <code>source</code> was not available on older versions of U-Boot. If the command is not recognized, use <code>autoscr</code> instead.}}

U-Boot will execute all commands in the script line-by-line until the script has finished, at which point the U-boot prompt will be returned to the user.




{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
In this article, you have seen how to load an image into RAM using U-Boot. You have seen how to execute an image from RAM. You have also seen how to copy an image from RAM to flash; how to configure your system to boot from an image once it has been saved to flash is documented elsewhere (see Related Information, below). You have also seen a brief description of how to create scripts for U-Boot.

With the information provided by this document, you are set to begin loading alternate kernels and filesystems onto EMAC hardware. These kernels and filesystems could be alternatives provided to you by EMAC, or they could be ones you create yourself. This provides you with a great deal of flexibility for your development work.




{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]
* [[Loading_JFFS2_Images_Onto_a_Board | Loading JFFS2 Images Onto a Board]]
* [[Archiving_JFFS2_Images | Archiving JFFS2 Images]]

{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[U-Boot_Overview | U-Boot Overview]]
* [[Creating_JFFS2_Images | Creating JFFS2 Images]]
* [[Mounting_JFFS2_Images_on_a_Linux_PC | Mounting JFFS2 Images on a Linux PC]]
* [[Repartitioning_NAND_Flash_with_JFFS2_for_Linux | Repartitioning NAND Flash with JFFS2 for Linux]]
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Booting_with_an_NFS_Root_Filesystem | Booting with an NFS Root Filesystem]]

Loading Images onto eMMC Devices

2021-04-15T18:13:36Z

Mgloff:

{{todo|SEOKWREV (12.31.13-13:15->MD-);(12.31.13-14:50->MW+);(12.31.13-18:10->MD+);(12.31.13-18:45->MG+);(03.06.14-15:35->BS-);(04.11.14-15:55->BS+);(05.01.15-12:12->MG+);(11.05.15-17:50->MD+)|Michael Welling|project=oe 4,oe 5,mw,md,mg,bs,SEOKWREV}}

{{#seo:
|title=Loading Images onto eMMC Devices
|titlemode=append
|keywords=eMMC,EXT3 Partition,FAT32 Partition,Root File System
|description=Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.
}}
== Background ==
Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.

U-Boot does not support writing to file systems in eMMC. To overcome this issue, the embedded target needs to boot into an alternate media such as a network file system or USB flash drive. Once the board has booted into Linux, the eMMC can be partitioned and formatted, and the root file system can be extracted. The SoM-3517M requires a special FAT formatted partition that contains the bootloader and Linux kernel images. This article explains the general process of writing the eMMC from Linux as well as some specifics related to programming the SoM-3517M, SoM-9X25, SoM-A5D35/6, SoM-3354, SoM-iMX6M, SoM-iMX6UL and IPAC-9X25.

{{note | The procedures below require that you have a TFTP and NFS server setup on a host computer or a USB thumb drive created using [[Booting_with_a_USB_Root_Filesystem | Booting with a USB Root Filesystem]]. }}

* Instructions on setting up a TFTP server: [[Installing TFTP server]]
* Installation of an NFS Server with Linux: [[Setting up an NFS File Server]]
* Instruction for booting into NFS with U-Boot: [[Booting with an NFS Root Filesystem]]
* Instruction for booting into a filesystem on a USB drive: [[Booting with a USB Root Filesystem]]
* More information about MMC: http://en.wikipedia.org/wiki/MultiMediaCard

== Creating partitions and formatting eMMC ==

Once the Linux command prompt is reached, Linux utilities can be used to create and format partitions on the eMMC. By partitioning the eMMC, the partitions can be accessed individually and formatted differently as required. The <code>fdisk</code> utility can be used to create these partitions on the eMMC.

For example here is the procedure for creating a 128 MB primary partition:

{{clop}}
{{cliop | hostname=emac-oe |fdisk /dev/mmcblk0}}<nowiki>
The number of cylinders for this disk is set to 57024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-57024, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-57024, default 57024): +128M

Command (m for help): p

Disk /dev/mmcblk0: 1868 MB, 1868562432 bytes
4 heads, 16 sectors/track, 57024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 3907 125016 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table
[ 566.062896] mmcblk0: p1
</nowiki>
{{cliop | hostname=emac-oe|}}
{{closp}}

For more information about <code>fdisk</code>, see:
http://tldp.org/HOWTO/Partition/fdisk_partitioning.html

After creating the partitions, they can formatted with the various <code>mkfs</code> utilities. The formatting used is dependent on how the partition is to be accessed. For eMMC root filesystems EMAC currently uses EXT4 (http://en.wikipedia.org/wiki/Ext3). Other formatting options are available (EXT2, EXT3, etc) and can be used. It should be noted that the kernel must be configured to support the chosen filesystem and the bootargs need to specify the correct type.

{{note | For additional information on configuring and compiling the Linux kernel see the following page: [[Building the Linux Kernel]] }}

As described above, the <code>bootargs</code> is used for signalling to the Linux kernel the location of the root filesystem partition, and its formatting. The <code>root</code> parameter is used to specify the partition to use while the <code>rootfstype</code> parameter is used to specify the formatting of the partition.

{{note | For more information about the <code>bootargs</code> variable see this page: [[U-Boot Overview]] }}

Partitions accessed by processor boot ROM or U-Boot typically need to be formatted with FAT32 formatting. The SoM-3517M, for instance, requires a FAT32 formatted partition for the bootloader and kernel in order to boot properly from eMMC. For more specifics about the SoM-3517M, see the quick reference section below.

===Formatting a partition with EXT4===

{{clop}}
{{cliop | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}<nowiki>
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
31360 inodes, 125016 blocks
6250 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
16 block groups
8192 blocks per group, 8192 fragments per group
1960 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
</nowiki>
{{cliop| hostname=emac-oe |}}
{{closp}}

===Formatting a partition with FAT32===

{{clop}}
{{cliop | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
mkdosfs 2.11 (12 Mar 2005)
{{cliop | hostname=emac-oe |}}
{{closp}}

== Extracting filesystems to eMMC ==
After formatting a partition correctly, the partition can be mounted and files can be loaded to the eMMC.

For example, here is the procedure for writing a root filesystem to the first partition of an eMMC card:

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe |tar xzvf /images/emac-image.rootfs.tar.gz}}
<nowiki> ⋮</nowiki>
{{clos}}

In the above example the <code>/mnt/card</code> directory is called the mount point. The <code>mkdir -p</code> command creates the directory if it does not already exist. The <code>mount</code> command attaches the specified partition to the directory. Any files written to the mounted directory will go to the partition on the eMMC. After the mount is complete, files can be extracted as shown using the <code>tar</code> command.

It should be noted that the <code>/etc/fstab</code> file can be used to specify mount points for partitions upon boot. See http://en.wikipedia.org/wiki/Fstab for additional information.

== Quick Reference (by Target Type) ==
This section is used to provide specifics for programming eMMC on various targets.

For the partitioning sections, the information in the parenthesis denotes a keyboard input sequence. The (n,p,1,default,+64M) creates a new primary partition. Each input is followed a carriage return and the default is selected by pressing carriage return with no entry. See the expanded example in the above '''Creating partitions and formatting eMMC''' section for an idea of how the interface looks when commands are executed correctly.

=== SoM-3517M ===
==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk -H 255 -S 63 /dev/mmcblk0}}

The partitioning steps are as follows:
# Create 1st partition (n,p,1,default,+64M)
# Create 2nd partition (n,p,2,default,default)
# Change 1st partition type to FAT32 (t,1,c)
# Make 1st partition ACTIVE (a,1)
# Write (w)

==== Formatting the eMMC ====

{{clo}}
{{clio | hostname=emac-oe |mkfs.ext3 /dev/mmcblk0p2}}
{{clio | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
{{clos}}

The first command formats the second partition as ext3. The <code>mkfs.ext3</code> command can take further configuration parameters. See the <code>mkfs.ext3</code> man page for more information.

The second command formats the first partition as FAT32 for use with the AM3517's boot ROM. This is a requirement to boot from the eMMC.

==== Adding Kernel and Bootloader ====

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /images}}
{{clio | hostname=emac-oe | pwd=images |cp MLO uImage u-boot.bin /mnt/card/}}
{{clio | hostname=emac-oe | pwd=images |sync}}
{{clio | hostname=emac-oe | pwd=images |umount /dev/mmcblk0p1}}
{{clos}}

{{ note | The first partition '''must''' be formatted FAT32 and the MLO binary '''must''' be in the first sector for the eMMC boot sequence to work properly. }}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe | pwd=images |mount /dev/mmcblk0p2 /mnt/card}}
{{clio | hostname=emac-oe | pwd=images |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p2}}
{{clos}}

=== SoM-9X25M / IPAC-9X25 / SoM-A5D35/6 / SoM-3354 / SoM-iMX6M / SoM-iMX6UL ===

Unlike the SoM-3517, these SoMs store U-Boot and the Linux kernel in a separate serial flash instead of the eMMC. Typically, two partitions are created. The first partition contains the complete filesystem and is mounted read-only while the second partition contains the /home directory and is mounted read-write.

=== Unmount partitions ===

{{cli | hostname=emac-oe |umount /dev/mmcblk0p1}}
{{cli | hostname=emac-oe |umount /dev/mmcblk0p2}}

==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk /dev/mmcblk0}}

{{ note | For the SoM-9x25M revisions 7 and above, the eMMC block device is /dev/sdb }}

The partitioning steps are as follows:

# Create 1st partition (n,p,1,default,+1G)
# Create 2nd partition (n,p,2,default,default)
# Write (w)

==== Formatting the eMMC ====
{{clo}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p2}}
{{clos}}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p1}}
{{clos}}

ARM SOM

2021-03-05T18:36:23Z

Mgloff:

{{todo| Review (02.15.2016-12:26->AW+)|Andrew Wichmann| project=OE 5.0,AW,Review }}



{{:Templateimpl:navpgtable | initials=AW | title=ARM System on Module (SoM) Products | desc=A collection of pages for all SoM products}}




System on module (SoM) is an ideal alternative to custom engineering. With an SoM approach you get the best of aspects of both buying an Off-The-Shelf Single Board Computer (SBC) and of a Custom Engineered solution. With Off-The-Shelf standard components such as a generic carrier board and SOM module, it is possible to start development on your software applications before the custom carrier board is complete; thus offering a reduced time to market for your system. A System on Module (SoM) is comprised of a small processor module with CPU bus accessibility and standard I/O functionality. The SoM module does not have any connectorization and is designed to be plugged into a Carrier Board.




{{:Templateimpl:navtableentry | title=ARM-144 Pin SoMs }}

{{:Templateimpl:Navti | [[SOM-9260 | SOM-9260 (Atmel ARM9 AT91SAM9260)]] }}
{{:Templateimpl:Navti | [[SOM-9G20 | SOM-9G20 (Atmel ARM9 AT91SAM9G20)]] }}
{{:Templateimpl:Navti | [[SOM-9G25 | SOM-9G25 (Atmel ARM9 AT91SAM9G25)]] }}
{{:Templateimpl:Navti | [[SOM-9X25 | SOM-9X25 (Atmel ARM9 AT91SAM9G25)]] }}
{{:Templateimpl:Navti | [[SOM-A5D35 | SOM-A5D35 (Atmel Cortex A5 ATSAMA5D35)]] }}
{{:Templateimpl:Navti | [[SOM-iMX6UL | SOM-iMX6UL (Freescale Cortex A9 iMX6UL)]] }}

{{:Templateimpl:navtend}}




{{:Templateimpl:navtableentry | title=ARM-200 Pin SoMs }}

{{:Templateimpl:Navti | [[SOM-9G45 | SOM-9G45 (Atmel ARM9 AT91SAM9G45)]] }}
{{:Templateimpl:Navti | [[SOM-9M10 | SOM-9M10 (Atmel ARM9 AT91SAM9M10)]] }}
{{:Templateimpl:Navti | [[SOM-3517 | SOM-3517 (TI Cortex A8 AM3517)]] }}
{{:Templateimpl:Navti | [[SOM-3354 | SOM-3354 (TI Cortex A8 AM3354)]] }}
{{:Templateimpl:Navti | [[SOM-A5D36 | SOM-A5D36 (Atmel Cortex A5 ATSAMA5D36)]] }}

{{:Templateimpl:navtend}}




{{:Templateimpl:navtablenewrow}}




{{:Templateimpl:navtableentry | title=ARM 314 Pin SoMs }}

{{:Templateimpl:Navti | [[SOM-IMX6 | SOM-IMX6 (Freescale Cortex A9 iMX6)]] }}

{{:Templateimpl:navtend}}




{{:Templateimpl:navtableentry | title=ARM-Carrier Boards }}

{{:Templateimpl:Navti | [[SOM-150 | SOM-150 (144-Pin Carrier, Text LCD)]] }}
{{:Templateimpl:Navti | [[SOM-200 | SOM-200 (200-Pin Carrier, 4.3" LCD)]] }}
{{:Templateimpl:Navti | [[SOM-210 | SOM-210 (200-Pin Carrier, 4.3" LCD)]] }}
{{:Templateimpl:Navti | [[SOM-212 | SOM-212 (200-Pin Carrier, 4.3" LCD)]] }}
{{:Templateimpl:Navti | [[SOM-250 | SOM-250 (200-Pin Carrier, 7 & 10" LCDs)]] }}
{{:Templateimpl:Navti | [[SOM-350 | SOM-350 (314-Pin Carrier, 7 & 10" LCDs)]] }}

{{:Templateimpl:navtend}}

Serial Connections

2021-03-05T18:31:03Z

Mgloff:

{{todo|SEOKWREV (11.25.13-13:05->KY+);(11.25.13-18:45->MD+);(11.26.13-21:40->MD+);(12.20.13-11:12->MW+);(03.04.14-15:20->BS-);(03.14.14-15:55->BS+)(03.14.14-15:55->BS+)(10.26.15-18:25->MG+)|Klint Youngmeyer|project=oe 4,oe 5,ky,SEOKWREV,md,mw,bs}}

{{#seo:
|title=Serial Connections
|titlemode=append
|keywords=Serial Connections,Serial Terminal,PuTTY,Serial Communication Parameters
|description=Serial Connections to EMAC boards.
}}


There are several ways to connect to a system running EMAC OE Linux. The preferred connection method depends on the capabilities of the hardware. For example, headless systems (those without a graphical interface) will most likely use a serial port console, while systems with a video connection may be accessed using a keyboard and LCD or monitor. When an LCD or monitor is available, a serial connection can occasionally still be needed; usually, this need arises after a user has accidentally misconfigured the display. Other times, it may be useful to be able to use a serial console on a board that's running remotely but has had its network connection drop out. The serial console can be a very useful tool for diagnosing and debugging issues even after development has finished.

== Serial Terminal ==
A serial terminal connection is most commonly the first connection that will be made to a system in its default configuration. A serial terminal application such as [[Getting_Started_With_Minicom | Minicom]] for Linux or [[PuTTY]] under Windows is required for this connection. The serial cable type, port, and communication parameters for each system type are listed in Table 1 below.

 
<div align=center>
{| class="wikitable" style="text-align: center;" |Table 1: Serial Communication Parameters
|-
! SoM !! Port !! Cable Type !! Baud Rate !! Data Bits !! Parity !! Stop Bits !! Flow Control
|-
| [[ ARM_SOM | 314 Pin SoM's ]] || COMA || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ ARM_SOM | 200 Pin SoM's ]] || COMB || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ ARM_SOM | 144 Pin SoM's ]] || COME || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ SOM-9260 ]] || COMA || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ SOM-9G20 ]] || COMA || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ iPac-9x25 ]] || COM1 || NULL Modem || 115200 || 8 || None || 1 || None
|-
| x86 Boards || COM1* || NULL Modem* || 115200 || 8 || None || 1 || None
|}
</div>

{{note | '''*''' : These settings vary among x86 systems. Refer to the system manual for the target board for more information. Not all x86 systems have a serial terminal connection enabled by default.}} 

Follow the steps below to establish a serial connection:
# Connect a NULL Modem serial cable between the serial port on the workstation and target board and start a terminal application.
# Setup the communication parameters for your board according to Table 1.
# Connect power to the target board; boot messages will begin to print within a few seconds.
# When the board has finished booting a login prompt will appear.

== Next Steps ==
After you have established a connection with your device running EMAC OE Linux, you will need to [[System_Log_In | log into the system.]]

Building the Linux Kernel

2020-09-26T17:32:52Z

Mgloff:

{{#seo:
|title=Building the Linux Kernel
|titlemode=append
|keywords=Building Linux Kernel,Configuring Kernel,Loading Kernel Modules
|description=Process of configuring and compiling the Linux kernel using the EMAC kernel build script.
}}
This page covers the process of configuring and compiling the Linux kernel using the EMAC kernel build script. This process assumes that you have already acquired the following software:

# EMAC Software Development Kit [[ Installing_EMAC_OE_4.0_SDK | OE 4 ]] or [[Installing_EMAC_OE_5.0_SDK | OE 5 ]]
# Linux kernel source for target hardware (provided via EMAC public [http://git.emacinc.com/Linux-Kernel GIT server] )
# [ftp://ftp.emacinc.com/EMAC_Linux/SDK/kernel-build-cross.tar.gz Kernel build script]

The example below will assume that a kernel image for the SoM-9x25 module will be created, although the instructions apply to other hardware as well assuming that the correct SDK, kernel tree, and build script is used.

==Setup==

The steps below assume that the <code>kernel-build-cross.sh</code> script is
located in the same directory as the kernel tree. Be sure to modify the <code>environment.cfg.sh</code> script for the correct
architecture and EMAC OE version.

==Configuring the Kernel==

The first step for building the kernel is to configure it as desired. It is recommended to start with the kernel configuration file used by EMAC to build the kernel for the target device. Starting with EMAC OE 5.0, the kernel configuration can be
obtained on a running board from /proc/config.gz. Please contact [http://www.emacinc.com/support EMAC support]
for earlier EMAC OE versions.
 
The following are steps to configure the kernel:
<cl>
1. Copy the default configuration file to the same directory as the kernel source tree and kernel-build-cross.sh and rename it defconfig.

* The kernel-build-cross script accepts the SOURCE_TREE as the first argument and either config or build as the second argument. Optionally, a third argument, BUILD_SUFFIX may be supplied as a suffix to add to the build directory. BUILD_SUFFIX is commonly used to add a tag or machine name to a build.

{{cli | username=developer | hostname=ldc |./kernel-build-cross.sh linux-emac config som9x25}}

* The kernel menu-driven configuration utility will be displayed. Features can be selected/deselected to be built into the kernel. Some features can be built as a loadable module, denoted by < >, and not built directly into the kernel.
{{ warning | Disabling or modularizing some kernel features may prevent the kernel from starting correctly or at all. }}

Use the space bar to select an option or the 'm' key to configure the selected option as a module. Select <code>Exit</code> to close the kernel configuration menu and save the configuration to the newly created build directory. When the same build-suffix is used for subsequent builds, this configuration will be used.
</cl>

==Building the Kernel==

<cl>
1. Run the kernel-build-cross script again with the build option, this time using the same build-suffix used in the configuration step.

{{cli | username=developer | hostname=ldc |./kernel-build-cross.sh linux-emac build som9x25}}

* The kernel will begin compiling now. This will take several minutes to complete depending on the kernel configuration and the speed of the development machine. Only move on to the next step if the build completes with no errors.

* The new kernel image will be in the <code>build-4.9.224-som9x25/Install/boot</code> directory. For the 3.10 and later device tree enabled ARM kernels, the image name will be a zImage. Also, the desired device tree blob (*.dtb) needs to be appended to the kernel. For earlier versions of the kernel, a uImage will be generated that can be loaded directly from U-Boot. X86 boards use a bzImage.

{{clo}}
{{clio | username=developer | hostname=ldc |cd build-4.9.224-som9x25/Install/boot}}
{{clio | username=developer | hostname=ldc |cat zImage-4.9.224 som-9x25-150es.dtb > zImage-som9x25}}
{{clos}}

This is the image that will get loaded onto the board and executed by the bootloader. To load the new kernel onto the target machine, see the [[Loading Linux Kernels Onto a Board]] page.

The build script will also create an archive of all of the modules created during the build process and place it in the <code>build-4.9.225-som9x25/Install/</code> directory. The archive will be called <code>modules.tar.gz</code>.
</cl>

==Loading Kernel Modules==

After re-compiling the kernel, it is recommended to load the corresponding kernel modules.

To reload the modules:
<cl>
1. Make sure that the root flash is mounted read/write before copying the modules to the target.

* Copy the archive to the root of the filesystem of the target machine

{{cli | username=developer | hostname=ldc |scp build-4.9.224-som9x25/Install/modules.tar.gz root@1IP_ADDRESS:/ }}

* Log onto the target machine

{{cli | username=developer | hostname=ldc |ssh root@IP_ADDRESS}}

* Extract the kernel modules archive and force the kernel to reload the modules.

{{clo}}
{{clio |cd /}}
{{clio |tar xzvf modules.tar.gz}}
{{clio |depmod -a}}
{{clio |reboot}}
{{clos}}
</cl>

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to build the linux kernel. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

OE50:Packages

2020-03-04T20:10:42Z

Mgloff:

{{todo|(1-12-15-12:30->MG+)(1.12.15-18:05->MD+)(11.10.15-16:05->KY+)|Michael Gloff|project=oe 5,mg,Complete}}

{{#seo:
|title=EMAC OE 5.X Release information
|titlemode=append
|keywords=OE 5.X Standard Packages,Release information
|description=Information about EMAC OE 5.X Release.
}}

{{DISPLAYTITLE:EMAC OE 5.X Release Information}}

The OE 5.''X'' releases represent the next generation of EMAC's embedded Linux distribution. The new crop of embedded machines on the market have become powerful enough to justify bringing some of the best parts of Linux distributions that are targeted towards servers and desktops into the embedded realm. OE 5.X is designed to make developing software for embedded Linux easier than ever before.

===New Features===

Quite a few new features are being introduced with OE 5.X to support the goal of streamlining the development process and improving the embedded Linux software development experience. These features can be broken down into the following categories.

====Operating System====

The underlying operating system, Linux, has seen a refresh to the much more modern 4.9 kernel on ARM and x86 systems. This updated kernel provides improved support for the ARM architecture, new drivers for new hardware, and the Device Tree File System for ARM hardware. Device Tree is a new way of specifying hardware parameters which pulls memory offset specifications (and similar) out of the kernel binary and puts them into a separate file which can be maintained independently of the kernel.

====Filesystem====

OE 5.X uses more modern filesystems to enable faster access to files, larger maximum filesystem sizes, and improved wear leveling on the underlying flash devices. The following filesystems are now a part of OE 5.X:

* '''ext4''' - for eMMC/mSATA/SD/CF devices
* '''JFFS2''' - for NAND flash devices

The filesystem is now generated using the Yocto build system, which enables a more streamlined and simpler process for generating custom filesystems based on our available base images. The Yocto Project is hosted by engineers at Intel, and is built upon the time tested OpenEmbedded project.

====SDK====

EMAC OE 5.X includes a new SDK with an updated GNU gcc compiler which brings enhanced optimization capabilities, advanced code generation, and improved support for C++11 features. The gcc cross compilers come bundled with support for the CMake build system which greatly eases the work involved in creating a build system for today's complex software. EMAC OE 5.X provides tools for generating the base CMake files from the commandline or from the IDE, allowing you to get started quickly whether you choose to use the commandline or an IDE for your development work.

====IDE====

EMAC OE 5.X now includes the Qt Creator IDE as the standard development environment. This IDE provides a polished, sophisticated development environment which can be used for developing any type of application in C or C++. For Qt, it provides a sophisticated GUI editor and code generation wizards to enable RAD. The integrated help system is of use whether the issue with the application under development is related to Qt, Linux, or just standard C/C++.

====Tools====

EMAC OE 5.X now includes tools to enable development to ease common tasks.

Some of the development work in a typical project requires performing complex tasks which are done so infrequently that most developers need to look them up each time they're performed. These tasks typically have eaten into a project's time by taking much longer than anticipated to perform. EMAC OE 5.X includes tools to make these tasks quick, simple, and intuitive. These tasks include:

* Timezone Configuration.
* Splashscreen Configuration.
* Touchscreen Calibration.
* Configuring software to automatically start on boot.
* Configuring a system to log messages to a remote syslog server.

==== Easy SDK Installation ====

The EMAC OE 5.X SDK, IDE, tools and examples can be installed on most common Linux distributions, though only Ubuntu 16.04 is currently tested and therefore recommended.

See [[ Installing_EMAC_OE_5.0_SDK | Installing EMAC OE 5.0 SDK ]]

===Release Testing===

EMAC has completely revamped its release testing for the EMAC OE 5.X release series. The new testing process provides a far more comprehensive and exhaustive method of testing our software and hardware together to ensure the highest quality experience possible. Throughout the 5.X release series, we will continue to improve and refine this testing process to ensure that each release is even better than the previous.

==Provided Software==

EMAC OE 5.X provides a number of software packages which weren't provided with previous versions of EMAC OE. These new packages provide additional capabilities and extend existing capabilities. These packages were carefully chosen to ensure that the best available tools are provided across the full range of tasks which need to be performed on EMAC OE machines.

The following list shows the new tools which have been added or updated, and what you will gain from each one.

* '''ethtool''' - This tool will allow you to inspect the network interfaces at the hardware level, allowing you to see if the physical link is good and, if so, what speed it's running at. No more guessing as to whether your networking issue is a hardware or software issue. If this shows your hardware is working correctly, you know it's a software configuration issue.
* '''lighttpd''' - This is a much more sophisticated web server than the one provided by Busybox. It was a very popular custom package for the 4.0 series, so it is now included by default in 5.X.
* '''vim''' - The real vim, not the Busybox version of vi. This provides syntax highlighting, undo, redo, macros, last position memory, and all of the other powerful features of vim that are missing from Busybox vi.
* '''wget''' and '''ftpput''' - These provide a simple way to retrieve files from a webserver and to push them to a webserver. This can make retrieving updated files much simpler.
* '''strace''' - Shows the system calls made by any executable which is run through it. This is a very powerful tool for debugging.
* '''ntp''' and '''ntpdate''' - These tools provide a method to update the system clock to the time provided by the atomic clocks which share their time over the Internet.  These full versions are more reliable and more sophisticated than the Busybox version.
* '''minicom''' - Much more sophisticated than microcom, this tool provides the same powerful terminal client you use on your desktop.
* '''htop''' - This tool provides a sophisticated view into what's running on your system.
* '''sudo''' - This tool allows for execution of a program with the elevated privileges of the superuser.
* '''rsync''' - This tool allows for easy remote file synchronization between two computers.
* '''file''' - This tool lets you inspect files to determine what type they are and various properties of them.
* '''evtest''' - This tool provides a way to diagnose issues with input events.
* '''bash''' - The real bash shell. Much more powerful than the Busybox shell, and much better for scripting.
* '''procps''' - The full suite of process utilities, such as ps, kill, watch, uptime, free, pgrep, sysctl, and top, the full versions of these tools provide the useful functionality which was missing from the Busybox versions.
* '''inotify-tools''' - These tools provide filesystem notifications which enable scripts and programs to only perform events after a file or directory has been modified/created/deleted/etc. No polling required.
* '''tftp client''' - Easily download files from a tftp server with the integrated tftp client.
* '''iptables''' - The standard tool for configuring firewalls on Linux.
* '''tcpdump''' - An invaluable tool for debugging firewalls and TCP/UDP/IP connections of any kind.

This partial list shows just the highlights of the new software that's part of EMAC OE 5.X.  All of the software previously provided in OE4 is available in 5.X as well.

Other software provided by OE 5.X includes:

* '''nano''' - Basic text editor.
* '''amidi/aplaymidi/arecordmidi''' - Simple MIDI music player/recorder/controller.
* '''candump/canecho/cansend/cansequence''' - Tools for working with a CAN bus (included only on systems which have CAN support).
* Tools for working with flash memory.
* '''opkg''' - Package management tools.
* '''mpg123''' - MPEG Audio Decoder/Player
* Memory testing tools.
* '''Busybox''' - The embedded "Swiss Army Knife"
* '''Openssh sshd''' - SSH server (and client).
* '''OpenSSL''' - standard ssl security libraries.

== See Also ==

* [[ EMAC_OE_50_Add-on_Packages | EMAC OE 5.X Add-on Packages ]]

Loading Linux Kernels Onto a Board

2019-11-04T22:24:54Z

Mgloff:

{{todo|SEOKWRev (11.06.13-08:47->MW+); (11.06.13-18:05->MD+); (12.12.13-11:10->MW+); (12.16.13-01:20->MD-); (12.16.13-10:42->MW+);(12.17.13-13:15->KY+);(03.06.14-15:30->BS-);(04.11.14-15:45->BS+);(11.06.15-16:45->MG+)|Michael Welling|project=oe 4,oe 5,mw,md,reorganize,ky,bs,mg}}

{{#seo:
|title=Loading Linux Kernels Onto a Board
|titlemode=append
|keywords=Linux Kernels,TFTP Server,Serial Connection,U-Boot
|description=For EMAC's ARM Linux builds, the kernel is loaded onto boards separately from file systems, while on others the kernel is loaded with the filesystem.
}}
=== Background Information ===

The Linux kernel is at the core of EMAC's OE operating system. The kernel provides essential I/O interfaces, task management, and memory management to the user simplifying the development environment. Each embedded target has a Linux kernel image that is tailored to its specific hardware needs. For more information about the Linux kernel see the links in the [[About Linux]] page.

For EMAC's ARM Linux builds, the kernel is loaded onto boards separately from file systems, while on others the kernel is loaded with the filesystem. It should be noted that, regardless of how the kernel is loaded, many of the kernel's drivers can be compiled as modules which have to be included in the file system in the <code>/lib/modules</code> directory. [[Building the Linux Kernel]] explains how to compile the Linux kernel and how to load the kernel modules onto an existing file system.

''See [[Installing LILO]] for more information on updating the kernel with X86 targets.''

''See the [[Loading Images with U-Boot]] page for more information on updating the kernel on ARM targets.''

=== General Information ===

As with the loading the JFFS2 file system, the kernel is loaded using TFTP and a serial connection to the boot loader. Once the boot loader and TFTP server are accessible the kernel is loaded into SDRAM and relocated to the target's embedded flash.

For instructions on installing a TFTP server on a development PC, see
[[Installing TFTP server]].

For details on connecting to the serial port for an embedded target, see
[[Serial Connections]].

The [[Loading Images with U-Boot]] page explains how to load a kernel onto a target. It is important to note the offset in SDRAM and Flash as setting them incorrectly could adversely affect the operation of the system. The current page details the utilization of U-Boot more specifically; for more information about Redboot see the [[Loading Images with RedBoot]] page.

Here is an example of configuring the networking for TFTP transfer and loading the kernel into the resident SDRAM on a SoM-9G45:
U-Boot> set autoload no
U-Boot> dhcp
U-Boot> set serverip 192.168.0.100
U-Boot> tftp 0x74000000 uImage-2.6.30-9g45

Once the kernel is loaded into SDRAM, the kernel image can be either booted directly or loaded into the board's flash memory for deployment. Booting directly into the kernel can be especially useful during development as it allows for testing and debugging without committing the kernel to flash. To boot the kernel directly, use the <code>bootm</code> command as follows:
U-Boot> bootm

The procedure for writing to the flash differs from board to board because of the different flash types that are used. For instance, the SoM-9G45 and SoM-9G20 use serial Dataflash to store the kernel, whereas the SoM-9260 uses NOR flash.

Here is an example for copying the the kernel image into the Dataflash on the SoM-9G45 using <code>cp.b</code>:
U-Boot> cp.b 0x74000000 0xC0042000 ${filesize}

{{imbox | type=notice | text = The $filesize variable is automatically set based on the size of the file loaded with the previous tftp load command. }}

Here is an example of writing the kernel to the NOR flash on the SoM-9260:
U-Boot> protect off all
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}
U-Boot> set kernelsize $filesize

The <code>protect off all</code> command unlocks NOR flash erasing and writing. NOR flash needs to be specifically erased before programming using the <code>erase</code> command. Once the erase is complete the kernel image can be written to the flash. The <code>kernelsize</code> variable is used in the boot script for the SoM-9260. To see the boot command sequence for a particular board, run the <code>printenv</code> command on the system and note the <code>bootcmd</code> variable.
{{imbox | type=notice | text = The 0x numbers represent the hexadecimal value of the offset from the top of specific memories. These values vary from system to system. See the quick reference below for examples on the various EMAC ARM based systems.}}

=== Quick Reference (By Target Type) ===
This section provides a quick reference for programming various targets with a kernel images.
==== SoM-9260M ====
<syntaxhighlight lang="bash">
U-Boot> tftp 0x20000000 uImage-som-9260m
U-Boot> protect off all
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}
U-Boot> set kernelsize $filesize
</syntaxhighlight>

==== SoM-9G20M ====
<syntaxhighlight lang="bash">
U-Boot> tftp 0x20000000 uImage-som-9g20m
U-Boot> cp.b 0x20000000 0xD0042000 ${filesize}
</syntaxhighlight>

==== SoM-9G45M/9M10M ====
<syntaxhighlight lang="bash">
U-Boot> tftp 0x74000000 uImage-som-9g45m
U-Boot> cp.b 0x74000000 0xC0042000 ${filesize}
</syntaxhighlight>

==== SoM-9x25 iPac-9x25 SoM-9G25 SoM-A5D3X ====
<syntaxhighlight lang="bash">

U-Boot> tftp 0x22000000 zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write 0x22000000 0x100000 ${filesize}
U-Boot> set kernelsize ${filesize};saveenv
</syntaxhighlight>

==== SoM-3354 ====
<syntaxhighlight lang="bash">

U-Boot> tftp 0x82000000 zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write 0x82000000 0x100000 ${filesize}
U-Boot> set kernelsize ${filesize};saveenv
</syntaxhighlight>

Loading Images onto eMMC Devices

2019-09-17T14:29:54Z

Mgloff:

{{todo|SEOKWREV (12.31.13-13:15->MD-);(12.31.13-14:50->MW+);(12.31.13-18:10->MD+);(12.31.13-18:45->MG+);(03.06.14-15:35->BS-);(04.11.14-15:55->BS+);(05.01.15-12:12->MG+);(11.05.15-17:50->MD+)|Michael Welling|project=oe 4,oe 5,mw,md,mg,bs,SEOKWREV}}

{{#seo:
|title=Loading Images onto eMMC Devices
|titlemode=append
|keywords=eMMC,EXT3 Partition,FAT32 Partition,Root File System
|description=Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.
}}
== Background ==
Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.

U-Boot does not support writing to file systems in eMMC. To overcome this issue, the embedded target needs to boot into an alternate media such as a network file system or USB flash drive. Once the board has booted into Linux, the eMMC can be partitioned and formatted, and the root file system can be extracted. The SoM-3517M requires a special FAT formatted partition that contains the bootloader and Linux kernel images. This article explains the general process of writing the eMMC from Linux as well as some specifics related to programming the SoM-3517M, SoM-9X25, SoM-A5D35/6, SoM-3354, SoM-iMX6M, SoM-iMX6UL and IPAC-9X25.

{{note | The procedures below require that you have a TFTP and NFS server setup on a host computer or a USB thumb drive created using [[Booting_with_a_USB_Root_Filesystem | Booting with a USB Root Filesystem]]. }}

* Instructions on setting up a TFTP server: [[Installing TFTP server]]
* Installation of an NFS Server with Linux: [[Setting up an NFS File Server]]
* Instruction for booting into NFS with U-Boot: [[Booting with an NFS Root Filesystem]]
* More information about MMC: http://en.wikipedia.org/wiki/MultiMediaCard

== Creating partitions and formatting eMMC ==

Once the Linux command prompt is reached, Linux utilities can be used to create and format partitions on the eMMC. By partitioning the eMMC, the partitions can be accessed individually and formatted differently as required. The <code>fdisk</code> utility can be used to create these partitions on the eMMC.

For example here is the procedure for creating a 128 MB primary partition:

{{clop}}
{{cliop | hostname=emac-oe |fdisk /dev/mmcblk0}}<nowiki>
The number of cylinders for this disk is set to 57024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-57024, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-57024, default 57024): +128M

Command (m for help): p

Disk /dev/mmcblk0: 1868 MB, 1868562432 bytes
4 heads, 16 sectors/track, 57024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 3907 125016 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table
[ 566.062896] mmcblk0: p1
</nowiki>
{{cliop | hostname=emac-oe|}}
{{closp}}

For more information about <code>fdisk</code>, see:
http://tldp.org/HOWTO/Partition/fdisk_partitioning.html

After creating the partitions, they can formatted with the various <code>mkfs</code> utilities. The formatting used is dependent on how the partition is to be accessed. For eMMC root filesystems EMAC currently uses EXT4 (http://en.wikipedia.org/wiki/Ext3). Other formatting options are available (EXT2, EXT3, etc) and can be used. It should be noted that the kernel must be configured to support the chosen filesystem and the bootargs need to specify the correct type.

{{note | For additional information on configuring and compiling the Linux kernel see the following page: [[Building the Linux Kernel]] }}

As described above, the <code>bootargs</code> is used for signalling to the Linux kernel the location of the root filesystem partition, and its formatting. The <code>root</code> parameter is used to specify the partition to use while the <code>rootfstype</code> parameter is used to specify the formatting of the partition.

{{note | For more information about the <code>bootargs</code> variable see this page: [[U-Boot Overview]] }}

Partitions accessed by processor boot ROM or U-Boot typically need to be formatted with FAT32 formatting. The SoM-3517M, for instance, requires a FAT32 formatted partition for the bootloader and kernel in order to boot properly from eMMC. For more specifics about the SoM-3517M, see the quick reference section below.

===Formatting a partition with EXT4===

{{clop}}
{{cliop | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}<nowiki>
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
31360 inodes, 125016 blocks
6250 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
16 block groups
8192 blocks per group, 8192 fragments per group
1960 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
</nowiki>
{{cliop| hostname=emac-oe |}}
{{closp}}

===Formatting a partition with FAT32===

{{clop}}
{{cliop | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
mkdosfs 2.11 (12 Mar 2005)
{{cliop | hostname=emac-oe |}}
{{closp}}

== Extracting filesystems to eMMC ==
After formatting a partition correctly, the partition can be mounted and files can be loaded to the eMMC.

For example, here is the procedure for writing a root filesystem to the first partition of an eMMC card:

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe |tar xzvf /images/emac-image.rootfs.tar.gz}}
<nowiki> ⋮</nowiki>
{{clos}}

In the above example the <code>/mnt/card</code> directory is called the mount point. The <code>mkdir -p</code> command creates the directory if it does not already exist. The <code>mount</code> command attaches the specified partition to the directory. Any files written to the mounted directory will go to the partition on the eMMC. After the mount is complete, files can be extracted as shown using the <code>tar</code> command.

It should be noted that the <code>/etc/fstab</code> file can be used to specify mount points for partitions upon boot. See http://en.wikipedia.org/wiki/Fstab for additional information.

== Quick Reference (by Target Type) ==
This section is used to provide specifics for programming eMMC on various targets.

For the partitioning sections, the information in the parenthesis denotes a keyboard input sequence. The (n,p,1,default,+64M) creates a new primary partition. Each input is followed a carriage return and the default is selected by pressing carriage return with no entry. See the expanded example in the above '''Creating partitions and formatting eMMC''' section for an idea of how the interface looks when commands are executed correctly.

=== SoM-3517M ===
==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk -H 255 -S 63 /dev/mmcblk0}}

The partitioning steps are as follows:
# Create 1st partition (n,p,1,default,+64M)
# Create 2nd partition (n,p,2,default,default)
# Change 1st partition type to FAT32 (t,1,c)
# Make 1st partition ACTIVE (a,1)
# Write (w)

==== Formatting the eMMC ====

{{clo}}
{{clio | hostname=emac-oe |mkfs.ext3 /dev/mmcblk0p2}}
{{clio | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
{{clos}}

The first command formats the second partition as ext3. The <code>mkfs.ext3</code> command can take further configuration parameters. See the <code>mkfs.ext3</code> man page for more information.

The second command formats the first partition as FAT32 for use with the AM3517's boot ROM. This is a requirement to boot from the eMMC.

==== Adding Kernel and Bootloader ====

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /images}}
{{clio | hostname=emac-oe | pwd=images |cp MLO uImage u-boot.bin /mnt/card/}}
{{clio | hostname=emac-oe | pwd=images |sync}}
{{clio | hostname=emac-oe | pwd=images |umount /dev/mmcblk0p1}}
{{clos}}

{{ note | The first partition '''must''' be formatted FAT32 and the MLO binary '''must''' be in the first sector for the eMMC boot sequence to work properly. }}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe | pwd=images |mount /dev/mmcblk0p2 /mnt/card}}
{{clio | hostname=emac-oe | pwd=images |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p2}}
{{clos}}

=== SoM-9X25M / IPAC-9X25 / SoM-A5D35/6 / SoM-3354 / SoM-iMX6M / SoM-iMX6UL ===

Unlike the SoM-3517, these SoMs store U-Boot and the Linux kernel in a separate serial flash instead of the eMMC. Typically, two partitions are created. The first partition contains the complete filesystem and is mounted read-only while the second partition contains the /home directory and is mounted read-write.

=== Unmount partitions ===

{{cli | hostname=emac-oe |umount /dev/mmcblk0p1}}
{{cli | hostname=emac-oe |umount /dev/mmcblk0p2}}

==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk /dev/mmcblk0}}

{{ note | For the SoM-9x25M revisions 7 and above, the eMMC block device is /dev/sdb }}

The partitioning steps are as follows:

# Create 1st partition (n,p,1,default,+1G)
# Create 2nd partition (n,p,2,default,default)
# Write (w)

==== Formatting the eMMC ====
{{clo}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p2}}
{{clos}}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p1}}
{{clos}}

SOM-IMX6

2019-09-09T19:19:31Z

Mgloff:

{{todo| Review (02.15.2016-12:55->AW+)|Andrew Wichmann| project=OE 5.0,AW,Review }}



{{:Templateimpl:navpgtable | initials=AW | title=SOM-iMX6 | desc=A collection of pages for the SOM-iMX6 | project=OE 5.0 }} 




The SoM-iMX6 is a System on Module (SoM) based on the Freescale iMX.6 Cortex A9 Single, Dual or Quad Core processor. Designed and manufactured in the USA, this wide temperature, fanless ARM 1GHz SoM has 10/100/1000 BaseT Ethernet included along with 4 serial ports. It utilizes up to 4GB of eMMC Flash, up to 16MB of serial data flash, and up to 1GB of LP DDR2 RAM. A SoM is a small embedded module that contains the core of a microprocessor system.




{{:Templateimpl:navtableentry | title=SoM-iMX6 Web Link }}

{{:Templateimpl:Navti | [http://www.emacinc.com/products/system_on_module/SoM-iMX6M SoM-iMX6 Web Link] }}

{{:Templateimpl:navtend}}





{{:Templateimpl:navtableentry | title=SOM-iMX6 Downloads }}

{{:Templateimpl:Navti | [ftp://ftp.emacinc.com/SoM/SoM-IMX6M/Manual/SoM-iMX6M_User_Manual.pdf User Manual] }}
{{:Templateimpl:Navti | [ftp://ftp.emacinc.com/SoM/SoM-IMX6M/DataSheets/SoM-iMX6M_Datasheet.pdf Datasheet] }}

{{:Templateimpl:navtend}}




{{:Templateimpl:navtablenewrow}}




{{:Templateimpl:navtableentry | title=SoM-iMX6 Carrier Boards }}

*'''SoM-350ES'''
:{{:Templateimpl:Navti | [http://emacinc.com/products/system_on_module/SoM-350ES SoM-350ES Web Link] }}
:{{:Templateimpl:Navti | [ftp://ftp.emacinc.com/SoM/SoM-350ES/ SoM-350ES Downloads] }}

{{:Templateimpl:navtend}}





{{:Templateimpl:navtableentry | title=SoM-iMX6 Wiki Links }}

{{:Templateimpl:Navti | [[SoM-iMX6_Getting_Started | SoM-iMX6 Getting Started]] }}

{{:Templateimpl:navtend}}

Example io demo

2019-06-14T18:46:04Z

Mgloff:

{{todo|SEOKWREV (01.03.14-16:47->JG+);(01.03.14-17:35->MD+);(04.07.14-09:45->BS+);(04.09.14-16:15->BS+)|Jgreene|project=oe 4,oe 5,jg,md,SEOKWREV,ky,bs}}

{{#seo:
|title=io demo
|titlemode=append
|keywords=ADC example,Ring Counter,Binary Counter
|description=This is a guide to the <code>io_demo</code> C example project included in the EMAC OE SDK.
}}
This is a guide to the <code>[http://git.emacinc.com/OE/qt-creator-example-projects/tree/master/io_demo io_demo]</code> C example project included in the EMAC OE SDK.

The <code>io_demo</code> project provides four examples using SOM-150ES carrier board I/O: 
* An analog-to-digital converter demo.
* A counter demo.
* An input-to-output demo.
* A ring demo.

The <code>io_demo</code> project builds one executable: <code>io_demo</code>.

== Opening, Building and Uploading the Project Files ==

For information on opening the project from within Eclipse, please see [[Importing the EMAC OE SDK Projects with Eclipse]]. Then, follow [[Using the EMAC OE SDK Projects with Eclipse]] for information on how to build, upload and execute the example.

Alternatively, the <code>Makefile</code> can be used with the <code>make</code> command from the commandline to build and upload the example. For more information on this method, please see [[Using EMAC OE SDK Example Projects]].

== Usage and Behavior ==

===Hardware Requirements===

To use the '''io demo''' program you will need the following hardware.

* An EMAC [http://www.emacinc.com/som/som150es.htm SOM-150ES] carrier board. 
* A compatible EMAC SoM for that carrier board ([http://www.emacinc.com/products/system_on_module/SoM-9260M SOM-9260M], [http://www.emacinc.com/products/system_on_module/som-9G20m SOM-9G20M] and [http://www.emacinc.com/products/system_on_module/som-9x25 SOM-9X25] are all compatible). 
* A multimeter or oscilloscope. See [[Example_io_demo#Input_to_Output_Demo_Usage | Input to Output Demo]] and [[Example_io_demo#Count_Demo_Usage | Count Demo]] for details. 
* A cable long enough to reach from GPIO Port B to GPIO Port C. See [[Example_io_demo#Input_to_Output_Demo_Usage | Input to Output Demo]] for details. 

====Carrier Board====

[[File:know_your_som_150.jpg|frame|left|SOM-150ES carrier board with GPIO, LEDs and analog IO indicated.]]
 

This is a detail of the '''HDR1 PLD & BUFFERED GPIO''' header. Pin 49 is Vcc. The bottom pins: 2, 4, 6...46, 48, 50; are all ground. Port A is pins 1, 3, 5, 7, 9, 11, 13, 15. Port B is pins 17, 19, 21, 23, 25, 27, 29, 31. Port C is pins 33, 35, 37, 39, 41, 43, 45, 47.

[[File:gpio_header_detail.png]]

===io_demo Usage===

Run '''io demo''' from the console. It takes no parameters.

<syntaxhighlight lang="text">
./io_demo
</syntaxhighlight>

This brings up a menu of demos. 
<syntaxhighlight lang="console">
****************************
Demo Menu

A/D Demo - a
Count Demo - c
Input to Output Demo - i
Ring Demo - r

Exit - x

Enter Selection:
</syntaxhighlight>

Now, press '''a''', '''c''', '''i''' or '''r''' to run a demo; otherwise, press '''x''' to exit.

===A/D Demo Usage===

From the demo menu press '''a'''.

<syntaxhighlight lang="text">
****************************
Demo Menu

A/D Demo - a
Count Demo - c
Input to Output Demo - i
Ring Demo - r

Exit - x

Enter Selection: a

A/D Demo
[0]=126 [1]=11B [2]=12C [3]=12B
</syntaxhighlight>

The output shows the stray charge on the inputs being read by the analog-to-digital converter on pins 11, 12, 13, 14. Press '''a''' a few times to watch the values change.

This is the HDR8 ANALOG IO header.

[[File:analog_io_header_detail.jpg]]

Let's do a couple of experiments on our analog in pins.

Connect pin 20 to pin 11 and hit '''a'''. Note that the first value is higher than the others. It should read approximately '''3FF'''. This means that the first analog-in pin has 2.5V on it.

Connect pin 1 to pin 11. Hit '''a'''. Note that the first value is lower than the others. It's the vicinity of 0. That means that the first analog-in pin is pulled down to ground.

===Count Demo Usage===

From the demo menu press '''c'''.

The system counts from 0 to 255 in binary. It takes about 15 seconds to complete. 
The steps of this process are reflected in the GPIO PortC header pins (see [[Example_io_demo#Carrier_Board | Carrier Board]], above). As each bit in our 8-bit register is set to 1, the corresponding pin in the PortC header momentarily registers 5 volts (easily detected with a multimeter or oscilloscope).

More visibly, the counting process is also reflected in the strip of 8 LEDs on the board LD1-LD8. (see [[Example_io_demo#Carrier_Board | Carrier Board]], above). A lit LED indicates a 1 in our 8-bit register and an unlit LED indicates a 0. When the counting process is finished, all 8 LEDs are lit (255).

===Input to Output Demo Usage===

In this usage example the carrier board talks to itself. We send an 8-bit data stream directly from Port B to Port C via a short piece of cable. See [[Example_io_demo#Carrier_Board | Carrier Board]], above, for details.

This is the ribbon cable for the input-to-output demo. Note that we connect PortC:pin0 to PortB:pin0; PortC:pin1 to PortB:pin1; etc. 
[[File:iodemo_homemaderibboncable.jpg|500px|border|]]

Here's the cable plugged into the GPIO header. You see that PortC:pin0 outputs to PortB:pin0; PortC:pin1 outputs to PortB:pin1; etc.
[[File:iodemo_homemaderibboncable_closeup.jpg|500px|border|]]

The data stream for each pin is 1, 0, 1, 0, 1, 0... That is to say: all pins are set to 1, then they are all set to 0, then to 1 again, etc. We observe our data stream in the strip of 8 LEDs on the carrier board. They blink in unison.

'''Note''' The blinking may get a little out of sync after a few seconds. This is normal.

===Usage Example. Ring Demo===

From the demo menu press '''r'''.

The system sets a bit on Port C to 1, then sets it to 0, then sets the bit after that to 1, then sets that pin to 0, and so on, sequentially. This shows a ring counter on the LED strip (see [[Example_io_demo#Carrier_Board | Carrier Board]], above).

The steps of this process are reflected in the GPIO PortC header pins. As each bit in the 8-bit register is set to 1, the corresponding pin in the PortC header momentarily registers 5 volts (easily detected with a multimeter or oscilloscope).

Example io demo

2019-06-14T18:42:27Z

Mgloff:

{{todo|SEOKWREV (01.03.14-16:47->JG+);(01.03.14-17:35->MD+);(04.07.14-09:45->BS+);(04.09.14-16:15->BS+)|Jgreene|project=oe 4,oe 5,jg,md,SEOKWREV,ky,bs}}

{{#seo:
|title=io demo
|titlemode=append
|keywords=ADC example,Ring Counter,Binary Counter
|description=This is a guide to the <code>io_demo</code> C example project included in the EMAC OE SDK.
}}
This is a guide to the <code>io_demo</code> C example project included in the EMAC OE SDK.

The <code>io_demo</code> project provides four examples using SOM-150ES carrier board I/O: 
* An analog-to-digital converter demo.
* A counter demo.
* An input-to-output demo.
* A ring demo.

The <code>io_demo</code> project builds one executable: <code>io_demo</code>.

== Opening, Building and Uploading the Project Files ==

For information on opening the project from within Eclipse, please see [[Importing the EMAC OE SDK Projects with Eclipse]]. Then, follow [[Using the EMAC OE SDK Projects with Eclipse]] for information on how to build, upload and execute the example.

Alternatively, the <code>Makefile</code> can be used with the <code>make</code> command from the commandline to build and upload the example. For more information on this method, please see [[Using EMAC OE SDK Example Projects]].

== Usage and Behavior ==

===Hardware Requirements===

To use the '''io demo''' program you will need the following hardware.

* An EMAC [http://www.emacinc.com/som/som150es.htm SOM-150ES] carrier board. 
* A compatible EMAC SoM for that carrier board ([http://www.emacinc.com/products/system_on_module/SoM-9260M SOM-9260M], [http://www.emacinc.com/products/system_on_module/som-9G20m SOM-9G20M] and [http://www.emacinc.com/products/system_on_module/som-9x25 SOM-9X25] are all compatible). 
* A multimeter or oscilloscope. See [[Example_io_demo#Input_to_Output_Demo_Usage | Input to Output Demo]] and [[Example_io_demo#Count_Demo_Usage | Count Demo]] for details. 
* A cable long enough to reach from GPIO Port B to GPIO Port C. See [[Example_io_demo#Input_to_Output_Demo_Usage | Input to Output Demo]] for details. 

====Carrier Board====

[[File:know_your_som_150.jpg|frame|left|SOM-150ES carrier board with GPIO, LEDs and analog IO indicated.]]
 

This is a detail of the '''HDR1 PLD & BUFFERED GPIO''' header. Pin 49 is Vcc. The bottom pins: 2, 4, 6...46, 48, 50; are all ground. Port A is pins 1, 3, 5, 7, 9, 11, 13, 15. Port B is pins 17, 19, 21, 23, 25, 27, 29, 31. Port C is pins 33, 35, 37, 39, 41, 43, 45, 47.

[[File:gpio_header_detail.png]]

===io_demo Usage===

Run '''io demo''' from the console. It takes no parameters.

<syntaxhighlight lang="text">
./io_demo
</syntaxhighlight>

This brings up a menu of demos. 
<syntaxhighlight lang="console">
****************************
Demo Menu

A/D Demo - a
Count Demo - c
Input to Output Demo - i
Ring Demo - r

Exit - x

Enter Selection:
</syntaxhighlight>

Now, press '''a''', '''c''', '''i''' or '''r''' to run a demo; otherwise, press '''x''' to exit.

===A/D Demo Usage===

From the demo menu press '''a'''.

<syntaxhighlight lang="text">
****************************
Demo Menu

A/D Demo - a
Count Demo - c
Input to Output Demo - i
Ring Demo - r

Exit - x

Enter Selection: a

A/D Demo
[0]=126 [1]=11B [2]=12C [3]=12B
</syntaxhighlight>

The output shows the stray charge on the inputs being read by the analog-to-digital converter on pins 11, 12, 13, 14. Press '''a''' a few times to watch the values change.

This is the HDR8 ANALOG IO header.

[[File:analog_io_header_detail.jpg]]

Let's do a couple of experiments on our analog in pins.

Connect pin 20 to pin 11 and hit '''a'''. Note that the first value is higher than the others. It should read approximately '''3FF'''. This means that the first analog-in pin has 2.5V on it.

Connect pin 1 to pin 11. Hit '''a'''. Note that the first value is lower than the others. It's the vicinity of 0. That means that the first analog-in pin is pulled down to ground.

===Count Demo Usage===

From the demo menu press '''c'''.

The system counts from 0 to 255 in binary. It takes about 15 seconds to complete. 
The steps of this process are reflected in the GPIO PortC header pins (see [[Example_io_demo#Carrier_Board | Carrier Board]], above). As each bit in our 8-bit register is set to 1, the corresponding pin in the PortC header momentarily registers 5 volts (easily detected with a multimeter or oscilloscope).

More visibly, the counting process is also reflected in the strip of 8 LEDs on the board LD1-LD8. (see [[Example_io_demo#Carrier_Board | Carrier Board]], above). A lit LED indicates a 1 in our 8-bit register and an unlit LED indicates a 0. When the counting process is finished, all 8 LEDs are lit (255).

===Input to Output Demo Usage===

In this usage example the carrier board talks to itself. We send an 8-bit data stream directly from Port B to Port C via a short piece of cable. See [[Example_io_demo#Carrier_Board | Carrier Board]], above, for details.

This is the ribbon cable for the input-to-output demo. Note that we connect PortC:pin0 to PortB:pin0; PortC:pin1 to PortB:pin1; etc. 
[[File:iodemo_homemaderibboncable.jpg|500px|border|]]

Here's the cable plugged into the GPIO header. You see that PortC:pin0 outputs to PortB:pin0; PortC:pin1 outputs to PortB:pin1; etc.
[[File:iodemo_homemaderibboncable_closeup.jpg|500px|border|]]

The data stream for each pin is 1, 0, 1, 0, 1, 0... That is to say: all pins are set to 1, then they are all set to 0, then to 1 again, etc. We observe our data stream in the strip of 8 LEDs on the carrier board. They blink in unison.

'''Note''' The blinking may get a little out of sync after a few seconds. This is normal.

===Usage Example. Ring Demo===

From the demo menu press '''r'''.

The system sets a bit on Port C to 1, then sets it to 0, then sets the bit after that to 1, then sets that pin to 0, and so on, sequentially. This shows a ring counter on the LED strip (see [[Example_io_demo#Carrier_Board | Carrier Board]], above).

The steps of this process are reflected in the GPIO PortC header pins. As each bit in the 8-bit register is set to 1, the corresponding pin in the PortC header momentarily registers 5 volts (easily detected with a multimeter or oscilloscope).

Example io demo

2019-06-14T18:30:32Z

Mgloff:

{{todo|SEOKWREV (01.03.14-16:47->JG+);(01.03.14-17:35->MD+);(04.07.14-09:45->BS+);(04.09.14-16:15->BS+)|Jgreene|project=oe 4,oe 5,jg,md,SEOKWREV,ky,bs}}

{{#seo:
|title=io demo
|titlemode=append
|keywords=ADC example,Ring Counter,Binary Counter
|description=This is a guide to the <code>io_demo</code> C example project included in the EMAC OE SDK.
}}
This is a guide to the <code>io_demo</code> C example project included in the EMAC OE SDK.

The <code>io_demo</code> project provides four examples using SOM-150ES carrier board I/O: 
* An analog-to-digital converter demo.
* A counter demo.
* An input-to-output demo.
* A ring demo.

The <code>io_demo</code> project builds one executable: <code>io_demo</code>.

== Opening, Building and Uploading the Project Files ==

For information on opening the project from within Eclipse, please see [[Importing the EMAC OE SDK Projects with Eclipse]]. Then, follow [[Using the EMAC OE SDK Projects with Eclipse]] for information on how to build, upload and execute the example.

Alternatively, the <code>Makefile</code> can be used with the <code>make</code> command from the commandline to build and upload the example. For more information on this method, please see [[Using EMAC OE SDK Example Projects]].

== Usage and Behavior ==

===Hardware Requirements===

To use the '''io demo''' program you will need the following hardware.

* An EMAC [http://www.emacinc.com/som/som150es.htm SOM-150ES] carrier board. 
* A compatible EMAC SoM for that carrier board ([http://www.emacinc.com/products/system_on_module/SoM-9260M SOM-9260M], [http://www.emacinc.com/products/system_on_module/som-9G20m SOM-9G20M] and [http://www.emacinc.com/products/system_on_module/som-9x25 SOM-9X25] are all compatible). 
* A multimeter or oscilloscope. See [http://wikidev.emacinc.com/wiki/Example_io_demo#Input_to_Output_Demo_Usage Usage Example. Input to Output Demo] and [http://wikidev.emacinc.com/wiki/Example_io_demo#Count_Demo_Usage Usage Example. Count Demo] for details. 
* A cable long enough to reach from GPIO Port B to GPIO Port C. See [http://wikidev.emacinc.com/wiki/Example_io_demo#Input_to_Output_Demo_Usage Usage Example. Input to Output Demo] for details. 

====Carrier Board====

[[File:know_your_som_150.jpg|frame|left|SOM-150ES carrier board with GPIO, LEDs and analog IO indicated.]]
 

This is a detail of the '''HDR1 PLD & BUFFERED GPIO''' header. Pin 49 is Vcc. The bottom pins: 2, 4, 6...46, 48, 50; are all ground. Port A is pins 1, 3, 5, 7, 9, 11, 13, 15. Port B is pins 17, 19, 21, 23, 25, 27, 29, 31. Port C is pins 33, 35, 37, 39, 41, 43, 45, 47.

[[File:gpio_header_detail.png]]

===io_demo Usage===

Run '''io demo''' from the console. It takes no parameters.

<syntaxhighlight lang="text">
./io_demo
</syntaxhighlight>

This brings up a menu of demos. 
<syntaxhighlight lang="console">
****************************
Demo Menu

A/D Demo - a
Count Demo - c
Input to Output Demo - i
Ring Demo - r

Exit - x

Enter Selection:
</syntaxhighlight>

Now, press '''a''', '''c''', '''i''' or '''r''' to run a demo; otherwise, press '''x''' to exit.

===A/D Demo Usage===

From the demo menu press '''a'''.

<syntaxhighlight lang="text">
****************************
Demo Menu

A/D Demo - a
Count Demo - c
Input to Output Demo - i
Ring Demo - r

Exit - x

Enter Selection: a

A/D Demo
[0]=126 [1]=11B [2]=12C [3]=12B
</syntaxhighlight>

The output shows the stray charge on the inputs being read by the analog-to-digital converter on pins 11, 12, 13, 14. Press '''a''' a few times to watch the values change.

This is the HDR8 ANALOG IO header.

[[File:analog_io_header_detail.jpg]]

Let's do a couple of experiments on our analog in pins.

Connect pin 20 to pin 11 and hit '''a'''. Note that the first value is higher than the others. It should read approximately '''3FF'''. This means that the first analog-in pin has 2.5V on it.

Connect pin 1 to pin 11. Hit '''a'''. Note that the first value is lower than the others. It's the vicinity of 0. That means that the first analog-in pin is pulled down to ground.

===Count Demo Usage===

From the demo menu press '''c'''.

The system counts from 0 to 255 in binary. It takes about 15 seconds to complete. 
The steps of this process are reflected in the GPIO PortC header pins (see [http://wikidev.emacinc.com/wiki/Example_io_demo#Know_Your_Carrier_Board Know Your Carrier Board], above). As each bit in our 8-bit register is set to 1, the corresponding pin in the PortC header momentarily registers 5 volts (easily detected with a multimeter or oscilloscope).

More visibly, the counting process is also reflected in the strip of 8 LEDs on the board LD1-LD8. (see [http://wikidev.emacinc.com/wiki/Example_io_demo#Know_Your_Carrier_Board Know Your Carrier Board], above). A lit LED indicates a 1 in our 8-bit register and an unlit LED indicates a 0. When the counting process is finished, all 8 LEDs are lit (255).

===Input to Output Demo Usage===

In this usage example the carrier board talks to itself. We send an 8-bit data stream directly from Port B to Port C via a short piece of ribbon cable. See [[http://wikidev.emacinc.com/wiki/Example_io_demo#Know_Your_Carrier_Board Know Your Carrier Board]], above, for details.

This is the ribbon cable for the input-to-output demo. Note that we connect PortC:pin0 to PortB:pin0; PortC:pin1 to PortB:pin1; etc. 
[[File:iodemo_homemaderibboncable.jpg|500px|border|]]

Here's the cable plugged into the GPIO header. You see that PortC:pin0 outputs to PortB:pin0; PortC:pin1 outputs to PortB:pin1; etc.
[[File:iodemo_homemaderibboncable_closeup.jpg|500px|border|]]

The data stream for each pin is 1, 0, 1, 0, 1, 0... That is to say: all pins are set to 1, then they are all set to 0, then to 1 again, etc. We observe our data stream in the strip of 8 LEDs on the carrier board. They blink in unison.

'''Note''' The blinking may get a little out of sync after a few seconds. This is normal.

===Usage Example. Ring Demo===

From the demo menu press '''r'''.

The system sets a bit on Port C to 1, then sets it to 0, then sets the bit after that to 1, then sets that pin to 0, and so on, sequentially. This shows a ring counter on the LED strip (see [http://wikidev.emacinc.com/wiki/Example_io_demo#Know_Your_Carrier_Board Know Your Carrier Board], above).

The steps of this process are reflected in the GPIO PortC header pins. As each bit in the 8-bit register is set to 1, the corresponding pin in the PortC header momentarily registers 5 volts (easily detected with a multimeter or oscilloscope).

System Logging

2019-06-11T22:40:42Z

Mgloff:

{{todo| Complete (04.13.2015-14:44->BS+)(11.10.2015-18:00->MD+)(11.11.2015-10:30->MD+)(11.17.2015-18:10->MD+);(11.18.2015-12:55->MD+)(11.18.2015-14:50->MD+)(11.18.2015-15:10->KY+);(11.18.2015-15:50->ER+)|Mike Dean| project=OE 5.0,MD,Complete}}
{{#seo:
|title=System Logging
|titlemode=append
|keywords=syslogd,syslog-ng,busybox
|description=The page describes how to work with syslog.
}}




This document provides an overview of how system logging works in Linux, and provides guidance on how to work with and configure system logging so that it meets your needs.

__TOC__




{{:Templateimpl:bg | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
System Logging services exist on Linux systems to provide a central logging facility. This central logging service can store logged messages in files on the local machine, can forward the log messages to a remote machine for remote storage and display, and can output the log messages as they arrive to a terminal.

The syslog facility is standardized by POSIX and, as a result, there is a great deal of support for the syslog facility. There are APIs for logging to the syslog facility from C, C++, Python, Java, PHP, Perl, Bash, the commandline, and many other languages. Using the commandline tool, it is even possible to write to the syslog facility from the commandline.

==== Facilities ====

In syslog terminology, a facility is a category for log messages. There are generally at least seven standard syslog facilities on any Linux syslog system. The following list shows the standard seven, as well as some which are rarely used anymore (especially in embedded systems). The name of the facility is followed, in parenthesis, by the integer facility code associated with the facility, which is then followed by a description of the facility. The ones you should not expect to find on an embedded system are demarcated with an asterisk (*):

;kern(0)
: Kernel messages
;user(1)
: User Level Messages
;mail(2)*
: Mail System Messages
;daemon(3)
: System Daemon Messages
;auth(4)
: Security/Authentication Messages
;syslog(5)
: Internally Generated Syslog Messages
;lpr(6)*
: Line Printer Subsystem Messages
;news(7)*
: Network News Subsystem Messages
;uucp(8)*
: UUCP Subsystem Messages
;cron(15)
: Cron Scheduling Daemon Messages
;local(16-23)
: Locally Defined Usage, Messages

==== Severity ====

Each of these facilities accepts messages which will have an associated severity level. The severity level is important for filtering messages. The following list shows the eight available severity levels:

;emerg(0)
: Emergency - System is now unusable
;alert(1)
: Alert - Immediate Attention is Required
;crit(2)
: Critical - The System is in a Critical Condition, which may be caused by a failure in the primary appliction.
;err(3)
: Error - An Error has occurred.
;warning(4)
: Warning - An unusual, but not erroneous, event has occurred. For example: "Warning: Could not check for updates."
;notice(5)
: Notice - Uncommon but generally expected messages. For example: "Network Interface eth0 received IP address of 192.168.0.100 from DHCP server."
;info(6)
: Informational - Common, expected events generate these messages. For example: "Application XYZ started successfully."
;debug(7)
: Debug - Debugging messages belong at this level.

==== Storage ====

By default, the log messages on an EMAC OE Linux machine are stored in a local ramdisk. This type of storage prevents excessive wear of the flash, and works when all of the flash partitions are mounted read-only. However, by storing the messages in a ramdisk, all messages in the ramdisk will be lost as soon as the machine resets, powers off, or reboots for any reason.

===== Alternate Logging Locations =====

The syslog server can be configured to log to alternate locations. This is useful for configuring the server to log to persistent storage, such as a writable partition on the local flash or a partition on an SD card. The alternate logging locations can even be remote machines.

===== Remote Logging =====

The <code>/var/log</code> directory is the standard location for holding local log messages. This directory usually contains either one file per facility or one directory per facility. If a facility has a directory, it may contain different files which all belong to the facility. The system logging facility directs messages to these files based on rules set in its configuration. The configured rules use the facility level and the severity level to direct the syslogger's filters regarding to which file to send any particular message. There are several different implementations of the syslogger facility, each with its own configuration mechanisms and level of flexibility.

The system logger is also able to send messages to a remote syslog server over a network. The remote syslog server will be able to filter the messages using all of the same criteria as above, but also by source. A remote syslog server configuration can be very useful for remotely debugging deployed machines. While an embedded machine stores its logs on a ramdisk, the remote machine may store them to a traditional hard disk or SSD, allowing them to be preserved through power cycles.

The remote syslog server can be on any normal server, it can be on a developer's desktop, or it can be on another embedded machine. Sending debug messages to a central syslog server ensures the debug messages will be available even if the machine of interest freezes or resets. The use of a remote syslog server can also assist with looking for trends and outliers among a group of deployed machines since the log messages for the entire group of machines can be located in one place.

===== Log Rotation =====

Syslog servers incorporate a feature called log rotation. Log rotation is a process which prevents log files from growing beyond a certain size while preserving log messages for later reference. The syslog server (or logrotate system) can be configured with a maximum file size and a maximum number of rotated logs to keep. When the maximum file size is reached, the file will be "rotated." When the maximum number of logs to keep is exceeded, the oldest one will be deleted. There is more information on how this process works below.




{{:Templateimpl:geninfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}

====Your Daemons====

When developing a software daemon, syslog is a very useful tool for monitoring and debugging your software. The syslog daemon is highly configurable, allowing filters to be altered to suit the current needs of a developer without recompiling software. This capability allows developers to deploy software which sends ample debugging messages to the syslog server without fear of overwhelming the system with debug messages. Using the eight <code>local</code> facilities syslog recognizes, these debug messages can be categorized by developers to allow them to selectively choose the amount of log information they store from each of up to eight different subsystems. This is extremely useful when a system in the field is experiencing intermittent issues. By enabling maximum debugging output for only the subsystem responsible for the feature which is misbehaving, the developers have the greatest chance of seeing the messages they need to diagnose the source of the problem without overwhelming the system (or the storage) with messages. If eight facilities is not enough, the developers can always repurpose dedicated facilities which aren't in use by their intended systems. For instance, the line printing facility is rarely used on an embedded system, and may be safely repurposed by developers.

====Web Development====

When providing a web interface for an embedded system, the syslog daemon is often the only way to debug a variety of issues with the web server. When links don't work, certain browsers have issues, pages load slowly, or any of a myriad of other issues crop up, the logs are generally the first place people turn for answers. This is just as true on embedded systems as it is on any large scale web server or server farm. On embedded systems, however, the configuration for the logging system may need to be altered due to the volatile nature of the logs in the default configuration. This document provides information on how to solve the issues which may be encountered as a result of this.

====Machine Startup====

When configuring a machine to start up all the necessary services in the correct sequential order, when the machine is powered on, the syslog server is very helpful in performing the following tasks:
* Ensuring that process X really did start before process Y.
* Checking to see if any errors or warnings were reported by processes starting up.
* Ensuring that processes really did start, at all.
* Checking to see what configuration was chosen by a process which is capable of choosing its configuration dynamically.
* Checking the messages reported by device drivers as they start up.
* Determining the IP address used by a system which gets its network configuration via DHCP.
Startup scripts log their activity to the syslog daemon. Any daemon process launched by these startup scripts should also log startup messages to indicate that they're starting, how they're configured, and that they've finished the startup sequence and are now running. The system logs enable the engineer to assure that a machine has started as intended.

====Malfunctioning Systems====

When a proven system is malfunctioning, the system logs can be essential in determining the cause of the malfunction. In cases such as this, the system logs are helpful for:
* Looking to see who logged into a machine, and when.
* Looking for signs of attacks directed at the machine.
* Looking for signs of failing hardware.
* Looking for error and warning messages coming from system processes, daemons, and/or your custom application.
Without these logs, it may be nearly impossible to diagnose these malfunctions.

====In Brief====

This guide provides enough background information to enable you to handle any of the situations described above. Using the information contain herein, you will be able to approach any of the above listed problems with the tools you need to solve the problems you are facing.

{{note | To make best use of the log files, a working knowledge of <code>grep</code> is highly beneficial. Experience with crafting and using regular expressions with <code>grep</code> prior to writing system logging messages in your application and init scripts can make the diagnosis process simpler, since a little forethought into a syntax for the messages can make filtering the messages through <code>grep</code> much easier to accomplish correctly.}}




{{:Templateimpl:using | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
EMAC OE Linux 5.X uses Busybox's built-in version of syslog daemon, <code>syslogd</code>, by default. However, the <code>syslog-ng</code> package can be installed to provide a much more capable system logging daemon, when needed.

====About====

The standard syslog daemon supports the following configuration capabilities:
* Maximum size limit for log files.
* Maximum number of log files to keep, when rotated.
* Minimum priority level for messages to log.
* Duplicate dropping (not usually recommended).
* Log to remote and local files simultaneously, just to local files, or to a memory buffer which needs to be read by a special utility.

====Working With====

The syslog daemon is configured, by default, to log to a shared memory buffer. The messages are displayed with the <code>logread</code> utility.

The standard <code>/etc/syslog-startup.conf</code> configuration is shown below:

<syntaxhighlight lang=bash>
# This configuration file is used by the busybox syslog init script,
# /etc/init.d/syslog[.busybox] to set syslog configuration at start time.

DESTINATION=buffer # log destinations (buffer file remote)
LOGFILE=/var/log/messages # where to log (file)
REMOTE=loghost:514 # where to log (syslog remote)
REDUCE=no # reduce-size logging
DROPDUPLICATES=no # whether to drop duplicate log entries
#ROTATESIZE=0 # rotate log if grown beyond X [kByte]
#ROTATEGENS=3 # keep X generations of rotated logs
BUFFERSIZE=64 # size of circular buffer [kByte]
FOREGROUND=no # run in foreground (don't use!)
#LOGLEVEL=5 # local log level (between 1 and 8)
</syntaxhighlight>

;DESTINATION
: This configures where the syslog messages will be sent.
:;buffer
:: The <code>buffer</code> option will cause the messages to be stored in an internal circular buffer, in RAM. This buffer must be read with <code>logread</code>.
:;file
:: The <code>file</code> option will cause the messages to be stored in a file in the location specified by the <code>LOGFILE</code> parameter, listed below.
:;remote
:: The <code>remote</code> option will cause syslog messages to be sent to a remote syslog daemon.
;LOGFILE
: The <code>LOGFILE</code> parameter specifies the location of the logfile which should be used with the <code>file</code> destination.
;REMOTE
: The <code>REMOTE</code> parameter specifies the host and port to which to send remote log messages. The two part format for this variable provides the destination host followed by the destination port number, with a colon as the delimiter between the two. The destination may be specified as a hostname, or as an IP address. The destination port number should be the port on which the remote syslog server listens. Port 514 is the default syslog port. A syslog collector server will need to be installed and set up in order to log remotely.

{{note | If the destination is specified as a hostname, it is best to create an entry in <code>/etc/hosts</code> for the hostname so that it will resolve to an IP address even if there is a problem with the DNS servers.}}

;REDUCE
: The <code>REDUCE</code> option takes a <code>yes</code> or <code>no</code> argument. When set to <code>yes</code>, the syslog server will neglect to log the hostname, facility, and severity level with each log message. This is only recommended for severely resource constrained systems, since the facility and severity level are often used for filtering messages through <code>grep</code>.
;DROPDUPLICATES
: The <code>DROPDUPLICATES</code> option takes a <code>yes</code> or <code>no</code> argument. When set to <code>yes</code>, the syslog server will ignore messages which duplicate the preceeding message. This can be useful when an errant process keeps sending the same message over and over again, and swamps out the other messages as a result (due to the maximum size setting for the log files). It is best to keep this option off unless it is absolutely needed for a situation like the one just described, because having it turned on can cause other problems to be hidden (generally leading to frustration and/or embarrassment).
;ROTATESIZE
: The <code>ROTATESIZE</code> option takes a numeric argument. This argument is the maximum desired size for a log file, specified in kibibytes. When a log file has grown to the point where it exceeds this high water mark, it will be rotated.
;ROTATEGENS
: The <code>ROTATEGENS</code> option takes a numeric argument. This argument specifies the number of older generations of log files to keep in existence. By generations, it means the number of log files which have already been renamed with a sequencing number as a postfix. See the note below for more information.
{{note | Logfile rotation is a process which renames log files sequentially, to preserve older log messages while keeping incoming messages writing to the same location. For instance, for the <code>/var/log/messages</code> file, this might look like:<code>
messages -> messages.0
+messages</code>
Or, if one were to perform this rotation manually at a terminal, it may look like:
{{clo}}
{{clio | pwd=/var/log |mv messages messages.0}}
{{clio | pwd=/var/log |touch messages}}
{{clos}}
If there already is a <code>messages.0</code> file, and the number of generations to keep is set to 2, then a manual version of the rotation might look something like this:
{{clo}}
{{clio | pwd=/var/log |rm -f messages.2}}
{{clio | pwd=/var/log |mv messages.1 messages.2}}
{{clio | pwd=/var/log |mv messages.0 messages.1}}
{{clio | pwd=/var/log |mv messages messages.0}}
{{clio | pwd=/var/log |touch messages}}
{{clos}}
}}

;BUFFERSIZE
: The <code>BUFFERSIZE</code> option takes a numeric argument. This argument specifies the size of the internal circular buffer to use for holding log messages in an internal RAM buffer. This argument only matters when the <code>DESTINATION</code> is set to <code>buffer</code>. The size is specified in kibibytes.
;FOREGROUND
: The <code>FOREGROUND</code> option takes a <code>yes</code> or <code>no</code> argument. This argument specifies whether the <code>syslogd</code> process should run in the foreground or as a daemon. It is strongly recommended for this option to always be set to, <code>no</code>, to run <code>syslogd</code> as a daemon. This option mostly exists for the developers of Busybox to debug their <code>syslogd</code> implementation.
;LOGLEVEL
: The <code>LOGLEVEL</code> option takes a numeric argument. This argument specifies the highest numbered severity level which should be logged (see [[System_Logging#Severity | severity]] above). By default, this is set such that messages with a severity of '''notice''', or more severe, will be logged.

===Optional <code>syslog-ng</code> With <code>logrotate</code>===

The optional <code>syslog-ng</code> and <code>logrotate</code> option provides everything that's provided by the Busybox syslog daemon, plus:
* Sophisticated filters for directing log traffic.
* The ability to act as a central syslog server which receives log messages from remote syslog machines.
* Enhanced control over the destination(s) for log messages, allowing (for example) messages to be logged to a local RAMDISK, a local SD card (if available), and to a remote syslog server (if available) simultaneously.
* The ability to configure logrotate to automatically e-mail log files when they're rotated.

* Same syslog server software is readily available for Linux desktops and servers.
As can be expected, the potential drawback of <code>syslog-ng</code> is the steeper learning curve required to make use of its more sophisticated features. However, those already familiar with <code>syslog-ng</code> will be able to benefit from its extra sophistication immediately.

The official manual page for <code>syslog-ng</code> has more details: http://www.syslog.org/syslog-ng/v1/

Please contact EMAC for details on how to install <code>syslog-ng</code> and <code>logrotate</code> if you have trouble finding and installing them with <code>opkg</code>.




{{:Templateimpl:examples | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}

===Evaluating Log Messages===

Log messages are stored in <code>/var/log/</code> by default. This directory contains at least one log file, <code>messages</code>. There are usually (at least) a few other small log files which where generated by the kernel before <code>syslogd</code> started. When <code>syslog-ng</code> is used, you may have several log files which are continually growing, depending on how you configured it.

====Showing All the Messages====

When the log is rotated, a sequence of additional files will be generated from it, such as <code>messages.0</code>, <code>messages.1</code>, etc. The highest numbered file is the oldest. If you wish to look for messages through as much of the log history as possible, you will need to look through all of the available log files. Fortunately, this is simple. Say you have two rotated versions of the <code>messages</code> file, <code>messages.0</code> and <code>messages.1</code>. You can output all of the messages from these three files, in order, with the following command:

{{clop}}
{{cliop | pwd=/var/log |cat messages.1 messages.0 messages}}
Nov 17 19:00:21 ipac9x25 user.notice kernel: klogd started: BusyBox v1.23.1 (2015-07-02 12:53:54 CDT)
Nov 17 19:00:21 ipac9x25 user.notice kernel: Linux version 3.10.0-emac-standard+23f12b107c (developer@OEBuilder) (gcc
ersion 4.9.2 (GCC) ) #1 Tue Jul 21 21:46:40 CDT 2015
Nov 17 19:00:21 ipac9x25 user.warn kernel: CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Nov 17 19:00:21 ipac9x25 user.warn kernel: CPU: VIVT data cache, VIVT instruction cache
Nov 17 19:00:21 ipac9x25 user.warn kernel: Memory policy: ECC disabled, Data cache writeback
''etc.''
{{cliop | pwd=/var/log |}}
{{closp}}

You can combine this with <code>grep</code> to see only what you're interested in:

{{clop}}
{{cliop | pwd=/var/log |cat messages.1 messages.0 messages {{!}} grep authpriv}}
Nov 17 19:01:11 ipac9x25 authpriv.notice login[1046]: ROOT LOGIN on '/dev/ttyS5'
{{cliop | pwd=/var/log |}}
{{closp}}

Here, we can see that someone logged into the machine as the <code>root</code> user on November 17 at 7:01pm, on the serial console (<code>/dev/ttyS5</code>). This is the only login on the machine since it booted. Had there been other logins, they would also have been shown.

Say you want to see a certain type of message, but there are a lot of results. You can add <code>less</code> to make it easier to read through them:

{{clop}}
{{cliop | pwd=/var/log |cat messages.1 messages.0 messages {{!}} grep user.notice {{!}} less}}<nowiki>
Nov 17 19:00:21 ipac9x25 user.notice kernel: klogd started: BusyBox v1.23.1 (2015-07-02 12:53:54 CDT)
Nov 17 19:00:21 ipac9x25 user.notice kernel: Linux version 3.10.0-emac-standard+23f12b107c (developer@OEBuilder) (gcc version 4.9.2 (GCC) ) #1 Tue Jul 21 21:46:40 CDT 2015
Nov 17 19:00:21 ipac9x25 user.warn kernel: CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Nov 17 19:00:21 ipac9x25 user.warn kernel: CPU: VIVT data cache, VIVT instruction cache
Nov 17 19:00:21 ipac9x25 user.warn kernel: Memory policy: ECC disabled, Data cache writeback
Nov 17 19:00:21 ipac9x25 user.warn kernel: Clocks: CPU 400 MHz, master 133 MHz, main 12.000 MHz
Nov 17 19:00:21 ipac9x25 user.warn kernel: Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Nov 17 19:00:21 ipac9x25 user.notice kernel: Kernel command line: console=ttyS5,115200 root=/dev/mmcblk0p1 rootfstype=ext4
w rootwait
Nov 17 19:00:21 ipac9x25 user.notice kernel: Memory: 124820k/124820k available, 6252k reserved, 0K highmem
Nov 17 19:00:21 ipac9x25 user.notice kernel: klogd started: BusyBox v1.23.1 (2015-07-02 12:53:54 CDT)
Nov 17 19:00:21 ipac9x25 user.notice kernel: Linux version 3.10.0-emac-standard+23f12b107c (developer@OEBuilder) (gcc
ersion 4.9.2 (GCC) ) #1 Tue Jul 21 21:46:40 CDT 2015
Nov 17 19:00:21 ipac9x25 user.notice kernel: Kernel command line: console=ttyS5,115200 root=/dev/mmcblk0p1 rootfstype=ext4 rw rootwait
Nov 17 19:00:21 ipac9x25 user.notice kernel: Memory: 124820k/124820k available, 6252k reserved, 0K highmem
Nov 17 19:00:21 ipac9x25 user.notice kernel: Virtual kernel memory layout:
Nov 17 19:00:21 ipac9x25 user.notice kernel: vector : 0xffff0000 - 0xffff1000 ( 4 kB)
Nov 17 19:00:21 ipac9x25 user.notice kernel: fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
Nov 17 19:00:21 ipac9x25 user.notice kernel: vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
Nov 17 19:00:21 ipac9x25 user.notice kernel: lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
</nowiki>
{{closp}}

====Helper Functions====

When it gets to the point where there are several rotated log files, the command to cat them all can be a lot to type. Let's create a couple of helper functions to make our lives easier. We can enter these at the shell, as shown here. To save them permanently, put them in your <code>~/.bashrc</code> or <code>/etc/profile</code> file.

{{clop}}
{{cliop | pwd=/var/log |<nowiki>function genseq() { logfn=$1; max=$2; for i in $(seq $max -1 0); do printf "${logfn}.${i} "; done; printf "$logfn\n"; }</nowiki>}}
{{closp}}

This function generates a sequence of log file names for us to use, like this:

{{clop}}
{{cliop | pwd=/var/log |genseq messages 5}}
messages.5 messages.4 messages.3 messages.2 messages.1 messages.0 messages
{{cliop | pwd=/var/log |}}
{{closp}}

While we could use this list directly, it's still a bit awkward to type:

{{cli | pwd=/var/log |cat $(genseq messages 5)}}

Especially when piping to <code>grep</code> and maybe <code>less</code>, so let's make a helper function:

{{cli | pwd=/var/log |<nowiki>function catseq() { cat $(genseq $1 $2); }</nowiki>}}

Okay, now we can just type:

{{cli | pwd=/var/log |catseq messages 5}}

Much easier to type. We'll use this function from here on.

====Sifting Through Messages====

Here are a few ways you may wish to sift through messages.

=====Checking for Errors, Only=====

If you only want to look for error messages, you might type something like:

{{cli | pwd=/var/log |catseq messages 3 {{!}} grep '\.err '}}

The regular expression used here is to avoid false positives. Note the trailing space in the regular expression.

=====Checking for Errors and Worse=====

If you want to scan for messages which are of these categories (only):
* Emergency
* Alert
* Critical
* Error
You might do the following:

{{cli | pwd=/var/log |catseq messages 3 {{!}} egrep '\.(emerg{{!}}alert{{!}}crit{{!}}err) '}}

Note the use of <code>egrep</code> here; it is required for this extended regular expression to work.

=====Looking for Certain <code>local</code> Facility Messages=====

Perhaps you're making use of several of the <code>local</code> log facilities, and you wish to see all of the messages from just a few of them. In this example, we'll filter out all but two local facilities: <code>local3</code> and <code>local5</code>:

{{cli | pwd=/var/log |catseq messages 3 {{!}} grep ' local[35]\.'}}

Note the leading space in the regular expression. The 3 and 5 are listed in between square brackets. You can list numbers you're interested in individually and/or use ranges. If you wanted to list all <code>local</code> facility messages except for <code>local4</code>, you could write:

{{cli | pwd=/var/log |catseq messages 3 {{!}} grep ' local[0-35-7]\.}}

=====Looking for <code>local</code> Facility Messages of a Certain Priority=====

While you're debugging your application, you find that you need to see all events from certain <code>local</code> facilities which are of a subset of priority levels, because you're sure you'll figure out what's going wrong if you can get these specific messages. So, you ignore the mumblings of your coworkers about, "famous last words," and such, and you type:

{{cli | pwd=/var/log |catseq messages 3 {{!}} egrep ' local([0-246]\.(err{{!}}notice{{!}}warn){{!}}[357]\.(emerg{{!}}alert)) '}}

By cleverly crafting this complex regular expression, you were able to filter out exactly the right messages you needed to see the sequence of events leading up to the catastrophic failure you were experiencing and save the day. Your coworkers cheer and hoist you on their shoulders, singing your praises.

Okay, so in reality, nobody notices and you go to lunch happily, knowing that you're not going to get yelled at for a major fault. You treat yourself to some dessert (because, hey, why should Fido be the only one who gets a treat for doing something right?), and everyone's happy.

Of course, you wouldn't have been able to properly diagnose what went wrong without having generated good log messages from your software in the first place. The next section shows you how to generate the messages; you'll have to figure out how to make them good messages on your own, though.

===Writing to Syslog from Programs and Scripts===
As mentioned previously, many languages support writing to the Linux system logging daemon. There are many handy libraries and functions which provide this capability. Some of the most commonly used ones are shown here.

====Shell Utility: <code>logger</code>====
Whether you are writing a shell script, or simply wishing to enter something into the system logs from the commandline, the <code>logger</code> utility will give you the capability you need. This simple command takes a few options, but it can also be run with the only argument being the message to log.

=====Arguments to <code>logger</code>=====

The following options are available for <code>logger</code>:
;<code>-t</code> ''TAG''
: Takes a ''TAG'' as an argument. This option specifies a tag to use for labeling the message. Tags are useful for sorting through logs later on.
;<code>-p</code> ''Priority''
: Takes a ''Priority'' as an argument. The priority may be specified as just a numeric priority level, identifying the severity of the message, or it can be specified as a tuple containing a facility name and a priority level, delimited by a dot (<code>.</code>). If no facility is specified, the facility defaults to, <code>user</code>. The severity levels are specified in [[System_Logging#Severity | severity]] above. The facility names are specified in [[System_Logging#Facilities | facilities]] above.
;<code>-s</code>
: This option sets a boolean which enables logging messages to <code>stdout</code> as well as to the system logger. This is especially useful in interactive shell scripts, since it allows the developer to use one function to output a message to the screen and to the system logs simultaneously.

=====Examples of Using <code>logger</code>=====

To send a message to the system log as simply as possible:
{{clo}}
{{clio |logger "Default settings message example"}}
{{clio |tail -n 1 /var/log/messages}}
Nov 17 19:20:23 ipac9x25 user.notice root: Default settings message example
{{clos}}

To send a message to the system log with severity 3 (err):
{{clo}}
{{clio |logger -p 3 "This is an example error message"}}
{{clio |tail -n 1 /var/log/messages}}
Nov 17 19:22:06 ipac9x25 user.err root: This is an example error message
{{clos}}

To send a message with the facility, <code>local5</code>, and the severity 4 (warn):
{{clo}}
{{clio |logger -p local5.4 "This is a local5 facility warning message example."}}
{{clio |tail -n 1 /var/log/messages}}
Nov 17 19:23:51 ipac9x25 local5.warn root: This is a local5 facility warning message example.{{clos}}
To add a tag (highly recommended) to the above, use <code>-t</code>. Here, we use the tag, <code>EXAMPLE</code>:
{{clo}}
{{clio |logger -t EXAMPLE -p local5.4 "This is a local5 facility warning message example."}}
{{clio |tail -n 1 /var/log/messages}}
Nov 17 19:25:19 ipac9x25 local5.warn EXAMPLE: This is a local5 facility warning message example.
{{clos}}
Notice that the username (<code>root</code>) was replaced by the tag (<code>EXAMPLE</code>). When using tags in a script or program, it is best to come up with a unique tag and create a function for sending messages to the system log with this tag. That way, you can easily find all messages from just your program/script. If you have a complex program or set of scripts to debug, you could use multiple tags, but this will be more difficult to search for unless you use the optional <code>syslog-ng</code> to redirect the messages from your software to distinct files.
In an interactive script, you might use <code>logger</code> like this:
{{clo}}
{{clio|logger -t EXAMPLE -p local3.6 -s "Successfully wrote new configuration file."}}
EXAMPLE: Successfully wrote new configuration file.
{{clio |tail -n 1 /var/log/messages}}
Nov 17 19:25:19 ipac9x25 local5.warn EXAMPLE: This is a local5 facility warning message example.
{{clos}}
Notice that the message isn't visible in the system log? This is because the <code>syslogd</code> daemon on this machine is only configured to log messages which have a severity of 5 or lower. We might modify the example so that it will be logged, like this:
{{clo}}
{{clio|logger -t EXAMPLE -p local3.5 -s "Successfully wrote new configuration file."}}
EXAMPLE: Successfully wrote new configuration file.
{{clio |tail -n 1 /var/log/messages}}
Nov 17 19:31:37 ipac9x25 local3.notice EXAMPLE: Successfully wrote new configuration file.
{{clos}}

Now the message has been saved to the system logs as well as displayed on <code>stdout</code>.

====Writing to Syslog from a C Program====
There is a standard C function call on Linux for writing to the system logger. This function, <code>syslog()</code>, uses a persistent connection to the log facility which can be opened and closed using the associated <code>openlog()</code> and <code>closelog()</code> functions. However, if the <code>syslog()</code> function is called without first calling <code>openlog()</code>, the <code>syslog()</code> function will open the connection implicitly.

=====Essential Elements=====
The header file required for these functions is <code>syslog.h</code>.

The relevant functions are:

{{function | name=openlog |
<code>'''void openlog( const char * ident, int option, int facility )'''</code>
 The <code>openlog()</code> function is used to (optionally) open a connection to the log daemon before writing log messages. If the <code>openlog()</code> function is called, the <code>closelog()</code> function must also be called before exiting. The following parameters are accepted by this function: 
:;<code>'''ident'''</code>
:: The <code>ident</code> parameter is an identification string to use for log messages. This is just like the tag option to the <code>logger</code> command available from the shell. If this parameter is <code>null</code>, the identification string defaults to the name of the process sending the messages.
:;<code>'''option'''</code>
:: The <code>option</code> parameter is a bit string which accepts the following single bit masks:
::;<code>'''LOG_PERROR'''</code>
::: If on, any log messages sent will also go to the <code>stderr</code> stream associated with the current process.
::;<code>'''LOG_CONS'''</code>
::: This useful flag causes any messages which were unable to be sent to the system logger (due to any kind of failure) will be sent to the system console instead.
::;<code>'''LOG_PID'''</code>
::: When on, the process ID of the current process will be printed with each log message. This is especially useful for programs which call <code>fork()</code> at some point in their lifetime.
::;<code>'''LOG_NDELAY'''</code>
::: This option forces the connection to be established immediately, rather than deferred to a later point (such as at the beginning of the first call to the <code>syslog()</code> function.)
:;<code>'''facility'''</code>
:: This is the facility to which the log messages should be directed. The available facilities were described earlier in this document; see [[System_Logging#Facilities | facilities]].
}}

{{function | name=syslog |
<code>'''void syslog( int facility_priority, const char * format, ... )'''</code>
 The <code>syslog()</code> function is the core function for writing messages to the system log. This function may be called in between calls to <code>openlog()</code> and <code>closelog()</code>, or standalone. Using this function is very similar to using the standard <code>printf()</code> function, or is (perhaps) even more similar to the standard <code>fprintf()</code> function. The following parameters are accepted by this function: 
:;<code>'''facility_priority'''</code>
:: The <code>facility_priority</code> argument is an integer which will accept any of the following predefined macros:
::* LOG_USER
::* LOG_MAIL
::* LOG_DAEMON
::* LOG_AUTH
::* LOG_SYSLOG
::* LOG_LPR
::* LOG_NEWS
::* LOG_UUCP
::* LOG_CRON
::* LOG_AUTHPRIV
::* LOG_FTP
::* LOG_LOCAL0
::* LOG_LOCAL1
::* LOG_LOCAL''2 through 7''...
:: These facility priorities correspond to the facilities discussed earlier in [[System_Logging#Facilities | facilities]].
:; <code>'''format'''</code>
:: The <code>format</code> parameter accepts a string with formatting parameters identical to the kind used for the standard <code>printf()</code> function. For information on how to craft such formatting strings, see the <code>printf()</code> documentation.
:; <code>'''...'''</code> ''(ellipsis operator)''
:: Any arguments needed for the formatting string are passed here, just like with the standard <code>printf()</code> function.
}}

{{function | name=closelog |
<code>'''void closelog( void )'''</code>
 The <code>closelog()</code> function must be called before exiting the program, but only if the <code>openlog()</code> function was called earlier. The <code>openlog()</code> and <code>closelog()</code> functions should be treated the same as <code>fopen()</code> and <code>fclose()</code>, or <code>malloc()</code> and <code>free()</code>.
 
This function takes no arguments.
}}

{{function | name=setlogmask |
<code>'''int setlogmask( int mask )'''</code>
 The <code>setlogmask()</code> function controls what messages get sent to the <code>syslog</code> server. While the <code>syslog</code> server does message filtering of its own, this function prevents the messages from ever reaching the <code>syslog</code> server. This type of filtering is good to use in conjunction with debug macros in order to reduce the overhead caused by having ample log messages spread throughout your software.
 
Each bit set in the <code>mask</code> represents a priority level. If the bit is set, a message of the corresponding priority level will be sent to syslog; otherwise, it won't. The <code>LOG_MASK</code> macro is used to translate priority levels into appropriate bits, such as <code>LOG_MASK( LOG_ERROR )</code>.
 
Using the <code>LOG_UPTO</code> macro is the easiest way to set the mask. Since the most critical error message has a value of zero, and every less critical message has a value greater than zero, the <code>LOG_UPTO</code> macro will create a mask which passes the given priority level and anything more severe. For example, to pass messages which have a severity of Warning or worse, you may use: <code>LOG_UPTO( LOG_WARN )</code>.
:;<code>mask</code>
:: The <code>mask</code> parameter is used to determine what messages to pass to <code>syslog</code>, as described above.
:;''Returns'': <code>int</code>
:: The previously set log mask is returned by the function. You may safely discard it if you don't intend to restore it later.
For example:
<syntaxhighlight lang=C>
#include <syslog.h>

int main( int argc, char ** argv )
{
setlogmask( LOG_UPTO( LOG_WARN ) );
syslog( LOG_INFO, "You'll never see me!" );
syslog( LOG_WARN, "Now you see me." );

return 0;
}
</syntaxhighlight>
}}

=====Examples of Using the C <code>syslog()</code> Function (and Friends)=====

The most simple use of this function is found in the following <code>Hello, World</code> style program:

<syntaxhighlight lang=C>
#include <syslog.h>

int main( int argc, char ** argv )
{
syslog( LOG_INFO, "Hello, World from syslog()!" );

return 0;
}
</syntaxhighlight>

Note the lack of a newline character. You should not pass newlines to syslog. If you do, they will be stripped off.

A slightly more sophisticated use of syslog follows:

<syntaxhighlight lang=C>
#include <syslog.h>
#include <unistd.h>

int main( int argc, char ** argv )
{
int i;
// Use "MyEXAMPLE" as the "tag" for messages. Log output to stderr and to the system log, and include my PID.
openlog( "MyEXAMPLE", LOG_PERROR | LOG_PID );
// Let's generate some output.
syslog( LOG_WARN, "You have until the count of ten, Mr..." );

for( i = 10; i > 0; --i )
{
syslog( LOG_WARN, "%d", i );
sleep( 1 );
}

syslog( LOG_ERR, "I warned you, sir and/or madam. You almost made an error. If you'd broken out of this with" );
syslog( LOG_ERR, "Control-C, the closelog() call never would have been made. Whew. That was a close one. Next" );
syslog( LOG_ERR, "time make sure to catch the SIGINT signal (at the least) and call the closelog() function in" );
syslog( LOG_ERR, "your signal handler to such avoid wasteful behavior." );

closelog();

return 0;
}
</syntaxhighlight>




{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
This article covered quite a bit of territory. You were given an overview of how logging works on Linux systems. We then talked about a variety of ways in which people make use of these logs to solve real world problems. We covered the basics of the standard <code>syslog</code> system for EMAC OE Linux as well as the alternative, <code>syslog-ng</code>, and gave an overview of what extras you can gain by installing <code>syslog-ng</code>. Next, we went through several examples of searching through messages to find the ones which are relevant to your current needs. Finally, we covered ways to send messages to the syslog service from software, and from the commandline as well. We didn't cover all programming languages, but the information presented here should provide a solid enough foundation for you to perform a search on the Internet for a syslog client library for other programming languages, and to make use of what you find quickly and easily.




{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Installing_EMAC_OE_5.0_SDK | Installing the EMAC SDK]]

{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Opkg | Working With the OPKG Package Manager]]

Loading Images with U-Boot

2019-04-15T19:26:35Z

Mgloff:

{{#seo:
|title=Loading Images with U-Boot
|titlemode=append
|keywords=U-Boot,OS Image,TFTP Server
|description=This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process.
}}
While U-Boot is used to load and execute the OS after initial programming, it can also be used to program the OS images to the local flash. This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process. Review the [[U-Boot Overview]] page for an introduction to U-Boot before continuing.

== Requirements ==
A TFTP server must be accessible on the local network. The specific details of TFTP server setup and configuration can be found on the [[Installing TFTP server]] page. Alternatively, NFS can be used in place of TFTP but will require an NFS server. Information on how to set up an NFS server [[Setting_up_an_NFS_File_Server | can be found here]]. Please contact EMAC if you need details on how to use NFS instead of TFTP to load images.

== Configuration ==
In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration or DHCP can be used on some systems (requires DHCP server). Typically, the IP address of the board and the IP address of the TFTP server are the only settings that need to be defined. The network mask and broadcast address will be determined automatically from these settings, and no default gateway setting is required if the server is on the same subnetwork as the board. Before continuing, determine a valid static network address for your local network; contact your IT department for more information on what address to use if required. The example below shows how to set the IP address of the board to 192.168.2.2 and the TFTP server IP address to 192.168.2.1:
{{clop}}<nowiki>U-Boot> setenv ipaddr 192.168.2.2
U-Boot> setenv serverip 192.168.2.1
U-Boot> saveenv
Saving Environment to dataflash...
U-Boot> reset</nowiki>{{closp}}

Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:
{{clop}}<nowiki>U-Boot> ping 192.168.2.1
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
host 192.168.2.1 is alive</nowiki>{{closp}}

== Loading Images to RAM ==
Files are loaded directly into RAM through TFTP. In order to load the image, you must know the physical address of the RAM device on the system. Refer to the documentation for your target board if you are unsure what value to use. The U-Boot environment variable <code>loadaddr</code> should already be set and can be used in place of the hex addresses below. The standard addresses for some common EMAC systems are shown in Table 1 below.

{| class="wikitable"
! colspan="2"|Table 1: Physical RAM Addresses
|-
! Product !! RAM Start Address
|-
| SoM-9260M || 0x20000000
|-
| SoM-9G20M || 0x20000000
|-
| SoM-9G45M || 0x70000000
|-
| SoM-3517M || 0x82000000
|-
| SoM-9x25M || 0x22000000
|-
| Ipac-9x25M || 0x22000000
|-
| SoM-9G25M || 0x22000000
|-
| SoM-A5D35M || 0x22000000
|-
| SoM-A5D36M || 0x22000000
|-
| SoM-3354M || 0x82000000
|-
| SoM-iMX6M || 0x12000000
|-
| SoM-iMX6UL || 0x82000000
|}

{{ warning | Before transferring a file to the system, make sure that it does not exceed the size of the available RAM. }}

The <code>tftp</code> U-Boot command is used to transfer files to the system. The command requires two arguments: the address to load the file into and the filename of the image on the TFTP server. The example below demonstrates loading a kernel image named <code>uImage-2.6.30</code> to RAM on an SoM-9G45M.
{{clop}}<nowiki>U-Boot> tftp ${loadaddr} uImage-2.6.30
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage-2.6.30'.
Load address: 0x70000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
############################
done
Bytes transferred = 1472456 (1677c8 hex)
U-Boot> printenv filesize
filesize=1677C8</nowiki>{{closp}}

{{ note | Note that the <code>filesize</code> variable has been automatically updated to the size of the file that was loaded.}}

== Executing kernel from RAM ==
In some situations, it is advantageous to execute the image directly from RAM after loading with TFTP rather than saving to flash. This is especially helpful when testing new Linux kernel images. Furthermore, the boot command can be set such that the image is automatically downloaded and executed on each boot, making testing more efficient.

After loading a bootable image to RAM, you can execute it directly using the <code>bootm</code> command for a uImage kernel or <code>bootz</code> for a zImage kernel. For example, after loading the kernel image above, running <code>bootm 0x70000000</code> would boot the board using the new image without making any changes to the images stored on the flash.

To update the <code>bootcmd</code> variable to download the image on each boot, simply replace the command used to load the image from flash with the TFTP download command. The following example illustrates this process on an SoM-9G45M module.
{{clop}}<nowiki>U-Boot> printenv bootcmd
bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000
U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000'
U-Boot> saveenv
Saving Environment to dataflash...</nowiki>{{closp}}

== Copying to Flash ==
The process of copying an image from RAM to flash memory differs depending on what type of flash storage devices are available on the system. Many systems have more than one device, such as serial DataFlash and NAND flash. This section explains the process of storing an image to non-volatile storage.

=== NOR Flash ===
A combination of the <code>erase</code> and <code>cp</code> commands are used to program an image to a NOR flash device. NOR flash is directly memory-mapped to the system at a physical address. Also, each image (U-Boot, bootstrap, kernel, filesystem) must be stored at the correct offset for the system to operate correctly. Refer to the documentation for your hardware for more information on the correct address ranges to use. The <code>flinfo</code> command can be used to display the addressing of available flash devices on the system.

After loading the image to RAM, the flash device should be erased followed by copying the image to the appropriate offset in the flash. The example below illustrates the commands used to program a new kernel image to a SoM-9260M module. Note the use of the <code>protect off all</code> command, which is required to unlock the flash on some systems.
{{clop}}<nowiki>U-Boot> protect off all
U-Boot> tftp 0x20000000 ${kernel_name}
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}</nowiki>{{closp}}

{{ note | Note that NOR flash can take a significant amount of time to program if the image size is large.}}

=== Serial DataFlash ===
Serial DataFlash is an SPI-based NOR flash device that is used on many systems that employ NAND flash as the primary storage device. On these systems, low-level boot code such as the bootstrap, U-Boot, and OS kernel are typically stored on the DataFlash device. As with NOR flash, the <code>flinfo</code> command can be used to determine the memory addressing layout of the DataFlash device. The <code>erase</code> command does not support the DataFlash devices and should not be used before programming an image. The <code>cp</code> command is capable of copying an image from RAM to DataFlash.

The example below illustrates the commands used to copy a kernel image to the DataFlash device on a SoM-9G45M module.
{{clop}}<nowiki>U-Boot> tftpboot 0x70000000 ${kernel_name}
U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}</nowiki>{{closp}}

=== NAND Flash ===
Generally, NAND flash is used to store only the root filesystem and auxiliary storage partitions of the OS. Storing an image to NAND flash under U-Boot uses a different set of commands than NOR or DataFlash devices. See <code>help nand</code> for more information on the available commands for examining and manipulating NAND flash devices. To gain information on what NAND devices are available on the system, use the command <code>nand info</code>. In general, programming a NAND flash device is much faster than programming NOR or DataFlash devices.

The example below illustrates the process of loading the root JFFS2 filesystem onto an SoM-9G45M device. Note that the device is erased prior to programming it.
{{clop}}<nowiki>U-Boot> nand erase
U-Boot> tftp 0x70000000 ${rootfs_name}
U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}</nowiki>{{closp}}

=== SPI NOR/eMMC Flash ===
Most of EMAC's newer SoM offerings utilize an eMMC flash for filesystem and auxiliary storage partitions of the OS and an SPI flash to store the bootloader and kernel. To reprogram the eMMC, see [[Loading_Images_onto_eMMC_Devices|Loading Images onto eMMC Devices]]. Be sure that the <code>loadaddr</code> variable is set and matches the table above. The example below illustrates the commands used to program a new kernel image to a SoM-9x25M module.
{{clop}}<nowiki>U-Boot> pri loadaddr
U-Boot> tftp ${loadaddr} zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize}
U-Boot> setenv kernelsize ${filesize};saveenv</nowiki>{{closp}}

Note: the "pri loadaddr" step above is not required it is just entered to make sure the variable is set.

== Scripting ==
U-Boot also includes a scripting feature that allows a script file with U-Boot commands to be loaded and executed. This can make the task of programming multiple systems much more efficient. The <code>mkimage</code> utility is required on a Linux development system in order to create a valid U-Boot image from a script. This section gives a brief example of a U-Boot script for programming a Linux kernel and filesystem.

Creating a text file with all of the desired commands is the first step in creating a U-Boot script. The example below is a script file used by EMAC to program SoM-9260M modules:
<syntaxhighlight lang=php>
echo ===== Setting Environment =====
setenv bootdelay 1
setenv rev sl013-aon-30010
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
setenv kernel_name ${rev}-uImage
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
saveenv
echo ===== Loading Kernel =====
protect off all
tftpboot 0x20000000 ${kernel_name}
erase 0x10100000 0x103fffff
cp.b 0x20000000 0x10100000 ${filesize}
setenv kernelsize ${filesize}
echo ===== Loading Root Filesystem =====
tftpboot 0x20000000 ${rootfs_name}
erase 0x10400000 0x11ffffff
cp.b 0x20000000 0x10400000 ${filesize}
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
saveenv
echo ===== DONE! =====
</syntaxhighlight>

Once the file has been created and saved, the <code>mkimage</code> utility must be used to create a U-Boot script image. A shell script such as the one shown below may be used to aid in this process:
<syntaxhighlight lang="bash">
#!/bin/sh

if [ ! -f "$1" ] || [ $# -lt 2 ]
then
echo "Usage: $0 SCRIPTNAME OUTPUTNAME"
exit 1
fi

mkimage -T script -C none -A arm -n 'SoM9260 Load Script' -d $1 $2
</syntaxhighlight>

Note that the script assumes that <code>mkimage</code> is installed in the user's PATH. The script should be run with the name of the existing file as the first argument and the desired output filename as the second argument:
{{cli|username=developer|hostname=ldc|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it should be copied to the TFTP server root directory, in this example <code>/srv/tftp</code> is used.
{{cli|username=developer|hostname=ldc|sudo cp sl013-aon-30010-flash-script.img /srv/tftp/}}

The image file can now be transferred to the board and executed as illustrated below:
{{clop}}<nowiki>U-Boot> tftp 0x20000000 sl013-aon-30010-flash-script.img
U-Boot> source 0x20000000</nowiki>{{closp}}

{{ note | Note that the U-Boot command <code>source</code> was not available on older versions of U-Boot. If the command is not recognized, use <code>autoscr</code> instead.}}

U-Boot will execute all commands in the script line-by-line until the script has finished, at which point the U-boot prompt will be returned to the user.




{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
In this article, you have seen how to load an image into RAM using U-Boot. You have seen how to execute an image from RAM. You have also seen how to copy an image from RAM to flash; how to configure your system to boot from an image once it has been saved to flash is documented elsewhere (see Related Information, below). You have also seen a brief description of how to create scripts for U-Boot.

With the information provided by this document, you are set to begin loading alternate kernels and filesystems onto EMAC hardware. These kernels and filesystems could be alternatives provided to you by EMAC, or they could be ones you create yourself. This provides you with a great deal of flexibility for your development work.




{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]
* [[Loading_JFFS2_Images_Onto_a_Board | Loading JFFS2 Images Onto a Board]]
* [[Archiving_JFFS2_Images | Archiving JFFS2 Images]]

{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[U-Boot_Overview | U-Boot Overview]]
* [[Creating_JFFS2_Images | Creating JFFS2 Images]]
* [[Mounting_JFFS2_Images_on_a_Linux_PC | Mounting JFFS2 Images on a Linux PC]]
* [[Repartitioning_NAND_Flash_with_JFFS2_for_Linux | Repartitioning NAND Flash with JFFS2 for Linux]]
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Booting_with_an_NFS_Root_Filesystem | Booting with an NFS Root Filesystem]]

Loading Images with U-Boot

2019-04-15T17:39:17Z

Mgloff:

{{todo|Complete (12.16.13-01:25->MD-);(12.31.13-11:02->MW+);(12.31.13-11:30->KY+);(12.31.13-11:35->MG+);(03.06.14-15:30->BS-);(04.11.14-15:55->BS+)(11.06.15-12:45->MG+)(11.13.2015-13:25->MD-);(11.13.2015-16:39->ER+);(11.13.2015-17:30->MD+);(11.17.2015-13:50->KY+);(11.17.2015-14:30->MG+)|Michael Welling|project=oe 4,oe 5,mw,md,ky,mg,bs,er,Complete}}



{{#seo:
|title=Loading Images with U-Boot
|titlemode=append
|keywords=U-Boot,OS Image,TFTP Server
|description=This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process.
}}
While U-Boot is used to load and execute the OS after initial programming, it can also be used to program the OS images to the local flash. This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process. Review the [[U-Boot Overview]] page for an introduction to U-Boot before continuing.

== Requirements ==
A TFTP server must be accessible on the local network. The specific details of TFTP server setup and configuration can be found on the [[Installing TFTP server]] page. Alternatively, NFS can be used in place of TFTP but will require an NFS server. Information on how to set up an NFS server [[Setting_up_an_NFS_File_Server | can be found here]]. Please contact EMAC if you need details on how to use NFS instead of TFTP to load images.

== Configuration ==
In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration or DHCP can be used on some systems (requires DHCP server). Typically, the IP address of the board and the IP address of the TFTP server are the only settings that need to be defined. The network mask and broadcast address will be determined automatically from these settings, and no default gateway setting is required if the server is on the same subnetwork as the board. Before continuing, determine a valid static network address for your local network; contact your IT department for more information on what address to use if required. The example below shows how to set the IP address of the board to 192.168.2.2 and the TFTP server IP address to 192.168.2.1:
{{clop}}<nowiki>U-Boot> setenv ipaddr 192.168.2.2
U-Boot> setenv serverip 192.168.2.1
U-Boot> saveenv
Saving Environment to dataflash...
U-Boot> reset</nowiki>{{closp}}

Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:
{{clop}}<nowiki>U-Boot> ping 192.168.2.1
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
host 192.168.2.1 is alive</nowiki>{{closp}}

== Loading Images to RAM ==
Files are loaded directly into RAM through TFTP. In order to load the image, you must know the physical address of the RAM device on the system. Refer to the documentation for your target board if you are unsure what value to use. The standard addresses for some common EMAC systems are shown in Table 1 below.

{| class="wikitable"
! colspan="2"|Table 1: Physical RAM Addresses
|-
! Product !! RAM Start Address
|-
| SoM-9260M || 0x20000000
|-
| SoM-9G20M || 0x20000000
|-
| SoM-9G45M || 0x70000000
|-
| SoM-3517M || 0x82000000
|-
| SoM-9x25M || 0x22000000
|-
| Ipac-9x25M || 0x22000000
|-
| SoM-9G25M || 0x22000000
|-
| SoM-A5D35M || 0x22000000
|-
| SoM-A5D36M || 0x22000000
|-
| SoM-3354M || 0x82000000
|-
| SoM-iMX6M || 0x12000000
|-
| SoM-iMX6UL || 0x82000000
|}

{{ warning | Before transferring a file to the system, make sure that it does not exceed the size of the available RAM. }}

The <code>tftp</code> U-Boot command is used to transfer files to the system. The command requires two arguments: the address to load the file into and the filename of the image on the TFTP server. The example below demonstrates loading a kernel image named <code>uImage-2.6.30</code> to RAM on an SoM-9G45M.
{{clop}}<nowiki>U-Boot> tftp 0x70000000 uImage-2.6.30
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage-2.6.30'.
Load address: 0x70000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
############################
done
Bytes transferred = 1472456 (1677c8 hex)
U-Boot> printenv filesize
filesize=1677C8</nowiki>{{closp}}

{{ note | Note that the <code>filesize</code> variable has been automatically updated to the size of the file that was loaded.}}

== Executing kernel from RAM ==
In some situations, it is advantageous to execute the image directly from RAM after loading with TFTP rather than saving to flash. This is especially helpful when testing new Linux kernel images. Furthermore, the boot command can be set such that the image is automatically downloaded and executed on each boot, making testing more efficient.

After loading a bootable image to RAM, you can execute it directly using the <code>bootm</code> command for a uImage kernel or <code>bootz</code> for a zImage kernel. For example, after loading the kernel image above, running <code>bootm 0x70000000</code> would boot the board using the new image without making any changes to the images stored on the flash.

To update the <code>bootcmd</code> variable to download the image on each boot, simply replace the command used to load the image from flash with the TFTP download command. The following example illustrates this process on an SoM-9G45M module.
{{clop}}<nowiki>U-Boot> printenv bootcmd
bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000
U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000'
U-Boot> saveenv
Saving Environment to dataflash...</nowiki>{{closp}}

== Copying to Flash ==
The process of copying an image from RAM to flash memory differs depending on what type of flash storage devices are available on the system. Many systems have more than one device, such as serial DataFlash and NAND flash. This section explains the process of storing an image to non-volatile storage.

=== NOR Flash ===
A combination of the <code>erase</code> and <code>cp</code> commands are used to program an image to a NOR flash device. NOR flash is directly memory-mapped to the system at a physical address. Also, each image (U-Boot, bootstrap, kernel, filesystem) must be stored at the correct offset for the system to operate correctly. Refer to the documentation for your hardware for more information on the correct address ranges to use. The <code>flinfo</code> command can be used to display the addressing of available flash devices on the system.

After loading the image to RAM, the flash device should be erased followed by copying the image to the appropriate offset in the flash. The example below illustrates the commands used to program a new kernel image to a SoM-9260M module. Note the use of the <code>protect off all</code> command, which is required to unlock the flash on some systems.
{{clop}}<nowiki>U-Boot> protect off all
U-Boot> tftp 0x20000000 ${kernel_name}
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}</nowiki>{{closp}}

{{ note | Note that NOR flash can take a significant amount of time to program if the image size is large.}}

=== Serial DataFlash ===
Serial DataFlash is an SPI-based NOR flash device that is used on many systems that employ NAND flash as the primary storage device. On these systems, low-level boot code such as the bootstrap, U-Boot, and OS kernel are typically stored on the DataFlash device. As with NOR flash, the <code>flinfo</code> command can be used to determine the memory addressing layout of the DataFlash device. The <code>erase</code> command does not support the DataFlash devices and should not be used before programming an image. The <code>cp</code> command is capable of copying an image from RAM to DataFlash.

The example below illustrates the commands used to copy a kernel image to the DataFlash device on a SoM-9G45M module.
{{clop}}<nowiki>U-Boot> tftpboot 0x70000000 ${kernel_name}
U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}</nowiki>{{closp}}

=== NAND Flash ===
Generally, NAND flash is used to store only the root filesystem and auxiliary storage partitions of the OS. Storing an image to NAND flash under U-Boot uses a different set of commands than NOR or DataFlash devices. See <code>help nand</code> for more information on the available commands for examining and manipulating NAND flash devices. To gain information on what NAND devices are available on the system, use the command <code>nand info</code>. In general, programming a NAND flash device is much faster than programming NOR or DataFlash devices.

The example below illustrates the process of loading the root JFFS2 filesystem onto an SoM-9G45M device. Note that the device is erased prior to programming it.
{{clop}}<nowiki>U-Boot> nand erase
U-Boot> tftp 0x70000000 ${rootfs_name}
U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}</nowiki>{{closp}}

=== SPI NOR/eMMC Flash ===
Most of EMAC's newer SoM offerings utilize an eMMC flash for filesystem and auxiliary storage partitions of the OS and an SPI flash to store the bootloader and kernel. To reprogram the eMMC, see [[Loading_Images_onto_eMMC_Devices|Loading Images onto eMMC Devices]]. Be sure that the <code>loadaddr</code> variable is set and matches the table above. The example below illustrates the commands used to program a new kernel image to a SoM-9x25M module.
{{clop}}<nowiki>U-Boot> pri loadaddr
U-Boot> tftp ${loadaddr} zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize}
U-Boot> setenv kernelsize ${filesize};saveenv</nowiki>{{closp}}

Note: the "pri loadaddr" step above is not required it is just entered to make sure the variable is set.

== Scripting ==
U-Boot also includes a scripting feature that allows a script file with U-Boot commands to be loaded and executed. This can make the task of programming multiple systems much more efficient. The <code>mkimage</code> utility is required on a Linux development system in order to create a valid U-Boot image from a script. This section gives a brief example of a U-Boot script for programming a Linux kernel and filesystem.

Creating a text file with all of the desired commands is the first step in creating a U-Boot script. The example below is a script file used by EMAC to program SoM-9260M modules:
<syntaxhighlight lang=php>
echo ===== Setting Environment =====
setenv bootdelay 1
setenv rev sl013-aon-30010
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
setenv kernel_name ${rev}-uImage
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
saveenv
echo ===== Loading Kernel =====
protect off all
tftpboot 0x20000000 ${kernel_name}
erase 0x10100000 0x103fffff
cp.b 0x20000000 0x10100000 ${filesize}
setenv kernelsize ${filesize}
echo ===== Loading Root Filesystem =====
tftpboot 0x20000000 ${rootfs_name}
erase 0x10400000 0x11ffffff
cp.b 0x20000000 0x10400000 ${filesize}
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
saveenv
echo ===== DONE! =====
</syntaxhighlight>

Once the file has been created and saved, the <code>mkimage</code> utility must be used to create a U-Boot script image. A shell script such as the one shown below may be used to aid in this process:
<syntaxhighlight lang="bash">
#!/bin/sh

if [ ! -f "$1" ] || [ $# -lt 2 ]
then
echo "Usage: $0 SCRIPTNAME OUTPUTNAME"
exit 1
fi

mkimage -T script -C none -A arm -n 'SoM9260 Load Script' -d $1 $2
</syntaxhighlight>

Note that the script assumes that <code>mkimage</code> is installed in the user's PATH. The script should be run with the name of the existing file as the first argument and the desired output filename as the second argument:
{{cli|username=developer|hostname=ldc|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it should be copied to the TFTP server root directory, in this example <code>/srv/tftp</code> is used.
{{cli|username=developer|hostname=ldc|sudo cp sl013-aon-30010-flash-script.img /srv/tftp/}}

The image file can now be transferred to the board and executed as illustrated below:
{{clop}}<nowiki>U-Boot> tftp 0x20000000 sl013-aon-30010-flash-script.img
U-Boot> source 0x20000000</nowiki>{{closp}}

{{ note | Note that the U-Boot command <code>source</code> was not available on older versions of U-Boot. If the command is not recognized, use <code>autoscr</code> instead.}}

U-Boot will execute all commands in the script line-by-line until the script has finished, at which point the U-boot prompt will be returned to the user.




{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
In this article, you have seen how to load an image into RAM using U-Boot. You have seen how to execute an image from RAM. You have also seen how to copy an image from RAM to flash; how to configure your system to boot from an image once it has been saved to flash is documented elsewhere (see Related Information, below). You have also seen a brief description of how to create scripts for U-Boot.

With the information provided by this document, you are set to begin loading alternate kernels and filesystems onto EMAC hardware. These kernels and filesystems could be alternatives provided to you by EMAC, or they could be ones you create yourself. This provides you with a great deal of flexibility for your development work.




{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]
* [[Loading_JFFS2_Images_Onto_a_Board | Loading JFFS2 Images Onto a Board]]
* [[Archiving_JFFS2_Images | Archiving JFFS2 Images]]

{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[U-Boot_Overview | U-Boot Overview]]
* [[Creating_JFFS2_Images | Creating JFFS2 Images]]
* [[Mounting_JFFS2_Images_on_a_Linux_PC | Mounting JFFS2 Images on a Linux PC]]
* [[Repartitioning_NAND_Flash_with_JFFS2_for_Linux | Repartitioning NAND Flash with JFFS2 for Linux]]
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Booting_with_an_NFS_Root_Filesystem | Booting with an NFS Root Filesystem]]

Loading Images with U-Boot

2019-04-15T17:33:24Z

Mgloff:

{{todo|Complete (12.16.13-01:25->MD-);(12.31.13-11:02->MW+);(12.31.13-11:30->KY+);(12.31.13-11:35->MG+);(03.06.14-15:30->BS-);(04.11.14-15:55->BS+)(11.06.15-12:45->MG+)(11.13.2015-13:25->MD-);(11.13.2015-16:39->ER+);(11.13.2015-17:30->MD+);(11.17.2015-13:50->KY+);(11.17.2015-14:30->MG+)|Michael Welling|project=oe 4,oe 5,mw,md,ky,mg,bs,er,Complete}}



{{#seo:
|title=Loading Images with U-Boot
|titlemode=append
|keywords=U-Boot,OS Image,TFTP Server
|description=This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process.
}}
While U-Boot is used to load and execute the OS after initial programming, it can also be used to program the OS images to the local flash. This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process. Review the [[U-Boot Overview]] page for an introduction to U-Boot before continuing.

== Requirements ==
A TFTP server must be accessible on the local network. The specific details of TFTP server setup and configuration can be found on the [[Installing TFTP server]] page. Alternatively, NFS can be used in place of TFTP but will require an NFS server. Information on how to set up an NFS server [[Setting_up_an_NFS_File_Server | can be found here]]. Please contact EMAC if you need details on how to use NFS instead of TFTP to load images.

== Configuration ==
In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration or DHCP can be used on some systems (requires DHCP server). Typically, the IP address of the board and the IP address of the TFTP server are the only settings that need to be defined. The network mask and broadcast address will be determined automatically from these settings, and no default gateway setting is required if the server is on the same subnetwork as the board. Before continuing, determine a valid static network address for your local network; contact your IT department for more information on what address to use if required. The example below shows how to set the IP address of the board to 192.168.2.2 and the TFTP server IP address to 192.168.2.1:
{{clop}}<nowiki>U-Boot> setenv ipaddr 192.168.2.2
U-Boot> setenv serverip 192.168.2.1
U-Boot> saveenv
Saving Environment to dataflash...
U-Boot> reset</nowiki>{{closp}}

Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:
{{clop}}<nowiki>U-Boot> ping 192.168.2.1
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
host 192.168.2.1 is alive</nowiki>{{closp}}

== Loading Images to RAM ==
Files are loaded directly into RAM through TFTP. In order to load the image, you must know the physical address of the RAM device on the system. Refer to the documentation for your target board if you are unsure what value to use. The standard addresses for some common EMAC systems are shown in Table 1 below.

{| class="wikitable"
! colspan="2"|Table 1: Physical RAM Addresses
|-
! Product !! RAM Start Address
|-
| SoM-9260M || 0x20000000
|-
| SoM-9G20M || 0x20000000
|-
| SoM-9G45M || 0x70000000
|-
| SoM-3517M || 0x82000000
|-
| SoM-9x25M || 0x22000000
|-
| Ipac-9x25M || 0x22000000
|-
| SoM-9G25M || 0x22000000
|-
| SoM-A5D35M || 0x22000000
|-
| SoM-A5D36M || 0x22000000
|-
| SoM-3354M || 0x82000000
|-
| SoM-iMX6M || 0x12000000
|-
| SoM-iMX6UL || 0x82000000
|}

{{ warning | Before transferring a file to the system, make sure that it does not exceed the size of the available RAM. }}

The <code>tftp</code> U-Boot command is used to transfer files to the system. The command requires two arguments: the address to load the file into and the filename of the image on the TFTP server. The example below demonstrates loading a kernel image named <code>uImage-2.6.30</code> to RAM on an SoM-9G45M.
{{clop}}<nowiki>U-Boot> tftp 0x70000000 uImage-2.6.30
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage-2.6.30'.
Load address: 0x70000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
############################
done
Bytes transferred = 1472456 (1677c8 hex)
U-Boot> printenv filesize
filesize=1677C8</nowiki>{{closp}}

{{ note | Note that the <code>filesize</code> variable has been automatically updated to the size of the file that was loaded.}}

== Executing kernel from RAM ==
In some situations, it is advantageous to execute the image directly from RAM after loading with TFTP rather than saving to flash. This is especially helpful when testing new Linux kernel images. Furthermore, the boot command can be set such that the image is automatically downloaded and executed on each boot, making testing more efficient.

After loading a bootable image to RAM, you can execute it directly using the <code>bootm</code> command. For example, after loading the kernel image above, running <code>bootm 0x70000000</code> would boot the board using the new image without making any changes to the images stored on the flash.

To update the <code>bootcmd</code> variable to download the image on each boot, simply replace the command used to load the image from flash with the TFTP download command. The following example illustrates this process on an SoM-9G45M module.
{{clop}}<nowiki>U-Boot> printenv bootcmd
bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000
U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000'
U-Boot> saveenv
Saving Environment to dataflash...</nowiki>{{closp}}

== Copying to Flash ==
The process of copying an image from RAM to flash memory differs depending on what type of flash storage devices are available on the system. Many systems have more than one device, such as serial DataFlash and NAND flash. This section explains the process of storing an image to non-volatile storage.

=== NOR Flash ===
A combination of the <code>erase</code> and <code>cp</code> commands are used to program an image to a NOR flash device. NOR flash is directly memory-mapped to the system at a physical address. Also, each image (U-Boot, bootstrap, kernel, filesystem) must be stored at the correct offset for the system to operate correctly. Refer to the documentation for your hardware for more information on the correct address ranges to use. The <code>flinfo</code> command can be used to display the addressing of available flash devices on the system.

After loading the image to RAM, the flash device should be erased followed by copying the image to the appropriate offset in the flash. The example below illustrates the commands used to program a new kernel image to a SoM-9260M module. Note the use of the <code>protect off all</code> command, which is required to unlock the flash on some systems.
{{clop}}<nowiki>U-Boot> protect off all
U-Boot> tftp 0x20000000 ${kernel_name}
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}</nowiki>{{closp}}

{{ note | Note that NOR flash can take a significant amount of time to program if the image size is large.}}

=== Serial DataFlash ===
Serial DataFlash is an SPI-based NOR flash device that is used on many systems that employ NAND flash as the primary storage device. On these systems, low-level boot code such as the bootstrap, U-Boot, and OS kernel are typically stored on the DataFlash device. As with NOR flash, the <code>flinfo</code> command can be used to determine the memory addressing layout of the DataFlash device. The <code>erase</code> command does not support the DataFlash devices and should not be used before programming an image. The <code>cp</code> command is capable of copying an image from RAM to DataFlash.

The example below illustrates the commands used to copy a kernel image to the DataFlash device on a SoM-9G45M module.
{{clop}}<nowiki>U-Boot> tftpboot 0x70000000 ${kernel_name}
U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}</nowiki>{{closp}}

=== NAND Flash ===
Generally, NAND flash is used to store only the root filesystem and auxiliary storage partitions of the OS. Storing an image to NAND flash under U-Boot uses a different set of commands than NOR or DataFlash devices. See <code>help nand</code> for more information on the available commands for examining and manipulating NAND flash devices. To gain information on what NAND devices are available on the system, use the command <code>nand info</code>. In general, programming a NAND flash device is much faster than programming NOR or DataFlash devices.

The example below illustrates the process of loading the root JFFS2 filesystem onto an SoM-9G45M device. Note that the device is erased prior to programming it.
{{clop}}<nowiki>U-Boot> nand erase
U-Boot> tftp 0x70000000 ${rootfs_name}
U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}</nowiki>{{closp}}

=== SPI NOR/eMMC Flash ===
Most of EMAC's newer SoM offerings utilize an eMMC flash for filesystem and auxiliary storage partitions of the OS and an SPI flash to store the bootloader and kernel. To reprogram the eMMC, see [[Loading_Images_onto_eMMC_Devices|Loading Images onto eMMC Devices]]. Be sure that the <code>loadaddr</code> variable is set and matches the table above. The example below illustrates the commands used to program a new kernel image to a SoM-9x25M module.
{{clop}}<nowiki>U-Boot> pri loadaddr
U-Boot> tftp ${loadaddr} zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize}
U-Boot> setenv kernelsize ${filesize};saveenv</nowiki>{{closp}}

Note: the "pri loadaddr" step above is not required it is just entered to make sure the variable is set.

== Scripting ==
U-Boot also includes a scripting feature that allows a script file with U-Boot commands to be loaded and executed. This can make the task of programming multiple systems much more efficient. The <code>mkimage</code> utility is required on a Linux development system in order to create a valid U-Boot image from a script. This section gives a brief example of a U-Boot script for programming a Linux kernel and filesystem.

Creating a text file with all of the desired commands is the first step in creating a U-Boot script. The example below is a script file used by EMAC to program SoM-9260M modules:
<syntaxhighlight lang=php>
echo ===== Setting Environment =====
setenv bootdelay 1
setenv rev sl013-aon-30010
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
setenv kernel_name ${rev}-uImage
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
saveenv
echo ===== Loading Kernel =====
protect off all
tftpboot 0x20000000 ${kernel_name}
erase 0x10100000 0x103fffff
cp.b 0x20000000 0x10100000 ${filesize}
setenv kernelsize ${filesize}
echo ===== Loading Root Filesystem =====
tftpboot 0x20000000 ${rootfs_name}
erase 0x10400000 0x11ffffff
cp.b 0x20000000 0x10400000 ${filesize}
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
saveenv
echo ===== DONE! =====
</syntaxhighlight>

Once the file has been created and saved, the <code>mkimage</code> utility must be used to create a U-Boot script image. A shell script such as the one shown below may be used to aid in this process:
<syntaxhighlight lang="bash">
#!/bin/sh

if [ ! -f "$1" ] || [ $# -lt 2 ]
then
echo "Usage: $0 SCRIPTNAME OUTPUTNAME"
exit 1
fi

mkimage -T script -C none -A arm -n 'SoM9260 Load Script' -d $1 $2
</syntaxhighlight>

Note that the script assumes that <code>mkimage</code> is installed in the user's PATH. The script should be run with the name of the existing file as the first argument and the desired output filename as the second argument:
{{cli|username=developer|hostname=ldc|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it should be copied to the TFTP server root directory, in this example <code>/srv/tftp</code> is used.
{{cli|username=developer|hostname=ldc|sudo cp sl013-aon-30010-flash-script.img /srv/tftp/}}

The image file can now be transferred to the board and executed as illustrated below:
{{clop}}<nowiki>U-Boot> tftp 0x20000000 sl013-aon-30010-flash-script.img
U-Boot> source 0x20000000</nowiki>{{closp}}

{{ note | Note that the U-Boot command <code>source</code> was not available on older versions of U-Boot. If the command is not recognized, use <code>autoscr</code> instead.}}

U-Boot will execute all commands in the script line-by-line until the script has finished, at which point the U-boot prompt will be returned to the user.




{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
In this article, you have seen how to load an image into RAM using U-Boot. You have seen how to execute an image from RAM. You have also seen how to copy an image from RAM to flash; how to configure your system to boot from an image once it has been saved to flash is documented elsewhere (see Related Information, below). You have also seen a brief description of how to create scripts for U-Boot.

With the information provided by this document, you are set to begin loading alternate kernels and filesystems onto EMAC hardware. These kernels and filesystems could be alternatives provided to you by EMAC, or they could be ones you create yourself. This provides you with a great deal of flexibility for your development work.




{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]
* [[Loading_JFFS2_Images_Onto_a_Board | Loading JFFS2 Images Onto a Board]]
* [[Archiving_JFFS2_Images | Archiving JFFS2 Images]]

{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[U-Boot_Overview | U-Boot Overview]]
* [[Creating_JFFS2_Images | Creating JFFS2 Images]]
* [[Mounting_JFFS2_Images_on_a_Linux_PC | Mounting JFFS2 Images on a Linux PC]]
* [[Repartitioning_NAND_Flash_with_JFFS2_for_Linux | Repartitioning NAND Flash with JFFS2 for Linux]]
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Booting_with_an_NFS_Root_Filesystem | Booting with an NFS Root Filesystem]]

Loading Images with U-Boot

2019-04-15T17:27:27Z

Mgloff:

{{todo|Complete (12.16.13-01:25->MD-);(12.31.13-11:02->MW+);(12.31.13-11:30->KY+);(12.31.13-11:35->MG+);(03.06.14-15:30->BS-);(04.11.14-15:55->BS+)(11.06.15-12:45->MG+)(11.13.2015-13:25->MD-);(11.13.2015-16:39->ER+);(11.13.2015-17:30->MD+);(11.17.2015-13:50->KY+);(11.17.2015-14:30->MG+)|Michael Welling|project=oe 4,oe 5,mw,md,ky,mg,bs,er,Complete}}



{{#seo:
|title=Loading Images with U-Boot
|titlemode=append
|keywords=U-Boot,OS Image,TFTP Server
|description=This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process.
}}
While U-Boot is used to load and execute the OS after initial programming, it can also be used to program the OS images to the local flash. This page describes the process of using U-Boot to load Linux kernel and filesystem images from a TFTP server and save them to the local flash for use during the boot process. Review the [[U-Boot Overview]] page for an introduction to U-Boot before continuing.

== Requirements ==
A TFTP server must be accessible on the local network. The specific details of TFTP server setup and configuration can be found on the [[Installing TFTP server]] page. Alternatively, NFS can be used in place of TFTP but will require an NFS server. Information on how to set up an NFS server [[Setting_up_an_NFS_File_Server | can be found here]]. Please contact EMAC if you need details on how to use NFS instead of TFTP to load images.

== Configuration ==
In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration or DHCP can be used on some systems (requires DHCP server). Typically, the IP address of the board and the IP address of the TFTP server are the only settings that need to be defined. The network mask and broadcast address will be determined automatically from these settings, and no default gateway setting is required if the server is on the same subnetwork as the board. Before continuing, determine a valid static network address for your local network; contact your IT department for more information on what address to use if required. The example below shows how to set the IP address of the board to 192.168.2.2 and the TFTP server IP address to 192.168.2.1:
{{clop}}<nowiki>U-Boot> setenv ipaddr 192.168.2.2
U-Boot> setenv serverip 192.168.2.1
U-Boot> saveenv
Saving Environment to dataflash...
U-Boot> reset</nowiki>{{closp}}

Once the network settings have been configured, attempt to ping the TFTP server to test the network connection as illustrated below:
{{clop}}<nowiki>U-Boot> ping 192.168.2.1
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
host 192.168.2.1 is alive</nowiki>{{closp}}

== Loading Images to RAM ==
Files are loaded directly into RAM through TFTP. In order to load the image, you must know the physical address of the RAM device on the system. Refer to the documentation for your target board if you are unsure what value to use. The standard addresses for some common EMAC systems are shown in Table 1 below.

{| class="wikitable"
! colspan="2"|Table 1: Physical RAM Addresses
|-
! Product !! RAM Start Address
|-
| SoM-9260M || 0x20000000
|-
| SoM-9G20M || 0x20000000
|-
| SoM-9G45M || 0x70000000
|-
| SoM-3517M || 0x82000000
|-
| SoM-9x25M || 0x22000000
|-
| Ipac-9x25M || 0x22000000
|-
| SoM-9G25M || 0x22000000
|-
| SoM-A5D35M || 0x22000000
|-
| SoM-A5D36M || 0x22000000
|-
| SoM-3354M || 0x82000000
|}

{{ warning | Before transferring a file to the system, make sure that it does not exceed the size of the available RAM. }}

The <code>tftp</code> U-Boot command is used to transfer files to the system. The command requires two arguments: the address to load the file into and the filename of the image on the TFTP server. The example below demonstrates loading a kernel image named <code>uImage-2.6.30</code> to RAM on an SoM-9G45M.
{{clop}}<nowiki>U-Boot> tftp 0x70000000 uImage-2.6.30
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage-2.6.30'.
Load address: 0x70000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
############################
done
Bytes transferred = 1472456 (1677c8 hex)
U-Boot> printenv filesize
filesize=1677C8</nowiki>{{closp}}

{{ note | Note that the <code>filesize</code> variable has been automatically updated to the size of the file that was loaded.}}

== Executing kernel from RAM ==
In some situations, it is advantageous to execute the image directly from RAM after loading with TFTP rather than saving to flash. This is especially helpful when testing new Linux kernel images. Furthermore, the boot command can be set such that the image is automatically downloaded and executed on each boot, making testing more efficient.

After loading a bootable image to RAM, you can execute it directly using the <code>bootm</code> command. For example, after loading the kernel image above, running <code>bootm 0x70000000</code> would boot the board using the new image without making any changes to the images stored on the flash.

To update the <code>bootcmd</code> variable to download the image on each boot, simply replace the command used to load the image from flash with the TFTP download command. The following example illustrates this process on an SoM-9G45M module.
{{clop}}<nowiki>U-Boot> printenv bootcmd
bootcmd=cp.b 0xC0042000 0x70000000 0x210000; bootm 0x70000000
U-Boot> setenv bootcmd 'tftp 0x70000000 uImage-2.6.30; bootm 0x70000000'
U-Boot> saveenv
Saving Environment to dataflash...</nowiki>{{closp}}



== Copying to Flash ==
The process of copying an image from RAM to flash memory differs depending on what type of flash storage devices are available on the system. Many systems have more than one device, such as serial DataFlash and NAND flash. This section explains the process of storing an image to non-volatile storage.

=== NOR Flash ===
A combination of the <code>erase</code> and <code>cp</code> commands are used to program an image to a NOR flash device. NOR flash is directly memory-mapped to the system at a physical address. Also, each image (U-Boot, bootstrap, kernel, filesystem) must be stored at the correct offset for the system to operate correctly. Refer to the documentation for your hardware for more information on the correct address ranges to use. The <code>flinfo</code> command can be used to display the addressing of available flash devices on the system.

After loading the image to RAM, the flash device should be erased followed by copying the image to the appropriate offset in the flash. The example below illustrates the commands used to program a new kernel image to a SoM-9260M module. Note the use of the <code>protect off all</code> command, which is required to unlock the flash on some systems.
{{clop}}<nowiki>U-Boot> protect off all
U-Boot> tftp 0x20000000 ${kernel_name}
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}</nowiki>{{closp}}

{{ note | Note that NOR flash can take a significant amount of time to program if the image size is large.}}

=== Serial DataFlash ===
Serial DataFlash is an SPI-based NOR flash device that is used on many systems that employ NAND flash as the primary storage device. On these systems, low-level boot code such as the bootstrap, U-Boot, and OS kernel are typically stored on the DataFlash device. As with NOR flash, the <code>flinfo</code> command can be used to determine the memory addressing layout of the DataFlash device. The <code>erase</code> command does not support the DataFlash devices and should not be used before programming an image. The <code>cp</code> command is capable of copying an image from RAM to DataFlash.

The example below illustrates the commands used to copy a kernel image to the DataFlash device on a SoM-9G45M module.
{{clop}}<nowiki>U-Boot> tftpboot 0x70000000 ${kernel_name}
U-Boot> cp.b 0x70000000 0xC0042000 ${filesize}</nowiki>{{closp}}

=== NAND Flash ===
Generally, NAND flash is used to store only the root filesystem and auxiliary storage partitions of the OS. Storing an image to NAND flash under U-Boot uses a different set of commands than NOR or DataFlash devices. See <code>help nand</code> for more information on the available commands for examining and manipulating NAND flash devices. To gain information on what NAND devices are available on the system, use the command <code>nand info</code>. In general, programming a NAND flash device is much faster than programming NOR or DataFlash devices.

The example below illustrates the process of loading the root JFFS2 filesystem onto an SoM-9G45M device. Note that the device is erased prior to programming it.
{{clop}}<nowiki>U-Boot> nand erase
U-Boot> tftp 0x70000000 ${rootfs_name}
U-Boot> nand write.jffs2 0x70000000 0x0 ${filesize}</nowiki>{{closp}}

=== SPI NOR/eMMC Flash ===
Most of EMAC's newer SoM offerings utilize an eMMC flash for filesystem and auxiliary storage partitions of the OS and an SPI flash to store the bootloader and kernel. To reprogram the eMMC, see [[Loading_Images_onto_eMMC_Devices|Loading Images onto eMMC Devices]]. Be sure that the <code>loadaddr</code> variable is set and matches the table above. The example below illustrates the commands used to program a new kernel image to a SoM-9x25M module.
{{clop}}<nowiki>U-Boot> pri loadaddr
U-Boot> tftp ${loadaddr} zImage
U-Boot> sf probe;sf erase 0x100000 +${filesize};sf write ${loadaddr} 0x100000 ${filesize}
U-Boot> setenv kernelsize ${filesize};saveenv</nowiki>{{closp}}

Note: the "pri loadaddr" step above is not required it is just entered to make sure the variable is set.

== Scripting ==
U-Boot also includes a scripting feature that allows a script file with U-Boot commands to be loaded and executed. This can make the task of programming multiple systems much more efficient. The <code>mkimage</code> utility is required on a Linux development system in order to create a valid U-Boot image from a script. This section gives a brief example of a U-Boot script for programming a Linux kernel and filesystem.

Creating a text file with all of the desired commands is the first step in creating a U-Boot script. The example below is a script file used by EMAC to program SoM-9260M modules:
<syntaxhighlight lang=php>
echo ===== Setting Environment =====
setenv bootdelay 1
setenv rev sl013-aon-30010
setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2'
setenv kernel_name ${rev}-uImage
setenv rootfs_name sl013-aon-emac-image-SOM9260M.jffs2
saveenv
echo ===== Loading Kernel =====
protect off all
tftpboot 0x20000000 ${kernel_name}
erase 0x10100000 0x103fffff
cp.b 0x20000000 0x10100000 ${filesize}
setenv kernelsize ${filesize}
echo ===== Loading Root Filesystem =====
tftpboot 0x20000000 ${rootfs_name}
erase 0x10400000 0x11ffffff
cp.b 0x20000000 0x10400000 ${filesize}
setenv bootcmd 'protect off all;cp.b 0x10100000 0x20000000 ${kernelsize};bootm 0x20000000'
saveenv
echo ===== DONE! =====
</syntaxhighlight>

Once the file has been created and saved, the <code>mkimage</code> utility must be used to create a U-Boot script image. A shell script such as the one shown below may be used to aid in this process:
<syntaxhighlight lang="bash">
#!/bin/sh

if [ ! -f "$1" ] || [ $# -lt 2 ]
then
echo "Usage: $0 SCRIPTNAME OUTPUTNAME"
exit 1
fi

mkimage -T script -C none -A arm -n 'SoM9260 Load Script' -d $1 $2
</syntaxhighlight>

Note that the script assumes that <code>mkimage</code> is installed in the user's PATH. The script should be run with the name of the existing file as the first argument and the desired output filename as the second argument:
{{cli|username=developer|hostname=ldc|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it should be copied to the TFTP server root directory, in this example <code>/srv/tftp</code> is used.
{{cli|username=developer|hostname=ldc|sudo cp sl013-aon-30010-flash-script.img /srv/tftp/}}

The image file can now be transferred to the board and executed as illustrated below:
{{clop}}<nowiki>U-Boot> tftp 0x20000000 sl013-aon-30010-flash-script.img
U-Boot> source 0x20000000</nowiki>{{closp}}

{{ note | Note that the U-Boot command <code>source</code> was not available on older versions of U-Boot. If the command is not recognized, use <code>autoscr</code> instead.}}

U-Boot will execute all commands in the script line-by-line until the script has finished, at which point the U-boot prompt will be returned to the user.




{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
In this article, you have seen how to load an image into RAM using U-Boot. You have seen how to execute an image from RAM. You have also seen how to copy an image from RAM to flash; how to configure your system to boot from an image once it has been saved to flash is documented elsewhere (see Related Information, below). You have also seen a brief description of how to create scripts for U-Boot.

With the information provided by this document, you are set to begin loading alternate kernels and filesystems onto EMAC hardware. These kernels and filesystems could be alternatives provided to you by EMAC, or they could be ones you create yourself. This provides you with a great deal of flexibility for your development work.




{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]
* [[Loading_JFFS2_Images_Onto_a_Board | Loading JFFS2 Images Onto a Board]]
* [[Archiving_JFFS2_Images | Archiving JFFS2 Images]]

{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[U-Boot_Overview | U-Boot Overview]]
* [[Creating_JFFS2_Images | Creating JFFS2 Images]]
* [[Mounting_JFFS2_Images_on_a_Linux_PC | Mounting JFFS2 Images on a Linux PC]]
* [[Repartitioning_NAND_Flash_with_JFFS2_for_Linux | Repartitioning NAND Flash with JFFS2 for Linux]]
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Booting_with_an_NFS_Root_Filesystem | Booting with an NFS Root Filesystem]]

Booting with a USB Root Filesystem

2019-04-12T18:26:25Z

Mgloff:

It is possible to boot most EMAC OE systems using a USB thumb drive as the root filesystem and to optionally load a kernel from. This method can be especially useful for updating or recovering the root filesystem when a network connection or a network file server is not available. This page describes the steps required to boot into a root filesystem residing on a USB thumb drive.

__TOC__

==Prerequisites==

Some prerequisites must be met prior to being able to boot a root filesystem from a USB drive.

===USB Thumb Drive===

Any blank USB drive. If it is not blank, this process will completely wipe the data that exists on the USB drive.

===Root Filesystem===

A complete root filesystem for the EMAC OE system to boot from must be stored on the USB drive.

===Linux Host Computer===

Either a native Linux host or Windows host running a Linux virtual machine.

==Configuring the USB Thumb Drive==

In a terminal window, start the dmesg log with the follow option to watch for new devices.

{{cli | username=developer | hostname=ldc | pwd=~ | dmesg -w }}

Insert the USB drive and watch for the device to be announced.

{{clo}}
[ 2796.940110] scsi host6: usb-storage 1-1.2:1.0 
[ 2797.963442] scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0272 PQ: 0 ANSI: 0 
[ 2797.963905] sd 6:0:0:0: Attached scsi generic sg4 type 0 
[ 2798.269544] sd 6:0:0:0: [sdd] 7774208 512-byte logical blocks: (3.98 GB/3.71 GiB) 
[ 2798.271027] sd 6:0:0:0: [sdd] Write Protect is off 
[ 2798.271030] sd 6:0:0:0: [sdd] Mode Sense: 0b 00 00 08 
[ 2798.272502] sd 6:0:0:0: [sdd] No Caching mode page found 
[ 2798.272508] sd 6:0:0:0: [sdd] Assuming drive cache: write through 
[ 2798.279486] sdd: 
[ 2798.283834] sd 6:0:0:0: [sdd] Attached SCSI removable disk 
{{clos}}

 
{{ imbox | type=notice | text=If using a virtual machine, wait for Windows to install the Virtualbox USB driver. Then make the virtual machine aware of the USB drive by going into the Devices menu option in virtualbox, then sub-option USB and select your USB device.}}
 

The output of the <code>dmesg</code> command shows that the root device node for the USB drive in this case is <code>sdd</code> and no partitions. Partitions on the drive would be listed as <code>sdd1</code>, <code>sdd2</code>, etc. Inspect the output shown above to see the particular device node on the development PC where the USB drive is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with <code>sd</code>. The third letter will specify which of these devices is assigned to the USB drive. The number will indicate the partitions, if any. Press Ctrl and 'c' to exit dmesg.

* At this point, it is wise to double check that device node is actually the USB drive and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdd</code> as the example device node, type the following command:

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | mount {{!}} grep sdd }}
/dev/sdd on /media/developer/FBF6-1988 type vfat
{{clos}}

This shows that the device node, <code>/dev/sdd</code>, is in fact the USB drive. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

If nothing is returned, then the USB drive did not get automatically mounted. Proceed to the next step.

Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4fcf5773
</nowiki>
{{closp}}

The output of fdisk will also show information about any partitions that may exist on the USB drive. For example, another drive with a single FAT32 formatted partition will look like:
{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe6077d37

Device Boot Start End Sectors Size Id Type
/dev/sdh1 2048 7774207 7772160 3.7G c W95 FAT32 (LBA)
</nowiki>
{{closp}}

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 3.7 GB in size, which corresponds with the size of the 4 GB USB drive being used in this example.

Unmount all of the USB drives partitions that were listed from the <code>mount</code> command above.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd }}

If there is a partition listed:

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd1 }}

==Repartition the USB Drive==

Once the correct drive letter is determined, we will create a new Linux partition.

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk /dev/sdd }}<nowiki>

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): o
Created a new DOS disklabel with disk identifier 0x05d5e983.

Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7774207, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-7774207, default 7774207):

Created a new partition 1 of type 'Linux' and of size 3.7 GiB.

Command (m for help): p
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x05d5e983

Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 7774207 7772160 3.7G 83 Linux

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
</nowiki>
{{closp}}

The fdisk commands are:

<code>o</code> - Create a new empty partition table

<code>n</code> - Create a new partition

<code>p</code> - The type of partition is a primary partition

<code>1</code> - Create the first partition

<code><ENTER></code> - Accept default start

<code><ENTER></code> - Accept default end

<code>p</code> - Print the new partition layout

<code>w</code> - Write the new partition layout and exit

==Format the Partition==

The first partition will be formatted with the ext4 filesystem.

{{cli | username=developer | hostname=ldc | pwd=~ | yes {{!}} sudo mkfs.ext4 /dev/sdd1 }}

==Mount the Partition==

The first partition of the USB drive will be mounted so that it is accessible to write to.

{{clop}}
{{clio | username=developer | hostname=ldc | pwd=~ | sudo mkdir -p /media/card }}
{{clio | username=developer | hostname=ldc | pwd=~ | sudo mount /dev/sdd1 /media/card }}
{{closp}}

The USB drive is now accessible through the <code>/media/card</code> directory.

==Extract Filesystem Archive==

Locate where the filesystem archive has been downloaded. If the archive is called rootfs.tar.gz and is in the users Downloads directory:

{{clop}}
{{clio | username=developer | hostname=ldc | pwd=~ | cd /media/card }}
{{clio | username=developer | hostname=ldc | pwd=/media/card | sudo tar zxf ~/Downloads/rootfs.tar.gz }}
{{clio | username=developer | hostname=ldc | pwd=/media/card | sync }}
{{clio | username=developer | hostname=ldc | pwd=/media/card | cd }}
{{clio | username=developer | hostname=ldc | pwd=~ | sudo umount /media/card }}
{{closp}}

It is now safe to remove the USB drive from the host computer.

==Configuring the Client to Boot from USB==

===Configuring U-Boot===

Insert the USB drive into an available port on the target board.
Set the bootargs variable to tell the kernel to boot into the USB filesystem:

U-Boot> setenv bootargs console=${console} root=/dev/sda1 rootfstype=ext4 rootwait
U-Boot> run bootargs

This line sets up the environment needed to boot from the USB drive. These options will be passed to the Linux kernel when booting it. The <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>. The <code>root=/dev/sda1</code> directive tells Linux to instantiate with the USB block device, <code>/dev/sda1</code>, as the root filesystem. The <code>rootfstype=ext4</code> directive tells Linux that the root filesystem is of the EXT4 variety.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the USB root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

===Alternate Kernel Load===

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. The below example assumes a kernel named zImage-test was placed in the /boot directory of the USB drive. Also see [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM | Executing kernel from RAM ]]

U-Boot> usb start
U-Boot> usb storage
U-Boot> ext2load usb 0:1 ${loadaddr} /boot/zImage-test
U-Boot> bootz ${loadaddr}

The first two commands initialize the USB storage system in U-Boot. The <code>ext2load</code> line says to use the USB device 0 partition 1 and load into RAM at ${loadaddr} the file /boot/zImage-test from the USB drive. The last line boots the kernel that has been loaded into memory.

==Conclusion==

Using a USB thumb drive for the root filesystem allows boards to boot quickly into a rescue or known good version of a filesystem and provides a method for remotely backing up the filesystem installed on an embedded machine. Setting up a machine to boot to a root filesystem via USB requires little work; most of the work is in setting up the USB thumb drive.

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to USB boot. | project=OE 5.0 }}
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Loading_Images_with_U-Boot | Loading Images with U-Boot]]
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

Opkg

2019-03-11T16:02:10Z

Mgloff:

{{todo| Complete (11.12.2014-18:38->MD+);(11.05.2015-19:20->MD+);(11.06.2015-16:10->MD+);(11.06.2015-17:25->MD+);(11.13.2015-16:15->KY+);(11.13.2015-16:24->ER+)|Mike Dean| project=OE 5,MD,KY,ER,Complete}}
{{#seo:
|title=OPKG
|titlemode=append
|keywords=opkg,yocto,openembedded
|description=Package Management with OPKG
}}


Every modern operating system is expected to host a variety of software applications and libraries. Managing their installation, upgrade, and removal has become more complex as software has become more sophisticated. Additionally, the pervasive presence of the Internet has driven an expectation by users of an ability to perform OS updates and upgrades via the Internet. This page describes the tool used by EMAC OE to cater to these needs and expectations.


__TOC__

{{:Templateimpl:bg | initials=MD | title=OPKG | desc=Package Management with OPKG | project=OE 5 }}
There are many package managers used for Linux systems. You may already be familiar with the ones most popularly used in desktop and server distributions of Linux: <code>apt</code> (<code>apt-get</code>, <code>aptitude</code>, etc), <code>rpm</code>, and <code>yum</code>. You may even be familiar with some of the less popular ones, such as <code>emerge</code> (from gentoo's <code>portage</code>), the Mac OS X GNU tools package manager <code>brew</code>, and the BSD package manager, <code>ports</code>. The package manager used by EMAC OE is similar to these tools, but is the popular choice for embedded Linux: <code>opkg</code>. If you're already familiar with any of the desktop/server package managers listed here, <code>opkg</code> should be very easy to learn since it is quite similar to all of those tools. If not, it should still be easy to learn because it has a well designed interface.

{{:Templateimpl:geninfo | initials=MD | title=OPKG | desc=Package Management with OPKG | project=OE 5 }}
The basic capabilities of <code>opkg</code> are available in OE 4.0 and earlier, but no packages are available online for these older versions. EMAC OE 5.X adds an online package repository complete with important updates for packages during the support window for each release. EMAC creates and hosts packages for all of our standard offerings, and may add updated packages as needed. EMAC recommends checking for and installing any updates available for your OE 5.X system prior to creating the final image which will be used to deploy your systems to ensure your image contains the latest bug fixes and security patches. It is important to remember to retest your application after an update to ensure that everything still works as expected, just as you would have to do for a desktop application.

Should your application require the ability to be updated/upgraded remotely, EMAC is able to provide assistance and services for creating custom packages for your application and hosting these packages for a modest fee. We will also assist you with configuring the systems to check for and install these updates. Please contact EMAC support should you need more information about this extra level of support.

The <code>opkg</code> tool is used to work with the OPKG package management system. This tool provides the user with many different capabilities. In this document, only the basic capabilities are described. More information can be found in the last section of this page.
{{:Templateimpl:using | initials=MD | title=OPKG | desc=Package Management with OPKG | project=OE 5 }}
The following basic capabilities are shown in this document:

* Updating the list of available packages.
* Upgrading the system.
* Finding packages to install.
* Installing new packages.
* Removing packages.

=== Updating the List of Available Packages ===

The OPKG Package Manager keeps a local cache of the list of available packages so that it doesn't have to reach out to the Internet every time the user wishes to use this list in any way. This list is updated on demand, rather than periodically, so it's important to update this list before attempting to search for or install any new packages, or attempting to upgrade the system.

To update the cached list of available packages, run:

{{cli|opkg update}}

Note that you must be root in order to update this list.

=== Upgrading the System ===

You can use <code>opkg</code> to upgrade the system by selectively telling it which packages to upgrade. You first need to obtain a list of available packages to upgrade with the following command:

{{cli|opkg list-upgradable}}

You can then upgrade a package with this command:

{{cli|opkg upgrade ''packagename''}}

=== Finding Packages to Install ===

==== Listing Packages ====

There is more than one way to look through packages to see what's available to be installed. The first is the <code>list</code> command by itself:

{{cli|opkg list}}

This provides a complete list of all available packages. ''If you're already comfortable with the Linux command line, you may now wish to skip to the section entitled, "Installing New Pacakges." If not, the following content shows how to more easily work with this output.''

==== Browsing the Package List ====

As usual on the Linux command line, this long list can be made much easier to peruse by piping the output of the <code>opkg list</code> command into the <code>less</code> command, like so:

{{cli|opkg list {{!}} less}}

{{note|Unlike the <code>more</code> command, the <code>less</code> command allows you to scroll bidirectionally through a text file. It also allows you to search through a document using regular expressions; press the <code>/</code> key followed by some text (or a basic regular expression) for which you would like to search. This can be used to directly read a text file as well: {{icli|less some_text_file}}}}

==== Filtering the Package List ====

Often times, you will wish to search for something more specific. The <code>grep</code> command is very useful for this task. The most basic use of grep looks like this:

{{cli|opkg list {{!}} grep ''packagename''}}

If you're not sure of the full package name, you can put in just a part of the name, since grep doesn't match against whole words by default.

===== Matching Whole Words =====

If, on the other hand, you want it to match against a whole word, you can enclose the word with escaped angle brackets:

{{cli|opkg list {{!}} grep \<''packagename''\>}}

This tells <code>grep</code> to only match against the full word represented by ''packagename''. Use only the opening angle bracket if you only want it to look for a word that starts with ''packagename'', and likewise, only use the closing angle bracket at the end if you only want it to search for a word that ends with ''packagename''.

===== More Stringent Filtering =====

If the search is returning too many results because the word you're looking for is found in package descriptions, you may want to try using the beginning of line glob character, the caret:

{{cli|opkg list{{!}} grep ^''packagename''}}

This will cause only lines which begin with ''packagename'' to be displayed.

===== More Information about Filtering the Package List =====

There are many more advanced regular expressions which can be used with grep. These will allow you to do things like match wildcards from the beginning of the line up to the characters you specify after the wildcard (which you might do if you know the package name contains a word, but doesn't start with that word, yet the word is too common to allow it to search through all of the text), but this should be enough to get you started. There are many in depth resources for the usage of <code>grep</code> available online.

=== Installing New Packages ===

Once you have found a package or list of packages you wish to install, the <code>opkg</code> command makes installation simple:

{{cli|opkg install ''packagename''}}

This will download and install ''packagename'' and all of its dependencies for you.

If you would like to install more than one at a time, you can do so by specifying them as a space-separated list:

{{cli|opkg install ''package1'' ''package2'' ''package3'' ''etc''}}

As before, all of the dependencies for the packages specified will be automatically downloaded and installed by <code>opkg</code> as well.

=== Removing Packages ===

When you have installed a package that you no longer want to have on your system, <code>opkg</code> provides the <code>remove</code> command for removal of the package:

{{cli|opkg remove ''packagename''}}

If there is anything that depends on it, <code>opkg</code> will output an error message indicating that packages depend on it.

You can add the <code>--force-removal-of-dependent-packages</code> to force it to remove the package and everything that depends on it:

{{cli|opkg remove --force-removal-of-dependent-packages ''packagename''}}

{{Caution|The very verbose argument name is required because this can be a dangerous way to remove packages. The length of the argument's name (<code>--force-removal-of-dependent-packages</code>)is intended to remind you of the danger. You may find yourself with an unbootable system if you uninstall a package which was depended upon by important system packages. It's generally wiser to use the less heavy handed version, <code>--force-depends</code>, which will only remove the package and the dependencies which are one layer deep:

{{cli|opkg remove --force-depends ''packagename''}}

If more than one layer of dependencies needs to be removed, you should use the <code>remove</code> command without either of these options. Use it on each dependency layer to see what depends upon those dependencies, and continue this procedure recursively to ensure that nothing important will be removed before you attempt to remove a package with the heavy handed variant.
 
If you do render your system unbootable, you may contact EMAC, and we will help you get your system back into a usable state for a small fee. If you would prefer to avoid this fee, please be very careful about what you remove since damage to the filesystem caused by misuse of the above commands is not covered under the EMAC warranty.
}}




{{:Templateimpl:examples | initials=MD | title=OPKG | desc=Package Management with OPKG | project=OE 5 }}
{{example|Removing a Package which has Dependencies}}

{{clo}}
{{clio|opkg remove alsa-conf-base}}
No packages removed. 
Collected errors: 
 * print_dependents_warning: Package alsa-conf-base is depended upon by packages: 
 * print_dependents_warning: libasound2 
 * print_dependents_warning: These might cease to work if package alsa-conf-base is removed. 
 * print_dependents_warning: Force removal of this package with --force-depends. 
 * print_dependents_warning: Force removal of this package and its dependents 
 * print_dependents_warning: with --force-removal-of-dependent-packages. 
{{clio|opkg remove --force-depends alsa-conf-base}}
Removing package alsa-conf-base from root...
{{clio|}}
{{clos}}

{{example|Updating a Package}}

{{clop}}
{{cliop|opkg update}}<nowiki>

Downloading ftp://oe50@ftp.emacinc.com/all/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/all/Packages.gz.
Downloading ftp://oe50@ftp.emacinc.com/ipac9x25/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/ipac9x25/Packages.gz.
Downloading ftp://oe50@ftp.emacinc.com/armv5e/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/armv5e/Packages.gz.
Collected errors:
* opkg_update_cmd: Not able to update list of packages in /var/lib/opkg/all.
* opkg_update_cmd: Not able to update list of packages in /var/lib/opkg/ipac9x25.
* opkg_update_cmd: Not able to update list of packages in /var/lib/opkg/armv5e.
</nowiki>{{closp}}

If you've forgotten to remount your root filesystem as rw, you'll see output similar to that shown above. Remount the filesystem rw and try again:

{{cli|oemntrw}}

{{clop}}
{{cliop|opkg update}}<nowiki>

Downloading ftp://oe50@ftp.emacinc.com/all/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/all/Packages.gz.
Updated list of available packages in /var/lib/opkg/all.
Downloading ftp://oe50@ftp.emacinc.com/ipac9x25/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/ipac9x25/Packages.gz.
Updated list of available packages in /var/lib/opkg/ipac9x25.
Downloading ftp://oe50@ftp.emacinc.com/armv5e/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/armv5e/Packages.gz.
Updated list of available packages in /var/lib/opkg/armv5e.

</nowiki>

{{cliop|opkg list-upgradable}}<nowiki>

u-boot-fw-utils - v2014.07+git0+91fbeacdf3-r0 - v2015.04+git0+5feae908fd-r0
libssl1.0.0 - 1.0.2a-r0 - 1.0.2d-r0
tzdata-pacific - 2015b-r0 - 2015d-r0
tzdata - 2015b-r0 - 2015d-r0
openssl-conf - 1.0.2a-r0 - 1.0.2d-r0
libcrypto1.0.0 - 1.0.2a-r0 - 1.0.2d-r0
tzdata-arctic - 2015b-r0 - 2015d-r0
tzdata-africa - 2015b-r0 - 2015d-r0
tzdata-europe - 2015b-r0 - 2015d-r0
tzdata-americas - 2015b-r0 - 2015d-r0
tzdata-atlantic - 2015b-r0 - 2015d-r0
tzdata-australia - 2015b-r0 - 2015d-r0
tzdata-antarctica - 2015b-r0 - 2015d-r0
tzdata-asia - 2015b-r0 - 2015d-r0

</nowiki>

{{cliop|opkg upgrade libssl1.0.0 openssl-conf}}<nowiki>

Upgrading libssl1.0.0 from 1.0.2a-r0 to 1.0.2d-r0 on root.
Downloading ftp://oe50opkg:opkgoe50123@ftp.emacinc.com/armv5e/libssl1.0.0_1.0.2d-r0_armv5e.ipk.
Upgrading libcrypto1.0.0 from 1.0.2a-r0 to 1.0.2d-r0 on root.
Downloading ftp://oe50opkg:opkgoe50123@ftp.emacinc.com/armv5e/libcrypto1.0.0_1.0.2d-r0_armv5e.ipk.
Upgrading openssl-conf from 1.0.2a-r0 to 1.0.2d-r0 on root.
Downloading ftp://oe50opkg:opkgoe50123@ftp.emacinc.com/armv5e/openssl-conf_1.0.2d-r0_armv5e.ipk.
Configuring openssl-conf.
Configuring libcrypto1.0.0.
Configuring libssl1.0.0.

</nowiki>
{{cliop|}}
{{closp}}

Here, the <code>libssl1.0.0</code> package and the <code>openssl-conf</code> package were both upgraded simultaneously by specifying them to <code>opkg upgrade</code> as a space delimited list.

{{example|Installing a New Package}}

{{clop}}
{{cliop|opkg update}}<nowiki>

Downloading ftp://oe50@ftp.emacinc.com/all/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/all/Packages.gz.
Updated list of available packages in /var/lib/opkg/all.
Downloading ftp://oe50@ftp.emacinc.com/ipac9x25/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/ipac9x25/Packages.gz.
Updated list of available packages in /var/lib/opkg/ipac9x25.
Downloading ftp://oe50@ftp.emacinc.com/armv5e/Packages.gz.
Inflating ftp://oe50@ftp.emacinc.com/armv5e/Packages.gz.
Updated list of available packages in /var/lib/opkg/armv5e.

</nowiki>
{{cliop|opkg list {{!}} grep iptables -A 2}}<nowiki>

iptables - 1.4.21-r0 - Tools for managing kernel packet filtering capabilities iptables is the
userspace command line program used to configure and control network
packet filtering code in Linux.
iptables-dbg - 1.4.21-r0 - Tools for managing kernel packet filtering capabilities - Debugging files
iptables is the userspace command line program used to configure and
control network packet filtering code in Linux. This package contains
ELF symbols and related sources for debugging purposes.
iptables-dev - 1.4.21-r0 - Tools for managing kernel packet filtering capabilities - Development
files iptables is the userspace command line program used to configure
and control network packet filtering code in Linux. This package
contains symbolic links, header files, and related items necessary for
--
iptables-doc - 1.4.21-r0 - Tools for managing kernel packet filtering capabilities - Documentation
files iptables is the userspace command line program used to configure
and control network packet filtering code in Linux. This package

</nowiki>
{{cliop|opkg install iptables-doc}}<nowiki>

Installing iptables-doc (1.4.21-r0) on root.
Downloading ftp://oe50@ftp.emacinc.com/armv5e/iptables-doc_1.4.21-r0_armv5e.ipk.
Configuring iptables-doc.

</nowiki>
{{cliop|}}
{{closp}}

If you try to install a package which is already installed, it will check to see if it's up to date:

{{clop}}
{{cliop |opkg install iptables}}<nowiki>

Package iptables (1.4.21-r0) installed in root is up to date.

</nowiki>
{{cliop|}}
{{closp}}

{{:Templateimpl:conclusion | initials=MD | title=OPKG | desc=Package Management with OPKG | project=OE 5 }}
This article demonstrated the basic usage of <code>opkg</code>, but did not cover any of the more advanced topics. Topics covered in this article include installing software, updating software, removing software, and searching for available packages.

More advanced topics are covered in other articles, such as configuring <code>opkg</code>, inspecting package metadata and package contents, and creating packages. Look to the last section of this article if you need more information on these topics.

The EMAC opkg package repository contains a wealth of software you can install to customize and enhance the environment of your EMAC OE Linux machine. While a great deal of additional functionality is provided with the standard EMAC opkg repository, you may not be able to find a particular package you need. If you encounter this situation, you may contact EMAC support to request the creation of a custom package for you. EMAC is able to provide custom packages for most opensource software, and can recommend good alternatives in cases where a specific software package has been found to work or perform poorly (or not at all) in an embedded environment. EMAC charges a nominal fee to provide this package, but this fee includes support for the package as well.

The EMAC opkg repository is a great source of additional functionality for your machine, but even more importantly, the EMAC opkg repository is a source of updates for the software installed on your machine. Taking advantage of the EMAC opkg repository to update your systems helps to ensure that your systems will be protected from the latest threats, such as the Heartbleed OpenSSL vulnerability that made a big splash in the recent past.

{{:Templateimpl:moreinfo | initials=MD | title=OPKG | desc=Package Management with OPKG | project=OE 5 }}
* [[opkg:installedPkgs|Working with Installed Packages]]
* [[opkg:configuration|Configuring the Package Manager]]
* [[opkg::advanced|Advanced Package Management]]

Booting with a USB Root Filesystem

2019-03-05T23:51:01Z

Mgloff:

It is possible to boot most EMAC OE systems using a USB thumb drive as the root filesystem and to optionally load a kernel from. This method can be especially useful for updating or recovering the root filesystem when a network connection or a network file server is not available. This page describes the steps required to boot into a root filesystem residing on a USB thumb drive.

__TOC__

==Prerequisites==

Some prerequisites must be met prior to being able to boot a root filesystem from a USB drive.

===USB Thumb Drive===

Any blank USB drive. If it is not blank, this process will completely wipe the data that exists on the USB drive.

===Root Filesystem===

A complete root filesystem for the EMAC OE system to boot from must be stored on the USB drive.

===Linux Host Computer===

Either a native Linux host or Windows host running a Linux virtual machine.

==Configuring the USB Thumb Drive==

In a terminal window, start the dmesg log with the follow option to watch for new devices.

{{cli | username=developer | hostname=ldc | pwd=~ | dmesg -w }}

Insert the USB drive and watch for the device to be announced.

{{clo}}
[ 2796.940110] scsi host6: usb-storage 1-1.2:1.0 
[ 2797.963442] scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0272 PQ: 0 ANSI: 0 
[ 2797.963905] sd 6:0:0:0: Attached scsi generic sg4 type 0 
[ 2798.269544] sd 6:0:0:0: [sdd] 7774208 512-byte logical blocks: (3.98 GB/3.71 GiB) 
[ 2798.271027] sd 6:0:0:0: [sdd] Write Protect is off 
[ 2798.271030] sd 6:0:0:0: [sdd] Mode Sense: 0b 00 00 08 
[ 2798.272502] sd 6:0:0:0: [sdd] No Caching mode page found 
[ 2798.272508] sd 6:0:0:0: [sdd] Assuming drive cache: write through 
[ 2798.279486] sdd: 
[ 2798.283834] sd 6:0:0:0: [sdd] Attached SCSI removable disk 
{{clos}}

 
{{ imbox | type=notice | text=If using a virtual machine, wait for Windows to install the Virtualbox USB driver. Then make the virtual machine aware of the USB drive by going into the Devices menu option in virtualbox, then sub-option USB and select your USB device.}}
 

The output of the <code>dmesg</code> command shows that the root device node for the USB drive in this case is <code>sdd</code> and no partitions. Partitions on the drive would be listed as <code>sdd1</code>, <code>sdd2</code>, etc. Inspect the output shown above to see the particular device node on the development PC where the USB drive is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with <code>sd</code>. The third letter will specify which of these devices is assigned to the USB drive. The number will indicate the partitions, if any. Press Ctrl and 'c' to exit dmesg.

* At this point, it is wise to double check that device node is actually the USB drive and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdd</code> as the example device node, type the following command:

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | mount {{!}} grep sdd }}
/dev/sdd on /media/developer/FBF6-1988 type vfat
{{clos}}

This shows that the device node, <code>/dev/sdd</code>, is in fact the USB drive. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

If nothing is returned, then the USB drive did not get automatically mounted. Proceed to the next step.

Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4fcf5773
</nowiki>
{{closp}}

The output of fdisk will also show information about any partitions that may exist on the USB drive. For example, another drive with a single FAT32 formatted partition will look like:
{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe6077d37

Device Boot Start End Sectors Size Id Type
/dev/sdh1 2048 7774207 7772160 3.7G c W95 FAT32 (LBA)
</nowiki>
{{closp}}

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 3.7 GB in size, which corresponds with the size of the 4 GB USB drive being used in this example.

Unmount all of the USB drives partitions that were listed from the <code>mount</code> command above.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd }}

If there is a partition listed:

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd1 }}

==Repartition the USB Drive==

Once the correct drive letter is determined, we will create a new Linux partition.

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk /dev/sdd }}<nowiki>

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): o
Created a new DOS disklabel with disk identifier 0x05d5e983.

Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7774207, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-7774207, default 7774207):

Created a new partition 1 of type 'Linux' and of size 3.7 GiB.

Command (m for help): p
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x05d5e983

Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 7774207 7772160 3.7G 83 Linux

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
</nowiki>
{{closp}}

The fdisk commands are:

<code>o</code> - Create a new empty partition table

<code>n</code> - Create a new partition

<code>p</code> - The type of partition is a primary partition

<code>1</code> - Create the first partition

<code><ENTER></code> - Accept default start

<code><ENTER></code> - Accept default end

<code>p</code> - Print the new partition layout

<code>w</code> - Write the new partition layout and exit

==Format the Partition==

The first partition will be formatted with the ext4 filesystem.

{{cli | username=developer | hostname=ldc | pwd=~ | yes {{!}} sudo mkfs.ext4 /dev/sdd1 }}

==Mount the Partition==

The first partition of the USB drive will be mounted so that it is accessible to write to.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo mkdir -p /media/card }}
{{cli | username=developer | hostname=ldc | pwd=~ | sudo mount /dev/sdd1 /media/card }}

The USB drive is now accessible through the <code>/media/card</code> directory.

==Extract Filesystem Archive==

Locate where the filesystem archive has been downloaded. If the archive is called rootfs.tar.gz and is in the users Downloads directory:

{{cli | username=developer | hostname=ldc | pwd=~ | cd /media/card }}
{{cli | username=developer | hostname=ldc | pwd=/media/card | sudo tar zxf ~/Downloads/rootfs.tar.gz }}

==Configuring the Client to Boot from USB==

===Configuring U-Boot===

Insert the USB drive into an available port on the target board.
Set the bootargs variable to tell the kernel to boot into the USB filesystem:

U-Boot> setenv bootargs console=${console} root=/dev/sda1 rootfstype=ext4
U-Boot> run bootargs

This line sets up the environment needed to boot from the USB drive. These options will be passed to the Linux kernel when booting it. The <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>. The <code>root=/dev/sda1</code> directive tells Linux to instantiate with the USB block device, <code>/dev/sda1</code>, as the root filesystem. The <code>rootfstype=ext4</code> directive tells Linux that the root filesystem is of the EXT4 variety.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the USB root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

===Alternate Kernel Load===

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. The below example assumes a kernel named zImage-test was placed in the /boot directory of the USB drive. Also see [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM | Executing kernel from RAM ]]

U-Boot> usb start
U-Boot> usb storage
U-Boot> ext2load usb 0:1 ${loadaddr} /boot/zImage-test
U-Boot> bootz ${loadaddr}

The first two commands initialize the USB storage system in U-Boot. The <code>ext2load</code> line says to use the USB device 0 partition 1 and load into RAM at ${loadaddr} the file /boot/zImage-test from the USB drive. The last line boots the kernel that has been loaded into memory.

==Conclusion==

Using a USB thumb drive for the root filesystem allows boards to boot quickly into a rescue or known good version of a filesystem and provides a method for remotely backing up the filesystem installed on an embedded machine. Setting up a machine to boot to a root filesystem via USB requires little work; most of the work is in setting up the USB thumb drive.

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to USB boot. | project=OE 5.0 }}
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Loading_Images_with_U-Boot | Loading Images with U-Boot]]
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

Loading Images onto eMMC Devices

2019-03-05T23:44:50Z

Mgloff:

{{todo|SEOKWREV (12.31.13-13:15->MD-);(12.31.13-14:50->MW+);(12.31.13-18:10->MD+);(12.31.13-18:45->MG+);(03.06.14-15:35->BS-);(04.11.14-15:55->BS+);(05.01.15-12:12->MG+);(11.05.15-17:50->MD+)|Michael Welling|project=oe 4,oe 5,mw,md,mg,bs,SEOKWREV}}

{{#seo:
|title=Loading Images onto eMMC Devices
|titlemode=append
|keywords=eMMC,EXT3 Partition,FAT32 Partition,Root File System
|description=Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.
}}
== Background ==
Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.

U-Boot does not support writing to file systems in eMMC. To overcome this issue, the embedded target needs to boot into an alternate media such as a network file system or USB flash drive. Once the board has booted into Linux, the eMMC can be partitioned and formatted, and the root file system can be extracted. The SoM-3517M requires a special FAT formatted partition that contains the bootloader and Linux kernel images. This article explains the general process of writing the eMMC from Linux as well as some specifics related to programming the SoM-3517M, SoM-9X25, SoM-A5D35/6, SoM-3354, SoM-iMX6M and IPAC-9X25.

{{note | The procedures below require that you have a TFTP and NFS server setup on a host computer or a USB thumb drive created using [[Booting_with_a_USB_Root_Filesystem | Booting with a USB Root Filesystem]]. }}

* Instructions on setting up a TFTP server: [[Installing TFTP server]]
* Installation of an NFS Server with Linux: [[Setting up an NFS File Server]]
* Instruction for booting into NFS with U-Boot: [[Booting with an NFS Root Filesystem]]
* More information about MMC: http://en.wikipedia.org/wiki/MultiMediaCard

== Creating partitions and formatting eMMC ==

Once the Linux command prompt is reached, Linux utilities can be used to create and format partitions on the eMMC. By partitioning the eMMC, the partitions can be accessed individually and formatted differently as required. The <code>fdisk</code> utility can be used to create these partitions on the eMMC.

For example here is the procedure for creating a 128 MB primary partition:

{{clop}}
{{cliop | hostname=emac-oe |fdisk /dev/mmcblk0}}<nowiki>
The number of cylinders for this disk is set to 57024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-57024, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-57024, default 57024): +128M

Command (m for help): p

Disk /dev/mmcblk0: 1868 MB, 1868562432 bytes
4 heads, 16 sectors/track, 57024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 3907 125016 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table
[ 566.062896] mmcblk0: p1
</nowiki>
{{cliop | hostname=emac-oe|}}
{{closp}}

For more information about <code>fdisk</code>, see:
http://tldp.org/HOWTO/Partition/fdisk_partitioning.html

After creating the partitions, they can formatted with the various <code>mkfs</code> utilities. The formatting used is dependent on how the partition is to be accessed. For eMMC root filesystems EMAC currently uses EXT4 (http://en.wikipedia.org/wiki/Ext3). Other formatting options are available (EXT2, EXT3, etc) and can be used. It should be noted that the kernel must be configured to support the chosen filesystem and the bootargs need to specify the correct type.

{{note | For additional information on configuring and compiling the Linux kernel see the following page: [[Building the Linux Kernel]] }}

As described above, the <code>bootargs</code> is used for signalling to the Linux kernel the location of the root filesystem partition, and its formatting. The <code>root</code> parameter is used to specify the partition to use while the <code>rootfstype</code> parameter is used to specify the formatting of the partition.

{{note | For more information about the <code>bootargs</code> variable see this page: [[U-Boot Overview]] }}

Partitions accessed by processor boot ROM or U-Boot typically need to be formatted with FAT32 formatting. The SoM-3517M, for instance, requires a FAT32 formatted partition for the bootloader and kernel in order to boot properly from eMMC. For more specifics about the SoM-3517M, see the quick reference section below.

===Formatting a partition with EXT4===

{{clop}}
{{cliop | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}<nowiki>
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
31360 inodes, 125016 blocks
6250 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
16 block groups
8192 blocks per group, 8192 fragments per group
1960 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
</nowiki>
{{cliop| hostname=emac-oe |}}
{{closp}}

===Formatting a partition with FAT32===

{{clop}}
{{cliop | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
mkdosfs 2.11 (12 Mar 2005)
{{cliop | hostname=emac-oe |}}
{{closp}}

== Extracting filesystems to eMMC ==
After formatting a partition correctly, the partition can be mounted and files can be loaded to the eMMC.

For example, here is the procedure for writing a root filesystem to the first partition of an eMMC card:

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe |tar xzvf /images/emac-image.rootfs.tar.gz}}
<nowiki> ⋮</nowiki>
{{clos}}

In the above example the <code>/mnt/card</code> directory is called the mount point. The <code>mkdir -p</code> command creates the directory if it does not already exist. The <code>mount</code> command attaches the specified partition to the directory. Any files written to the mounted directory will go to the partition on the eMMC. After the mount is complete, files can be extracted as shown using the <code>tar</code> command.

It should be noted that the <code>/etc/fstab</code> file can be used to specify mount points for partitions upon boot. See http://en.wikipedia.org/wiki/Fstab for additional information.

== Quick Reference (by Target Type) ==
This section is used to provide specifics for programming eMMC on various targets.

For the partitioning sections, the information in the parenthesis denotes a keyboard input sequence. The (n,p,1,default,+64M) creates a new primary partition. Each input is followed a carriage return and the default is selected by pressing carriage return with no entry. See the expanded example in the above '''Creating partitions and formatting eMMC''' section for an idea of how the interface looks when commands are executed correctly.

=== SoM-3517M ===
==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk -H 255 -S 63 /dev/mmcblk0}}

The partitioning steps are as follows:
# Create 1st partition (n,p,1,default,+64M)
# Create 2nd partition (n,p,2,default,default)
# Change 1st partition type to FAT32 (t,1,c)
# Make 1st partition ACTIVE (a,1)
# Write (w)

==== Formatting the eMMC ====

{{clo}}
{{clio | hostname=emac-oe |mkfs.ext3 /dev/mmcblk0p2}}
{{clio | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
{{clos}}

The first command formats the second partition as ext3. The <code>mkfs.ext3</code> command can take further configuration parameters. See the <code>mkfs.ext3</code> man page for more information.

The second command formats the first partition as FAT32 for use with the AM3517's boot ROM. This is a requirement to boot from the eMMC.

==== Adding Kernel and Bootloader ====

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /images}}
{{clio | hostname=emac-oe | pwd=images |cp MLO uImage u-boot.bin /mnt/card/}}
{{clio | hostname=emac-oe | pwd=images |sync}}
{{clio | hostname=emac-oe | pwd=images |umount /dev/mmcblk0p1}}
{{clos}}

{{ note | The first partition '''must''' be formatted FAT32 and the MLO binary '''must''' be in the first sector for the eMMC boot sequence to work properly. }}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe | pwd=images |mount /dev/mmcblk0p2 /mnt/card}}
{{clio | hostname=emac-oe | pwd=images |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p2}}
{{clos}}

=== SoM-9X25M / IPAC-9X25 / SoM-A5D35/6 / SoM-3354 / SoM-iMX6M ===

Unlike the SoM-3517, these SoMs store U-Boot and the Linux kernel in a separate serial flash instead of the eMMC. Typically, two partitions are created. The first partition contains the complete filesystem and is mounted read-only while the second partition contains the /home directory and is mounted read-write.

=== Unmount partitions ===

{{cli | hostname=emac-oe |umount /dev/mmcblk0p1}}
{{cli | hostname=emac-oe |umount /dev/mmcblk0p2}}

==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk /dev/mmcblk0}}

{{ note | For the SoM-9x25M revisions 7 and above, the eMMC block device is /dev/sdb }}

The partitioning steps are as follows:

# Create 1st partition (n,p,1,default,+1G)
# Create 2nd partition (n,p,2,default,default)
# Write (w)

==== Formatting the eMMC ====
{{clo}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p2}}
{{clos}}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p1}}
{{clos}}

Booting with a USB Root Filesystem

2019-03-05T23:40:33Z

Mgloff:

It is possible to boot most EMAC OE systems using a USB thumb drive as the root filesystem and to optionally load a kernel from. This method can be especially useful for updating or recovering the root filesystem when a network connection or a network file server is not available. This page describes the steps required to boot into a root filesystem residing on a USB thumb drive.

__TOC__

==Prerequisites==

Some prerequisites must be met prior to being able to boot a root filesystem from a USB drive.

===USB Thumb Drive===

Any blank USB drive. If it is not blank, this process will completely wipe the data that exists on the USB drive.

===Root Filesystem===

A complete root filesystem for the EMAC OE system to boot from must be stored on the USB drive.

===Linux Host Computer===

Either a native Linux host or Windows host running a Linux virtual machine.

==Configuring the USB Thumb Drive==

In a terminal window, start the dmesg log with the follow option to watch for new devices.

{{cli | username=developer | hostname=ldc | pwd=~ | dmesg -w }}

Insert the USB drive and watch for the device to be announced.

{{clo}}
[ 2796.940110] scsi host6: usb-storage 1-1.2:1.0 
[ 2797.963442] scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0272 PQ: 0 ANSI: 0 
[ 2797.963905] sd 6:0:0:0: Attached scsi generic sg4 type 0 
[ 2798.269544] sd 6:0:0:0: [sdd] 7774208 512-byte logical blocks: (3.98 GB/3.71 GiB) 
[ 2798.271027] sd 6:0:0:0: [sdd] Write Protect is off 
[ 2798.271030] sd 6:0:0:0: [sdd] Mode Sense: 0b 00 00 08 
[ 2798.272502] sd 6:0:0:0: [sdd] No Caching mode page found 
[ 2798.272508] sd 6:0:0:0: [sdd] Assuming drive cache: write through 
[ 2798.279486] sdd: 
[ 2798.283834] sd 6:0:0:0: [sdd] Attached SCSI removable disk 
{{clos}}

 
{{ imbox | type=notice | text=If using a virtual machine, wait for Windows to install the Virtualbox USB driver. Then make the virtual machine aware of the USB drive by going into the Devices menu option in virtualbox, then sub-option USB and select your USB device.}}
 

The output of the <code>dmesg</code> command shows that the root device node for the USB drive in this case is <code>sdd</code> and no partitions. Partitions on the drive would be listed as <code>sdd1</code>, <code>sdd2</code>, etc. Inspect the output shown above to see the particular device node on the development PC where the USB drive is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with <code>sd</code>. The third letter will specify which of these devices is assigned to the USB drive. The number will indicate the partitions, if any. Press Ctrl and 'c' to exit dmesg.

* At this point, it is wise to double check that device node is actually the USB drive and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdd</code> as the example device node, type the following command:

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | mount {{!}} grep sdd }}
/dev/sdd on /media/developer/FBF6-1988 type vfat
{{clos}}

This shows that the device node, <code>/dev/sdd</code>, is in fact the USB drive. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4fcf5773
</nowiki>
{{closp}}

The output of fdisk will also show information about any partitions that may exist on the USB drive. For example, another drive with a single FAT32 formatted partition will look like:
{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe6077d37

Device Boot Start End Sectors Size Id Type
/dev/sdh1 2048 7774207 7772160 3.7G c W95 FAT32 (LBA)
</nowiki>
{{closp}}

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 3.7 GB in size, which corresponds with the size of the 4 GB USB drive being used in this example.

Unmount all of the USB drives partitions that were listed from the <code>mount</code> command above.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd }}

If there is a partition listed:

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd1 }}

==Repartition the USB Drive==

Once the correct drive letter is determined, we will create a new Linux partition.

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk /dev/sdd }}<nowiki>

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): o
Created a new DOS disklabel with disk identifier 0x05d5e983.

Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7774207, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-7774207, default 7774207):

Created a new partition 1 of type 'Linux' and of size 3.7 GiB.

Command (m for help): p
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x05d5e983

Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 7774207 7772160 3.7G 83 Linux

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
</nowiki>
{{closp}}

The fdisk commands are:

<code>o</code> - Create a new empty partition table

<code>n</code> - Create a new partition

<code>p</code> - The type of partition is a primary partition

<code>1</code> - Create the first partition

<code><ENTER></code> - Accept default start

<code><ENTER></code> - Accept default end

<code>p</code> - Print the new partition layout

<code>w</code> - Write the new partition layout and exit

==Format the Partition==

The first partition will be formatted with the ext4 filesystem.

{{cli | username=developer | hostname=ldc | pwd=~ | yes {{!}} sudo mkfs.ext4 /dev/sdd1 }}

==Mount the Partition==

The first partition of the USB drive will be mounted so that it is accessible to write to.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo mkdir -p /media/card }}
{{cli | username=developer | hostname=ldc | pwd=~ | sudo mount /dev/sdd1 /media/card }}

The USB drive is now accessible through the <code>/media/card</code> directory.

==Extract Filesystem Archive==

Locate where the filesystem archive has been downloaded. If the archive is called rootfs.tar.gz and is in the users Downloads directory:

{{cli | username=developer | hostname=ldc | pwd=~ | cd /media/card }}
{{cli | username=developer | hostname=ldc | pwd=/media/card | sudo tar zxf ~/Downloads/rootfs.tar.gz }}

==Configuring the Client to Boot from USB==

===Configuring U-Boot===

Insert the USB drive into an available port on the target board.
Set the bootargs variable to tell the kernel to boot into the USB filesystem:

U-Boot> setenv bootargs console=${console} root=/dev/sda1 rootfstype=ext4
U-Boot> run bootargs

This line sets up the environment needed to boot from the USB drive. These options will be passed to the Linux kernel when booting it. The <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>. The <code>root=/dev/sda1</code> directive tells Linux to instantiate with the USB block device, <code>/dev/sda1</code>, as the root filesystem. The <code>rootfstype=ext4</code> directive tells Linux that the root filesystem is of the EXT4 variety.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the USB root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

===Alternate Kernel Load===

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. The below example assumes a kernel named zImage-test was placed in the /boot directory of the USB drive. Also see [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM | Executing kernel from RAM ]]

U-Boot> usb start
U-Boot> usb storage
U-Boot> ext2load usb 0:1 ${loadaddr} /boot/zImage-test
U-Boot> bootz ${loadaddr}

The first two commands initialize the USB storage system in U-Boot. The <code>ext2load</code> line says to use the USB device 0 partition 1 and load into RAM at ${loadaddr} the file /boot/zImage-test from the USB drive. The last line boots the kernel that has been loaded into memory.

==Conclusion==

Using a USB thumb drive for the root filesystem allows boards to boot quickly into a rescue or known good version of a filesystem and provides a method for remotely backing up the filesystem installed on an embedded machine. Setting up a machine to boot to a root filesystem via USB requires little work; most of the work is in setting up the USB thumb drive.

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to USB boot. | project=OE 5.0 }}
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Loading_Images_with_U-Boot | Loading Images with U-Boot]]
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

Booting with a USB Root Filesystem

2019-03-05T23:31:51Z

Mgloff:

It is possible to boot most EMAC OE systems using a USB thumb drive as the root filesystem and to optionally load a kernel from. This method can be especially useful for updating or recovering the root filesystem when a network connection or a network file server is not available. This page describes the steps required to boot into a root filesystem residing on a USB thumb drive.

__TOC__

==Prerequisites==

Some prerequisites must be met prior to being able to boot a root filesystem from a USB drive.

===USB Thumb Drive===

Any blank USB drive. If it is not blank, this process will completely wipe the data that exists on the USB drive.

===Root Filesystem===

A complete root filesystem for the EMAC OE system to boot from must be stored on the USB drive.

===Linux Host Computer===

Either a native Linux host or Windows host running a Linux virtual machine.

==Configuring the USB Thumb Drive==

In a terminal window, start the dmesg log with the follow option to watch for new devices.

{{cli | username=developer | hostname=ldc | pwd=~ | dmesg -w }}

Insert the USB drive and watch for the device to be announced.

{{clo}}
[ 2796.940110] scsi host6: usb-storage 1-1.2:1.0 
[ 2797.963442] scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0272 PQ: 0 ANSI: 0 
[ 2797.963905] sd 6:0:0:0: Attached scsi generic sg4 type 0 
[ 2798.269544] sd 6:0:0:0: [sdd] 7774208 512-byte logical blocks: (3.98 GB/3.71 GiB) 
[ 2798.271027] sd 6:0:0:0: [sdd] Write Protect is off 
[ 2798.271030] sd 6:0:0:0: [sdd] Mode Sense: 0b 00 00 08 
[ 2798.272502] sd 6:0:0:0: [sdd] No Caching mode page found 
[ 2798.272508] sd 6:0:0:0: [sdd] Assuming drive cache: write through 
[ 2798.279486] sdd: 
[ 2798.283834] sd 6:0:0:0: [sdd] Attached SCSI removable disk 
{{clos}}

The output of the <code>dmesg</code> command shows that the root device node for the USB drive in this case is <code>sdd</code> and no partitions. Partitions on the drive would be listed as <code>sdd1</code>, <code>sdd2</code>, etc. Inspect the output shown above to see the particular device node on the development PC where the USB drive is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with <code>sd</code>. The third letter will specify which of these devices is assigned to the USB drive. The number will indicate the partitions, if any. Press Ctrl and 'c' to exit dmesg.

* At this point, it is wise to double check that device node is actually the USB drive and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdd</code> as the example device node, type the following command:

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | mount {{!}} grep sdd }}
/dev/sdd on /media/developer/FBF6-1988 type vfat
{{clos}}

This shows that the device node, <code>/dev/sdd</code>, is in fact the USB drive. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4fcf5773
</nowiki>
{{closp}}

The output of fdisk will also show information about any partitions that may exist on the USB drive. For example, another drive with a single FAT32 formatted partition will look like:
{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}<nowiki>

Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe6077d37

Device Boot Start End Sectors Size Id Type
/dev/sdh1 2048 7774207 7772160 3.7G c W95 FAT32 (LBA)
</nowiki>
{{closp}}

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 3.7 GB in size, which corresponds with the size of the 4 GB USB drive being used in this example.

Unmount all of the USB drives partitions that were listed from the <code>mount</code> command above.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd }}

If there is a partition listed:

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd1 }}

==Repartition the USB Drive==

Once the correct drive letter is determined, we will create a new Linux partition.

{{clop}}
{{cliop | username=developer | hostname=ldc | pwd=~ | sudo fdisk /dev/sdd }}<nowiki>

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): o
Created a new DOS disklabel with disk identifier 0x05d5e983.

Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-7774207, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-7774207, default 7774207):

Created a new partition 1 of type 'Linux' and of size 3.7 GiB.

Command (m for help): p
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors
Disk model: STORAGE DEVICE
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x05d5e983

Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 7774207 7772160 3.7G 83 Linux

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
</nowiki>
{{closp}}

The fdisk commands are:

<code>o</code> - Create a new empty partition table

<code>n</code> - Create a new partition

<code>p</code> - The type of partition is a primary partition

<code>1</code> - Create the first partition

<code><ENTER></code> - Accept default start

<code><ENTER></code> - Accept default end

<code>p</code> - Print the new partition layout

<code>w</code> - Write the new partition layout and exit

==Format the Partition==

The first partition will be formatted with the ext4 filesystem.

{{cli | username=developer | hostname=ldc | pwd=~ | yes {{!}} sudo mkfs.ext4 /dev/sdd1 }}

==Mount the Partition==

The first partition of the USB drive will be mounted so that it is accessible to write to.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo mkdir -p /media/card }}
{{cli | username=developer | hostname=ldc | pwd=~ | sudo mount /dev/sdd1 /media/card }}

The USB drive is now accessible through the <code>/media/card</code> directory.

==Extract Filesystem Archive==

Locate where the filesystem archive has been downloaded. If the archive is called rootfs.tar.gz and is in the users Downloads directory:

{{cli | username=developer | hostname=ldc | pwd=~ | cd /media/card }}
{{cli | username=developer | hostname=ldc | pwd=/media/card | sudo tar zxf ~/Downloads/rootfs.tar.gz }}

==Configuring the Client to Boot from USB==

===Configuring U-Boot===

Insert the USB drive into an available port on the target board.
Set the bootargs variable to tell the kernel to boot into the USB filesystem:

U-Boot> setenv bootargs console=${console} root=/dev/sda1 rootfstype=ext4
U-Boot> run bootargs

This line sets up the environment needed to boot from the USB drive. These options will be passed to the Linux kernel when booting it. The <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>. The <code>root=/dev/sda1</code> directive tells Linux to instantiate with the USB block device, <code>/dev/sda1</code>, as the root filesystem. The <code>rootfstype=ext4</code> directive tells Linux that the root filesystem is of the EXT4 variety.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the USB root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

===Alternate Kernel Load===

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. The below example assumes a kernel named zImage-test was placed in the /boot directory of the USB drive. Also see [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM | Executing kernel from RAM ]]

U-Boot> usb start
U-Boot> usb storage
U-Boot> ext2load usb 0:1 ${loadaddr} /boot/zImage-test
U-Boot> bootz ${loadaddr}

The first two commands initialize the USB storage system in U-Boot. The <code>ext2load</code> line says to use the USB device 0 partition 1 and load into RAM at ${loadaddr} the file /boot/zImage-test from the USB drive. The last line boots the kernel that has been loaded into memory.

==Conclusion==

Using a USB thumb drive for the root filesystem allows boards to boot quickly into a rescue or known good version of a filesystem and provides a method for remotely backing up the filesystem installed on an embedded machine. Setting up a machine to boot to a root filesystem via USB requires little work; most of the work is in setting up the USB thumb drive.

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to USB boot. | project=OE 5.0 }}
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Loading_Images_with_U-Boot | Loading Images with U-Boot]]
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

Booting with a USB Root Filesystem

2019-03-05T23:13:39Z

Mgloff:

It is possible to boot most EMAC OE systems using a USB thumb drive as the root filesystem and to optionally load a kernel from. This method can be especially useful for updating or recovering the root filesystem when a network connection or a network file server is not available. This page describes the steps required to boot into a root filesystem residing on a USB thumb drive.

__TOC__

==Prerequisites==

Some prerequisites must be met prior to being able to boot a root filesystem from a USB drive.

===USB Thumb Drive===

Any blank USB drive. If it is not blank, this process will completely wipe the data that exists on the USB drive.

===Root Filesystem===

A complete root filesystem for the EMAC OE system to boot from must be stored on the USB drive.

===Linux Host Computer===

Either a native Linux host or Windows host running a Linux virtual machine.

==Configuring the USB Thumb Drive==

In a terminal window, start the dmesg log with the follow option to watch for new devices.

{{cli | username=developer | hostname=ldc | pwd=~ | dmesg -w }}

Insert the USB drive and watch for the device to be announced.

{{clo}}
[ 2796.940110] scsi host6: usb-storage 1-1.2:1.0 
[ 2797.963442] scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0272 PQ: 0 ANSI: 0 
[ 2797.963905] sd 6:0:0:0: Attached scsi generic sg4 type 0 
[ 2798.269544] sd 6:0:0:0: [sdd] 7774208 512-byte logical blocks: (3.98 GB/3.71 GiB) 
[ 2798.271027] sd 6:0:0:0: [sdd] Write Protect is off 
[ 2798.271030] sd 6:0:0:0: [sdd] Mode Sense: 0b 00 00 08 
[ 2798.272502] sd 6:0:0:0: [sdd] No Caching mode page found 
[ 2798.272508] sd 6:0:0:0: [sdd] Assuming drive cache: write through 
[ 2798.279486] sdd: 
[ 2798.283834] sd 6:0:0:0: [sdd] Attached SCSI removable disk 
{{clos}}

The output of the <code>dmesg</code> command shows that the root device node for the USB drive in this case is <code>sdd</code> and no partitions. Partitions on the drive would be listed as <code>sdd1</code>, <code>sdd2</code>, etc. Inspect the output shown above to see the particular device node on the development PC where the USB drive is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with <code>sd</code>. The third letter will specify which of these devices is assigned to the USB drive. The number will indicate the partitions, if any. Press Ctrl and 'c' to exit dmesg.

* At this point, it is wise to double check that device node is actually the USB drive and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdd</code> as the example device node, type the following command:

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | mount {{!}} grep sdd }}
/dev/sdd on /media/developer/FBF6-1988 type vfat
{{clos}}

This shows that the device node, <code>/dev/sdd</code>, is in fact the USB drive. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}
'Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier 0x00000000 
{{clos}}

The output of fdisk will also show information about any partitions that may exist on the USB drive. For example, a drive with a single FAT32 formatted partition will look like:
{{clo}}
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier 0xb04870e5 
 
Device Boot Start End Sectors Size Id Type 
/dev/sdd1 * 8760 14438399 14429640 3.7G c W95 FAT32 (LBA) 
{{clos}}

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 3.7 GB in size, which corresponds with the size of the 4 GB USB drive being used in this example.

Unmount all of the USB drives partitions that were listed from the <code>mount</code> command above.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd }}

If there is a partition listed:

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd1 }}

==Repartition the USB Drive==

Once the correct drive letter is determined, we will create a new Linux partition.

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | sudo fdisk /dev/sdd }}
 
Welcome to fdisk (util-linux 2.31.1). 
Changes will remain in memory only, until you decide to write them. 
Be careful before using the write command. 
 
 
Command (m for help) o 
Created a new DOS disklabel with disk identifier 0xe6077d37. 
 
Command (m for help) n 
Partition type 
: p primary (0 primary, 0 extended, 4 free) 
: e extended (container for logical partitions) 
Select (default p) p 
Partition number (1-4, default 1) 1 
First sector (2048-7774207, default 2048) 
Last sector, +sectors or +size{K,M,G,T,P} (2048-7774207, default 7774207) 
 
Created a new partition 1 of type 'Linux' and of size 3.7 GiB. 
 
Command (m for help) p 
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors 
Units sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical) 512 bytes / 512 bytes 
I/O size (minimum/optimal) 512 bytes / 512 bytes 
Disklabel type dos 
Disk identifier 0xe6077d37 
 
Device Boot Start End Sectors Size Id Type 
/dev/sdd1 2048 7774207 7772160 3.7G 83 Linux 
 
Command (m for help) w 
The partition table has been altered. 
Calling ioctl() to re-read partition table. 
Syncing disks. 
 
{{clos}}

The fdisk commands are:

<code>o</code> - Create a new empty partition table

<code>n</code> - Create a new partition

<code>p</code> - The type of partition is a primary partition

<code>1</code> - Create the first partition

<code><ENTER></code> - Accept default start

<code><ENTER></code> - Accept default end

<code>p</code> - Print the new partition layout

<code>w</code> - Write the new partition layout and exit

==Format the Partition==

The first partition will be formatted with the ext4 filesystem.

{{cli | username=developer | hostname=ldc | pwd=~ | yes {{!}} sudo mkfs.ext4 /dev/sdd1 }}

==Mount the Partition==

The first partition of the USB drive will be mounted so that it is accessible to write to.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo mkdir -p /media/card }}
{{cli | username=developer | hostname=ldc | pwd=~ | sudo mount /dev/sdd1 /media/card }}

The USB drive is now accessible through the <code>/media/card</code> directory.

==Extract Filesystem Archive==

Locate where the filesystem archive has been downloaded. If the archive is called rootfs.tar.gz and is in the users Downloads directory:

{{cli | username=developer | hostname=ldc | pwd=~ | cd /media/card }}
{{cli | username=developer | hostname=ldc | pwd=/media/card | sudo tar zxf ~/Downloads/rootfs.tar.gz }}

==Configuring the Client to Boot from USB==

===Configuring U-Boot===

Insert the USB drive into an available port on the target board.
Set the bootargs variable to tell the kernel to boot into the USB filesystem:

U-Boot> setenv bootargs console=${console} root=/dev/sda1 rootfstype=ext4
U-Boot> run bootargs

This line sets up the environment needed to boot from the USB drive. These options will be passed to the Linux kernel when booting it. The <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>. The <code>root=/dev/sda1</code> directive tells Linux to instantiate with the USB block device, <code>/dev/sda1</code>, as the root filesystem. The <code>rootfstype=ext4</code> directive tells Linux that the root filesystem is of the EXT4 variety.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the USB root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

===Alternate Kernel Load===

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. The below example assumes a kernel named zImage-test was placed in the /boot directory of the USB drive. Also see [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM | Executing kernel from RAM ]]

U-Boot> usb start
U-Boot> usb storage
U-Boot> ext2load usb 0:1 ${loadaddr} /boot/zImage-test
U-Boot> bootz ${loadaddr}

The first two commands initialize the USB storage system in U-Boot. The <code>ext2load</code> line says to use the USB device 0 partition 1 and load into RAM at ${loadaddr} the file /boot/zImage-test from the USB drive. The last line boots the kernel that has been loaded into memory.

==Conclusion==

Using a USB thumb drive for the root filesystem allows boards to boot quickly into a rescue or known good version of a filesystem and provides a method for remotely backing up the filesystem installed on an embedded machine. Setting up a machine to boot to a root filesystem via USB requires little work; most of the work is in setting up the USB thumb drive.

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to USB boot. | project=OE 5.0 }}
* [[Loading_Images_onto_eMMC_Devices | Loading Images onto eMMC Devices]]
* [[Loading_Images_with_U-Boot | Loading Images with U-Boot]]
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

Booting with a USB Root Filesystem

2019-03-05T18:27:43Z

Mgloff: Created page with "It is possible to boot most EMAC OE systems using a USB thumb drive as the root filesystem and to optionally load a kernel from. This method can be especially useful for updat..."

It is possible to boot most EMAC OE systems using a USB thumb drive as the root filesystem and to optionally load a kernel from. This method can be especially useful for updating or recovering the root filesystem when a network connection or a network file server is not available. This page describes the steps required to boot into a root filesystem residing on a USB thumb drive.

__TOC__

==Prerequisites==

Some prerequisites must be met prior to being able to boot a root filesystem from a USB drive.

===USB Thumb Drive===

Any blank USB drive. If it is not blank, this process will completely wipe the data that exists on the USB drive.

===Root Filesystem===

A complete root filesystem for the EMAC OE system to boot from must be stored on the USB drive.

===Linux Host Computer===

Either a native Linux host or Windows host running a Linux virtual machine.

==Configuring the USB Thumb Drive==

In a terminal window, start the dmesg log with the follow option to watch for new devices.

{{cli | username=developer | hostname=ldc | pwd=~ | dmesg -w }}

Insert the USB drive and watch for the device to be announced.

{{clo}}
[ 2796.940110] scsi host6: usb-storage 1-1.2:1.0 
[ 2797.963442] scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0272 PQ: 0 ANSI: 0 
[ 2797.963905] sd 6:0:0:0: Attached scsi generic sg4 type 0 
[ 2798.269544] sd 6:0:0:0: [sdd] 7774208 512-byte logical blocks: (3.98 GB/3.71 GiB) 
[ 2798.271027] sd 6:0:0:0: [sdd] Write Protect is off 
[ 2798.271030] sd 6:0:0:0: [sdd] Mode Sense: 0b 00 00 08 
[ 2798.272502] sd 6:0:0:0: [sdd] No Caching mode page found 
[ 2798.272508] sd 6:0:0:0: [sdd] Assuming drive cache: write through 
[ 2798.279486] sdd: 
[ 2798.283834] sd 6:0:0:0: [sdd] Attached SCSI removable disk 
{{clos}}

The output of the <code>dmesg</code> command shows that the root device node for the USB drive in this case is <code>sdd</code> and no partitions. Partitions on the drive would be listed as <code>sdd1</code>, <code>sdd2</code>, etc. Inspect the output shown above to see the particular device node on the development PC where the USB drive is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with <code>sd</code>. The third letter will specify which of these devices is assigned to the USB drive. The number will indicate the partitions, if any. Press Ctrl and 'c' to exit dmesg.

* At this point, it is wise to double check that device node is actually the USB drive and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdd</code> as the example device node, type the following command:

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | mount {{!}} grep sdd }}
/dev/sdd on /media/developer/FBF6-1988 type vfat
{{clos}}

This shows that the device node, <code>/dev/sdd</code>, is in fact the USB drive. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | sudo fdisk -l /dev/sdd }}
'Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier 0x00000000 
{{clos}}

The output of fdisk will also show information about any partitions that may exist on the USB drive. For example, a drive with a single FAT32 formatted partition will look like:
{{clo}}
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors 
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier 0xb04870e5 
 
Device Boot Start End Sectors Size Id Type 
/dev/sdd1 * 8760 14438399 14429640 3.7G c W95 FAT32 (LBA) 
{{clos}}

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 3.7 GB in size, which corresponds with the size of the 4 GB USB drive being used in this example.

Unmount all of the USB drives partitions that were listed from the <code>mount</code> command above.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd }}

If there is a partition listed:

{{cli | username=developer | hostname=ldc | pwd=~ | sudo umount /dev/sdd1 }}

==Repartition the USB Drive==

Once the correct drive letter is determined, we will create a new Linux partition.

{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ | sudo fdisk /dev/sdd }}
 
Welcome to fdisk (util-linux 2.31.1). 
Changes will remain in memory only, until you decide to write them. 
Be careful before using the write command. 
 
 
Command (m for help) o 
Created a new DOS disklabel with disk identifier 0xe6077d37. 
 
Command (m for help) n 
Partition type 
: p primary (0 primary, 0 extended, 4 free) 
: e extended (container for logical partitions) 
Select (default p) p 
Partition number (1-4, default 1) 1 
First sector (2048-7774207, default 2048) 
Last sector, +sectors or +size{K,M,G,T,P} (2048-7774207, default 7774207) 
 
Created a new partition 1 of type 'Linux' and of size 3.7 GiB. 
 
Command (m for help) p 
Disk /dev/sdd: 3.7 GiB, 3980394496 bytes, 7774208 sectors 
Units sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical) 512 bytes / 512 bytes 
I/O size (minimum/optimal) 512 bytes / 512 bytes 
Disklabel type dos 
Disk identifier 0xe6077d37 
 
Device Boot Start End Sectors Size Id Type 
/dev/sdd1 2048 7774207 7772160 3.7G 83 Linux 
 
Command (m for help) w 
The partition table has been altered. 
Calling ioctl() to re-read partition table. 
Syncing disks. 
 
{{clos}}

The fdisk commands are:

<code>o</code> - Create a new empty partition table

<code>n</code> - Create a new partition

<code>p</code> - The type of partition is a primary partition

<code>1</code> - Create the first partition

<code><ENTER></code> - Accept default start

<code><ENTER></code> - Accept default end

<code>p</code> - Print the new partition layout

<code>w</code> - Write the new partition layout and exit

==Format the Partition==

The first partition will be formatted with the ext4 filesystem.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo yes {{!}} mkfs.ext4 /dev/sdd1 }}

==Mount the Partition==

The first partition of the USB drive will be mounted so that it is accessible to write to.

{{cli | username=developer | hostname=ldc | pwd=~ | sudo mkdir -p /media/card }}
{{cli | username=developer | hostname=ldc | pwd=~ | sudo mount /dev/sdd1 /media/card }}

The USB drive is now accessible through the <code>/media/card</code> directory.

==Extract Filesystem Archive==

Locate where the filesystem archive has been downloaded. If the archive is called rootfs.tar.gz and is in the users Downloads directory:

{{cli | username=developer | hostname=ldc | pwd=~ | cd /media/card }}
{{cli | username=developer | hostname=ldc | pwd=/media/card | sudo tar zxf ~/Downloads/rootfs.tar.gz }}

==Configuring the Client to Boot from USB==

===Configuring U-Boot===

Set the bootargs variable to tell the kernel to boot into the USB filesystem:

U-Boot> setenv bootargs console=${console} root=/dev/sda1 rootfstype=ext4
U-Boot> run bootargs

This line sets up the environment needed to boot from the USB drive. These options will be passed to the Linux kernel when booting it. The <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>. The <code>root=/dev/sda1</code> directive tells Linux to instantiate with the USB block device, <code>/dev/sda1</code>, as the root filesystem. The <code>rootfstype=ext4</code> directive tells Linux that the root filesystem is of the EXT4 variety.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the USB root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

===Alternate Kernel Load===

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. Also see [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM | Executing kernel from RAM ]]

U-Boot> usb start

Booting with an NFS Root Filesystem

2019-03-04T23:24:38Z

Mgloff:

{{#seo:
|title=Booting with an NFS Root Filesystem
|titlemode=append
|keywords=TFTP Server,NFS Server,U-Boot,Root File System
|description=This page describes the steps required to boot over NFS.
}}
It is possible to boot most EMAC OE systems using NFS (Network File System) as the root filesystem. This method can be especially useful during development where the root filesystem is changing frequently. This can save time as well as wear on the on-board flash device. This page describes the steps required to boot over NFS.

__TOC__

==Prerequisites==

Some prerequisites must be met prior to being able to boot a root filesystem over NFS.

===TFTP Server===

A TFTP server is required if a kernel image is not already programmed in flash. For information on installing a TFTP server, see [[Installing TFTP server]].

===NFS Server===

To boot an EMAC OE system over NFS, an NFS server must be available on the local network. This is often the same machine that is being used for software development. EMAC recommends using the <code>nfs-kernel-server</code> package available on most desktop Linux distributions if setting up a new NFS server. Once the server has been installed, export a directory to use as the root filesystem. This is often done using the <code>/etc/exports</code> file. This document assumes that the root filesystem for the board will be located at <code>/srv/nfs/rootfs</code> on the NFS server.

For more information on setting up an NFS server, see [[Setting up an NFS File Server]].

===Root Filesystem===

A complete root filesystem for the EMAC OE system to boot from must be stored on the NFS server. The NFS server must be configured to allow clients to access this filesystem. The root filesystem does not have to be the directory shared by the NFS filesystem; it can be in a subdirectory, which means many root filesystems can be shared by one NFS server.

==Configuring the Client to Boot from NFS==

===Configuring U-Boot===

Set the bootargs variable to tell the kernel to boot into the NFS filesystem:

U-Boot> setenv bootargs console=${console} root=/dev/nfs rootfstype=nfs ip=dhcp nfsroot=10.0.0.20:/srv/nfs/test_fileystem
U-Boot> run bootargs

This line sets up the environment needed to boot from the NFS server. These options will be passed to the Linux kernel when booting it. The <code>console=${console}</code> part tells Linux to use the console setting from the U-Boot environment variable; this will usually be something along the lines of <code>console=ttyS0,115200n8</code>. The <code>root=/dev/nfs</code> directive tells Linux to instantiate with the virtual device, <code>/dev/nfs</code>, as the root filesystem. The <code>rootfstype=nfs</code> directive tells Linux that the root filesystem is of the NFS variety. The <code>ip=dhcp</code> directive tells Linux to acquire an IP address by requesting one from the DHCP server. The <code>nfsroot=10.0.0.20:/srv/nfs/test_filesystem</code> directive tells Linux to look for an NFS server at <code>10.0.0.20</code> and to mount the <code>/srv/nfs/test_filesystem</code> directory as the root filesystem for the machine.

If the kernel is already programmed into the flash, it can be used in most cases to boot into the NFS root filesystem. Execute the next line to load and run the default kernel.

U-Boot> boot

The machine should now boot, and show output on its console as it does so.

===Alternate Kernel Load===

An alternate kernel can be loaded into memory temporarily and booted if the kernel is not already programmed in the flash or a development kernel is to be tested. Also see [[ Loading_Images_with_U-Boot#Executing_kernel_from_RAM | Executing kernel from RAM ]]

U-Boot> set autoload no
U-Boot> dhcp
DHCP client bound to address 10.0.0.100

Here, the first command, <code>set autoload no</code>, tells U-Boot not to try to load an image after they've gotten an IP address from the DHCP server. The second command, <code>dhcp</code>, tells U-Boot to use DHCP to acquire an IP address. In this example, the DHCP server assigned <code>10.0.0.100</code> as the IP address for the machine.

U-Boot> set serverip 10.0.0.20

This line sets the IP address of the TFTP server to <code>10.0.0.20</code>. This is the server which hosts the Linux kernel which will be used by the machine.

U-Boot> tftp ${loadaddr} zImage
...
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#####################

This line tells U-Boot to load the kernel from the TFTP server, whose IP address was set earlier with the <code>set serverip 10.0.0.20</code> command. The filename U-Boot requests from the TFTP server is <code>zImage</code>, and it stores it in the memory location pointed to by <code>loadaddr</code>. The text which follows displays U-Boot's progress in loading the kernel into RAM. When the U-Boot prompt returns, the environment is fully setup and ready to boot from an NFS root filesystem.

U-Boot> bootz ${loadaddr}

The <code>bootz</code> command tells U-Boot to boot the kernel from RAM. This means it boots the kernel which was just loaded into RAM, passing the commandline arguments specified by <code>bootargs</code> to the Linux kernel as it does so.

The machine should now boot, and show output on its console as it does so.

==Conclusion==

Using NFS for the root filesystem allows boards to boot quickly into test versions of a filesystem, provides a tool for remotely backing up the filesystem installed on an embedded machine, can provide a central filesystem image for many boards which can allow updating one filesystem to update all boards which use it simultaneously, and more. Setting up a machine to boot to a root filesystem via NFS requires little work; most of the work is in setting up the server.

Serial Connections

2019-02-13T21:27:41Z

Mgloff:

{{todo|SEOKWREV (11.25.13-13:05->KY+);(11.25.13-18:45->MD+);(11.26.13-21:40->MD+);(12.20.13-11:12->MW+);(03.04.14-15:20->BS-);(03.14.14-15:55->BS+)(03.14.14-15:55->BS+)(10.26.15-18:25->MG+)|Klint Youngmeyer|project=oe 4,oe 5,ky,SEOKWREV,md,mw,bs}}

{{#seo:
|title=Serial Connections
|titlemode=append
|keywords=Serial Connections,Serial Terminal,PuTTY,Serial Communication Parameters
|description=Serial Connections to EMAC boards.
}}


There are several ways to connect to a system running EMAC OE Linux. The preferred connection method depends on the capabilities of the hardware. For example, headless systems (those without a graphical interface) will most likely use a serial port console, while systems with a video connection may be accessed using a keyboard and LCD or monitor. When an LCD or monitor is available, a serial connection can occasionally still be needed; usually, this need arises after a user has accidentally misconfigured the display. Other times, it may be useful to be able to use a serial console on a board that's running remotely but has had its network connection drop out. The serial console can be a very useful tool for diagnosing and debugging issues even after development has finished.

== Serial Terminal ==
A serial terminal connection is most commonly the first connection that will be made to a system in its default configuration. A serial terminal application such as [[Getting_Started_With_Minicom | Minicom]] for Linux or [[PuTTY]] under Windows is required for this connection. The serial cable type, port, and communication parameters for each system type are listed in Table 1 below.

 
<div align=center>
{| class="wikitable" style="text-align: center;" |Table 1: Serial Communication Parameters
|-
! SoM !! Port !! Cable Type !! Baud Rate !! Data Bits !! Parity !! Stop Bits !! Flow Control
|-
| [[ ARM_SOM | 200 Pin SoM's ]] || COMB || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ ARM_SOM | 144 Pin SoM's ]] || COME || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ SOM-9260 ]] || COMA || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ SOM-9G20 ]] || COMA || NULL Modem || 115200 || 8 || None || 1 || None
|-
| [[ iPac-9x25 ]] || COM1 || NULL Modem || 115200 || 8 || None || 1 || None
|-
| x86 Boards || COM1* || NULL Modem* || 115200 || 8 || None || 1 || None
|}
</div>

{{note | '''*''' : These settings vary among x86 systems. Refer to the system manual for the target board for more information. Not all x86 systems have a serial terminal connection enabled by default.}} 

Follow the steps below to establish a serial connection:
# Connect a NULL Modem serial cable between the serial port on the workstation and target board and start a terminal application.
# Setup the communication parameters for your board according to Table 1.
# Connect power to the target board; boot messages will begin to print within a few seconds.
# When the board has finished booting a login prompt will appear.

== Next Steps ==
After you have established a connection with your device running EMAC OE Linux, you will need to [[System_Log_In | log into the system.]]

Getting Started with the EMAC OE SDK

2019-02-11T20:47:31Z

Mgloff:

{{todo| Complete (03.31.2015-13:42->BS+);(04.08.2015-15:00->BS+);(04.09.15-14:00->MD+);(04.21.2015-10:15->BS+);(04.24.2015-20:00->MD-);(04.28.2015-12:20->MD+);(04.29.2015-16:00->BS+);(04.29.2015-17:30->MD+);(04.30.2015-15:30->KY+); (07.22.2015-11:00->BS+)(10.07.2015-16:32->KY+)|Brian Serrano| project=OE 5.0,BS,MD,Complete,KY}}
{{#seo:
|title=Getting Started with the EMAC OE SDK
|titlemode=append
|keywords=EMAC SDK,Cross compiling, ARM Target Compiling, CMake Build System, CMake Cross Compiling, CMake, CMake Arm
|description=A basic tutorial for using the EMAC OE SDK.
}}






The EMAC OE SDK is distributed with a set of example projects intended to demonstrate how to use the EMAC OE toolchain and libraries. This page demonstrates the process of compiling an example project and running it on the target machine. Also, it provides a straightforward guide to the essential steps you need to follow to get started with cross compiling a simple program with gcc and running the program on your embedded machine.

__TOC__




{{:Templateimpl:using | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}

=== Video Series ===
<youtube>https://www.youtube.com/watch?v=v4ajuBPMiO4&list=PLZVpLvdEOZHYPwvOVAYCPS6Sw6I3sQA9w</youtube>

=== Installing EMAC SDK ===

[[Installing_EMAC_OE_5.0_SDK | SDK Install]]

=== Connecting to a Target Board ===

Primarily a board is connected to through it's debug serial port. If it also connected to a network and the IP address is known, ssh can be used to connect as well. More information on establishing a physical connection to a board is available on the [[Serial_Connections |Serial Connections]] and [[Network_Connections |Network Connections]] page.

The next step after establishing a physical connection to the board is logging in. For more information visit the [[System_Log_In | System Log In]] page.

=== Setting the Filesystem to Read-Write ===
The root filesystem on a machine running EMAC OE Linux is mounted read-only by default. In order to put files on the board, you may need to make the filesystem read-write. The [[Linux_Filesystem_Organization|Linux Filesystem Organization page]] has more information regarding which parts of the filesystem are mounted read-only by default versus which parts are always writeable. Note that EMAC recommends installing your program into a read-only portion of the filesystem (according to the guide) to safeguard it from filesystem corruption (such as may be caused by removing power from the board without shutting down the operating system first, which is normal in embedded systems).

To remount the root filesytem in read-write mode, enter the following into the terminal:
{{cli | oemntrw | hostname=ipac9x25}}

{{note|This will only change the root filesystem to read-write for the current boot. When the system is rebooted, the root filesystem will once again be mounted read-only.}}

=== Transferring Files ===
The command line syntax for transferring a file using the SSH protocol is <code>scp file user@host:/directory</code>. SCP, or Secure Copy, is a way of securely transferring files between a local and remote host. For example, to send the file ''example.text'' to the <code>/usr/bin</code> directory of a system with the IP address 10.0.6.221, enter the following command:
{{cli | username=developer | hostname=ldc | scp example.text root@10.0.6.221:/usr/bin/ }}

Alternatively, you can leave off the path after the colon if you want the file to go directly into the root user's home directory.

{{cli | username=developer | hostname=ldc | scp example.text root@10.0.6.221: }}

=== Remote Execution ===
SSH can also be used to execute programs on remote systems without logging in. The syntax for SSH remote execution is <code>ssh user@host "my_command -args file"</code>. The following is an example of a command to run a program on a board with the IP address ''10.0.6.221''.

{{cli | username=developer | hostname=ldc | ssh root@10.0.6.221 "/path/to/executable -args" }}

=== Basic Compiling ===
The two subsections below show the two common options for how to compile source code. The first subsection demonstrates how to use the EMAC [[ #CMake_Compiling| CMake ]] tool, while the second subsection demonstrates how to compile c code [[ #Manual_Compiling | manually ]].

==== CMake Compiling ====
===== Host Machine Compiling =====

This section demonstrates how to use the EMAC CMake tool to generate CMake files automatically for a project. When using the EMAC SDK there are currently two options for cross compiling:
* arm
* x86
For the purposes of this guide, the <tt>arm</tt> option will be used for the listed examples.

Navigate to the directory where the project will be located. Then run the CMake new project script.
{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ |cd projects }}
{{clio | username=developer | hostname=ldc | pwd=~/projects | 1 = export PATH=/opt/emac/5.1/bin:$PATH}}
{{clio | username=developer | hostname=ldc | pwd=~/projects |oe_init_project -n hello.c }}
If desired, please enter a name for this project, otherwise press Enter to use the default: hello_emac 

-- Creating new project directory... 
-- Creating new source file... 
-- Building custom CMakeLists.txt file... 
-- Done. 

Do you want to create a build directory for this project? (y/n) y 

-- Creating build directory... 

Do you want to run cmake for this project? (y/n) y 

-- Using system compiler 
-- The C compiler identification is GNU 4.8.2 
-- The CXX compiler identification is GNU 4.8.2 
-- Check for working C compiler: /usr/bin/cc 
-- Check for working C compiler: /usr/bin/cc -- works 
-- Detecting C compiler ABI info 
-- Detecting C compiler ABI info - done 
-- Check for working CXX compiler: /usr/bin/c++ 
-- Check for working CXX compiler: /usr/bin/c++ -- works 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done 
-- Configuring done 
-- Generating done 
-- Build files have been written to: /home/developer/projects/hello_emac/hello_emac-build 

Do you want to compile this project? (y/n) y

Scanning dependencies of target hello_emac 
[100%] Building C object CMakeFiles/hello_emac.dir/hello.c.o 
Linking C executable hello_emac 
[100%] Built target hello_emac 
{{clos}}

The executable, in this case, is now inside the <code> hello_emac/hello_emac-build </code> directory.

===== Target Machine Compiling =====

The CMake project script has now made a project directory that contains the following:
* CMakeLists.txt
* Source code file (''hello.c'' in this case)
* ''README'' file
* Desktop Build Directory (''hello_emac-build'' in this case)

The ''CMakeLists.txt'' contains the required information to automatically create a ''Makefile'' for a given architecture. This was created by the EMAC <tt>oe_init_project</tt> script, and will need to be modified over time as a project grows. The comments in the file generated by the EMAC tool will provide a good starting point for how to add additional source files and how to perform other common tasks related to maintaining your CMake build system as your project grows. The CMake project provides extensive documentation on how to work with these files.

The source code file generated by the script (''hello.c'') contains a basic Hello World style program.

The ''README'' file contains more information on using ''CMake'' with the EMAC 5.X SDK.

The Desktop Build Directory (''hello_emac-build'') contains the executable ''hello_emac'', the ''Makefile'', and various cache files. These were automatically created by CMake and by the build system, and can be recreated at any time.

It is useful to have a Desktop Build Directory because it is easier (in the beginning) to use the desktop to verify all code changes before cross-compiling for a target board. This will be useful until the application under development depends upon resources which are only available on the target hardware, such as certain devices drivers or the touchscreen (if so equipped).

Use the following steps to cross-compile the project and send it to a target board.
 
 
<cl>
1. In a terminal, navigate to the base directory of the project.
{{note | If the target board being used is <tt>x86</tt>, then change all occurrences of <tt>arm</tt> in the following sections below to <tt>x86</tt>.}}
* Create a build directory for cross compiling.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm }}
* Change directories into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm }}
* Run cmake using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm }}
* Compile the code using make.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}

The <code> make </code> command creates the target executable in the <code> hello_emac-build-arm </code> directory.
* Now copy the executable to the target board. For information on copying the executable file, see the [[ #Transferring_Files | Transferring Files ]] section.
</cl>
 
 

==== Manual Compiling ====
===== Host Machine Compiling =====
 {{note|In these examples we are using the Ipac-9x25 board. Your board's processor's architecture will determine which file needs to be sourced. These files come from the EMAC SDK toolchain.}}

Create a file called hello.c using a text editor such as vi, nano, or gedit. Then copy and paste the source code from the [[ #Hello_World_System_Log_Example | Hello World System Log Example ]] section in the text editor of your choice.

Once you've created and saved the file with the source code, use the following syntax to compile the program called hello.c:
{{cli | username=developer | hostname=ldc | gcc -o hello hello.c }}

If there is no error in your code then the compiler will successfully create an executable file called hello in the current directory.

To verify this, enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | ls -l hello* }}
-rwxrwxr-x 1 bserrano bserrano 9583 Apr 6 12:45 hello 
-rwxr-xr-x 1 bserrano bserrano 129 Apr 6 12:28 hello.c
{{clos}}

To run the program, enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | ./hello }}
Hello EMAC OE!
{{clos}}

OR
{{clo}}
{{clio | username=developer | hostname=ldc | /path/to/hello }}
Hello EMAC OE!
{{clos}}
 
 

===== Target Board Compiling =====

To compile for the target board, you must <code>source</code> the <code>environment-setup-armv5e-emac-linux-gnueabi</code> file.
{{cli | username=developer | hostname=ldc | source /opt/emac/5.X/environment-setup-armv5e-emac-linux-gnueabi }}

Once you are in the directory with the source file, enter the following command:
{{cli | username=developer | hostname=ldc | $CC -o hello hello.c }}

{{note|Once you source the file in your current terminal, you can only use it to cross-compile your program for the target board. You can no longer compile it for your host machine. To compile it to your host machine, simply open a new terminal.}}

After sourcing the file, copy the program over to the target board using <code>scp</code>. Enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | scp hello root@10.0.6.221: }}
root@10.0.6.221's password:

hello 100% 9583 9.4KB/s 00:00
{{clos}}

After copying the program, you can now execute the program on the target board. Enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | ssh root@10.0.6.221 ./hello}}
root@10.0.6.221's password: 
Hello EMAC OE!
{{clos}}
 
 

=== Remote Debugging ===

When working with embedded systems the binary is usually compiled on a development machine with a different CPU architecture than what is on the target machine. This can be a problem when, as is typically the case, the target machine lacks the system resources to run a debugger. In these cases, it is possible to use the GNU debugger (<tt>gdb</tt>) on the development machine to remotely debug the target machine provided it has a flavor-matched version of a program named <tt>gdbserver</tt>. All EMAC OE builds are packaged with a flavor-matched <tt>gdbserver</tt> to simplify the setup process for developers.

{{note | A flavor-matched <tt>gdbserver</tt> is one which is built against the same source code revision as the <tt>gdb</tt> client for your desktop, because <tt>gdb</tt> does not have a stable interface for attaching to the <tt>gdbserver</tt>. In fact, the interface changes slightly with almost every release, so if you find yourself having difficulty getting <tt>gdb</tt> and <tt>gdbserver</tt> to communicate with each other, make sure they're the exact same version before trying any other debugging steps.}}

For more information visit the [[Remote_Debugging_EMAC_OE_SDK_Projects_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver]] page.




{{:Templateimpl:examples | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}

=== Hello World System Log Example ===
This example will print <code>Hello EMAC OE!</code> to the syslog facility as well as the console. This will allow you to log, debug, and send status messages to the system logger.

To compile and run this program, see the sections above.

<syntaxhighlight lang="c">
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <syslog.h>

int main(int argc, char** argv)
{
char message[] = "Hello EMAC OE!";

openlog("slog", LOG_PID|LOG_CONS, LOG_USER);
syslog(LOG_INFO, "%s", message);
closelog();

printf("%s\n", message);

return 0;
}
</syntaxhighlight>

This is extremely useful because it allows you to save a record of the output that you might not see first hand.

To verify the output of the program went into syslog, enter the following command:
{{clo}}
{{clio | username=developer | hostname=ldc | tail /var/log/syslog}}
Apr 7 14:10:06 ENG-26-LX dhclient: DHCPACK of 10.0.6.237 from 10.0.2.1 
Apr 7 14:10:06 ENG-26-LX dhclient: bound to 10.0.6.237 -- renewal in 3306 seconds. 
Apr 7 14:17:01 ENG-26-LX CRON[21193]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 
Apr 7 14:54:41 ENG-26-LX hpcups[21266]: prnt/hpcups/HPCupsFilter.cpp 689: First raster data plane.. 
Apr 7 14:55:31 hpcups[21266]: last message repeated 3 times 
Apr 7 15:05:12 ENG-26-LX dhclient: DHCPREQUEST of 10.0.6.237 on eth0 to 10.0.2.1 port 67 
Apr 7 15:05:12 ENG-26-LX dhclient: DHCPACK of 10.0.6.237 from 10.0.2.1 
Apr 7 15:05:12 ENG-26-LX dhclient: bound to 10.0.6.237 -- renewal in 3559 seconds. 
Apr 7 15:17:01 ENG-26-LX CRON[21302]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) 
Apr 7 15:27:08 ENG-26-LX slog[21375]: Hello EMAC OE!
{{clos}}

As you can see on the bottom line, your program output has been recorded and date stamped in syslog.

For more information on system logging visit the [[System_Logging| System Logging ]] page.




{{:Templateimpl:moreinfo | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}
* [[Getting_Started_With_Qt_Creator |Getting Started With Qt Creator]]

{{:Templateimpl:whatnext | initials=BS | title=Getting Started with the EMAC OE SDK | desc=Basic tutorial for using the EMAC OE SDK. | project=OE 5.0 }}
* [[Getting_Started_With_Qt_Creator |Getting Started With Qt Creator]]
* [[System_Log_In | System Log In]]
* [[Serial_Connections | Serial Connections ]]
* [[Network_Connections | Network_Connections ]]
* [[System_Log_In | System Log In ]]
* [[Remote_Debugging_EMAC_OE_SDK_Projects_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver ]]
* [[Linux_Filesystem_Organization | Linux Filesystem Organization]]
* [[Creating_a_New_EMAC_OE_SDK_Project_with_CMake | Creating a Project with CMake ]]
* [[Remote_Debugging_EMAC_OE_SDK_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver]]
* [[System_Logging | System Logging ]]

Creating a New EMAC OE SDK Project with CMake

2019-02-11T20:46:11Z

Mgloff:

{{todo| Complete (08.07.2015-12:59->KY+)(08.17.2015-12:07->KY+)(08.17.2015-14:25->KY+)(08.17.2015-17:40->MD-)(11.03.2015-13:38->KY+);(11.04.2015-11:20->MD-)(11.04.2015-13:04->KY+-);(11.04.2015-13:25->MD+)(11.04.2015-14:45->MG+)|Klint Youngmeyer| project=OE 5.0,KY,MD,Complete }}
{{#seo:
|title=Creating a New EMAC OE SDK Project with CMake
|titlemode=append
|keywords=CMakeLists.txt, CMake cross-compiling, CMake, CMake ARM, oe_init_project
|description=Creating an EMAC OE SDK project which uses the CMake build system.
}}




The EMAC OE SDK is distributed with the intent that CMake be used with the EMAC OE toolchain and libraries to build most projects. This page demonstrates the process of creating and compiling a new project with CMake, and running it on the target machine.

__TOC__




{{:Templateimpl:geninfo | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK Project which Builds via CMake | project=OE 5.0 }}
Creating a new EMAC CMake project is accomplished with the use of the <code>oe_init_project</code> program. This program is included in the [ftp://oe50opkg:opkgoe50123@ftp.emacinc.com/5.1/x86_64-nativesdk/nativesdk-emac-tools_git-r0_x86_64-nativesdk.ipk emac-tools] opkg package, which is part of the ADT EMAC SDK. For instructions on installing the EMAC SDK, please see [[Installing_EMAC_OE_5.0_SDK | SDK Install]].



{{:Templateimpl:using | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project which Builds with CMake | project=OE 5.0 }}

This section demonstrates how to use the EMAC CMake tool, <code>oe_init_project</code>, to generate CMake files automatically for a project. When using the EMAC SDK there are currently two options for cross compiling:
* <code>arm</code>
* <code>x86</code>
For the purposes of this guide, the <code>arm</code> option will be used for the listed examples.
=== Host Machine Compiling ===
Navigate to the directory where the project will be located. Then run the CMake new project tool, <code>/opt/emac/5.x/bin/oe_init_project</code>.
{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~ |cd projects }}
{{clio | username=developer | hostname=ldc | pwd=~/projects | 1 = export PATH=/opt/emac/5.1/bin:$PATH}}
{{clio | username=developer | hostname=ldc | pwd=~/projects |oe_init_project -n hello.c }}
If desired, please enter a name for this project, otherwise press Enter to use the default: hello_emac 

-- Creating new project directory... 
-- Creating new source file... 
-- Building custom CMakeLists.txt file... 
-- Done. 

Do you want to create a build directory for this project? (y/n) y 

-- Creating build directory... 

Do you want to run cmake for this project? (y/n) y 

-- Using system compiler 
-- The C compiler identification is GNU 4.8.2 
-- The CXX compiler identification is GNU 4.8.2 
-- Check for working C compiler: /usr/bin/cc 
-- Check for working C compiler: /usr/bin/cc -- works 
-- Detecting C compiler ABI info 
-- Detecting C compiler ABI info - done 
-- Check for working CXX compiler: /usr/bin/c++ 
-- Check for working CXX compiler: /usr/bin/c++ -- works 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done 
-- Configuring done 
-- Generating done 
-- Build files have been written to: /home/developer/projects/hello_emac/hello_emac-build 

Do you want to compile this project? (y/n) y

Scanning dependencies of target hello_emac 
[100%] Building C object CMakeFiles/hello_emac.dir/hello.c.o 
Linking C executable hello_emac 
[100%] Built target hello_emac 
{{clos}}

The executable, in this case, is now inside the <code> hello_emac/hello_emac-build </code> directory and can be executed by the host machine (X86_64).

The CMake project script has now made a project directory that contains the following:
* <code>CMakeLists.txt</code>
* Source code file (<code>hello.c</code> in this case)
* <code>README</code> file
* Desktop Build Directory (<code>hello_emac-build</code> in this case)

The <code>CMakeLists.txt</code> is a script which contains the required information to automatically create a <code>Makefile</code> for any supported architecture. This file was generated by the EMAC <code>oe_init_project</code> tool, and will need to be modified over time as a project grows. The comments in the <code>CMakeLists.txt</code> file generated by the EMAC tool will provide a good starting point for how to add additional source files and how to perform other common tasks related to maintaining your CMake build system as you develop your software project. The [http://cmake.org CMake] project provides extensive documentation on how to work with these files.

The source code file generated by the script (<code>hello.c</code>) contains a basic Hello World style program. This can provide a starting point for your application, or can be replaced by another source file with the same name.

The <code>README</code> file contains more information on using <code>CMake</code> with the EMAC OE 5.X SDK. You may refer to this file for quick reference.

The Desktop Build Directory (<code>hello_emac-build</code>) contains the executable, <code>hello_emac</code>, the <code>Makefile</code>, and various cache files. These were automatically created by CMake and by the build system, and can be recreated at any time.

It is useful to have a Desktop Build Directory because it is easier (in the beginning) to use the desktop to verify all code changes before cross-compiling for a target board. This will be useful until the application under development depends upon resources which are only available on the target hardware, such as certain device drivers or the touchscreen (if so equipped).

=== Target Machine Compiling ===

Use the following steps to cross-compile the project and send it to a target board.
 
<cl>
1. In a terminal, navigate to the base directory of the project. {{note | If the architecture of the target board you're using for your appliction <code>x86</code>, then you will need to change all occurrences of <code>arm</code> in the following sections below to <code>x86</code>.}}
* Create a build directory for cross compiling.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm }}
* Navigate into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm }}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm }}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
The <code> make </code> command creates the target executable in the <code>hello_emac-build-arm</code> directory.
* Now copy the executable to the target board. For information on copying the executable file, see the [[ #Transferring_Files | Transferring Files ]] section.
</cl>




{{:Templateimpl:examples | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project for use with CMake | project=OE 5.0 }}
This section illustrates how to complete various tasks associated with configuring and building a CMake project.
===Debug Build Types===
By default, new projects will have the Debug build type. To compile the project with the Release or Minimum Size Release build types, there are two options:
*Make a secondary (or tertiary) build directory. (Recommended)
*Clean the current build directory and re-run CMake.
The different levels of build type correlate to usage of different C Flags. When cross-compiling, these C Flags are located in the <code>toolchain.<architecture>.cmake</code> files located, by default, in <code>/opt/emac/5.X/</code>, with ''X'' being the specific version of SDK. The following table will give a brief overview of the different build types.

 
 
<table style="border-style:double; border-width:2px; margin-top:-10%; margin-bottom:-3%;"><tr style="border-style:double; border-width:2px;"><td>'''Name:'''</td><td>'''Type:'''</td><td>'''Debugging Features:'''</td><td>'''Description:'''</td><td>'''Optimization Level:'''</td><td>'''C Flags Used:'''</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>Release</td><td>Release</td><td>disabled</td><td>Release targeted build optimized for best performance.</td><td>-O2</td><td>CMAKE_C_FLAGS_RELEASE</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>MinSizeRel</td><td>Release</td><td>disabled</td><td>Release targeted build with experimental optimizations. (Builds using this should be thoroughly tested.)</td><td>-O3</td><td>CMAKE_C_FLAGS_MINSIZEREL</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>Debug</td><td>Debug</td><td>enabled</td><td>A standard debugging oriented build, optimized for improved debugging.</td><td>-O0</td><td>CMAKE_C_FLAGS_DEBUG</td></tr>

</table>
 
 
 
If you wish to add any additional flags to a build type, they can be defined in the project's <code>CMakeList.txt</code> file as shown in the code snippet below.
<syntaxhighlight lang="cmake">
project(example)

SET(MAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -Wall -Wpedantic")

# This will add the -Wall and -Wpedantic options to the existing debug build flags
</syntaxhighlight>


====Method 1: Create separate build directory====
To create a Release build using the 1st (recommended) method, use the following steps. This method is recommended because it allows both the Debug and the Release executable to exist at the same time.
<cl>
1. In a terminal, navigate to the base directory of the project.
* Create a new release build directory
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm-release }}
* Change directories into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm-release }}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm -DCMAKE_BUILD_TYPE:STRING=Release }}{{note | The string 'MinSizeRel' can be used in place of 'Release' for a potentially smaller executable}}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
</cl>
 
====Method 2: Re-use build directory====
Another option for creating a release build is as follows:
<cl>
1. In a terminal, navigate to the build directory of the project.
* Clean the directory with <code>make</code>
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = make clean}}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm -DCMAKE_BUILD_TYPE:STRING=Release }}{{note | The string 'MinSizeRel' can be used in place of 'Release' for a potentially smaller executable}}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
</cl>

===Renaming the Target Executable===
To rename the executable, the <code>ADD_EXECUTABLE()</code> function arguments must be changed. The first argument refers to the name of the executable, and the second refers to the source code file.

To change the name of the executable from "main" to "new_name", change the <code>ADD_EXECUTABLE()</code> from the first code box to the second code box.
<syntaxhighlight lang="cmake">
ADD_EXECUTABLE(main main.cpp)
</syntaxhighlight>

<syntaxhighlight lang="cmake">
ADD_EXECUTABLE(new_name main.cpp)
</syntaxhighlight>

===Adding Include Files===
To add an include file and implementation file (in this case, the <code>tools.cpp</code> and <code>tools.h</code> in the <code>util</code> and <code>include</code> directory, respectively) to the CMake project, changes will need to be made to the CMakeLists.txt file. Please refer to the code sample below.

# The directory to be included must be specified by the <code>INCLUDE_DIRECTORIES()</code> function. The variable <code>${PROJECT_SOURCE_DIR}</code> refers to the base path of the project which is generally where this <code>README</code> file is located.
# The <code>SOURCES</code> must be set. This list of files should include all of the source files in the project.

<syntaxhighlight lang="cmake">
INCLUDE_DIRECTORIES(${PROJECT_SOURCE_DIR}include)

SET(SOURCES
${PROJECT_SOURCE_DIR}main.cpp
${PROJECT_SOURCE_DIR}util/tools.cpp
)
SET(HEADERS
${PROJECT_SOURCE_DIR}include/tools.h
)

ADD_EXECUTABLE(main ${SOURCES} ${HEADERS})
</syntaxhighlight>




{{:Templateimpl:moreinfo | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project for use with CMake | project=OE 5.0 }}

* [[System_Log_In | System Log In]]
* [[Serial_Connections | Serial Connections ]]
* [[Network_Connections | Network Connections ]]
* [[System_Log_In | System Log In ]]
* [[Remote_Debugging_EMAC_OE_SDK_Projects_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver ]]
* [[System_Logging | System Logging ]]

Creating a New EMAC OE SDK Project with CMake

2018-08-09T23:15:20Z

Mgloff:

{{todo| Complete (08.07.2015-12:59->KY+)(08.17.2015-12:07->KY+)(08.17.2015-14:25->KY+)(08.17.2015-17:40->MD-)(11.03.2015-13:38->KY+);(11.04.2015-11:20->MD-)(11.04.2015-13:04->KY+-);(11.04.2015-13:25->MD+)(11.04.2015-14:45->MG+)|Klint Youngmeyer| project=OE 5.0,KY,MD,Complete }}
{{#seo:
|title=Creating a New EMAC OE SDK Project with CMake
|titlemode=append
|keywords=CMakeLists.txt, CMake cross-compiling, CMake, CMake ARM, oe_init_project
|description=Creating an EMAC OE SDK project which uses the CMake build system.
}}




The EMAC OE SDK is distributed with the intent that CMake be used with the EMAC OE toolchain and libraries to build most projects. This page demonstrates the process of creating and compiling a new project with CMake, and running it on the target machine.

__TOC__




{{:Templateimpl:geninfo | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK Project which Builds via CMake | project=OE 5.0 }}
Creating a new EMAC CMake project is accomplished with the use of the <code>oe_init_project</code> program. This program is included in the [ftp://oe50opkg:opkgoe50123@ftp.emacinc.com/5.1/x86_64-nativesdk/nativesdk-emac-tools_git-r0_x86_64-nativesdk.ipk emac-tools] opkg package, which is part of the ADT EMAC SDK. For instructions on installing the EMAC SDK, please see [[Installing_EMAC_OE_5.0_SDK | SDK Install]].



{{:Templateimpl:using | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project which Builds with CMake | project=OE 5.0 }}

This section demonstrates how to use the EMAC CMake tool, <code>oe_init_project</code>, to generate CMake files automatically for a project. When using the EMAC SDK there are currently two options for cross compiling:
* <code>arm</code>
* <code>x86</code>
For the purposes of this guide, the <code>arm</code> option will be used for the listed examples.
=== Host Machine Compiling ===
Navigate to the directory where the project will be located. Then run the CMake new project tool, <code>/opt/emac/5.x/bin/oe_init_project</code>.
{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~/projects | /opt/emac/5.x/bin/oe_init_project -n hello.c }}
If desired, please enter a name for this project, otherwise press Enter to use the default: hello_emac 

-- Creating new project directory... 
-- Creating new source file... 
-- Building custom CMakeLists.txt file... 
-- Done. 

Do you want to create a build directory for this project? (y/n) y 

-- Creating build directory... 

Do you want to run cmake for this project? (y/n) y 

-- Using system compiler 
-- The C compiler identification is GNU 4.8.2 
-- The CXX compiler identification is GNU 4.8.2 
-- Check for working C compiler: /usr/bin/cc 
-- Check for working C compiler: /usr/bin/cc -- works 
-- Detecting C compiler ABI info 
-- Detecting C compiler ABI info - done 
-- Check for working CXX compiler: /usr/bin/c++ 
-- Check for working CXX compiler: /usr/bin/c++ -- works 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done 
-- Configuring done 
-- Generating done 
-- Build files have been written to: /home/developer/projects/hello_emac/hello_emac-build 

Do you want to compile this project? (y/n) y

Scanning dependencies of target hello_emac 
[100%] Building C object CMakeFiles/hello_emac.dir/hello.c.o 
Linking C executable hello_emac 
[100%] Built target hello_emac 
{{clos}}

The executable, in this case, is now inside the <code> hello_emac/hello_emac-build </code> directory and can be executed by the host machine (X86_64).

The CMake project script has now made a project directory that contains the following:
* <code>CMakeLists.txt</code>
* Source code file (<code>hello.c</code> in this case)
* <code>README</code> file
* Desktop Build Directory (<code>hello_emac-build</code> in this case)

The <code>CMakeLists.txt</code> is a script which contains the required information to automatically create a <code>Makefile</code> for any supported architecture. This file was generated by the EMAC <code>oe_init_project</code> tool, and will need to be modified over time as a project grows. The comments in the <code>CMakeLists.txt</code> file generated by the EMAC tool will provide a good starting point for how to add additional source files and how to perform other common tasks related to maintaining your CMake build system as you develop your software project. The [http://cmake.org CMake] project provides extensive documentation on how to work with these files.

The source code file generated by the script (<code>hello.c</code>) contains a basic Hello World style program. This can provide a starting point for your application, or can be replaced by another source file with the same name.

The <code>README</code> file contains more information on using <code>CMake</code> with the EMAC OE 5.X SDK. You may refer to this file for quick reference.

The Desktop Build Directory (<code>hello_emac-build</code>) contains the executable, <code>hello_emac</code>, the <code>Makefile</code>, and various cache files. These were automatically created by CMake and by the build system, and can be recreated at any time.

It is useful to have a Desktop Build Directory because it is easier (in the beginning) to use the desktop to verify all code changes before cross-compiling for a target board. This will be useful until the application under development depends upon resources which are only available on the target hardware, such as certain device drivers or the touchscreen (if so equipped).

=== Target Machine Compiling ===

Use the following steps to cross-compile the project and send it to a target board.
 
<cl>
1. In a terminal, navigate to the base directory of the project. {{note | If the architecture of the target board you're using for your appliction <code>x86</code>, then you will need to change all occurrences of <code>arm</code> in the following sections below to <code>x86</code>.}}
* Create a build directory for cross compiling.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm }}
* Navigate into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm }}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm }}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
The <code> make </code> command creates the target executable in the <code>hello_emac-build-arm</code> directory.
* Now copy the executable to the target board. For information on copying the executable file, see the [[ #Transferring_Files | Transferring Files ]] section.
</cl>




{{:Templateimpl:examples | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project for use with CMake | project=OE 5.0 }}
This section illustrates how to complete various tasks associated with configuring and building a CMake project.
===Debug Build Types===
By default, new projects will have the Debug build type. To compile the project with the Release or Minimum Size Release build types, there are two options:
*Make a secondary (or tertiary) build directory. (Recommended)
*Clean the current build directory and re-run CMake.
The different levels of build type correlate to usage of different C Flags. When cross-compiling, these C Flags are located in the <code>toolchain.<architecture>.cmake</code> files located, by default, in <code>/opt/emac/5.X/</code>, with ''X'' being the specific version of SDK. The following table will give a brief overview of the different build types.

 
 
<table style="border-style:double; border-width:2px; margin-top:-10%; margin-bottom:-3%;"><tr style="border-style:double; border-width:2px;"><td>'''Name:'''</td><td>'''Type:'''</td><td>'''Debugging Features:'''</td><td>'''Description:'''</td><td>'''Optimization Level:'''</td><td>'''C Flags Used:'''</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>Release</td><td>Release</td><td>disabled</td><td>Release targeted build optimized for best performance.</td><td>-O2</td><td>CMAKE_C_FLAGS_RELEASE</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>MinSizeRel</td><td>Release</td><td>disabled</td><td>Release targeted build with experimental optimizations. (Builds using this should be thoroughly tested.)</td><td>-O3</td><td>CMAKE_C_FLAGS_MINSIZEREL</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>Debug</td><td>Debug</td><td>enabled</td><td>A standard debugging oriented build, optimized for improved debugging.</td><td>-O0</td><td>CMAKE_C_FLAGS_DEBUG</td></tr>

</table>
 
 
 
If you wish to add any additional flags to a build type, they can be defined in the project's <code>CMakeList.txt</code> file as shown in the code snippet below.
<syntaxhighlight lang="cmake">
project(example)

SET(MAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -Wall -Wpedantic")

# This will add the -Wall and -Wpedantic options to the existing debug build flags
</syntaxhighlight>


====Method 1: Create separate build directory====
To create a Release build using the 1st (recommended) method, use the following steps. This method is recommended because it allows both the Debug and the Release executable to exist at the same time.
<cl>
1. In a terminal, navigate to the base directory of the project.
* Create a new release build directory
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm-release }}
* Change directories into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm-release }}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm -DCMAKE_BUILD_TYPE:STRING=Release }}{{note | The string 'MinSizeRel' can be used in place of 'Release' for a potentially smaller executable}}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
</cl>
 
====Method 2: Re-use build directory====
Another option for creating a release build is as follows:
<cl>
1. In a terminal, navigate to the build directory of the project.
* Clean the directory with <code>make</code>
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = make clean}}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm -DCMAKE_BUILD_TYPE:STRING=Release }}{{note | The string 'MinSizeRel' can be used in place of 'Release' for a potentially smaller executable}}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
</cl>

===Renaming the Target Executable===
To rename the executable, the <code>ADD_EXECUTABLE()</code> function arguments must be changed. The first argument refers to the name of the executable, and the second refers to the source code file.

To change the name of the executable from "main" to "new_name", change the <code>ADD_EXECUTABLE()</code> from the first code box to the second code box.
<syntaxhighlight lang="cmake">
ADD_EXECUTABLE(main main.cpp)
</syntaxhighlight>

<syntaxhighlight lang="cmake">
ADD_EXECUTABLE(new_name main.cpp)
</syntaxhighlight>

===Adding Include Files===
To add an include file and implementation file (in this case, the <code>tools.cpp</code> and <code>tools.h</code> in the <code>util</code> and <code>include</code> directory, respectively) to the CMake project, changes will need to be made to the CMakeLists.txt file. Please refer to the code sample below.

# The directory to be included must be specified by the <code>INCLUDE_DIRECTORIES()</code> function. The variable <code>${PROJECT_SOURCE_DIR}</code> refers to the base path of the project which is generally where this <code>README</code> file is located.
# The <code>SOURCES</code> must be set. This list of files should include all of the source files in the project.

<syntaxhighlight lang="cmake">
INCLUDE_DIRECTORIES(${PROJECT_SOURCE_DIR}include)

SET(SOURCES
${PROJECT_SOURCE_DIR}main.cpp
${PROJECT_SOURCE_DIR}util/tools.cpp
)
SET(HEADERS
${PROJECT_SOURCE_DIR}include/tools.h
)

ADD_EXECUTABLE(main ${SOURCES} ${HEADERS})
</syntaxhighlight>




{{:Templateimpl:moreinfo | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project for use with CMake | project=OE 5.0 }}

* [[System_Log_In | System Log In]]
* [[Serial_Connections | Serial Connections ]]
* [[Network_Connections | Network Connections ]]
* [[System_Log_In | System Log In ]]
* [[Remote_Debugging_EMAC_OE_SDK_Projects_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver ]]
* [[System_Logging | System Logging ]]

Creating a New EMAC OE SDK Project with CMake

2018-08-09T23:13:23Z

Mgloff:

{{todo| Complete (08.07.2015-12:59->KY+)(08.17.2015-12:07->KY+)(08.17.2015-14:25->KY+)(08.17.2015-17:40->MD-)(11.03.2015-13:38->KY+);(11.04.2015-11:20->MD-)(11.04.2015-13:04->KY+-);(11.04.2015-13:25->MD+)(11.04.2015-14:45->MG+)|Klint Youngmeyer| project=OE 5.0,KY,MD,Complete }}
{{#seo:
|title=Creating a New EMAC OE SDK Project with CMake
|titlemode=append
|keywords=CMakeLists.txt, CMake cross-compiling, CMake, CMake ARM, oe_init_project
|description=Creating an EMAC OE SDK project which uses the CMake build system.
}}




The EMAC OE SDK is distributed with the intent that CMake be used with the EMAC OE toolchain and libraries to build most projects. This page demonstrates the process of creating and compiling a new project with CMake, and running it on the target machine.

__TOC__




{{:Templateimpl:geninfo | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK Project which Builds via CMake | project=OE 5.0 }}
Creating a new EMAC CMake project is accomplished with the use of the <code>oe_init_project</code> program. This program is included in the [ftp://oe50opkg:opkgoe50123@ftp.emacinc.com/5.1/x86_64-nativesdk/nativesdk-emac-tools_git-r0_x86_64-nativesdk.ipk emac-tools] opkg package, which is part of the ADT EMAC SDK. For instructions on installing the EMAC SDK, please see [[Getting_Started_with_the_EMAC_OE_SDK#Installing_EMAC_SDK |this section]] in the getting started guide.



{{:Templateimpl:using | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project which Builds with CMake | project=OE 5.0 }}

This section demonstrates how to use the EMAC CMake tool, <code>oe_init_project</code>, to generate CMake files automatically for a project. When using the EMAC SDK there are currently two options for cross compiling:
* <code>arm</code>
* <code>x86</code>
For the purposes of this guide, the <code>arm</code> option will be used for the listed examples.
=== Host Machine Compiling ===
Navigate to the directory where the project will be located. Then run the CMake new project tool, <code>/opt/emac/5.x/bin/oe_init_project</code>.
{{clo}}
{{clio | username=developer | hostname=ldc | pwd=~/projects | /opt/emac/5.x/bin/oe_init_project -n hello.c }}
If desired, please enter a name for this project, otherwise press Enter to use the default: hello_emac 

-- Creating new project directory... 
-- Creating new source file... 
-- Building custom CMakeLists.txt file... 
-- Done. 

Do you want to create a build directory for this project? (y/n) y 

-- Creating build directory... 

Do you want to run cmake for this project? (y/n) y 

-- Using system compiler 
-- The C compiler identification is GNU 4.8.2 
-- The CXX compiler identification is GNU 4.8.2 
-- Check for working C compiler: /usr/bin/cc 
-- Check for working C compiler: /usr/bin/cc -- works 
-- Detecting C compiler ABI info 
-- Detecting C compiler ABI info - done 
-- Check for working CXX compiler: /usr/bin/c++ 
-- Check for working CXX compiler: /usr/bin/c++ -- works 
-- Detecting CXX compiler ABI info 
-- Detecting CXX compiler ABI info - done 
-- Configuring done 
-- Generating done 
-- Build files have been written to: /home/developer/projects/hello_emac/hello_emac-build 

Do you want to compile this project? (y/n) y

Scanning dependencies of target hello_emac 
[100%] Building C object CMakeFiles/hello_emac.dir/hello.c.o 
Linking C executable hello_emac 
[100%] Built target hello_emac 
{{clos}}

The executable, in this case, is now inside the <code> hello_emac/hello_emac-build </code> directory and can be executed by the host machine (X86_64).

The CMake project script has now made a project directory that contains the following:
* <code>CMakeLists.txt</code>
* Source code file (<code>hello.c</code> in this case)
* <code>README</code> file
* Desktop Build Directory (<code>hello_emac-build</code> in this case)

The <code>CMakeLists.txt</code> is a script which contains the required information to automatically create a <code>Makefile</code> for any supported architecture. This file was generated by the EMAC <code>oe_init_project</code> tool, and will need to be modified over time as a project grows. The comments in the <code>CMakeLists.txt</code> file generated by the EMAC tool will provide a good starting point for how to add additional source files and how to perform other common tasks related to maintaining your CMake build system as you develop your software project. The [http://cmake.org CMake] project provides extensive documentation on how to work with these files.

The source code file generated by the script (<code>hello.c</code>) contains a basic Hello World style program. This can provide a starting point for your application, or can be replaced by another source file with the same name.

The <code>README</code> file contains more information on using <code>CMake</code> with the EMAC OE 5.X SDK. You may refer to this file for quick reference.

The Desktop Build Directory (<code>hello_emac-build</code>) contains the executable, <code>hello_emac</code>, the <code>Makefile</code>, and various cache files. These were automatically created by CMake and by the build system, and can be recreated at any time.

It is useful to have a Desktop Build Directory because it is easier (in the beginning) to use the desktop to verify all code changes before cross-compiling for a target board. This will be useful until the application under development depends upon resources which are only available on the target hardware, such as certain device drivers or the touchscreen (if so equipped).

=== Target Machine Compiling ===

Use the following steps to cross-compile the project and send it to a target board.
 
<cl>
1. In a terminal, navigate to the base directory of the project. {{note | If the architecture of the target board you're using for your appliction <code>x86</code>, then you will need to change all occurrences of <code>arm</code> in the following sections below to <code>x86</code>.}}
* Create a build directory for cross compiling.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm }}
* Navigate into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm }}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm }}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
The <code> make </code> command creates the target executable in the <code>hello_emac-build-arm</code> directory.
* Now copy the executable to the target board. For information on copying the executable file, see the [[ #Transferring_Files | Transferring Files ]] section.
</cl>




{{:Templateimpl:examples | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project for use with CMake | project=OE 5.0 }}
This section illustrates how to complete various tasks associated with configuring and building a CMake project.
===Debug Build Types===
By default, new projects will have the Debug build type. To compile the project with the Release or Minimum Size Release build types, there are two options:
*Make a secondary (or tertiary) build directory. (Recommended)
*Clean the current build directory and re-run CMake.
The different levels of build type correlate to usage of different C Flags. When cross-compiling, these C Flags are located in the <code>toolchain.<architecture>.cmake</code> files located, by default, in <code>/opt/emac/5.X/</code>, with ''X'' being the specific version of SDK. The following table will give a brief overview of the different build types.

 
 
<table style="border-style:double; border-width:2px; margin-top:-10%; margin-bottom:-3%;"><tr style="border-style:double; border-width:2px;"><td>'''Name:'''</td><td>'''Type:'''</td><td>'''Debugging Features:'''</td><td>'''Description:'''</td><td>'''Optimization Level:'''</td><td>'''C Flags Used:'''</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>Release</td><td>Release</td><td>disabled</td><td>Release targeted build optimized for best performance.</td><td>-O2</td><td>CMAKE_C_FLAGS_RELEASE</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>MinSizeRel</td><td>Release</td><td>disabled</td><td>Release targeted build with experimental optimizations. (Builds using this should be thoroughly tested.)</td><td>-O3</td><td>CMAKE_C_FLAGS_MINSIZEREL</td></tr>

<tr style="border-style:solid; border-width:2px;"><td>Debug</td><td>Debug</td><td>enabled</td><td>A standard debugging oriented build, optimized for improved debugging.</td><td>-O0</td><td>CMAKE_C_FLAGS_DEBUG</td></tr>

</table>
 
 
 
If you wish to add any additional flags to a build type, they can be defined in the project's <code>CMakeList.txt</code> file as shown in the code snippet below.
<syntaxhighlight lang="cmake">
project(example)

SET(MAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -Wall -Wpedantic")

# This will add the -Wall and -Wpedantic options to the existing debug build flags
</syntaxhighlight>


====Method 1: Create separate build directory====
To create a Release build using the 1st (recommended) method, use the following steps. This method is recommended because it allows both the Debug and the Release executable to exist at the same time.
<cl>
1. In a terminal, navigate to the base directory of the project.
* Create a new release build directory
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | mkdir hello_emac-build-arm-release }}
* Change directories into the newly created directory.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac | cd hello_emac-build-arm-release }}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm -DCMAKE_BUILD_TYPE:STRING=Release }}{{note | The string 'MinSizeRel' can be used in place of 'Release' for a potentially smaller executable}}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
</cl>
 
====Method 2: Re-use build directory====
Another option for creating a release build is as follows:
<cl>
1. In a terminal, navigate to the build directory of the project.
* Clean the directory with <code>make</code>
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = make clean}}
* Run <code>cmake</code> using the target architecture.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | 1 = cmake .. -DARCH:STRING=arm -DCMAKE_BUILD_TYPE:STRING=Release }}{{note | The string 'MinSizeRel' can be used in place of 'Release' for a potentially smaller executable}}
* Compile the code using <code>make</code>.
{{cli | username=developer | hostname=ldc | pwd=~/projects/hello_emac/hello_emac-build-arm | make }}
</cl>

===Renaming the Target Executable===
To rename the executable, the <code>ADD_EXECUTABLE()</code> function arguments must be changed. The first argument refers to the name of the executable, and the second refers to the source code file.

To change the name of the executable from "main" to "new_name", change the <code>ADD_EXECUTABLE()</code> from the first code box to the second code box.
<syntaxhighlight lang="cmake">
ADD_EXECUTABLE(main main.cpp)
</syntaxhighlight>

<syntaxhighlight lang="cmake">
ADD_EXECUTABLE(new_name main.cpp)
</syntaxhighlight>

===Adding Include Files===
To add an include file and implementation file (in this case, the <code>tools.cpp</code> and <code>tools.h</code> in the <code>util</code> and <code>include</code> directory, respectively) to the CMake project, changes will need to be made to the CMakeLists.txt file. Please refer to the code sample below.

# The directory to be included must be specified by the <code>INCLUDE_DIRECTORIES()</code> function. The variable <code>${PROJECT_SOURCE_DIR}</code> refers to the base path of the project which is generally where this <code>README</code> file is located.
# The <code>SOURCES</code> must be set. This list of files should include all of the source files in the project.

<syntaxhighlight lang="cmake">
INCLUDE_DIRECTORIES(${PROJECT_SOURCE_DIR}include)

SET(SOURCES
${PROJECT_SOURCE_DIR}main.cpp
${PROJECT_SOURCE_DIR}util/tools.cpp
)
SET(HEADERS
${PROJECT_SOURCE_DIR}include/tools.h
)

ADD_EXECUTABLE(main ${SOURCES} ${HEADERS})
</syntaxhighlight>




{{:Templateimpl:moreinfo | initials=KY | title=Creating a New EMAC OE SDK Project with CMake | desc=Creating an EMAC OE SDK project for use with CMake | project=OE 5.0 }}

* [[System_Log_In | System Log In]]
* [[Serial_Connections | Serial Connections ]]
* [[Network_Connections | Network Connections ]]
* [[System_Log_In | System Log In ]]
* [[Remote_Debugging_EMAC_OE_SDK_Projects_with_gdbserver | Remote Debugging EMAC OE SDK Projects with gdbserver ]]
* [[System_Logging | System Logging ]]

Loading JFFS2 Images Onto a Board

2018-06-05T16:23:27Z

Mgloff:

{{todo|SEOKWREV, held for FTP server update; (11.06.13-08:24->MW+)(11.06.13-17:55->MD+)(12.11.13-13:56->MW+)(12.19.13-18:40->MD+);(12.20.13-11:30->KY+);(03.06.14-15:05->BS-);(04.11.14-11:35->BS+)|Michael Welling|project=oe 4,oe 5,mw,md,bs,SEOKWREV}}

{{#seo:
|title=Loading JFFS2 Images Onto a Board
|titlemode=append
|keywords=JFFS2,U-Boot,TFTP Server
|description=The section provides links and useful information for performing JFFS2 programming using U-Boot and Redboot.
}}
== Background ==

Journalling Flash File System version 2, or JFFS2, is a log-structured file system used on flash memory devices. JFFS2 images are typically created on a development PC and deployed to an embedded target using TFTP commands from the target's bootloader. Deployment requires both serial and Ethernet connections to the board along with a TFTP server set up on a development machine.

For instructions on installing a TFTP server on a development PC:
[[Installing TFTP server]]

For details on connecting to the serial port for an embedded target:
[[Serial Connections]]

JFFS2 file systems are available for download on [ftp://ftp.emacinc.com EMAC's FTP site].

For instructions on creating a JFFS2 file system image see the following page:
[[Creating JFFS2 Images]]

== General Information ==
The section below provides links and useful information for performing JFFS2 programming using U-Boot and Redboot. The links provide pages with the generic procedures for programming EMAC modules based on the bootloader type.

=== Using U-Boot ===
Refer to the following pages for instructions on accessing U-Boot on the serial console: 
[[U-Boot Overview]] 
[[Loading Images with U-Boot]]

From the U-Boot prompt it is possible to set the target's IP address dynamically using DHCP:
<syntaxhighlight lang="console">
U-Boot> set autoload no
U-Boot> dhcp
</syntaxhighlight>

The target's IP can also be manually set using the <code>ipaddr</code> environment variable as follows:
<syntaxhighlight lang="console">
U-Boot> set ipaddr 192.168.0.101
</syntaxhighlight>

Once the target IP is set, the TFTP server's IP address must be specified:
<syntaxhighlight lang="console">
U-Boot> set serverip 192.168.0.100
</syntaxhighlight>

The configuration of the bootloader environment can be checked at any time using the <code>printenv</code> command. As described in [[Loading Images with U-Boot]], the JFFS2 image will then be loaded into SDRAM and programmed into flash. A full example for the SoM-9G45 will be provided below.

== Full Example Using U-Boot (SoM-9G45) ==
This section provides a detailed example of loading a JFFS2 file system onto the SoM-9G45 and shows how U-Boot responds to the various commands when performed successfully.

U-Boot 2009.06-rc1-svn1786 (Nov 28 2011 - 17:22:29)

EMAC Inc. SOM-9M10/G45M

I2C: ready
DRAM: 128 MB
NAND: 256 MiB
DataFlash:AT45DB321
Nb pages: 8192
Page Size: 528
Size= 4325376 bytes
Logical address: 0xC0000000
Area 0: C0000000 to C00041FF (RO) Bootstrap
Area 1: C0004200 to C00083FF Environment
Area 2: C0008400 to C0041FFF (RO) U-Boot
Area 3: C0042000 to C0251FFF Kernel
Area 4: C0252000 to C041FFFF FS
In: serial
Out: serial
Err: serial
Net: macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Hit any key to stop autoboot: 0
U-Boot> set autoload no
U-Boot> dhcp
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
BOOTP broadcast 1
DHCP client bound to address 10.0.2.221
U-Boot> set serverip 10.0.2.168
U-Boot> tftp 0x74000000 som-9g45m-rootfs.jffs2
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 10.0.2.168; our IP address is 10.0.2.221
Filename 'som-9g45m-rootfs.jffs2'.
Load address: 0x74000000
Loading: #################################################################
...
####################################################
done
Bytes transferred = 27473444 (1a33624 hex)
U-Boot> nand erase

NAND erase: device 0 whole chip
Skipping bad block at 0x03320000
Skipping bad block at 0x079e0000
Skipping bad block at 0x085e0000
Erasing at 0xffe0000 -- 100% complete.
OK
U-Boot> nand write.jffs2 0x74000000 0x0 ${filesize}

NAND write: device 0 offset 0x0, size 0x1a33624
NAND write: Padding to page size...
27473444 bytes written: OK
U-Boot>

== Quick Reference (By Target Type) ==
This section provides a quick reference for programming various targets with a JFFS2 image.
It is assumed that the Ethernet setup is performed as described above in the General Information section.

=== SoM-9260M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x20000000 som-9260m-rootfs.jffs2
U-Boot> protect off all
U-Boot> erase 0x10400000 0x11ffffff
U-Boot> cp.b 0x20000000 0x10400000 ${filesize}
# Erase the second bank for 64Mb modules
U-Boot> erase 0x12000000 0x13ffffff
# OE 4 - set filesystem read/write on first boot
U-Boot> setenv bootargs 'console=ttyS3,115200 root=/dev/mtdblock3 rootfstype=jffs2 rw'
</syntaxhighlight>

=== SoM-9G20M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x20000000 som-9g20m-rootfs.jffs2
U-Boot> nand erase
U-Boot> nand write.jffs2 0x20000000 0x0 ${filesize}
</syntaxhighlight>

=== SoM-9G45M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x74000000 som-9g45m-rootfs.jffs2
U-Boot> nand erase
U-Boot> nand write.jffs2 0x74000000 0x0 ${filesize}

</syntaxhighlight>

=== SoM-9M10M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x74000000 som-9m10m-rootfs.jffs2
U-Boot> nand erase
U-Boot> nand write.jffs2 0x74000000 0x0 ${filesize}
</syntaxhighlight>

Loading JFFS2 Images Onto a Board

2018-06-01T18:47:23Z

Mgloff:

{{todo|SEOKWREV, held for FTP server update; (11.06.13-08:24->MW+)(11.06.13-17:55->MD+)(12.11.13-13:56->MW+)(12.19.13-18:40->MD+);(12.20.13-11:30->KY+);(03.06.14-15:05->BS-);(04.11.14-11:35->BS+)|Michael Welling|project=oe 4,oe 5,mw,md,bs,SEOKWREV}}

{{#seo:
|title=Loading JFFS2 Images Onto a Board
|titlemode=append
|keywords=JFFS2,U-Boot,TFTP Server
|description=The section provides links and useful information for performing JFFS2 programming using U-Boot and Redboot.
}}
== Background ==

Journalling Flash File System version 2, or JFFS2, is a log-structured file system used on flash memory devices. JFFS2 images are typically created on a development PC and deployed to an embedded target using TFTP commands from the target's bootloader. Deployment requires both serial and Ethernet connections to the board along with a TFTP server set up on a development machine.

For instructions on installing a TFTP server on a development PC:
[[Installing TFTP server]]

For details on connecting to the serial port for an embedded target:
[[Serial Connections]]

JFFS2 file systems are available for download on [ftp://ftp.emacinc.com EMAC's FTP site].

For instructions on creating a JFFS2 file system image see the following page:
[[Creating JFFS2 Images]]

== General Information ==
The section below provides links and useful information for performing JFFS2 programming using U-Boot and Redboot. The links provide pages with the generic procedures for programming EMAC modules based on the bootloader type.

=== Using U-Boot ===
Refer to the following pages for instructions on accessing U-Boot on the serial console: 
[[U-Boot Overview]] 
[[Loading Images with U-Boot]]

From the U-Boot prompt it is possible to set the target's IP address dynamically using DHCP:
<syntaxhighlight lang="console">
U-Boot> set autoload no
U-Boot> dhcp
</syntaxhighlight>

The target's IP can also be manually set using the <code>ipaddr</code> environment variable as follows:
<syntaxhighlight lang="console">
U-Boot> set ipaddr 192.168.0.101
</syntaxhighlight>

Once the target IP is set, the TFTP server's IP address must be specified:
<syntaxhighlight lang="console">
U-Boot> set serverip 192.168.0.100
</syntaxhighlight>

The configuration of the bootloader environment can be checked at any time using the <code>printenv</code> command. As described in [[Loading Images with U-Boot]], the JFFS2 image will then be loaded into SDRAM and programmed into flash. A full example for the SoM-9G45 will be provided below.

== Full Example Using U-Boot (SoM-9G45) ==
This section provides a detailed example of loading a JFFS2 file system onto the SoM-9G45 and shows how U-Boot responds to the various commands when performed successfully.

U-Boot 2009.06-rc1-svn1786 (Nov 28 2011 - 17:22:29)

EMAC Inc. SOM-9M10/G45M

I2C: ready
DRAM: 128 MB
NAND: 256 MiB
DataFlash:AT45DB321
Nb pages: 8192
Page Size: 528
Size= 4325376 bytes
Logical address: 0xC0000000
Area 0: C0000000 to C00041FF (RO) Bootstrap
Area 1: C0004200 to C00083FF Environment
Area 2: C0008400 to C0041FFF (RO) U-Boot
Area 3: C0042000 to C0251FFF Kernel
Area 4: C0252000 to C041FFFF FS
In: serial
Out: serial
Err: serial
Net: macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Hit any key to stop autoboot: 0
U-Boot> set autoload no
U-Boot> dhcp
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
BOOTP broadcast 1
DHCP client bound to address 10.0.2.221
U-Boot> set serverip 10.0.2.168
U-Boot> tftp 0x74000000 som-9g45m-rootfs.jffs2
macb0: link up, 100Mbps full-duplex (lpa: 0xcde1)
Using macb0 device
TFTP from server 10.0.2.168; our IP address is 10.0.2.221
Filename 'som-9g45m-rootfs.jffs2'.
Load address: 0x74000000
Loading: #################################################################
...
####################################################
done
Bytes transferred = 27473444 (1a33624 hex)
U-Boot> nand erase

NAND erase: device 0 whole chip
Skipping bad block at 0x03320000
Skipping bad block at 0x079e0000
Skipping bad block at 0x085e0000
Erasing at 0xffe0000 -- 100% complete.
OK
U-Boot> nand write.jffs2 0x74000000 0x0 ${filesize}

NAND write: device 0 offset 0x0, size 0x1a33624
NAND write: Padding to page size...
27473444 bytes written: OK
U-Boot>

== Quick Reference (By Target Type) ==
This section provides a quick reference for programming various targets with a JFFS2 image.
It is assumed that the Ethernet setup is performed as described above in the General Information section.

=== SoM-9260M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x20000000 som-9260m-rootfs.jffs2
U-Boot> protect off all
U-Boot> erase 0x10400000 0x11ffffff
U-Boot> cp.b 0x20000000 0x10400000 ${filesize}
# Erase the second bank for 64Mb modules
U-Boot> erase 0x12000000 0x13ffffff
</syntaxhighlight>

=== SoM-9G20M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x20000000 som-9g20m-rootfs.jffs2
U-Boot> nand erase
U-Boot> nand write.jffs2 0x20000000 0x0 ${filesize}
</syntaxhighlight>

=== SoM-9G45M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x74000000 som-9g45m-rootfs.jffs2
U-Boot> nand erase
U-Boot> nand write.jffs2 0x74000000 0x0 ${filesize}

</syntaxhighlight>

=== SoM-9M10M ===
<syntaxhighlight lang="bash">
U-Boot> tftp 0x74000000 som-9m10m-rootfs.jffs2
U-Boot> nand erase
U-Boot> nand write.jffs2 0x74000000 0x0 ${filesize}
</syntaxhighlight>

Product wiki

2018-04-23T16:13:04Z

Mgloff:

{{todo| Review (11.19.2014-20:52->MD+)(11.19.2014-13:19->MD+)(09.04.2014-11:30->MD+)(11.18.2015-17:10->MD+)|Mike Dean| project=OE 5,MD }}
__NOTOC__



{{:Template:Navpgtable | initials={{{initials}}} | title=EMAC Support Wiki | desc={{{desc}}} | project=OE 5 }}




{{:Templateimpl:navtableentry | title=Getting Started }}

{{:Templateimpl:Navti | [[Getting_Started_with_the_EMAC_OE_SDK | With the EMAC OE SDK]] }}
{{:Templateimpl:Navti | [[Getting_Started_With_Qt_Creator | With Qt Creator]] }}
{{:Templateimpl:Navti | [[Quick_Reference | Quick Reference]] }}
{{:Templateimpl:Navtii | [[OE_50_Getting_Started | More Getting Started Guides]] }}

{{:Templateimpl:navtend}}




{{:Templateimpl:navtableentry | title=How-To }}

{{:Templateimpl:Navti | [[Opkg | Work with the EMAC OE Package Manager ]] }}
{{:Templateimpl:Navti | [[Serial_Connections | Establishing a Serial Connection ]] }}
{{:Templateimpl:Navti | [[Network_Connections | Connecting to a Network ]] }}
{{:Templateimpl:Navti | [[System_Log_In | How to Log In to an EMAC OE Linux System ]] }}
{{:Templateimpl:Navti | [[Installing_EMAC_OE_5.0_SDK | Install the SDK ]] }}
{{:Templateimpl:Navtii | [[OE_50_How_To | More How To Pages]] }}

{{:Templateimpl:navtend}}





{{:Templateimpl:navtablenewrow}}




{{:Templateimpl:navtableentry | title=EMAC Linux OE }}

{{:Templateimpl:Navti | [[EMAC_OpenEmbedded_Fact_Sheet | Information about EMAC OE Linux ]] }}
{{:Templateimpl:Navti | [[OE:Versions | EMAC OE Linux Versions ]] }}
{{:Templateimpl:Navti | [[OE50:Packages | What's New ]] }}
{{:Templateimpl:Navtii | [[OE_50_EMAC_Linux | More On EMAC OE Linux]] }}

{{:Templateimpl:navtend}}




{{:Templateimpl:navtableentry | title=EMAC Hardware }}

{{:Templateimpl:Navti | [http://www.emacinc.com/products/system_on_module System on Module (SoM)] }}
{{:Templateimpl:Navti | [http://www.emacinc.com/products/panel_pcs_and_lcds Panel PC (PPC)] }}
{{:Templateimpl:Navti | [http://www.emacinc.com/products/pc_compatible_sbcs Single Board Computer (SBC)] }}
{{:Templateimpl:Navti | [http://www.emacinc.com/products/embedded_servers Server In a Box (SIB)] }}
{{:Templateimpl:Navtii | [[EMAC_HW | More EMAC Hardware]] }}

{{:Templateimpl:navtend}}




{{:Templateimpl:navtableend}}

Installing EMAC OE 5.0 SDK

2018-04-23T16:10:44Z

Mgloff:

==Prerequisites==
If you are installing the SDK using the ADT Installer (Automatic Install), dependencies will be automatically installed for the supported distributions: Debian/Ubuntu, Fedora, CentOS, openSUSE. EMAC also provides a [ftp://ftp.emacinc.com/EMAC_Linux/Virtual_LDCs/EMAC_Virtual_LDC.ova pre-configured virtual machine image.]
{{note | Currently the version of Qt Creator installed during the automatic installation does not work on Debian 8}}

If you are installing the SDK manually or using a non-supported distribution, you will have to install the dependencies manually.
==Procedure (Automatic Install)==
<cl>
1. Download the ADT Installer. (Right click, save link as)
* [ftp://ftp.emacinc.com/EMAC_Linux/SDK/emac_adt_installer EMAC ADT Installer].

* Change to the directory where the ADT Installer was downloaded from the command line:
{{cli | username=developer | hostname=ldc |cd ~/Downloads }}

* Make the file executable:
{{cli | username=developer | hostname=ldc | chmod +x emac_adt_installer }}

* Run ADT Installer script:
{{cli | username=developer | hostname=ldc |./emac_adt_installer }}
The installer will start.

* Watch for errors:
{{clo}}######################################################################### # Met Errors when installing EMAC ADT! Please check log file for details. ######################################################################### {{clos}}

* Enter the development user's password if prompted. Allow the installer to install dependencies.

* Enter the number for your boards architecture.
{{clo}}
Please enter the target architecture: 
1. Arm 
2. x86 
board: 
{{clos}}

* The ADT Installer will then display what is to be installed. You may now choose to exit the installation, or continue if the displayed information is correct.

* Once the installation of the sdk completes, the ADT Installer will ask whether or not to install Qt Creator.

{{clo}}

Would you like to install Qt Creator? [y/N]?
{{clos}}
* Qt Creator is the IDE that EMAC provides with our SDK to allow users to easily cross compile projects and upload them to their boards.
* If you chose to install Qt creator, the installer will then ask you whether or not you would like to place the icon on the desktop.

* If the installation finishes, status text will appear:{{clo}}############################################################# # EMAC ADT has been successfully installed. ############################################################# {{clos}}

</cl>

==Procedure (Manual Install)==
<cl>
1. Download the SDK. The latest version can be found on the EMAC FTP site. Download the SDK that matches the architecture of your target system. (Right click, save link as)

* SDK for x86: [ftp://ftp.emacinc.com/EMAC_Linux/SDK/emac-x86-toolchain.sh emac-x86-toolchain.sh]
* SDK for ARM: [ftp://ftp.emacinc.com/EMAC_Linux/SDK/emac-arm-toolchain.sh emac-arm-toolchain.sh]

* Change to the directory where the SDK was downloaded from the command line:
{{cli | username=developer | hostname=ldc |cd ~/Downloads }}
* Run SDK installer script:
{{cli | username=developer | hostname=ldc |./emac-ARCH-toolchain.sh }}
The installer will start. It is recommended to select the default target directory for the SDK: <code>/opt/emac/5.X</code>
* Press enter to proceed.
* Enter your password if prompted.
* Status text will appear:
{{clo}}
Extracting SDK...done 
Setting it up...done 
SDK has been successfully set up and is ready to be used. 
{{clos}}
</cl>

== Next Steps ==

* [[Getting_Started_with_the_EMAC_OE_SDK | Getting Started with the EMAC OE SDK ]]
* [[Getting_Started_With_Qt_Creator |Getting Started With Qt Creator]]

Loading Linux Images to a Compact Flash Disk

2018-03-05T20:33:58Z

Mgloff:

{{#seo:
|title=Loading Linux Images to a Compact Flash Disk
|titlemode=append
|keywords=Compact Flash,Linux Image,Firmware Image
|description=When changing firmware images or creating custom firmware images for your Compact Flash-based machine, it is necessary to perform a few steps to load the firmware image onto the CF card.
}}
When changing firmware images or creating custom firmware images for your Compact Flash-based machine, it is necessary to perform a few steps to load the firmware image onto the CF card.
__TOC__
==Necessary Tools==

To perform this procedure, the following items are required:

* The Compact Flash card to hold the firmware.
* A Compact Flash card reader attached to a computer.
* The filesystem tar.
* A fully functional Linux desktop.
* Linux tools installed: <code>tar</code>, and either <code>gzip</code> or <code>bzip2</code> (depending on the image).
* The EMAC [ftp://ftp.emacinc.com/EMAC_Linux/SDK/Archive/Linux/put-image.tar.gz put-image] package which provides the <code>put-image</code> script. The <code>README.TXT</code> file in the package details the steps needed to install the script properly.

Unpack the put-image tar after downloading:

<syntaxhighlight lang="bash">
developer@ldc:~$ tar zxvf ~/Downloads/put-image.tar.gz
</syntaxhighlight>

{{mbox | type=warning | text= '''WARNING''': Performing the following procedure incorrectly can cause a catastrophic loss of data. The individual steps should be carefully studied prior to attempting the procedure for the first time. EMAC cannot be responsible for the loss of data which may result from following this procedure incorrectly. EMAC strongly recommends having a current backup of the data on the development computer before attempting this procedure.}}

==Procedure==

Perform the following steps to load the firmware onto the Compact Flash card:

* Insert the Compact Flash card into the card reader.
* Navigate (from within the shell) to the directory which contains the firmware image to be used.
* Determine where the Compact Flash card was mounted.

<syntaxhighlight lang="console">
developer@ldc:~$ dmesg | tail -n 10
[23236.042944] sdc: detected capacity change from 4110188544 to 0
[23243.783467] sd 12:0:0:0: [sdc] 8027712 512-byte logical blocks: (4.11 GB/3.82 GiB)
[23243.785199] sd 12:0:0:0: [sdc] No Caching mode page present
[23243.785204] sd 12:0:0:0: [sdc] Assuming drive cache: write through
[23243.787314] sd 12:0:0:0: [sdc] No Caching mode page present
[23243.787326] sd 12:0:0:0: [sdc] Assuming drive cache: write through
[23243.790625] sdc: sdc1
[23244.290093] kjournald starting. Commit interval 5 seconds
[23244.293646] EXT3-fs (sdc1): using internal journal
[23244.293651] EXT3-fs (sdc1): mounted filesystem with ordered data mode
developer@ldc:~$
</syntaxhighlight>

The output of the <code>dmesg</code> command shows that the root device node for the Compact Flash card in this case is <code>sdc</code>, and that the only partition found is <code>sdc1</code>. Inspect the output shown above to see the particular device node on the development PC where the Compact Flash card is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with either <code>sd</code> or <code>hd</code>. The third letter will specify which of these devices is assigned to the CF card.

* At this point, it is wise to double check that device node is actually the CF card and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdc1</code> as the example device node, type the following command:

<syntaxhighlight lang="console">
developer@ldc:~$ mount | grep sdc1
/dev/sdc1 on /media/EMAC-OE type ext3 (rw,nosuid,nodev,uhelper=udisks)
</syntaxhighlight>

This shows that the device node, <code>/dev/sdc1</code>, is in fact the Compact Flash card. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

{{mbox | type=notice | text='''NOTE''': Not all Linux distributions will automatically mount the CF card when it is inserted into the card reader. The CF card must first be mounted in order to be accessible to the operating system. See [http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html] for more information about mounting filesystems.}}

* Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

<syntaxhighlight lang="console">
developer@ldc:~$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 4009 MB, 4009549824 bytes
77 heads, 56 sectors/track, 1816 cylinders, total 7831152 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00090707

Device Boot Start End Blocks Id System
/dev/sdc1 62 7831151 3915545 83 Linux
developer@ldc:~$
</syntaxhighlight>

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 4009 MB in size, which corresponds with the size of the 4 GB Compact Flash being used in this example.

* The device to specify for the target boot argument must also be determined prior to installing the image onto the Compact Flash card. Images obtained from EMAC will contain a text file that specifies what boot device node to use. For a custom image, use the <code>fdisk -l</code> command on the target device to determine the boot device. In this example, the target hardware specifies ''/dev/hdc'' for the boot device.

* Now, run the ''put-image'' script as below.
** The --target option specifies where the card is mounted.
** The --boot option specifies the target boot argument.
** The last option is the file name of the compressed target root filesystem.

After completion, the ''put-image'' script will output a message indicating success or failure.

<syntaxhighlight lang="console">
developer@ldc:~$ /path/to/put-image --target=/dev/sdc --boot=/dev/sda emac-firmware-image.tar.gz
</syntaxhighlight>

* The ''put-image'' script should automatically unmount the Compact Flash card after the process completes. It is best to check that the Compact Flash card is actually unmounted before unplugging it. Using the ''/dev/sdc1'' example from above, type the following command.
<syntaxhighlight lang="console">
developer@ldc:~$ mount | grep sdc1
</syntaxhighlight>

* If the command does not return anything, the Compact Flash card is not mounted and can be removed and inserted into the target device. However, if the command returns something similar to the following listing, the card will need to be unmounted manually.

<syntaxhighlight lang="console">
/dev/sdc1 on /media/EMAC-OE type ext3 (rw,nosuid,nodev,uhelper=udisks)
</syntaxhighlight>

* To unmount the Compact Flash card manually, run the following command:
<syntaxhighlight lang="console">
developer@ldc:~$ umount /dev/sdc1
</syntaxhighlight>

== See Also ==

* [[EMAC_OE_Boot_Process_Customization|Linux Boot Process Customization]]

[[Category:Filesystems]]

Loading Linux Images to a Compact Flash Disk

2018-03-05T20:29:11Z

Mgloff:

{{#seo:
|title=Loading Linux Images to a Compact Flash Disk
|titlemode=append
|keywords=Compact Flash,Linux Image,Firmware Image
|description=When changing firmware images or creating custom firmware images for your Compact Flash-based machine, it is necessary to perform a few steps to load the firmware image onto the CF card.
}}
When changing firmware images or creating custom firmware images for your Compact Flash-based machine, it is necessary to perform a few steps to load the firmware image onto the CF card.
__TOC__
==Necessary Tools==

To perform this procedure, the following items are required:

* The Compact Flash card to hold the firmware.
* A Compact Flash card reader attached to a computer.
* The filesystem tar.
* A fully functional Linux desktop.
* Linux tools installed: <code>tar</code>, and either <code>gzip</code> or <code>bzip2</code> (depending on the image).
* The EMAC [ftp://ftp.emacinc.com/EMAC_Linux/SDK/Archive/Linux/put-image.tar.gz| put-image] package which provides the <code>put-image</code> script. The <code>README.TXT</code> file in the package details the steps needed to install the script properly.

Unpack the put-image tar after downloading:

<syntaxhighlight lang="bash">
developer@ldc:~$ tar zxvf ~/Downloads/put-image.tar.gz
</syntaxhighlight>

{{mbox | type=warning | text= '''WARNING''': Performing the following procedure incorrectly can cause a catastrophic loss of data. The individual steps should be carefully studied prior to attempting the procedure for the first time. EMAC cannot be responsible for the loss of data which may result from following this procedure incorrectly. EMAC strongly recommends having a current backup of the data on the development computer before attempting this procedure.}}

==Procedure==

Perform the following steps to load the firmware onto the Compact Flash card:

* Insert the Compact Flash card into the card reader.
* Navigate (from within the shell) to the directory which contains the firmware image to be used.
* Determine where the Compact Flash card was mounted.

<syntaxhighlight lang="console">
developer@ldc:~$ dmesg | tail -n 10
[23236.042944] sdc: detected capacity change from 4110188544 to 0
[23243.783467] sd 12:0:0:0: [sdc] 8027712 512-byte logical blocks: (4.11 GB/3.82 GiB)
[23243.785199] sd 12:0:0:0: [sdc] No Caching mode page present
[23243.785204] sd 12:0:0:0: [sdc] Assuming drive cache: write through
[23243.787314] sd 12:0:0:0: [sdc] No Caching mode page present
[23243.787326] sd 12:0:0:0: [sdc] Assuming drive cache: write through
[23243.790625] sdc: sdc1
[23244.290093] kjournald starting. Commit interval 5 seconds
[23244.293646] EXT3-fs (sdc1): using internal journal
[23244.293651] EXT3-fs (sdc1): mounted filesystem with ordered data mode
developer@ldc:~$
</syntaxhighlight>

The output of the <code>dmesg</code> command shows that the root device node for the Compact Flash card in this case is <code>sdc</code>, and that the only partition found is <code>sdc1</code>. Inspect the output shown above to see the particular device node on the development PC where the Compact Flash card is mounted. This will be different depending on the configuration of the development PC. The <code>/dev/</code> prefix will go before the device name, but is not shown in the output of <code>dmesg</code>. The device node will start with either <code>sd</code> or <code>hd</code>. The third letter will specify which of these devices is assigned to the CF card.

* At this point, it is wise to double check that device node is actually the CF card and not a hard drive in the system. Specifying the wrong device node could cause a complete loss of data on a hard drive. Continuing with <code>/dev/sdc1</code> as the example device node, type the following command:

<syntaxhighlight lang="console">
developer@ldc:~$ mount | grep sdc1
/dev/sdc1 on /media/EMAC-OE type ext3 (rw,nosuid,nodev,uhelper=udisks)
</syntaxhighlight>

This shows that the device node, <code>/dev/sdc1</code>, is in fact the Compact Flash card. This is because:
* It is not mounted on one of the standard Linux filesystem mountpoints, such as <code>/</code>, <code>/boot</code>, <code>/usr</code>, or <code>/home</code>.
* It '''is''' mounted in the <code>/media</code> directory, where it is expected. It may alternatively get mounted in <code>/mnt</code>, depending upon the configuration of the Linux distribution in use.

{{mbox | type=notice | text='''NOTE''': Not all Linux distributions will automatically mount the CF card when it is inserted into the card reader. The CF card must first be mounted in order to be accessible to the operating system. See [http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html http://www.gnu.org/software/libc/manual/html_node/Mount_002dUnmount_002dRemount.html] for more information about mounting filesystems.}}

* Use <code>fdisk -l</code> to inspect the device node. Use <code>sudo</code> with <code>fdisk</code> to gain the required <code>root</code> privileges to run <code>fdisk</code>

<syntaxhighlight lang="console">
developer@ldc:~$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 4009 MB, 4009549824 bytes
77 heads, 56 sectors/track, 1816 cylinders, total 7831152 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00090707

Device Boot Start End Blocks Id System
/dev/sdc1 62 7831151 3915545 83 Linux
developer@ldc:~$
</syntaxhighlight>

* As can be seen from the output of the <code>fdisk -l</code> command above, the disk is 4009 MB in size, which corresponds with the size of the 4 GB Compact Flash being used in this example.

* The device to specify for the target boot argument must also be determined prior to installing the image onto the Compact Flash card. Images obtained from EMAC will contain a text file that specifies what boot device node to use. For a custom image, use the <code>fdisk -l</code> command on the target device to determine the boot device. In this example, the target hardware specifies ''/dev/hdc'' for the boot device.

* Now, run the ''put-image'' script as below.
** The --target option specifies where the card is mounted.
** The --boot option specifies the target boot argument.
** The last option is the file name of the compressed target root filesystem.

After completion, the ''put-image'' script will output a message indicating success or failure.

<syntaxhighlight lang="console">
developer@ldc:~$ /path/to/put-image --target=/dev/sdc --boot=/dev/sda emac-firmware-image.tar.gz
</syntaxhighlight>

* The ''put-image'' script should automatically unmount the Compact Flash card after the process completes. It is best to check that the Compact Flash card is actually unmounted before unplugging it. Using the ''/dev/sdc1'' example from above, type the following command.
<syntaxhighlight lang="console">
developer@ldc:~$ mount | grep sdc1
</syntaxhighlight>

* If the command does not return anything, the Compact Flash card is not mounted and can be removed and inserted into the target device. However, if the command returns something similar to the following listing, the card will need to be unmounted manually.

<syntaxhighlight lang="console">
/dev/sdc1 on /media/EMAC-OE type ext3 (rw,nosuid,nodev,uhelper=udisks)
</syntaxhighlight>

* To unmount the Compact Flash card manually, run the following command:
<syntaxhighlight lang="console">
developer@ldc:~$ umount /dev/sdc1
</syntaxhighlight>

== See Also ==

* [[EMAC_OE_Boot_Process_Customization|Linux Boot Process Customization]]

[[Category:Filesystems]]

Xenomai RTSerial

2018-02-06T22:16:16Z

Mgloff:

{{todo| NotStarted (03.03.2016-13:01->MW+)|Michael Welling| project=OE 5.0,MW,NotStarted }}
{{#seo:
|title=Xenomai RTSerial
|titlemode=append
|keywords=
|description=Xenomai RTSerial
}}




__TOC__




{{:Templateimpl:geninfo | initials=MW | title=Xenomai RTSerial | desc=Xenomai RTSerial | project=OE 5.0 }}
Xenomai provides a RTDM profile for serial device drivers enabling real-time UART serial communication.
The RTDM serial driver provides the necessary user-space API to perform serial port configuration and communication.
The following sections will outline the use of the user-space interface and provide basic examples.




{{:Templateimpl:using | initials=MW | title=Xenomai RTSerial | desc=Xenomai RTSerial | project=OE 5.0 }}
Given the RTDM serial port driver exists and is loaded for the target on hand, it will provide device nodes at <code>/dev/rtdm/rtserX</code> where X is replaced by the number of each port.
The device nodes are then accessed to configured and communicate the underlying serial ports. The following subsections will outline loading the driver, configuring the port, and performing basic serial transactions.

=== Loading the driver ===
Typically there will be a Linux kernel driver associated with the serial port by default. If the desired device is associated with a Linux driver the driver must be unloaded or the device must be unbound from the driver. Below are examples of loading the RTDM driver for some supported targets.

==== x86 16550A ====

==== iMX6 rt_imx_uart ====
<syntaxhighlight lang="console">
root@somimx6-xenomai:~# echo 2020000.serial > /sys/bus/platform/drivers/imx-uart/unbind
root@somimx6-xenomai:~# echo 21e8000.serial > /sys/bus/platform/drivers/imx-uart/unbind
root@somimx6-xenomai:~# modprobe xeno_imx_uart
root@somimx6-xenomai:~# dmesg | tail
.
.
[ 462.425158] console [ttymxc1] disabled
[ 528.025034] rtser0 on IMX UART0: membase=0xc0c10000 irq=58 uartclk=80000000
[ 528.025700] rtser1 on IMX UART1: membase=0xc0c18000 irq=59 uartclk=80000000
</syntaxhighlight>

==== AT91 atmel_rt_serial ====
<syntaxhighlight lang="console">
COMA
root@som9x25:~# echo f8040000.serial > /sys/bus/platform/drivers/atmel_usart/unbind
COMD
root@som9x25:~# echo f8024000.serial > /sys/bus/platform/drivers/atmel_usart/unbind
root@som9x25:~# modprobe atmel_rt_serial
rtser0 on ATMEL UART-1: membase=0xc8dd0000 irq=29 uartclk=133333333
rtser1 on ATMEL UART-1: membase=0xc8dd2000 irq=30 uartclk=133333333
</syntaxhighlight>

=== Configuring the serial port ===
<syntaxhighlight lang="c">
static const struct rtser_config my_config = {
.config_mask = 0xFFFF,
.baud_rate = 115200,
.parity = RTSER_DEF_PARITY,
.data_bits = RTSER_DEF_BITS,
.stop_bits = RTSER_DEF_STOPB,
.handshake = RTSER_DEF_HAND,
.fifo_depth = RTSER_DEF_FIFO_DEPTH,
.rx_timeout = RTSER_DEF_TIMEOUT,
.tx_timeout = RTSER_DEF_TIMEOUT,
.event_timeout = 1000000000, /* 1 s */
.timestamp_history = RTSER_RX_TIMESTAMP_HISTORY,
.event_mask = RTSER_EVENT_RXPEND,
};
...
int fd;
int err;
...
fd = open("/dev/rtdm/rtser0", 0);

if (fd < 0) {
printf("open error %s\n", strerror(errno));
return -errno;
}
...
err = ioctl(fd, RTSER_RTIOC_SET_CONFIG, &my_config);
if (err) {
printf("ioctl error %s\n", strerror(errno));
goto error;
}
...
</syntaxhighlight>
=== Performing serial transactions ===
Performing serial transactions is as simple as reading and write to the rtser file descriptor.

Sending the contents of a buffer over the serial port:
<syntaxhighlight lang="c">
ret = write(fd, buffer, sizeof(buffer));
</syntaxhighlight>

Receiving serial port input data into buffer:
<syntaxhighlight lang="c">
ret = read(fd, buffer, sizeof(buffer));
</syntaxhighlight>

When reading from the serial it is useful to wait for an event to occur before reading:
<syntaxhighlight lang="c">
err = ioctl(read_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
if (err) {
printf("ioctl error on RTSER_RTIOC_WAIT_EVENT %s\n",
strerror(errno));
}
</syntaxhighlight>




{{:Templateimpl:examples | initials=MW | title=Xenomai RTSerial | desc=Xenomai RTSerial | project=OE 5.0 }}
Xenomai provides an example called cross-link which provides an easy way to test serial ports. Essentially the demo sends data from one serial port and receives it on another. To run the demo make sure the RTDM driver is loaded and connect the first two ports via a NULL modem cable.
<syntaxhighlight lang="console">
root@somimx6-xenomai:~# /usr/demo/cross-link
main : write-file opened
main : write-config written
main : read-file openedmain : read-config written
main : write-task createdmain : read-task created
main : starting write-task
main : starting read-task
Nr | write->irq | irq->read | write->read |
-----------------------------------------------------------
0 |18446744041591572624 | 32118717325 | 738333
1 |18446744041591563290 | 32118715326 | 727000
2 |18446744041591563957 | 32118716326 | 728667
3 |18446744041591561291 | 32118714658 | 724333
4 |18446744041591562624 | 32118715992 | 727000
5 |18446744041591560290 | 32118715326 | 724000
.
.
</syntaxhighlight>

== External Links ==
* https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__rtdm__serial.html
* https://xenomai.org/documentation/xenomai-3/html/xeno3prm/rtdm_2uapi_2serial_8h.html
* https://xenomai.org/documentation/xenomai-3/html/xeno3prm/cross-link_8c-example.html

OE 50 How To

2017-12-19T23:43:58Z

Mgloff:

{{todo| Review (10.06.2015-14:23->MD+)(11.18.2015-13:00->MD+)(11.18.2015-16:30->MD+)|Mike Dean| project=OE 5.0,MD,Review }}
{{DISPLAYTITLE:EMAC OE 5.X How To}}

__NOTOC__




{{:Templateimpl:navpgtable | initials=MD | title=How To Articles | desc=A collection of How To pages for EMAC OE Linux | project=OE 5.0 }}




{{:Templateimpl:navtableentry | title=System Administration }}

{{:Templateimpl:Navti | [[ Network_Configuration | Configure Networking ]] }}
{{:Templateimpl:Navti | [[ User_Account_Configuration | Configure User Accounts ]] }}
{{:Templateimpl:Navti | [[ Setting_the_System_Time | Set the Time ]] }}
{{:Templateimpl:Navti | [[ System_Logging | Configure the System Logger ]] }}

{{:Templateimpl:Navti | [[ Installing_LILO | Install LILO ]] }}
{{:Templateimpl:Navti | [[ U-Boot_Overview | Work with U-Boot ]] }}

{{:Templateimpl:Navti | [[ Mounting_a_Flash_Filesystem | Mount a Filesystem ]] }}
{{:Templateimpl:Navti | [[ Setting_up_an_NFS_File_Server | Set Up an NFS Server ]] }}
{{:Templateimpl:Navti | [[ Installing_TFTP_server | Install a TFTP Server ]] }}

{{:Templateimpl:Navti | [[ Loading_Images_onto_eMMC_Devices | Load Images onto eMMC Devices ]] }}
{{:Templateimpl:navtend}}













{{:Templateimpl:navtableentry | title=Software Development }}

{{:Templateimpl:Navti | [[ Installing_EMAC_OE_5.0_SDK | SDK Install]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_CMake | Create a New Project (CMake command line) ]] }}
{{:Templateimpl:Navti | [[ Advanced_CMake_Features | Utilize Advanced CMake Features ]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_qmake_in_Qt_Creator | Create a New Project (Qt Creator) ]] }}
{{:Templateimpl:Navti | [[ Building_the_Linux_Kernel | Build the Linux Kernel ]] }}
{{:Templateimpl:Navti | [[Getting_Started_With_Qt_Creator | Get Started with Qt Creator]] }}
{{:Templateimpl:Navti | [[ Installing_QtCreator | Install Qt Creator Manually ]] }}

{{:Templateimpl:Navti | [[ System_Logging | Log to <code>syslog</code> ]] }}

{{:Templateimpl:navtend}}







{{:Templateimpl:navtableend}}

MediaWiki:Sidebar

2017-12-19T16:29:50Z

Mgloff:

OE 50 How To

2017-12-19T16:06:26Z

Mgloff:

{{todo| Review (10.06.2015-14:23->MD+)(11.18.2015-13:00->MD+)(11.18.2015-16:30->MD+)|Mike Dean| project=OE 5.0,MD,Review }}
{{DISPLAYTITLE:EMAC OE 5.X How To}}

__NOTOC__




{{:Templateimpl:navpgtable | initials=MD | title=How To Articles | desc=A collection of How To pages for EMAC OE Linux | project=OE 5.0 }}




{{:Templateimpl:navtableentry | title=System Administration }}

{{:Templateimpl:Navti | [[ Network_Configuration | Configure Networking ]] }}
{{:Templateimpl:Navti | [[ User_Account_Configuration | Configure User Accounts ]] }}
{{:Templateimpl:Navti | [[ Setting_the_System_Time | Set the Time ]] }}
{{:Templateimpl:Navti | [[ System_Logging | Configure the System Logger ]] }}

{{:Templateimpl:Navti | [[ Installing_LILO | Install LILO ]] }}
{{:Templateimpl:Navti | [[ U-Boot_Overview | Work with U-Boot ]] }}

{{:Templateimpl:Navti | [[ Mounting_a_Flash_Filesystem | Mount a Filesystem ]] }}
{{:Templateimpl:Navti | [[ Setting_up_an_NFS_File_Server | Set Up an NFS Server ]] }}
{{:Templateimpl:Navti | [[ Installing_TFTP_server | Install a TFTP Server ]] }}

{{:Templateimpl:Navti | [[ Loading_Images_onto_eMMC_Devices | Load Images onto eMMC Devices ]] }}
{{:Templateimpl:navtend}}













{{:Templateimpl:navtableentry | title=Software Development }}

{{:Templateimpl:Navti | [[Install the_EMAC_OE_5.0_SDK | SDK Install]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_CMake | Create a New Project (CMake command line) ]] }}
{{:Templateimpl:Navti | [[ Advanced_CMake_Features | Utilize Advanced CMake Features ]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_qmake_in_Qt_Creator | Create a New Project (Qt Creator) ]] }}
{{:Templateimpl:Navti | [[ Building_the_Linux_Kernel | Build the Linux Kernel ]] }}
{{:Templateimpl:Navti | [[Getting_Started_With_Qt_Creator | Get Started with Qt Creator]] }}
{{:Templateimpl:Navti | [[ Installing_QtCreator | Install Qt Creator Manually ]] }}

{{:Templateimpl:Navti | [[ System_Logging | Log to <code>syslog</code> ]] }}

{{:Templateimpl:navtend}}







{{:Templateimpl:navtableend}}

OE 50 How To

2017-12-19T16:05:02Z

Mgloff:

{{todo| Review (10.06.2015-14:23->MD+)(11.18.2015-13:00->MD+)(11.18.2015-16:30->MD+)|Mike Dean| project=OE 5.0,MD,Review }}

{{DISPLAYTITLE:EMAC OE 5.X How To}}



__NOTOC__




{{:Templateimpl:navpgtable | initials=MD | title=How To Articles | desc=A collection of How To pages for EMAC OE Linux | project=OE 5.0 }}





{{:Templateimpl:navtableentry | title=System Administration }}

{{:Templateimpl:Navti | [[ Network_Configuration | Configure Networking ]] }}
{{:Templateimpl:Navti | [[ User_Account_Configuration | Configure User Accounts ]] }}
{{:Templateimpl:Navti | [[ Setting_the_System_Time | Set the Time ]] }}
{{:Templateimpl:Navti | [[ System_Logging | Configure the System Logger ]] }}

{{:Templateimpl:Navti | [[ Installing_LILO | Install LILO ]] }}
{{:Templateimpl:Navti | [[ U-Boot_Overview | Work with U-Boot ]] }}

{{:Templateimpl:Navti | [[ Mounting_a_Flash_Filesystem | Mount a Filesystem ]] }}
{{:Templateimpl:Navti | [[ Setting_up_an_NFS_File_Server | Set Up an NFS Server ]] }}
{{:Templateimpl:Navti | [[ Installing_TFTP_server | Install a TFTP Server ]] }}

{{:Templateimpl:Navti | [[ Loading_Images_onto_eMMC_Devices | Load Images onto eMMC Devices ]] }}
{{:Templateimpl:navtend}}













{{:Templateimpl:navtableentry | title=Software Development }}

{{:Templateimpl:Navti | [[Install the_EMAC_OE_5.0_SDK | SDK Install]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_CMake | Create a New Project (CMake command line) ]] }}
{{:Templateimpl:Navti | [[ Advanced_CMake_Features | Utilize Advanced CMake Features ]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_qmake_in_Qt_Creator | Create a New Project (Qt Creator) ]] }}
{{:Templateimpl:Navti | [[ Building_the_Linux_Kernel | Build the Linux Kernel ]] }}
{{:Templateimpl:Navti | [[Getting_Started_With_Qt_Creator | Get Started with Qt Creator]] }}
{{:Templateimpl:Navti | [[ Installing_QtCreator | Install Qt Creator Manually ]] }}

{{:Templateimpl:Navti | [[ System_Logging | Log to <code>syslog</code> ]] }}

{{:Templateimpl:navtend}}







{{:Templateimpl:navtableend}}

OE 50 How To

2017-12-19T15:39:32Z

Mgloff:

{{todo| Review (10.06.2015-14:23->MD+)(11.18.2015-13:00->MD+)(11.18.2015-16:30->MD+)|Mike Dean| project=OE 5.0,MD,Review }}



__NOTOC__




{{:Templateimpl:navpgtable | initials=MD | title=How To Articles | desc=A collection of How To pages for EMAC OE Linux | project=OE 5.0 }}





{{:Templateimpl:navtableentry | title=System Administration }}

{{:Templateimpl:Navti | [[ Network_Configuration | Configure Networking ]] }}
{{:Templateimpl:Navti | [[ User_Account_Configuration | Configure User Accounts ]] }}
{{:Templateimpl:Navti | [[ Setting_the_System_Time | Set the Time ]] }}
{{:Templateimpl:Navti | [[ System_Logging | Configure the System Logger ]] }}

{{:Templateimpl:Navti | [[ Installing_LILO | Install LILO ]] }}
{{:Templateimpl:Navti | [[ U-Boot_Overview | Work with U-Boot ]] }}

{{:Templateimpl:Navti | [[ Mounting_a_Flash_Filesystem | Mount a Filesystem ]] }}
{{:Templateimpl:Navti | [[ Setting_up_an_NFS_File_Server | Set Up an NFS Server ]] }}
{{:Templateimpl:Navti | [[ Installing_TFTP_server | Install a TFTP Server ]] }}

{{:Templateimpl:Navti | [[ Loading_Images_onto_eMMC_Devices | Load Images onto eMMC Devices ]] }}
{{:Templateimpl:navtend}}













{{:Templateimpl:navtableentry | title=Software Development }}

{{:Templateimpl:Navti | [[Install the_EMAC_OE_5.0_SDK | SDK Install]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_CMake | Create a New Project (CMake command line) ]] }}
{{:Templateimpl:Navti | [[ Advanced_CMake_Features | Utilize Advanced CMake Features ]] }}
{{:Templateimpl:Navti | [[ Creating_a_New_EMAC_OE_SDK_Project_with_qmake_in_Qt_Creator | Create a New Project (Qt Creator) ]] }}
{{:Templateimpl:Navti | [[ Building_the_Linux_Kernel | Build the Linux Kernel ]] }}
{{:Templateimpl:Navti | [[Getting_Started_With_Qt_Creator | Get Started with Qt Creator]] }}
{{:Templateimpl:Navti | [[ Installing_QtCreator | Install Qt Creator Manually ]] }}

{{:Templateimpl:Navti | [[ System_Logging | Log to <code>syslog</code> ]] }}

{{:Templateimpl:navtend}}







{{:Templateimpl:navtableend}}

Building the Linux Kernel

2017-08-29T15:24:22Z

Mgloff:

{{#seo:
|title=Building the Linux Kernel
|titlemode=append
|keywords=Building Linux Kernel,Configuring Kernel,Loading Kernel Modules
|description=Process of configuring and compiling the Linux kernel using the EMAC kernel build script.
}}
This page covers the process of configuring and compiling the Linux kernel using the EMAC kernel build script. This process assumes that you have already acquired the following software:

# EMAC Software Development Kit [[ Installing_EMAC_OE_4.0_SDK | OE 4 ]] or [[Installing_EMAC_OE_5.0_SDK | OE 5 ]]
# Linux kernel source for target hardware (provided via EMAC public [http://git.emacinc.com/ GIT server] )
# [ftp://ftp.emacinc.com/EMAC_Linux/SDK/kernel-build-cross.tar.gz Kernel build script]

The example below will assume that a kernel image for the SoM-9x25 module will be created, although the instructions apply to other hardware as well assuming that the correct SDK, kernel tree, and build script is used.

==Setup==

The steps below assume that the <code>kernel-build-cross.sh</code> script is
located in the same directory as the kernel tree. Be sure to modify the <code>environment.cfg.sh</code> script for the correct
architecture and EMAC OE version.

==Configuring the Kernel==

The first step for building the kernel is to configure it as desired. It is recommended to start with the kernel configuration file used by EMAC to build the kernel for the target device. Starting with EMAC OE 5, the kernel configuration can be
obtained on a running board from /proc/config.gz. Please contact [http://www.emacinc.com/support EMAC support]
for earlier EMAC OE versions.
 
The following are steps to configure the kernel:
<cl>
1. Copy the default configuration file to the same directory as the kernel source tree and kernel-build-cross.sh and rename it defconfig.

* The kernel-build-cross script accepts the SOURCE_TREE as the first argument and either config or build as the second argument. Optionally, a third argument, BUILD_SUFFIX may be supplied as a suffix to add to the build directory. BUILD_SUFFIX is commonly used to add a date tag or machine name to a build.

{{cli | username=developer | hostname=ldc |./kernel-build-cross.sh linux-at91 config som9x25}}

* The kernel menu-driven configuration utility will be displayed. Features can be selected/deselected to be built into the kernel. Some features can be built as a loadable module, denoted by < >, and not built directly into the kernel.
{{ warning | Disabling or modularizing some kernel features may prevent the kernel from starting correctly or at all. }}

Use the space bar to select an option or the 'm' key to configure the selected option as a module. Select <code>Exit</code> to close the kernel configuration menu and save the configuration to the newly created build directory. When the same build-suffix is used for subsequent builds, this configuration will be used.
</cl>

==Building the Kernel==

<cl>
1. Run the kernel-build-cross script again with the build option, this time using the same build-suffix used in the configuration step.

{{cli | username=developer | hostname=ldc |./kernel-build-cross.sh linux-at91 build som9x25}}

* The kernel will begin compiling now. This will take several minutes to complete depending on the kernel configuration and the speed of the development machine. Only move on to the next step if the build completes with no errors.

* The new kernel image will be in the <code>build-3.10.0-som9x25/Install/boot</code> directory. For the 3.10 and later device tree enabled ARM kernels, the image name will be a zImage. Also, the desired device tree blob (*.dtb) needs to be appended to the kernel. For earlier versions of the kernel, a uImage will be generated that can be loaded directly from U-Boot. X86 boards use a bzImage.

{{clo}}
{{clio | username=developer | hostname=ldc |cd build-3.10.0-som9x25/Install/boot}}
{{clio | username=developer | hostname=ldc |cat zImage-3.10.0 som-9x25-150es.dtb > zImage-boot}}
{{clos}}

This is the image that will get loaded onto the board and executed by the bootloader. To load the new kernel onto the target machine, see the [[Loading Linux Kernels Onto a Board]] page.

The build script will also create an archive of all of the modules created during the build process and place it in the <code>build-3.10.0-som9x25/Install/</code> directory. The archive will be called <code>modules.tar.gz</code>.
</cl>

==Loading Kernel Modules==

If the kernel is recompiled without changing the configuration or source code for any modules, it is not necessary to reload the modules archive. Alternatively, if a module was modified or added, it is only necessary to reload the modules archive.
To reload the modules:
<cl>
1. Copy the archive to the root of the filesystem of the target machine

{{cli | username=developer | hostname=ldc |scp build-3.10.0-som9x25/Install/modules.tar.gz root@1IP_ADDRESS:/ }}

* Log onto the target machine

{{cli | username=developer | hostname=ldc |ssh root@IP_ADDRESS}}

* Extract the kernel modules archive and force the kernel to reload the modules. Make sure that the root flash is mounted read/write before extracting.

{{clo}}
{{clio |cd /}}
{{clio |tar xzvf modules.tar.gz}}
{{clio |depmod -a}}
{{clio |reboot}}
{{clos}}
</cl>

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to build the linux kernel. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

Building the Linux Kernel

2017-08-25T20:53:54Z

Mgloff:

{{#seo:
|title=Building the Linux Kernel
|titlemode=append
|keywords=Building Linux Kernel,Configuring Kernel,Loading Kernel Modules
|description=Process of configuring and compiling the Linux kernel using the EMAC kernel build script.
}}
This page covers the process of configuring and compiling the Linux kernel using the EMAC kernel build script. This process assumes that you have already acquired the following software:

# EMAC Software Development Kit [[ Installing_EMAC_OE_4.0_SDK | OE 4 ]] or [[Installing_EMAC_OE_5.0_SDK | OE 5 ]]
# Linux kernel source for target hardware (provided via EMAC public [http://git.emacinc.com/ GIT server] )
# [ftp://ftp.emacinc.com/EMAC_Linux/SDK/kernel-build-cross.tar.gz Kernel build script]

The example below will assume that a kernel image for the SoM-9x25 module will be created, although the instructions apply to other hardware as well assuming that the correct SDK, kernel tree, and build script is used.

==Setup==

The steps below assume that the <code>kernel-build-cross.sh</code> script is
located in the same directory as the kernel tree. Be sure to modify the <code>environment.cfg.sh</code> script for the correct
architecture and EMAC OE version.

==Configuring the Kernel==

The first step for building the kernel is to configure it as desired. It is recommended to start with the kernel configuration file used by EMAC to build the kernel for the target device. Starting with EMAC OE 5, the kernel configuration can be
obtained on a running board from /proc/config.gz. Please contact [http://www.emacinc.com/support EMAC support]
for earlier EMAC OE versions.
 
The following are steps to configure the kernel:
<cl>
1. Copy the default configuration file to the same directory as the kernel source tree and kernel-build-cross.sh and rename it defconfig.

* The kernel-build-cross script accepts the SOURCE_TREE as the first argument and either config or build as the second argument. Optionally, a third argument, BUILD_SUFFIX may be supplied as a suffix to add to the build directory. BUILD_SUFFIX is commonly used to add a date tag or machine name to a build.

{{cli | username=developer | hostname=ldc |./kernel-build-cross.sh linux-at91 config som9x25}}

* The kernel menu-driven configuration utility will be displayed. Features can be selected/deselected to be built into the kernel. Some features can be built as a loadable module, denoted by < >, and not built directly into the kernel.
{{ warning | Disabling or modularizing some kernel features may prevent the kernel from starting correctly or at all. }}

Use the space bar to select an option or the 'm' key to configure the selected option as a module. Select <code>Exit</code> to close the kernel configuration menu and save the configuration to the newly created build directory. When the same build-suffix is used for subsequent builds, this configuration will be used.
</cl>

==Building the Kernel==

<cl>
1. Run the kernel-build-cross script again with the build option, this time using the same build-suffix used in the configuration step.

{{cli | username=developer | hostname=ldc |./kernel-build-cross.sh linux-at91 build som9x25}}

* The kernel will begin compiling now. This will take several minutes to complete depending on the kernel configuration and the speed of the development machine. Only move on to the next step if the build completes with no errors.

* The new kernel image will be in the <code>build-3.10.0-som9x25/Install/boot</code> directory called zImage. For the 3.10 and later device tree enabled kernels, the desired device tree blob needs to be appended to the kernel.

{{clo}}
{{clio | username=developer | hostname=ldc |cd build-3.10.0-som9x25/Install/boot}}
{{clio | username=developer | hostname=ldc |cat zImage-3.10.0 som-9x25-150es.dtb > zImage-boot}}
{{clos}}

This is the image that will get loaded onto the board and executed by the bootloader. To load the new kernel onto the target machine, see the [[Loading Linux Kernels Onto a Board]] page.

The build script will also create an archive of all of the modules created during the build process and place it in the <code>build-3.10.0-som9x25/Install/</code> directory. The archive will be called <code>modules.tar.gz</code>.
</cl>

==Loading Kernel Modules==

If the kernel is recompiled without changing the configuration or source code for any modules, it is not necessary to reload the modules archive. Alternatively, if a module was modified or added, it is only necessary to reload the modules archive.
To reload the modules:
<cl>
1. Copy the archive to the root of the filesystem of the target machine

{{cli | username=developer | hostname=ldc |scp build-3.10.0-som9x25/Install/modules.tar.gz root@1IP_ADDRESS:/ }}

* Log onto the target machine

{{cli | username=developer | hostname=ldc |ssh root@IP_ADDRESS}}

* Extract the kernel modules archive and force the kernel to reload the modules. Make sure that the root flash is mounted read/write before extracting.

{{clo}}
{{clio |cd /}}
{{clio |tar xzvf modules.tar.gz}}
{{clio |depmod -a}}
{{clio |reboot}}
{{clos}}
</cl>

{{:Templateimpl:moreinfo | initials=MG | title=System Logging | desc=The page describes how to build the linux kernel. | project=OE 5.0 }}
* [[Loading_Linux_Kernels_Onto_a_Board | Loading Linux Kernels Onto a Board]]

Loading Images onto eMMC Devices

2017-08-08T19:39:19Z

Mgloff:

{{todo|SEOKWREV (12.31.13-13:15->MD-);(12.31.13-14:50->MW+);(12.31.13-18:10->MD+);(12.31.13-18:45->MG+);(03.06.14-15:35->BS-);(04.11.14-15:55->BS+);(05.01.15-12:12->MG+);(11.05.15-17:50->MD+)|Michael Welling|project=oe 4,oe 5,mw,md,mg,bs,SEOKWREV}}

{{#seo:
|title=Loading Images onto eMMC Devices
|titlemode=append
|keywords=eMMC,EXT3 Partition,FAT32 Partition,Root File System
|description=Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.
}}
== Background ==
Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.

U-Boot does not support writing to file systems in eMMC. To overcome this issue, the embedded target needs to boot into an alternate media such as a network file system or USB flash drive. Once the board has booted into Linux, the eMMC can be partitioned and formatted, and the root file system can be extracted. The SoM-3517M requires a special FAT formatted partition that contains the bootloader and Linux kernel images. This article explains the general process of writing the eMMC from Linux as well as some specifics related to programming the SoM-3517M, SoM-9X25, SoM-A5D35/6, SoM-3354 and IPAC-9X25.

{{note | The procedures below require that you have a TFTP and NFS server setup on a host computer. }}

* Instructions on setting up a TFTP server: [[Installing TFTP server]]
* Installation of an NFS Server with Linux: [[Setting up an NFS File Server]]
* Instruction for booting into NFS with U-Boot: [[Booting with an NFS Root Filesystem]]
* More information about MMC: http://en.wikipedia.org/wiki/MultiMediaCard

== Creating partitions and formatting eMMC ==

Once the Linux command prompt is reached, Linux utilities can be used to create and format partitions on the eMMC. By partitioning the eMMC, the partitions can be accessed individually and formatted differently as required. The <code>fdisk</code> utility can be used to create these partitions on the eMMC.

For example here is the procedure for creating a 128 MB primary partition:

{{clop}}
{{cliop | hostname=emac-oe |fdisk /dev/mmcblk0}}<nowiki>
The number of cylinders for this disk is set to 57024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-57024, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-57024, default 57024): +128M

Command (m for help): p

Disk /dev/mmcblk0: 1868 MB, 1868562432 bytes
4 heads, 16 sectors/track, 57024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 3907 125016 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table
[ 566.062896] mmcblk0: p1
</nowiki>
{{cliop | hostname=emac-oe|}}
{{closp}}

For more information about <code>fdisk</code>, see:
http://tldp.org/HOWTO/Partition/fdisk_partitioning.html

After creating the partitions, they can formatted with the various <code>mkfs</code> utilities. The formatting used is dependent on how the partition is to be accessed. For eMMC root filesystems EMAC currently uses EXT4 (http://en.wikipedia.org/wiki/Ext3). Other formatting options are available (EXT2, EXT3, etc) and can be used. It should be noted that the kernel must be configured to support the chosen filesystem and the bootargs need to specify the correct type.

{{note | For additional information on configuring and compiling the Linux kernel see the following page: [[Building the Linux Kernel]] }}

As described above, the <code>bootargs</code> is used for signalling to the Linux kernel the location of the root filesystem partition, and its formatting. The <code>root</code> parameter is used to specify the partition to use while the <code>rootfstype</code> parameter is used to specify the formatting of the partition.

{{note | For more information about the <code>bootargs</code> variable see this page: [[U-Boot Overview]] }}

Partitions accessed by processor boot ROM or U-Boot typically need to be formatted with FAT32 formatting. The SoM-3517M, for instance, requires a FAT32 formatted partition for the bootloader and kernel in order to boot properly from eMMC. For more specifics about the SoM-3517M, see the quick reference section below.

===Formatting a partition with EXT4===

{{clop}}
{{cliop | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}<nowiki>
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
31360 inodes, 125016 blocks
6250 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
16 block groups
8192 blocks per group, 8192 fragments per group
1960 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
</nowiki>
{{cliop| hostname=emac-oe |}}
{{closp}}

===Formatting a partition with FAT32===

{{clop}}
{{cliop | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
mkdosfs 2.11 (12 Mar 2005)
{{cliop | hostname=emac-oe |}}
{{closp}}

== Extracting filesystems to eMMC ==
After formatting a partition correctly, the partition can be mounted and files can be loaded to the eMMC.

For example, here is the procedure for writing a root filesystem to the first partition of an eMMC card:

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe |tar xzvf /images/emac-image.rootfs.tar.gz}}
<nowiki> ⋮</nowiki>
{{clos}}

In the above example the <code>/mnt/card</code> directory is called the mount point. The <code>mkdir -p</code> command creates the directory if it does not already exist. The <code>mount</code> command attaches the specified partition to the directory. Any files written to the mounted directory will go to the partition on the eMMC. After the mount is complete, files can be extracted as shown using the <code>tar</code> command.

It should be noted that the <code>/etc/fstab</code> file can be used to specify mount points for partitions upon boot. See http://en.wikipedia.org/wiki/Fstab for additional information.

== Quick Reference (by Target Type) ==
This section is used to provide specifics for programming eMMC on various targets.

For the partitioning sections, the information in the parenthesis denotes a keyboard input sequence. The (n,p,1,default,+64M) creates a new primary partition. Each input is followed a carriage return and the default is selected by pressing carriage return with no entry. See the expanded example in the above '''Creating partitions and formatting eMMC''' section for an idea of how the interface looks when commands are executed correctly.

=== SoM-3517M ===
==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk -H 255 -S 63 /dev/mmcblk0}}

The partitioning steps are as follows:
# Create 1st partition (n,p,1,default,+64M)
# Create 2nd partition (n,p,2,default,default)
# Change 1st partition type to FAT32 (t,1,c)
# Make 1st partition ACTIVE (a,1)
# Write (w)

==== Formatting the eMMC ====

{{clo}}
{{clio | hostname=emac-oe |mkfs.ext3 /dev/mmcblk0p2}}
{{clio | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
{{clos}}

The first command formats the second partition as ext3. The <code>mkfs.ext3</code> command can take further configuration parameters. See the <code>mkfs.ext3</code> man page for more information.

The second command formats the first partition as FAT32 for use with the AM3517's boot ROM. This is a requirement to boot from the eMMC.

==== Adding Kernel and Bootloader ====

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /images}}
{{clio | hostname=emac-oe | pwd=images |cp MLO uImage u-boot.bin /mnt/card/}}
{{clio | hostname=emac-oe | pwd=images |sync}}
{{clio | hostname=emac-oe | pwd=images |umount /dev/mmcblk0p1}}
{{clos}}

{{ note | The first partition '''must''' be formatted FAT32 and the MLO binary '''must''' be in the first sector for the eMMC boot sequence to work properly. }}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe | pwd=images |mount /dev/mmcblk0p2 /mnt/card}}
{{clio | hostname=emac-oe | pwd=images |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p2}}
{{clos}}

=== SoM-9X25M / IPAC-9X25 / SoM-A5D35/6 / SoM-3354 ===

Unlike the SoM-3517, these SoMs store U-Boot and the Linux kernel in a separate serial flash instead of the eMMC. Typically, two partitions are created. The first partition contains the complete filesystem and is mounted read-only while the second partition contains the /home directory and is mounted read-write.
==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk /dev/mmcblk0}}

{{ note | For the SoM-9x25M revisions 7 and above, the eMMC block device is /dev/sdb }}

The partitioning steps are as follows:

# Create 1st partition (n,p,1,default,+1G)
# Create 2nd partition (n,p,2,default,default)
# Write (w)

==== Formatting the eMMC ====
{{clo}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p2}}
{{clos}}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p1}}
{{clos}}

Loading Images onto eMMC Devices

2017-08-08T19:36:07Z

Mgloff:

{{todo|SEOKWREV (12.31.13-13:15->MD-);(12.31.13-14:50->MW+);(12.31.13-18:10->MD+);(12.31.13-18:45->MG+);(03.06.14-15:35->BS-);(04.11.14-15:55->BS+);(05.01.15-12:12->MG+);(11.05.15-17:50->MD+)|Michael Welling|project=oe 4,oe 5,mw,md,mg,bs,SEOKWREV}}

{{#seo:
|title=Loading Images onto eMMC Devices
|titlemode=append
|keywords=eMMC,EXT3 Partition,FAT32 Partition,Root File System
|description=Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.
}}
== Background ==
Some EMAC products use eMMC in place of NAND flash. eMMC is an embedded MMC compliant memory that takes the form of an integrated circuit instead of a media card.

U-Boot does not support writing to file systems in eMMC. To overcome this issue, the embedded target needs to boot into an alternate media such as a network file system or USB flash drive. Once the board has booted into Linux, the eMMC can be partitioned and formatted, and the root file system can be extracted. The SoM-3517M requires a special FAT formatted partition that contains the bootloader and Linux kernel images. This article explains the general process of writing the eMMC from Linux as well as some specifics related to programming the SoM-3517M, SoM-9X25, SoM-A5D35/6, SoM-3354 and IPAC-9X25.

{{note | The procedures below require that you have a TFTP and NFS server setup on a host computer. }}

* Instructions on setting up a TFTP server: [[Installing TFTP server]]
* Installation of an NFS Server with Linux: [[Setting up an NFS File Server]]
* Instruction for booting into NFS with U-Boot: [[Booting with an NFS Root Filesystem]]
* More information about MMC: http://en.wikipedia.org/wiki/MultiMediaCard

== Creating partitions and formatting eMMC ==

Once the Linux command prompt is reached, Linux utilities can be used to create and format partitions on the eMMC. By partitioning the eMMC, the partitions can be accessed individually and formatted differently as required. The <code>fdisk</code> utility can be used to create these partitions on the eMMC.

For example here is the procedure for creating a 128 MB primary partition:

{{clop}}
{{cliop | hostname=emac-oe |fdisk /dev/mmcblk0}}<nowiki>
The number of cylinders for this disk is set to 57024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-57024, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-57024, default 57024): +128M

Command (m for help): p

Disk /dev/mmcblk0: 1868 MB, 1868562432 bytes
4 heads, 16 sectors/track, 57024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 3907 125016 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table
[ 566.062896] mmcblk0: p1
</nowiki>
{{cliop | hostname=emac-oe|}}
{{closp}}

For more information about <code>fdisk</code>, see:
http://tldp.org/HOWTO/Partition/fdisk_partitioning.html

After creating the partitions, they can formatted with the various <code>mkfs</code> utilities. The formatting used is dependent on how the partition is to be accessed. For eMMC root filesystems EMAC currently uses EXT4 (http://en.wikipedia.org/wiki/Ext3). Other formatting options are available (EXT2, EXT3, etc) and can be used. It should be noted that the kernel must be configured to support the chosen filesystem and the bootargs need to specify the correct type.

{{note | For additional information on configuring and compiling the Linux kernel see the following page: [[Building the Linux Kernel]] }}

As described above, the <code>bootargs</code> is used for signalling to the Linux kernel the location of the root filesystem partition, and its formatting. The <code>root</code> parameter is used to specify the partition to use while the <code>rootfstype</code> parameter is used to specify the formatting of the partition.

{{note | For more information about the <code>bootargs</code> variable see this page: [[U-Boot Overview]] }}

Partitions accessed by processor boot ROM or U-Boot typically need to be formatted with FAT32 formatting. The SoM-3517M, for instance, requires a FAT32 formatted partition for the bootloader and kernel in order to boot properly from eMMC. For more specifics about the SoM-3517M, see the quick reference section below.

===Formatting a partition with EXT4===

{{clop}}
{{cliop | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}<nowiki>
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
31360 inodes, 125016 blocks
6250 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
16 block groups
8192 blocks per group, 8192 fragments per group
1960 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
</nowiki>
{{cliop| hostname=emac-oe |}}
{{closp}}

===Formatting a partition with FAT32===

{{clop}}
{{cliop | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
mkdosfs 2.11 (12 Mar 2005)
{{cliop | hostname=emac-oe |}}
{{closp}}

== Extracting filesystems to eMMC ==
After formatting a partition correctly, the partition can be mounted and files can be loaded to the eMMC.

For example, here is the procedure for writing a root filesystem to the first partition of an eMMC card:

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe |tar xzvf /images/emac-image.rootfs.tar.gz}}
<nowiki> ⋮</nowiki>
{{clos}}

In the above example the <code>/mnt/card</code> directory is called the mount point. The <code>mkdir -p</code> command creates the directory if it does not already exist. The <code>mount</code> command attaches the specified partition to the directory. Any files written to the mounted directory will go to the partition on the eMMC. After the mount is complete, files can be extracted as shown using the <code>tar</code> command.

It should be noted that the <code>/etc/fstab</code> file can be used to specify mount points for partitions upon boot. See http://en.wikipedia.org/wiki/Fstab for additional information.

== Quick Reference (by Target Type) ==
This section is used to provide specifics for programming eMMC on various targets.

For the partitioning sections, the information in the parenthesis denotes a keyboard input sequence. The (n,p,1,default,+64M) creates a new primary partition. Each input is followed a carriage return and the default is selected by pressing carriage return with no entry. See the expanded example in the above '''Creating partitions and formatting eMMC''' section for an idea of how the interface looks when commands are executed correctly.

=== SoM-3517M ===
==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk -H 255 -S 63 /dev/mmcblk0}}

The partitioning steps are as follows:
# Create 1st partition (n,p,1,default,+64M)
# Create 2nd partition (n,p,2,default,default)
# Change 1st partition type to FAT32 (t,1,c)
# Make 1st partition ACTIVE (a,1)
# Write (w)

==== Formatting the eMMC ====

{{clo}}
{{clio | hostname=emac-oe |mkfs.ext3 /dev/mmcblk0p2}}
{{clio | hostname=emac-oe |mkdosfs -F 32 /dev/mmcblk0p1}}
{{clos}}

The first command formats the second partition as ext3. The <code>mkfs.ext3</code> command can take further configuration parameters. See the <code>mkfs.ext3</code> man page for more information.

The second command formats the first partition as FAT32 for use with the AM3517's boot ROM. This is a requirement to boot from the eMMC.

==== Adding Kernel and Bootloader ====

{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /images}}
{{clio | hostname=emac-oe | pwd=images |cp MLO uImage u-boot.bin /mnt/card/}}
{{clio | hostname=emac-oe | pwd=images |sync}}
{{clio | hostname=emac-oe | pwd=images |umount /dev/mmcblk0p1}}
{{clos}}

{{ note | The first partition '''must''' be formatted FAT32 and the MLO binary '''must''' be in the first sector for the eMMC boot sequence to work properly. }}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe | pwd=images |mount /dev/mmcblk0p2 /mnt/card}}
{{clio | hostname=emac-oe | pwd=images |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p2}}
{{clos}}

=== SoM-9X25M / IPAC-9X25 / SoM-A5D35/6 / SoM-3354 ===

Unlike the SoM-3517, these SoMs store U-Boot and the Linux kernel in a separate serial flash instead of the eMMC.
==== Partitioning the eMMC ====

{{cli | hostname=emac-oe |fdisk /dev/mmcblk0}}

{{ note | For the SoM-9x25M revisions 7 and above, the eMMC block device is /dev/sdb }}

The partitioning steps are as follows:

# Create 1st partition (n,p,1,default,+1G)
# Create 2nd partition (n,p,2,default,default)
# Write (w)

==== Formatting the eMMC ====
{{clo}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p1}}
{{clio | hostname=emac-oe |mkfs.ext4 /dev/mmcblk0p2}}
{{clos}}

==== Extracting Root Filesystem ====
{{clo}}
{{clio | hostname=emac-oe |mkdir -p /mnt/card}}
{{clio | hostname=emac-oe |mount /dev/mmcblk0p1 /mnt/card}}
{{clio | hostname=emac-oe |cd /mnt/card}}
{{clio | hostname=emac-oe | pwd=/mnt/card |tar xzvf /emac-image.rootfs.tar.gz}}
{{clio | hostname=emac-oe | pwd=/mnt/card |cd ..}}
{{clio | hostname=emac-oe | pwd=/mnt |sync}}
{{clio | hostname=emac-oe | pwd=/mnt |umount /dev/mmcblk0p1}}
{{clos}}

Getting Started With EMAC Virtual LDC

2017-07-19T16:01:13Z

Mgloff: Created page with "{{todo| NotStarted (03.06.2017-12:18->DS+)|Daniel Sojka| project=OE 5.0,DS,NotStarted }} {{#seo: |title=Getting Started With EMAC Virtual LDC |titlemode=append |keywords= |de..."

{{todo| NotStarted (03.06.2017-12:18->DS+)|Daniel Sojka| project=OE 5.0,DS,NotStarted }}

{{#seo:
|title=Getting Started With EMAC Virtual LDC
|titlemode=append
|keywords=
|description=This page describes how to get started with the EMAC Virtual LDC in VirtualBox}}





This page describes how to get started with the EMAC Virtual LDC in VirtualBox

__TOC__





{{:Templateimpl:bg | initials=DS | title=Getting Started With EMAC Virtual LDC | desc=This page describes how to get started with the EMAC Virtual LDC in VirtualBox | project=OE 5.0 }}
VirtualBox is a general-purpose full virtualizer for x86 hardware, targeted at server, desktop and embedded use. 
For more information, visit the Virtual Box website: https://www.virtualbox.org/wiki/VirtualBox




{{:Templateimpl:geninfo | initials=DS | title=Getting Started With EMAC Virtual LDC | desc=This page describes how to get started with the EMAC Virtual LDC in VirtualBox | project=OE 5.0 }}
Before getting started with the EMAC Virtual LDC, ensure that your computer meets the minimum specifications: 
* Intel Core i3 processor (or equivalent)
* 4GB RAM
* At least 30GB of free storage space




{{:Templateimpl:using | initials=DS | title=Getting Started With EMAC Virtual LDC | desc=This page describes how to get started with the EMAC Virtual LDC in VirtualBox | project=OE 5.0 }}
1. Download and install VirtualBox.
* [https://www.virtualbox.org/wiki/Downloads VirtualBox Download]

2. Download the EMAC Virtual LDC .ova file. (Right click, Save link as)
* [ftp://ftp.emacinc.com/EMAC_Linux/Virtual_LDCs/EMAC_Virtual_LDC.ova EMAC Virtual LDC .ova File]

3. Navigate to the directory you saved the file to, right click it and select "Open with VirtualBox"

4. VirtualBox and an Import Wizard should start. Click "Import".
[[File:Importwizard.png|600px|left|thumb|Figure 1: VirtualBox Import Wizard]]
 

5. Once the file is imported, select the EMAC_Virtual_LDC and click "Start".
[[File:Ldcstart.png|800px|left|thumb|Figure 2: Starting the virtual machine]]

 

6. The virtual machine will boot and arrive at the login screen
* Password: emac_inc 

[[File:Ldclogin.png|800px|left|thumb|Figure 3: Logging into the virtual machine]]
 

7. You are now ready to begin developing. The EMAC SDK and Qt Creator IDE are already installed.
[[File:Ldcdesktop.png|800px|left|thumb|Figure 4: Virtual machine desktop]]

 

{{:Templateimpl:using | initials=DS | title=Further Information | desc=This page describes how to get started with the EMAC Virtual LDC in VirtualBox | project=OE 5.0 }}
Where to go next:
* [http://wiki.emacinc.com/wiki/Getting_Started_with_the_EMAC_OE_SDK Getting Started with the EMAC OE SDK]
* [http://wiki.emacinc.com/wiki/Getting_Started_With_Minicom Getting Started with Minicom]
* [http://wiki.emacinc.com/wiki/Getting_Started_With_Qt_Creator Getting Started with Qt Creator]