Q: What is the standard usage model? Which components go where?

A:

The Intel® Software Development Tool Suites support a wide variety of Intel® Atom™ Processor based devices. This means that there is not one single use case or usage model that will fit the needs of every developer. Development for Intel® Atom™ Processor based devices tends to have one aspect in common however. In most cases you will want to take advantage of the performance and the high screen resolution of your regular development environment and deploy your build to the real hardware for validation and analysis only. In short, most commonly the usage model will be one of cross development.

The Intel® Embedded Software Development Tool Suite for Intel® Atom™ Processor addresses this in multiple ways.

• The Intel® C++ Compiler and the Intel® Integrated Performance Primitives will by default be installed on the development host system. To provide a protected build environment without host system library polution it is however also supported to install these components into the Moblin* Image Creator 2 jailroot system or to install them into a Moblin* 2 developer image running inside a KVM* virtual machine or even on a real target. For the installation into Moblin* Image Creator 2 or into a KVM* image it is recommended to do this following the yum rpm repository based installation processs outlined in the Moblin* Integration Guide Moblin_Integration.htm.
  • Moblin* Image Creator 2 kickstart scripts can be found at /en-us/articles/meego-integration-software-development-tool-suite-atom .

  • A template rpm repository definition file for the direct KVM* image instalaltion of compiler and Intel® IPP can be found at /en-us/articles/installing-the-intel-c-compiler-and-intel-integrated-performance-primitives-into-qemu-for.

• The Intel® Application Debugger will with the standard installation package be installed on your development host. Via TCP/IP you can connect to and debug a process either running on actual Intel® Atom™ Processor based target hardware or a KVM* virtual machine or some other virtualization method that assures you that the application to be debugged runs in a software environment identical to the later application deployment. Please also have a look at the Getting Started Guide Getting_Started.html that is part of the tool suite distribution for further details on the Intel® Application Debugger usage.
• The Intel® JTAG Debugger will with the standard installation package be installed on your development host. Via a JTAG device you can connect to your target platforms eXtended Debug Port (XDP) and thus commence remote cross-debugging of your entire platform and system level software.
• The Intel® VTune™ Performance Analyzer analyzes event based and time based sampling data on the development host. The data has been gathered on an Intel® Atom™ Processor based target platform with low overhead giving you accurate sampling data. The analysis can be done within the standard KDE* or Gnome* based standard Linux* GUI you are used to for your development efforts.

Please follow the instructions in the Installation Guide Install_All.htm for the installation of all the development host system tool suite components. Have a close look at the Moblin* Integration Guide Moblin_Integration.htm to pick your best customized solution for the target components and for cross-development.

Q: How do I install the Intel® Software Development Tool Suites for Intel® Atom™ Processor?

A:

The default installation directories are:

• /opt/intel/atom/vtune
• /opt/intel/atom/Compiler/11.1/xxx/ipp/
• /opt/intel/atom/Compiler/11.1/xxx/
• /opt/intel/atom/idb/2.0.xxx
• /opt/intel/atom/xdb/2.0.xxx

for the VTune™ Performance Analyzer, Intel® Integrated Performance Primitives, Intel® C++ Compiler, Intel® Application Debugger and the Intel® JTAG Debugger respectively.

The tool suite is intended for Intel® Atom™ Processor targeted cross-development. It is recommended to install the tool suite on your software development host system. It is further recommended to install selective components like the Intel® C++ Compiler, the Intel® IPP, the VTune™ Analyzer Sampling Collector (SEP) and the idbserver debug server in one of the following locations:

• Intel® Atom™ Processor based target device
• Moblin Image Creator 2 based jailroot environment
• Moblin 2 virtual image running inside KVM*

To understand the later two installation options and the integration of the Intel® Software Development Tool Suite for Intel® Atom™ Processor with the Moblin build environment please refer to the Moblin* Integration Guide Moblin_Integration.htm.

For installation of the tool suite on the development host please follow the steps below:

1. Unpack the tool suite package in a directory to which you have write access.
   > tar -zxvf l_MID_DBG_p_2.0.xxx.tar.gz
2. If you do not have a license file, please note the product serial number. You will need it to complete the installation process. Otherwise copy the license file you may have received via email from the Intel® Software Development Products Registration Center to /opt/intel/licenses/.
3. It is recommended to register your product at https://registrationcenter.intel.com. If you purchased support for this product you will need to register to take full advantage of Intel Premier Support at https://premier.intel.com.

4. Change into the directory the tar file was extracted to ../l_MID_DBG_p_2.0.xxx

5. Run the installation script
   

   Execute the install script in the directory where the tar file was extracted.
   >./install.sh

6. If you are not logged in as root, you will be asked if you want to install as root, install as root using sudo, or install without root privileges. Installing as root (using sudo if you have that privilege) is recommended, as that will update the system RPM database. Use the install as current user option if you want to install to a private area. The USB port configuration for the Intel® JTAG Debugger installation will however not be complete if current user install is selected.
7. In the next step you will be informed about the Intel® Embedded Software Development Tool Suite for Intel® Atom™ Processor components and the installation flow. Press the Enter key to continue
8. Afterwards you will be asked to read the end-user license agreement for the tool suite. Press theEnter key to continue with reading the license agreement. Once done type accept to continue with the installation.
9. When asked whether you would like to activate and install your product select one of th eoptions provided depending on whether you have a license file available or not. If there is already a valid license file available and installed on your system, the installation routine will recommend to simply use the existing license file. If you do not have access to the internet at the time of installation select the alternative activation option.
10. You can choose between a typical install, which installs all tool suite components or a custome install, which permits the selection of individual tool suite components.

Step no: 4 of 7 | Installation Type
--------------------------------------------------------------------------------
Congratulations! Your software has been activated. Please continue the
installation by choosing Typical Install (default installation options) or
Custom Install to change the default installation options.
--------------------------------------------------------------------------------
1. Typical Install (Recommended) [default]
2. Custom Install (For Advanced Users)

h. Help
b. Back to the previous menu
q. Quit
--------------------------------------------------------------------------------
Please type a selection or press "Enter" to accept default choice [1]:

 

1. If you choose the recommended typical install you will be prompted to choose one of several target processors. The debugger startup script install_dir/bin/xdb.sh automatically loads this processor. You can select a different target processor by starting the debugger using another startup script, called xdb_processor_name.sh, where processor_name is the name of the processor you want to use as the target. See install_dir/bin/ for the exact names of the different scripts. You can decide whether the default target processor supported by the Intel® JTAG Debugger shall be the Intel® Atom™ Processor Z5xx or the Intel® Media Processor CE3100. The Intel® Atom™ Processor is the default selection.
2. After reviewing the installation options

Step no: 4 of 7 | Configuration - Intel® VTune™ Performance Analyzer
-------------------------------------------------------------------------------
- Select '1' to use current settings.
- Select options 2-6 to change the installation settings.
-------------------------------------------------------------------------------

1. Finish configuration

2. VTune analyzer group [ use group 'vtune' ]
3. Driver kit options... [ auto ]
4. Eclipse options... [ install ]
5. Advanced options... [ installation type: 'full install' ]

h. Help
b. Back to the previous menu
q. Quit
-------------------------------------------------------------------------------
Please type a selection or press "Enter" to accept default choice [1]:

 

you can finalize the configuration and commence with the tool suite component installation itself.

1. The installation will be finalized and you will be informed when the installation has been completed succesfully. .

Installing the Intel VTune Performance Analyzer Sampling Collector on the target platform

1. Please follow the instructions in ~/l_MID_DBG_p_2.0.xxx/INSTALL_VTUNE.txt closely.
2. Copy the Intel® VTune™ Performance Analyzer Sampling Collector tool suite component located at ~/l_MID_DBG_p_2.0.xxx/rpm/vtune91_target.tar.gz onto the Mobile Internet Device.
3. On the target Mobile Internet Device unpack the sampling collector using the following command:

> tar -xvzf vtune91_target.tar.gz

1. Run the install script ~/vtune91_target/install-vtune-sep.sh and follow the installation instructions outlined in ~/vtune91_target/INSTALL.txt.

2. The file vtune_user_guide.pdf, which is located in ~/l_MID_DBG_p_2.0/, will give you detailed advice on how to use this utility.

--------------------------------------------------------------------

Q: What type of JRE does the GUI for the Intel® Debuggers require?

A:
Java runtime environment (JRE 1.5 or 1.6) is needed to use the Eclipse* framework. In a web browser, access www.java.com, and download and install JRE 1.6. Make sure that the $PATH environment variable contains the path to the JRE bin-directory.

Other software host requirements are:

To start the Intel® JTAG Debugger do the following:

1. Connect the XDP3 JTAG hardware adapter with the target.
2. Power on the adapter.
3. Connect the USB cable with the adapter.
4. Connect the USB cable with the host system.
5. Wait for the LEDs to change to red & green.
6. Power on the target system.
7. Start the debugger on the host system.

---------------------------------------------------------------

Q: What are the hardware requirements for using the tool suite?

A:

• Intel® IA-32 architecture or Intel®64 architecture based host computer. (The Linux* OS used should however be an IA-32 build)
• Ethernet TCP/IP Connection and ethernet cable
• Development platform based on the Intel® Atom™ Processor or the Intel® Media Processor CE3100
• For system debugging you may additionally require an In-Target-Probe for an eXtended Debug Port on the target device.

-------------------------------------------------

Q: Can the prebuild libraries included in the Intel® IPP be redistributed?

A:
The Intel® Integrated Performance Primitives Library End User License Agreements specifies most prebuild libraries as redistributable. They are however not be be redistributed under an evaluation license.

Please refer to /opt/intel/atom/ipp/6.x.xxx/redist.txt for details.

--------------------------------------------------------

Q: Which compiler optimization switch does specifically address optimizations for the new Intel® Atom™ Processor?

A:
The architecture specific optimization switch is -xSSE3_ATOM.

The new Intel® Atom™ processors are in-order machines. The Intel® C++ Compiler models the Intel® Atom™ processor pipeline and execution flow, thus enabling it to produce code with the optimum instruction execution sequence for low-power IA.

Additionally the Intel® C++ Compiler for Linux* has a whole set of Intel® Atom™ Processor specific optimizations that further help with getting the best performance out of your application running on an Intel® Atom™ Processor based platform.

All the user needs to do to enable the in-order instruction pipeline modeling is to use the option switch -xSSE3_ATOM along with all the other compiler options they may be using to optimize their code. This allows for reordering the generated machine instructions and thus minimize pipeline stalls.

-xSSE3_ATOM also implicitely enables generation of movbe instructions. if you would like to disable this, please additionally use

-------------------------------------------

Q: Can the development tools included in the Intel® Software Development Tool Suites for Intel® Atom™ Processor be used for applications targeting the Moblin Mobile Internet and Linux Project initiative (

)?

A: The answer is yes.

The tool suite actively supports installing the Intel® C++ Compiler and Intel® IPPs into the Moblin Image Creator 2 protected chroot environment via kickstart scripts. It also supports installing them into a ready to go Moblin Developer image that can be downloaded at Moblin.org. For more detail on this and also on how to use the Intel® Application Debugger to remotely debug an application running on a target device or on a Moblin* image inside a KVM* virtual machine, please consult the Moblin* Integration Guide Moblin_Integration.htm that is part of the tool suite distribution.

-----------------------------------------------------

Q: Are there any host USB driver updates required for system debug support?

A: Current versions of the FXLOAD and LIBUSB packages in the host Linux* OS installation will be necessary so the debug probe firmware can be successfully downloaded and the debug communication can be handled correctly for JTAG based system debug.

The minimu requirements for these drivers are:

--------------------------------------------------------

Q: What is execution trace?

A: The Intel® Atom™ Processor contains a small branch trace buffer that can be used for tracing the instructions actually executed on the processor.

The Intel® JTAG Debugger can directly access this buffer and reconstruct the instructions, thus providing the user with a snapshot of recent instructions executed.

The Intel® Application Debugger does the same if a small kernel patch necessary to support his feature is part of the target Linux* OS kernel. The Intel® Application Debugger trace readout will additionally filter out all instructions that don't belong to the debuggee process, thus only providing the execution flow for the very application the developer is interested in.

The benefit of having debugger access to the execution trace is that it allows to analyze the exact instruction execution flow leading up to a stack overflow or an exception. Simply set a breakpoint at the exception handler or at the error condition, enable trace logging and once you hit the breakpoint have a look at the instructions that were executed on the target device while looking at current register content. This should allow you to pin down the source of these types of traditionally hard to pin-down errors more quickly.

--------------------------------------------------------------

Q: Why does the Intel® JTAG Debugger provide a graphical representation of the page translation?

A: An OS or device driver developer may need to frequently access peripheral hardware devices and memory mapped configuration registers. Thus, while having code (OS initialization, driver kernel modules) executing in virtual memory space, they are accessing physical addresses and need to make sure that they either translate those addresses correctly in their code or that they exclude these memory areas used by peripheral configuration registers from any mapping.

The page translation table view allows to see the memory setup for any address on your system at any given point in time by a simple mouse click. If you need to change the configuration on the fly you additionally have detailed access to the translation table entires and all the descriptor tables as well.

---------------------------------------------------------------

Q: Is the Intel® Application Debugger by default supporting GDB style command and scripting language or DBX style command and scripting language?

A:

By default the Intel® Application Debugger for Intel® Atom™ Processor is launched in the IDB command language interface mode and the debugger should be launched in this default mode. The IDB command language interface (CLI) mode is using DBX style commands. To switch between GDB and IDB mode after connection you can use the following commands.

(idb) set $cmdset="gdb"

(idb) set $cmdset="idb"

or

(idb) set $cmdset="dbx"

-----------------------------------------------------------

The Debugger Message "Function not available when target is running" can have a set of reasons:

The message mostly occurs from the following scenario:

The target does stop (user press stop button, hit a breakpoint, any other debug exception or stopping because a linux module is loaded and the 'linux os awareness plug-in' is loaded).

Now, the debugger is updating the information of all the open windows. (assembler, memory, callstack or evaluation windows - read memory, register window - read registers, trace window, aso.)

What can happen is that during one of these update operations the target crashs

- most likely a memory access to invalid memory

- after loading a module the target gets released before all updates are done

- SW breakpoints are set (again invalid memory access)

- memory access due to evaluations or loaded debug information

What can you do to isolate the problem and avoid invalid memory accesses additionally to setting the option "set option /hard=on" is the following:

- In these cases, I'm closing all windows besides the console. (This will avoid a bunch of memory reads, register reads and other target accesses. After this I play with 'restart', 'run', 'stop', 'step' (which is an instruction step), 'show reg eip', aso.

- I do theses test first without debug information, that with it.

- Unload all plugins, and try to reproduce it without the plugins (If you see the target stops at in F1 instruction, this is the linux module load which is not handled by the linux os plugin - bug)

- the command prompt 'xdb' and 'xdb_R' are not always up-to-date (GUI-bug); the command 'status' does help in these cases.

Whenever you expect the target is stopped and 'status' changes the prompt to xdb_R you target is most likely in an inconsistent state.

--------------------------------------------------------

If you cannot view the Intel Debugger Online-Help

via the Help/Help Contents menu on Ubuntu* Linux host, because you encounter an

Unable to open web browser on {0}

error message when starting the Online-Help you need to create a symbloc link mozilla to the Firefox* Browser as follows:

sudo ln -s /usr/bin/firefox /usr/bin/mozilla

or (if you do not have sudo root rights)

ln -s /usr/bin/firefox <user_dir>/mozilla

Make sure you have the directory <user_dir>/mozilla included in your $PATH variable.

-----------------------------------------------------

Q: How do I install the VTune target Sampling Collector?

A:

Please follow the instructions in ~/l_MID_APPDBG_p_2.0.xxx/INSTALL_VTUNE.txt or ~/l_MID_DBG_p_2.0.xxx/INSTALL_VTUNE.txt closely.

Copy the Intel® VTune™ Performance Analyzer Sampling Collector tool suite component vtune91_target.tar.gz located at ~/l_MID_DBG_p_2.0.xxx/data/ onto the Mobile Internet Device.

On the target Mobile Internet Device unpack the samplinc collector using the following command:

> tar -xvzf vtune91_target.tar.gz

The file user_guide.pdf, which you will find in ~/vtune91_target/doc/ after installation is complete, will give you detailed advice on how to use this utility.

----------------------------------

Before starting the debugger, the recommended connection sequence is as follows:

To start the debugger enter the command:

xdb –tgttype ’<target connection type>’ -core 1 –target device=’<JTAG device>’ scanchain=’<target name>’ <additional target options>

or invoke the start script:

/opt/intel/atom/xdb/2.0.xxx/bin/xdb.sh

Once you are connected the JTAG interface will have taken over control and if you try to move the mouse on your target device or enter commands in a command shell it should not react – independent of whether you stopped directly after reset or whether your OS is already fully booted.

It is now time to load the symbol information for the Linux kernel.

You can do so by clicking on the “Load” button in the debugger menu bar and navigate to the vmlinux kernel ELF/Dwarf2 file in the Linux kernel source tree that matches the Linux image running on the MID target.

Alternatively you may also type

LOAD /SEGMENT /DEBUG /NOLOAD /GLOBAL OF "/usr/linux-2.6.31.i686/vmlinux"

into the console window. While the debugger is loading and interpreting this large OS kernel file it may seem unresponsive for a few moments.

To map the paths for the location of the sources associated with the symbol info on the debug host system correctly, it is necessary to tell the debugger where the top level directory of the source tree is located on the debug host system.

You may navigate to the the Options pulldown menu and select Source Directories.

After selecting the Rules tab and clicking on Add New… you will get to a dialog, which allows you to enter the correct source mapping.

Alternatively in the debugger console window you could also enter a command of the form below, which equals what is outlined above as the GUI based source mapping approach.

SET DIRECTORY /SUBSTITUTE = """/usr/linux-2.6.31.i686/"

Now we are done with making sure that we have full symbol debug capabilities for the Linux* OS kernel enabled and can proceed debugging the kernel.

----------------------------------------------

Debugging a dynamically loaded kernel module

1) Installing the OS awareness kernel module

To use this feature for runtime loaded kernel module debugging you will need to have the kernel module idbntf.ko running and installed on the target device. The folder /opt/intel/atom/xdb/2.0.xxx/kernel-modules/idbntf contains code to generate a Linux kernel module that enables kernel module debugging with the Intel system debugger.

For generation simply transfer these files to your target system and invoke make. This will generate the kernel object idbntf.ko.

To enable module debugging this object has to be loaded prior to starting the debugger via the command insmod idbntf.ko. After finishing the debug session, the module can be unloaded with rmmod idbntf.

2) Debugging a dynamically loaded kernel module named scull.ko

In the debugger tell the Linux OS awareness plug-in where to find the kernel module sources using the debugger console window:

set directory "/home/lab/scull/"

OS "setdir "/home/lab/scull/""

Then open the Linux Modules window and do a right mouse click and select “add” from the pulldown menu. You will notice all the other kernel modules already loaded during the boot process being listed. You will also notice that for most of them it states file not found. Referring to the location of the kernel module with symbol info.

In the dialog that pops up you type in ”scull” and you again select “Stop at Init”. Now the target can be released with the run command or button.

PuTTy/SSH or Telnet onto the released and running target. After changing to the scull directory you initialize the kernel module by typing

./scull.init start

The debugger as expected stops at the scull init method.

Set a breakpoint at the scull_read() function and release the target once more.

Then you send an echo to the /dev/scull0 device. The debugger halts and you can step through the function.

-------------------------------------------

Application Debugger, buildroot and idbserver

The Intel® Application Debugger communicates with the target application through a debug agent, called idbserver, which is running on the target system as outlined above. Idbserver itself is controlling the application to be debugged. The communication between the debugger on the host side and the debug agent is done via TCP/IP. This is true whether the application runs on a remote target or on localhost. The idbserver application should be executed inside of buildroot.

GUI based applications running inside the Moblin 2 GUI will have the screen size set to that of the Intel® Atom™ Processor based device. This is not desirable for the debugger and therefore the debugger itself should be installed and executed outside buildroot.

In order to map source path names which are relative to the buildroot environment (like source file names in the debug information) to path names as seen by the system outside of buildroot, the debugger offers a map command.

map source <from> <to>

For ease of use this command can be placed into the debugger startup file .idbrc.

--------------------------------------------------

Debugging shared libraries

To successfully debug shared libraries it is necessary to define a rule that maps to the shared library object on the host environment. The basic command line syntax for this purpose is

(idb) set solib-path-substitute <dir-path> <replacement-dir-path>

This can also be done using the debugger's graphical user interface. In the "Options" pulldown menu under "Shared Library Settings" you could select "Shared Library Path Substitutions" and enter the two paths to be mapped.

Using the GUI as well as the command line you can also remove shared object path subsititution rules

(idb) unset solib-path-substitute [ <dir-path> ]

or display them

(idb) show solib-path-substitute

Below is a brief description of an example how to apply this functionality specifically when working with a Moblin Image Creator based Chroot / Buildroot environment:

Let us assume we have the following environment setup using the Moblin Image Creator

$HOME: /home/mid_user

Project: mid_project

Target: mid_cb_full

Application directory (inside chroot environment): root/my_app

The application executable may be named sample_app and the shared library used may be named sample_lib.so for the sake of our example.

Under the assumption that we created a LiveRW image, after building the application we should then find that the image on the USB drive contains the directory /root/my_app/along with the application.

The application should then be launched and loaded into the debugger using the "Load" button to open the "Open Executable" dialog. The settings used in this "Open Executable" dialog are

• Local Executable File = /home/mid_user/mid_project/targets/mid_cb_full/fs/root/my_app/sample_app
• Remote Executable File=/root/my_app/sample_app

Additionally you will want to define a rule that allows the debugger to find the shared library associated with the debuggee application.

The rule would intuitively be set as follows

• idb set solib-path-subst / /home/mid_user/mid_project/targets/mid_cb_full/fs/

However, the IDBserver communication handler on the MID target device reads from the file /proc/<pid>/maps, that there is a shared library in /squashmnt/root/my_app/sample_lib.so. To accommodate this path as found by IDBserver the correct shared library mapping rule for an application that is part of the LiveRW image instead ne eds to be

• idb set solib-path-subst / /squashmnt/home/mid_user/mid_project/targets/mid_cb_full/fs/

If the application is copied onto the target device separately after the creation of the target image, the shared library image mapping rule needs to be

• idb set solib-path-subst / /persistmnt/home/mid_user/mid_project/targets/mid_cb_full/fs/

instead. Please note that the only difference is the /persistmnt versus /squashmnt option.

---------------------------