wiki.emacinc.com - User contributions [en]

SOM-150

2015-11-18T23:41:23Z

Rossi:

System Logging

2015-11-18T21:48:28Z

Rossi:

{{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.0 uses Busybox's 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.

===Default Syslog Daemon===

The Busybox syslog daemon is used by default.

====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 Busybox syslog daemon is configured, by default, to log to files in the RAMDISK mounted on <code>/var/log/</code>. The files contained in this directory will be capped in size and rotated according to the configuration of the syslog daemon.

The Busybox syslog daemon is configured with the file, <code>/etc/syslog-startup.conf</code>. This file is used for backwards compatibility, because the Busybox syslog daemon recently began reading the <code>/etc/syslog.conf</code> file. The <code>/etc/syslog-startup.conf</code> comes from OE rather than from Busybox.

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=file # 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.

{{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;</nowiki>}}<nowiki>
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>
<br /><br />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. <br /><br />The following parameters are accepted by this function:<br /><br />
:;<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>
<br /><br />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.<br /><br />The following parameters are accepted by this function:<br /><br />
:;<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]].
:;<br /><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.
:;<br /><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>
<br /><br />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>.
<br /><br />
This function takes no arguments.
}}

{{function | name=setlogmask |
<code>'''int setlogmask( int mask )'''</code>
<br /><br />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.
<br /><br />
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>.
<br /><br />
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 }}
* [[Install_the_EMAC_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

2015-11-13T23:08:11Z

Rossi:

{{todo|Buggy (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+)|Michael Welling|project=oe 4,oe 5,mw,md,ky,mg,bs,er,Buggy}}

{{#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. 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}}

{{ warning | All these hard coded addresses don't contribute much to the reader's understanding of what each address is for... especially 0xC0042000, since it's not mentioned elsewhere, and ones that may happen to be the same number for different reasons.}}

== 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> set 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|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it can be transferred to the board and executed as illustrated below:
{{clo}}<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.

{{warning | Needs Conclusion}}

{{warning | Needs "Where to Go Next"}}

Loading Images with U-Boot

2015-11-13T23:02:08Z

Rossi:

{{todo|Buggy (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+)|Michael Welling|project=oe 4,oe 5,mw,md,ky,mg,bs,er,Buggy}}

{{#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. 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}}

{{ warning | All these hard coded addresses don't contribute much to the reader's understanding of what each address is for... especially 0xC0042000, since it's not mentioned elsewhere, and ones that may happen to be the same number for different reasons.}}

== 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> set kernelsize ${filesize};saveenv</nowiki>{{closp}}

Note: the "pri loadaddr" step about 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|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it can be transferred to the board and executed as illustrated below:
{{clo}}<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.

{{warning | Needs Conclusion}}

{{warning | Needs "Where to Go Next"}}

Loading Images with U-Boot

2015-11-13T22:40:28Z

Rossi:

{{todo|Review (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+)|Michael Welling|project=oe 4,oe 5,mw,md,ky,mg,bs,er, Review}}

{{#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 would require an NFS server.

== Configuration ==
In order to load a file using TFTP, U-Boot must be configured to access the local network. Static networking configuration is recommended, although DHCP can be used on some systems. 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}}

{{ warning | Why is static configuration recommended? We use DHCP all the time without issues. DHCP is much easier, so why don't we recommend it instead? Most (all?) corporate networks will already have a DHCP server which functions well. Some are highly locked down (especially many Fortune 1000 networks) and may require IT support to allow unknown MAC addresses onto the network, but this will apply with static configurations as well; a note may be needed about that. }}

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}}

{{ warning | All these hard coded addresses don't contribute much to the reader's understanding of what each address is for... especially 0xC0042000, since it's not mentioned elsewhere, and ones that may happen to be the same number for different reasons.}}

== 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> set kernelsize ${filesize};saveenv</nowiki>{{closp}}

{{warning | The <code>pri loadaddr</code> step isn't needed; it's just there to check to make sure the variable is set, but the reader is not informed of this. The reader should be informed, or it should be removed.}}

== 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|./script_mkimage.sh sl013-aon-30010-flash-script sl013-aon-30010-flash-script.img}}

Once an image file has been created, it can be transferred to the board and executed as illustrated below:
{{clo}}<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.

{{warning | Needs Conclusion}}

{{warning | Needs "Where to Go Next"}}

Configuring LILO

2015-11-13T22:30:32Z

Rossi:

{{todo|Complete (12.16.13-02:25->MD+);(12.16.13-15:15->MD+);(12.17.13-11:45->MW+);(12.17.13-15:25->KY+);(03.06.14-15:40->BS-);(03.17.14-13:10->MD-);(04.11.14-16:50->BS+);(11.13.2015-16:15->MD+)(11.13.2015-16:25->KY+);(11.13.2015-16:30->|Mike Dean|project=oe 4,oe 5,md,Complete,mw,bs,er}}

{{#seo:
|title=Configuring LILO
|titlemode=append
|keywords=LILO,LILO Configuration,LILO config
|description=This page describes the parts of the LILO bootloader configuration file, and provides guidance on how to work with it.
}}
LILO is a bootloader which provides a number of useful features while remaining compact. This document describes the details behind configuring the LILO bootloader.

==Configuring LILO==

As with any software of moderate or better complexity, configuration is required for LILO to function as desired. The configuration created by EMAC and shipped with a system will usually suffice. However, sometimes enough customization is required that the bootloader itself will need to be reconfigured. Even if custom configuration isn't required, some of this information is important for protecting against accidentally overwriting the bootloader on a developer's desktop with a bootloader that was intended for an embedded machine.

This page describes the parts of the LILO bootloader configuration file, and provides guidance on how to work with it. The other LILO pages describe how to install and use the bootloader after it has been configured.

===Sections of the LILO Configuration File===

The LILO configuration file is split into two sections: global and per-image. The global section, as the name implies, specifies options that pertain to LILO itself and to all images specified in the file. The per-image section specifies options that apply to a specific image, some of which may override the global options.

Shown here is the default configuration for most EMAC boards which make use of LILO:

<syntaxhighlight lang=bash>
# This tells the LILO utility where to install LILO. This must be changed if using a desktop
# system to install LILO to a CompactFlash card.
boot=/dev/sda
map=/boot/map

lba32
# This is where the disk is found on the current system. See the wiki for more information.
disk=/dev/sda
# This indicates that the BIOS will see this drive as the first drive.
bios=0x80
read-only
prompt
# This sets the prompt to wait for 2.5 seconds before automatically booting the first image.
# The time is specified in deciseconds.
timeout=25
vga=9
install=text
compact
# This is for lilo serial console (ttyS0,9600,8,n,1):
#serial=0,115200n8

# The following path points to the Linux kernel that LILO should boot.
image=/boot/bzImage
root=/dev/sda1 # This is the root filesystem for the kernel to use.
label=emac-oe
# These are kernel commandline parameters:
append="console=ttyS0,115200 quiet splash=silent"
</syntaxhighlight>

====Global Options====

The LILO configuration file needs the following options, at a minimum, configured for the global settings:

* <code>disk</code> This option specifies the disk to which the LILO bootloader needs to be written. This should always point to the device node currently associated with the disk. For example, when mounted on a desktop, this may be <code>/dev/sdc</code>, which is (usually) the third "SCSI" device connected to the system. The first would be <code>/dev/sda</code>, the second <code>/dev/sdb</code>, etc. Even though the device may not be a SCSI device, it may be mounted via a generic SCSI driver, which is why it can appear as a SCSI device. If it were mounted through the IDE subsystem instead, its device node would appear like <code>/dev/hdc</code> instead.
* <code>map</code> This option specifies the location of the map file to use. Usually, this will be <code>/boot/map</code>.
* <code>lba32</code> This option tells LILO to use 32-bit Logical Block Addresses instead of cylinder/head/sector addresses. This is needed for any disk with more than 1024 cylinders. Since the vast majority of modern drives have more than 1024 cylinders, this option should always be specified.
* <code>boot</code> This option specifies the device which contains the boot sector. As with the <code>disk</code> option, this should always be the device node associated with the disk on the current system. For example, <code>boot=/dev/sdc</code>

'''Additional useful options:'''

* <code>vga</code> For systems which have video, this option specifies the video mode the device should use. The parameter to pass comes from the BSP (Board Support Profile) layer for the board. If unsure what to set here, EMAC can provide assistance with this.
* <code>serial</code> This useful option specifies a serial device to which a console should be attached, as well as the configuration settings for the console. For example, to use the <code>/dev/ttyS0</code> serial device (the default console port on many boards) as a serial console which communicates as 115,200 baud, 8 bits, with no stop bits: <code>serial=0,115200n8</code>
* <code>timeout</code> This specifies the amount of time to wait before timing out and continuing on with the boot process using the configured defaults. This value is specified in deciseconds. For example, to set this value to 4.3 seconds: <code>timeout=43</code>
* <code>read-only</code> This option tells LILO to mount the root filesystem as read-only. This is usually desired, since the Linux kernel will remount the device as writeable (if it needs to) once the boot process has been handed over to it.
* <code>install</code> This option specifies the type of screen which will be seen when the bootloader starts. Normally, this will be set to <code>text</code>, which presents the simple interface shown in the examples on this page. The <code>menu</code> option provides a nicer way to select an image to boot, but is usually not desirable to have on an embedded machine. The <code>bitmap</code> option provides a graphical boot screen which looks very nice on a desktop installation, but is usually only used on an embedded machine when the product calls for showing graphics as early in the boot process as possible; a logo is typically placed here in such a case.

====Per-Image Options====

The following options are needed to configure images to be available to boot with LILO:

* <code>image</code> This option specifies the location of the kernel to boot. Commonly, this will be <code>/boot/bzImage</code> or <code>/boot/bzImage-custom-3.10.2</code>
* <code>root</code> This option specifies the root partition to mount for the image. This is typically <code>/dev/hda1</code> or <code>/dev/sda1</code>
* <code>label</code> This option tells LILO by what name to call the image. For instance, this is usually <code>label=emac-oe</code> for a standard EMAC image, but for a custom product under development, it might be <code>label=custom-image-test-v3</code>

====Working with LILO Configurations====

The above information talks about the common options and how to set them. Additional information can be found by reading through the manual page for <code>lilo.conf</code>. This manpage is available on many sites online.

Actually using these options to create a configuration file is done most easily by copying the EMAC provided LILO configuration file, then modifying the copy. It is a good practice to make sure a bootable flash card is set aside in case of difficulties with getting the modified flash card back into a bootable state.




{{:Templateimpl:conclusion | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
LILO has a straightforward configuration syntax, but the details may not be immediately apparent. This documentation should fill in the missing pieces when you are configuring LILO.




{{:Templateimpl:moreinfo | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[Installing_LILO | Installing LILO]]

{{:Templateimpl:whatnext | initials=MD | title=System Logging | desc=The page describes how to system log. | project=OE 5.0 }}
* [[LILO_Overview | LILO Overview]]

Opkg

2015-11-13T22:25:34Z

Rossi:

{{todo| Completed (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,Completed}}
{{#seo:
|title=OPKG
|titlemode=append
|keywords=opkg,yocto,openembedded
|description=Package Management with OPKG
}}

<span class="pagedesc">
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.
</span>

__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.0 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.
<br /><br />
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.<br />
Collected errors:<br />
 * print_dependents_warning: Package alsa-conf-base is depended upon by packages:<BR>
 * print_dependents_warning: libasound2<br />
 * print_dependents_warning: These might cease to work if package alsa-conf-base is removed.<br />
 * print_dependents_warning: Force removal of this package with --force-depends.<br />
 * print_dependents_warning: Force removal of this package and its dependents<br />
 * print_dependents_warning: with --force-removal-of-dependent-packages.<br />
{{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:
{{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}}
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
{{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]]

{{:Templateimpl:whatnext | initials=MD | title=OPKG | desc=Package Management with OPKG | project=OE 5 }}
* [[Install_the_EMAC_SDK#Install_Using_apt_.28Recommended.29 | Installing EMAC Packages Using Apt]]

OE 5 Software Overview

2015-11-13T20:54:02Z

Rossi:

{{todo| Final Draft (05.20.2015-12:35->BS+);(05.21.2015-15:35->BS+);(05.21.2015-16:48->KY+);(11.13.2015-12:00->MG+);(11.13.2015-14:26->ER+)|Brian Serrano| project=OE 5.0,BS,KY,MD,MG,ER,FinalDraft}}
{{#seo:
|title=Software Overview
|titlemode=append
|keywords=Qt Creator, Open Embedded, Linux U-boot, Xenomai
|description=EMAC products offer a wide variety of software support from both open source and proprietary sources.
}}
{{DISPLAYTITLE:EMAC OE 5.X Software Overview}}




<span style="background:#00FF00;color:#FF0000;font-size:300%"></span>
EMAC products offer a wide variety of software support from both open source and proprietary sources. The hardware core was designed to be software compatible with the given processor reference design, which is supported by Linux.

__TOC__




{{:Templateimpl:geninfo | initials=BS | title=Software Overview | desc=EMAC products offer a wide variety of software support from both open source and proprietary sources. | project=OE 5.0 }}
=== Das U-Boot ===
EMAC's ARM based products are distributed with Das U-Boot installed. U-Boot is an open source/cross-architecture platform independent bootloader. It supports reading and writing to the flash, auto-booting, environmental variables, and TFTP. Das U-boot can be used to upload and run and/or reflash the OS on EMAC Products or to run stand-alone programs without an OS. EMAC Products modules are shipped with a valid MAC address installed in flash in the protected U-boot environmental variable “ethaddr”. At boot time U-Boot automatically stores this address in a register within the MAC, which effectively provides it to any OS loaded after that point.

For more information visit the [[U-Boot_Overview | U-Boot Overview]] page.

=== Embedded Linux ===
EMAC Open Embedded Linux is an open source Linux distribution for use in embedded systems. The distribution is based on the latest [http://www.openembedded.org OpenEmbedded] release and contains everything a user could expect from a standard Linux distribution: powerful networking features, advanced file system support, security, debugging utilities, and countless other features. EMAC can provide a customized Linux build if required.

The basic root file system includes:

* Busybox
* Hotplugging support
* APM utilities for power management
* Openssh SSH server
* lighttpd HTTP server
* EXT4 file system with utilities

For more information visit the [[OE50:Packages| EMAC OE 5.X Release Information]] page.

=== Linux with Xenomai Real Time Extensions ===
Xenomai provides real time extensions to the kernel and can be used to schedule tasks with hard deadlines and μs latencies. The Xenomai build is an additional module that can be added to the standard Linux kernel and is available for one-time inexpensive support/installation fee.

For more information visit the [[Xenomai]] page.

=== Linux Software Packages ===
EMAC provides support for many additional Linux packages such as: PHP, Java, Perl, SNMP, Web browser, etc. As with the Xenomai package, other packages can be added to the standard Linux file system and are available for a one-time inexpensive support/installation fee.

For more information visit the [[EMAC_OE_50_Add-on_Packages |EMAC OE 5.X Add-on Packages]] page.

=== Linux Patches ===
In addition to standard Embedded Linux support, EMAC has released a number of patches and device drivers from the open source community and from internal EMAC engineering into its standard distribution. Along with kernel patches, EMAC provides the binaries for the kernel and root file system.

=== Qt Creator ===
Qt Creator is a cross-platform IDE (Integrated Development Environment) tailored to the needs of Qt developers but works well for headless applications as well. EMAC provides sample code for EMAC Products as projects that can be imported into Qt Creator. Qt Creator supports remote deployment and source debugging.

For more information visit the [http://doc.qt.io/qtcreator/ Qt Creator] page.

EMAC provides a custom version of Qt Creator based on the 3.x or later release. This custom version includes examples and documentation relevant to EMAC customers. EMAC also provides a getting started guide for Qt Creator as a separate document.

For more information on using Qt Creator with the EMAC SDK visit the [[Getting_Started_With_Qt_Creator |Getting Started With Qt Creator]] page.

=== ARM EABI Cross Compiler ===
The popular open source gcc compiler has a stable build for the ARM family. The Embedded Linux kernel and EMAC Qt Creator projects use this compiler for building ARM stand alone, and OS specific binaries. The EMAC OE SDK provides for source level debugging over Ethernet or serial using gdb. The Linux binaries for the ARM EABI cross compiler are available online with the SDK for EMAC Products.

For more information visit the [[Install_the_EMAC_SDK EMAC SDK]] page.

OE 5 Software Overview

2015-11-13T20:50:15Z

Rossi:

{{todo| Final Draft (05.20.2015-12:35->BS+);(05.21.2015-15:35->BS+);(05.21.2015-16:48->KY+);(11.13.2015-12:00->MG+);(11.13.2015-14:26->ER+)|Brian Serrano| project=OE 5.0,BS,KY,MD,MG,ER,Review}}
{{#seo:
|title=Software Overview
|titlemode=append
|keywords=Qt Creator, Open Embedded, Linux U-boot, Xenomai
|description=EMAC products offer a wide variety of software support from both open source and proprietary sources.
}}
{{DISPLAYTITLE:EMAC OE 5.X Software Overview}}




<span style="background:#00FF00;color:#FF0000;font-size:300%"></span>
EMAC products offer a wide variety of software support from both open source and proprietary sources. The hardware core was designed to be software compatible with the given processor reference design, which is supported by Linux.

__TOC__




{{:Templateimpl:geninfo | initials=BS | title=Software Overview | desc=EMAC products offer a wide variety of software support from both open source and proprietary sources. | project=OE 5.0 }}
=== Das U-Boot ===
EMAC's ARM based products are distributed with Das U-Boot installed. U-Boot is an open source/cross-architecture platform independent bootloader. It supports reading and writing to the flash, auto-booting, environmental variables, and TFTP. Das U-boot can be used to upload and run and/or reflash the OS on EMAC Products or to run stand-alone programs without an OS. EMAC Products modules are shipped with a valid MAC address installed in flash in the protected U-boot environmental variable “ethaddr”. At boot time U-Boot automatically stores this address in a register within the MAC, which effectively provides it to any OS loaded after that point.

For more information visit the [[U-Boot_Overview | U-Boot Overview]] page.

=== Embedded Linux ===
EMAC Open Embedded Linux is an open source Linux distribution for use in embedded systems. The distribution is based on the latest [http://www.openembedded.org OpenEmbedded] release and contains everything a user could expect from a standard Linux distribution: powerful networking features, advanced file system support, security, debugging utilities, and countless other features. EMAC can provide a customized Linux build if required.

The basic root file system includes:

* Busybox
* Hotplugging support
* APM utilities for power management
* Openssh SSH server
* lighttpd HTTP server
* EXT4 file system with utilities

For more information visit the [[OE50:Packages| EMAC OE 5.X Release Information]] page.

=== Linux with Xenomai Real Time Extensions ===
Xenomai provides real time extensions to the kernel and can be used to schedule tasks with hard deadlines and μs latencies. The Xenomai build is an additional module that can be added to the standard Linux kernel and is available for one-time inexpensive support/installation fee.

For more information visit the [[Xenomai]] page.

=== Linux Software Packages ===
EMAC provides support for many additional Linux packages such as: PHP, Java, Perl, SNMP, Web browser, etc. As with the Xenomai package, other packages can be added to the standard Linux file system and are available for a one-time inexpensive support/installation fee.

For more information visit the [[EMAC_OE_50_Add-on_Packages |EMAC OE 5.X Add-on Packages]] page.

=== Linux Patches ===
In addition to standard Embedded Linux support, EMAC has released a number of patches and device drivers from the open source community and from internal EMAC engineering into its standard distribution. Along with kernel patches, EMAC provides the binaries for the kernel and root file system.

=== Qt Creator ===
Qt Creator is a cross-platform IDE (Integrated Development Environment) tailored to the needs of Qt developers but works well for headless applications as well. EMAC provides sample code for EMAC Products as projects that can be imported into Qt Creator. Qt Creator supports remote deployment and source debugging.

For more information visit the [http://doc.qt.io/qtcreator/ Qt Creator] page.

EMAC provides a custom version of Qt Creator based on the 3.x or later release. This custom version includes examples and documentation relevant to EMAC customers. EMAC also provides a getting started guide for Qt Creator as a separate document.

For more information on using Qt Creator with the EMAC SDK visit the [[Getting_Started_With_Qt_Creator |Getting Started With Qt Creator]] page.

=== ARM EABI Cross Compiler ===
The popular open source gcc compiler has a stable build for the ARM family. The Embedded Linux kernel and EMAC Qt Creator projects use this compiler for building ARM stand alone, and OS specific binaries. The EMAC OE SDK provides for source level debugging over Ethernet or serial using gdb. The Linux binaries for the ARM EABI cross compiler are available online with the SDK for EMAC Products.

For more information visit the [[Install_the_EMAC_SDK EMAC SDK]] page.

ARM SBC

2015-10-29T21:56:54Z

Rossi:

SOM-IMX6

2015-10-29T21:53:38Z

Rossi:

SoM-A5D36 Getting Started

2015-10-29T21:33:30Z

Rossi: Created page with "= SOM-A5D36 Page Under Construction ="

= SOM-A5D36 Page Under Construction =

SoM-3354 Getting Started

2015-10-29T21:33:04Z

Rossi: Created page with "= SOM-3354 Page Under Construction ="

= SOM-3354 Page Under Construction =

SOM-9M10

2015-10-29T21:32:27Z

Rossi:

<p style="width:100%;font-size:xx-large;text-align:center;font-weight:bold;line-height:125%;"> SOM-9M10 ARM 200-Pin SoM </p>




<p style="width:100%;font-size:small;text-align:left;line-height:100%;"/p>
The SoM-9M10 is a System-on-Module (SoM) based on the AT91SAM9M10 processor. This Fanless ARM9, 400 MHz SoM has an Ethernet PHY included along with 4 serial ports. It utilizes up to 256MB of external DDR2 / SDRAM, 1GB of NAND Flash and includes an MMU which allows it to run Linux Operating System. A SoM is a small embedded module that contains the core of a microprocessor system.

<table style="width:100%; text-align: center">
<tr>
<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">SOM-9M10 Website Link</div>
<ul style="text-align: left;">
<li>[http://www.emacinc.com/products/system_on_module/SoM-9M10M SoM-9M10 Web Link]</li>
</ul>
</td>




<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">SoM-9M10 Downloads</div>
<ul style="text-align: left;">
<li>[ftp://ftp.emacinc.com/SoM/SoM-9G45-9M10/Manual/SoM-9G45-9M10_User_Manual.pdf User Manual]</li>
<li>[ftp://ftp.emacinc.com/SoM/SoM-9G45-9M10/DataSheets/ Datasheet]</li>
</ul>
</td>
</tr>




<tr>
<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">SoM-9M10 Carrier Boards</div>
<ul style="text-align: left;">
<li><b> SoM-200ES </b><ul>
<li>[http://www.emacinc.com/products/system_on_module/SoM-200ES SoM-200ES Web Link]</li>
<li>[ftp://ftp.emacinc.com/SoM/SoM-200ES/ SoM-200ES Downloads]</li>
</ul></li>
<li><b> SoM-210ES </b><ul>
<li>[http://www.emacinc.com/products/system_on_module/SoM-210ES SoM-210ES Web Link]</li>
<li>[ftp://ftp.emacinc.com/SoM/SoM-210ES/ SoM-210ES Downloads]</li>
</ul></li>
<li><b> SoM-212ES </b><ul>
<li>[http://www.emacinc.com/products/system_on_module/SoM-212ES SoM-212ES Web Link]</li>
<li>[ftp://ftp.emacinc.com/SoM/SoM-212ES/ SoM-212ES Downloads]</li>
</ul></li>
<li><b> SoM-250ES </b><ul>
<li>[http://www.emacinc.com/products/system_on_module/SoM-250ES SoM-250ES Web Link]</li>
<li>[ftp://ftp.emacinc.com/SoM/SoM-250ES/ SoM-250ES Downloads]</li>
</ul></li>
</ul>
</td>




<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">SoM-9M10 Wiki Links</div>
<ul style="text-align: left;">
<li>[[SoM-9G45_Getting_Started | SoM-9M10 Getting Started]]</li>
</ul>
</td>
</tr>
</table>

























<!--

SoM-9G45 Getting Started

2015-10-29T21:31:20Z

Rossi:

= SOM-9G45/9M10 Page Under Construction =

SoM-9G45 Getting Started

2015-10-29T21:30:18Z

Rossi: Created page with "= SOM-9G45 Page Under Construction ="

= SOM-9G45 Page Under Construction =

SoM-A5D35 Getting Started

2015-10-29T21:29:16Z

Rossi: Created page with "= SOM-A5D35 Page Under Construction ="

= SOM-A5D35 Page Under Construction =

SoM-9x25 Getting Started

2015-10-29T21:28:37Z

Rossi: Created page with "= SOM-9x25 Page Under Construction ="

= SOM-9x25 Page Under Construction =

SoM-9G25 Getting Started

2015-10-29T21:28:03Z

Rossi: Created page with "= SOM-9G25 Page Under Construction ="

= SOM-9G25 Page Under Construction =

SoM-9G20 Getting Started

2015-10-29T21:27:32Z

Rossi: Created page with "= SOM-9G20 Page Under Construction ="

= SOM-9G20 Page Under Construction =

SoM-9260 Getting Started

2015-10-29T21:27:00Z

Rossi: Created page with "= SOM-9260 Page Under Construction ="

= SOM-9260 Page Under Construction =

SoM-3517 Getting Started

2015-10-29T21:26:22Z

Rossi: Created page with "= SOM-3517 Page Under Construction ="

= SOM-3517 Page Under Construction =

SoM-iMX6 Getting Started

2015-10-29T21:23:45Z

Rossi: Created page with "= SOM-iMX6 Page Under Construction ="

= SOM-iMX6 Page Under Construction =

SOM-320

2015-10-29T21:22:21Z

Rossi: Created page with "= SOM-320 Page Under Construction ="

= SOM-320 Page Under Construction =

SOM-250

2015-10-29T21:19:58Z

Rossi: Created page with " <!-- /**************************************** Page Descr..."

SOM-210

2015-10-29T21:17:33Z

Rossi:

SOM-212

2015-10-29T21:16:36Z

SOM-200

2015-10-29T21:13:19Z

Rossi:

SOM-150

2015-10-29T21:12:24Z

Rossi:

SOM-210

2015-10-29T21:11:05Z

SOM-A5D36

2015-10-29T21:05:52Z

Rossi:

SOM-A5D36

2015-10-29T21:05:02Z

Rossi:

ARM PPC

2015-10-29T20:51:45Z

Rossi:

<p style="width:100%;font-size:xx-large;text-align:center;font-weight:bold;line-height:125%;"> ARM Panel PCs (PPC) </p>




<p style="width:100%;font-size:small;text-align:left;line-height:100%;"/p>
EMAC is a global leader in industrial automation and HMI Panel PCs. We provide Panel PCs for embedded automation computers, automation controllers, remote i/o modules, and custom data acquisition solutions.

EMAC's Panel PCs are available ready to run with the Operating System installed on flash disk or hard drive. Apply power and watch either the Windows or Linux User Interface appear on the vivid color LCD. Interact with the PPC using the responsive integrated touchscreen. Everything works out of the box, allowing you to concentrate on your application, rather than building and configuring device drivers. Just Write-It and Run-It.

Contact the EMAC Panel PC Sales Department for details on Sunlight Readable Panel PC, IP65 Panel PC, IP67 Panel PC, Wide Voltage Panel PC, and/or Low Power Consumption Panel PC specifications.

<table style="width:100%; text-align: center">
<tr>

<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Open Frame ARM PPCs</div>
<ul style="text-align: left;">
<li><b> PPC-E4+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E4%2B PPC-E4+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E4+/ PPC-E4+ Downloads]</li>
</ul></li>
<li><b> PPC-E7+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E7%2B%5B3354%5D PPC-E7+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E7+/ PPC-E7+ Downloads]</li>
</ul></li>
<li><b> PPC-E10 </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E10 PPC-E10 Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E10/ PPC-E10 Downloads]</li>
</ul></li>
</ul>
</td>





<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Enclosed ARM PPCs</div>
<ul style="text-align: left;">

</ul>
</td>
</tr>
</table>

























<!--

X86 SBC

2015-10-29T20:44:49Z

Rossi:

X86 SIB

2015-10-29T20:43:49Z

Rossi:

X86 SIB

2015-10-29T20:42:50Z

EMAC HW

2015-10-29T20:32:32Z

Rossi:

__NOTOC__



<p style="width:80%;font-size:xx-large;text-align:center;font-weight:bold;line-height:125%;"> EMAC Hardware Wiki </p>




<table style="width:80%">
<tr>
<td style="width:20%;vertical-align:top;background-color:white;">
<ul>
<li style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">ARM Hardware</li>
<ul>
<li>[[ARM_SOM | System on Module (SoM)]]</li>
<li>[[ARM_PPC | Panel PC (PPC)]]</li>
<li>[[ARM_SBC | Single Board Computer (SBC)]]</li>
<li>[[ARM_SIB | Server In a Box (SIB Embedded Servers)]]</li>
</ul>
</ul>
</td>




<td style="width:20%;vertical-align:top;background-color:white;">
<ul>
<li style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">x86 Hardware</li>
<ul>
<li>[[x86_SOM | System on Module (SoM)]]</li>
<li>[[x86_PPC | Panel PC (PPC)]]</li>
<li>[[x86_SBC | Single Board Computer (SBC)]]</li>
<li>[[x86_SIB | Server In a Box (SIB Embedded Servers)]]</li>
</ul>
</ul>
</td>

</tr>
</table>



















<!--

X86 SBC

2015-10-29T20:29:00Z

X86 SOM

2015-10-26T15:45:32Z

Rossi:

X86 PPC

2015-10-26T15:43:20Z

X86 SOM

2015-10-26T15:36:07Z

ARM SIB

2015-10-26T15:15:31Z

SOM-A5D36

2015-10-26T15:00:15Z

Rossi:

ARM SBC

2015-10-23T23:12:21Z

Rossi:

ARM SBC

2015-10-23T23:09:48Z

ARM SOM

2015-10-23T22:32:03Z

Rossi:

<p style="width:100%;font-size:xx-large;text-align:center;font-weight:bold;line-height:125%;"> ARM System on Module (SoM) Products </p>





<p style="width:100%;font-size:small;text-align:left;line-height:100%;"/p>
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.

<table style="width:100%; text-align: center">
<tr>
<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">ARM-144 Pin SoMs</div>
<ul style="text-align: left;">
<li>[[SOM-9260 | SOM-9260 (Atmel ARM9 AT91SAM9260)]]</li>
<li>[[SOM-9G20 | SOM-9G20 (Atmel ARM9 AT91SAM9G20)]]</li>
<li>[[SOM-9G25 | SOM-9G25 (Atmel ARM9 AT91SAM9G25)]]</li>
<li>[[SOM-9X25 | SOM-9X25 (Atmel ARM9 AT91SAM9G25)]]</li>
<li>[[SOM-A5D35 | SOM-A5D35 (Atmel Cortex A5 ATSAMA5D35)]]</li>
</ul>
</td>




<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">ARM 200-Pin SoMs</div>
<ul style="text-align: left;">
<li>[[SOM-9G45 | SOM-9G45 (Atmel ARM9 AT91SAM9G45)]]</li>
<li>[[SOM-9M10 | SOM-9M10 (Atmel ARM9 AT91SAM9M10)]]</li>
<li>[[SOM-3517 | SOM-3517 (TI Cortex A8 AM3517)]]</li>
<li>[[SOM-3354 | SOM-3354 (TI Cortex A8 AM3354)]]</li>
<li>[[SOM-A5D36 | SOM-A5D36 (Atmel Cortex A5 ATSAMA5D36)]]</li>
</ul>
</td>
</tr>




<tr>
<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">ARM 314-Pin SoMs</div>
<ul style="text-align: left;">
<li>[[SOM-IMX6 | SOM-IMX6 (Freescale Cortex A9 iMX6)]]</li>
</ul>
</td>




<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">ARM SoM Carrier Boards</div>
<ul style="text-align: left;">
<li>[[SOM-150 | SOM-150 (144-Pin Carrier, Text LCD)]]</li>
<li>[[SOM-200 | SOM-200 (200-Pin Carrier, 4.3" LCD)]]</li>
<li>[[SOM-210 | SOM-210 (200-Pin Carrier, 4.3" LCD)]]</li>
<li>[[SOM-212 | SOM-210 (200-Pin Carrier, 4.3" LCD)]]</li>
<li>[[SOM-250 | SOM-250 (200-Pin Carrier, 7 & 10" LCDs)]]</li>
<li>[[SOM-320 | SOM-320 (314-Pin Carrier, Customer Defined LCD)]]</li>
</ul>
</td>
</tr>
</table>

ARM PPC

2015-10-23T22:29:32Z

Rossi:

<p style="width:100%;font-size:xx-large;text-align:center;font-weight:bold;line-height:125%;"> ARM Panel PCs (PPC) </p>




<p style="width:100%;font-size:small;text-align:left;line-height:100%;"/p>
EMAC is a global leader in industrial automation and HMI Panel PCs. We provide Panel PCs for embedded automation computers, automation controllers, remote i/o modules, and custom data acquisition solutions.

EMAC's Panel PCs are available ready to run with the Operating System installed on flash disk or hard drive. Apply power and watch either the Windows or Linux User Interface appear on the vivid color LCD. Interact with the PPC using the responsive integrated touchscreen. Everything works out of the box, allowing you to concentrate on your application, rather than building and configuring device drivers. Just Write-It and Run-It.

Contact the EMAC Panel PC Sales Department for details on Sunlight Readable Panel PC, IP65 Panel PC, IP67 Panel PC, Wide Voltage Panel PC, and/or Low Power Consumption Panel PC specifications.

<table style="width:100%; text-align: center">
<tr>

<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Open Frame ARM PPCs</div>
<ul style="text-align: left;">
<li><b> PPC-E4+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E4%2B PPC-E4+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E4+/ PPC-E4+ Downloads]</li>
</ul></li>
<li><b> PPC-E7+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E7%2B%5B3354%5D PPC-E7+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E7+/ PPC-E7+ Downloads]</li>
</ul></li>
<li><b> PPC-E10 </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E10 PPC-E10 Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E10/ PPC-E10 Downloads]</li>
</ul></li>
</ul>
</td>





<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Enclosed ARM PPCs</div>
<ul style="text-align: left;">
<li><b> PPC-E4+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E4%2B PPC-E4+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E4+/ PPC-E4+ Downloads]</li>
</ul></li>
<li><b> PPC-E7+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E7%2B%5B3354%5D PPC-E7+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E7+/ PPC-E7+ Downloads]</li>
</ul></li>
</ul>
</td>
</tr>
</table>

























<!--

ARM PPC

2015-10-23T22:24:58Z

Rossi:

<p style="width:100%;font-size:xx-large;text-align:center;font-weight:bold;line-height:125%;"> ARM Panel PCs (PPC) </p>




<p style="width:100%;font-size:small;text-align:left;line-height:100%;"/p>
EMAC is a global leader in industrial automation and HMI Panel PCs. We provide Panel PCs for embedded automation computers, automation controllers, remote i/o modules, and custom data acquisition solutions.

EMAC's Panel PCs are available ready to run with the Operating System installed on flash disk or hard drive. Apply power and watch either the Windows or Linux User Interface appear on the vivid color LCD. Interact with the PPC using the responsive integrated touchscreen. Everything works out of the box, allowing you to concentrate on your application, rather than building and configuring device drivers. Just Write-It and Run-It.

Contact the EMAC Panel PC Sales Department for details on Sunlight Readable Panel PC, IP65 Panel PC, IP67 Panel PC, Wide Voltage Panel PC, and/or Low Power Consumption Panel PC specifications.

<table style="width:100%; text-align: center">
<tr>

<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Open Frame ARM PPCs</div>
<ul style="text-align: left;">
<li><b> PPC-E4+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E4%2B PPC-E4+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E4+/ PPC-E4+ Downloads]</li>
</ul></li>
<li><b> PPC-E7+ </b><ul>
<li>[http://www.emacinc.com/panel_pcs_and_lcds/PPC-E7%2B%5B3354%5D PPC-E7+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E7+/ PPC-E7+ Downloads]</li>
</ul></li>
<li><b> PPC-E10 </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E10 PPC-E10 Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E10/ PPC-E10 Downloads]</li>
</ul></li>
</ul>
</td>





<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Enclosed ARM PPCs</div>
<ul style="text-align: left;">
<li><b> PPC-E4+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E4%2B PPC-E4+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E4+/ PPC-E4+ Downloads]</li>
</ul></li>
<li><b> PPC-E7+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E7%2B%5B3354%5D PPC-E7+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E7+/ PPC-E7+ Downloads]</li>
</ul></li>
</ul>
</td>
</tr>
</table>

























<!--

ARM PPC

2015-10-23T22:19:32Z

<p style="width:100%;font-size:xx-large;text-align:center;font-weight:bold;line-height:125%;"> ARM Panel PCs (PPC) </p>




<p style="width:100%;font-size:small;text-align:left;line-height:100%;"/p>
EMAC is a global leader in industrial automation and HMI Panel PCs. We provide Panel PCs for embedded automation computers, automation controllers, remote i/o modules, and custom data acquisition solutions.

EMAC's Panel PCs are available ready to run with the Operating System installed on flash disk or hard drive. Apply power and watch either the Windows or Linux User Interface appear on the vivid color LCD. Interact with the PPC using the responsive integrated touchscreen. Everything works out of the box, allowing you to concentrate on your application, rather than building and configuring device drivers. Just Write-It and Run-It.

Contact the EMAC Panel PC Sales Department for details on Sunlight Readable Panel PC, IP65 Panel PC, IP67 Panel PC, Wide Voltage Panel PC, and/or Low Power Consumption Panel PC specifications.

<table style="width:100%; text-align: center">
<tr>

<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Open Frame ARM PPCs</div>
<ul style="text-align: left;">
<li><b> PPC-E4+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E4+ PPC-E4+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E4+/ PPC-E4+ Downloads]</li>
</ul></li>
<li><b> PPC-E7+ </b><ul>
<li>[http://www.emacinc.com/panel_pcs_and_lcds/PPC-E7+ PPC-E7+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E7+/ PPC-E7+ Downloads]</li>
</ul></li>
<li><b> PPC-E10 </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E10 PPC-E10 Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E10/ PPC-E10 Downloads]</li>
</ul></li>
</ul>
</td>





<td style="width:50%;vertical-align:top;background-color:white; padding: 10px;">
<div style="font-variant:small-caps;font-weight:bolder;font-size:x-large;line-height:136%;">Enclosed ARM PPCs</div>
<ul style="text-align: left;">
<li><b> PPC-E4+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E4+ PPC-E4+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E4+/ PPC-E4+ Downloads]</li>
</ul></li>
<li><b> PPC-E7+ </b><ul>
<li>[http://www.emacinc.com/products/panel_pcs_and_lcds/PPC-E7+ PPC-E7+ Web Link]</li>
<li>[ftp://ftp.emacinc.com/PanelPC/PPC-E7+/ PPC-E7+ Downloads]</li>
</ul></li>
</ul>
</td>
</tr>
</table>

























<!--

SOM-200

2015-10-23T21:45:46Z