Project

General

Profile

ARM Software FAQs

How do I find / add pre-built software to the linux filesystem?

The OpenEmbedded framework uses a basic package management system based on debian called "opkg". There are 1000's of software packages pre-built (or that may be rebuilt using a linux host and the ARM 9 gcc cross tools in the MityDSP-L138 SDK) for the ARM 9 architecture used by the MityDSP-L138 and MityARM-1808 SOMs available from the open-embedded main build site. Most likely, the package you are looking for can be quickly installed if your target and your linux development host or VM has connectivity to the internet. The pre-built packages handle dependencies (such that requested packages will retrieve other packages they are dependent upon). You can also install source versions of the packages in order to perform debugging or version control, etc. Please note that you must honor the licensing (details of which are included in the package details) of software you wish to install.

In order to prepare the opkg databases, you first need to run:

bash#> opkg-update

This command will cause the target to retreive locations of package files as well as any dependencies from the openembedded mainsite. Once updated, you can list software that is readily available by using the following command:

bash#> opkg list

Note that this will generate a very long list of potential software. To search for a partical peice of software, you might try:

bash#> opkg list | grep -i qt4

This command will print out any software package containing "qt4". Once you have found a package you would like to install, you can install it via:

bash#> opkg install my_package_name

If you are developing with an NFS based root filesystem, you can select and install all of the packages you need for your end application and create a JFFS2 (or other suitable filesystem image) for programming your NAND or NOR device for final factory deployment.

If you are developing on a linux host and need to rebuild a package, link against a library provided by a package, or build against API header files for a package, then you will also need to install packages on your linux host. The MityDSP-L138 SDK includes the cross tools as well as a copy of a program "opkg-target". opkg-target must be run as root on your host, and essentially behaves the same way as "opkg" on the target machine, except that it will install libraries and/or headers and/or source code in the "/usr/local/angstrom/arm/" path of your linux build host. This will then allow you to compile and link against libraries pre-built for your target machine (the ARM 9).

How do I create a user filesystem in NAND flash?

Many users find it useful to have a filesystem separate from the root file system on the module. Typical users will use the user file system to store their application images (both ARM and DSP), FPGA image(s), and application configuration and runtime data. The following steps are necessary to create and mount a user file system in NAND flash per the memory map described in the MityDSP-L138_Architecture page.

  • First, you must make sure that you have the mtd-utils package installed on your module. This package includes the flash_eraseall utility needed for this procedure. The easiest way to install this package is to first make sure your system is on the network. Once on the network, use the following commands to install this package.
opkg update
opkg install mtd-utils
  • Once this utility has been installed the following command will prepare the User File System area of NAND flash to contain a jffs2 filesystem.
flash_eraseall -j /dev/mtd1

This command is verbose and can be quieted using the -q option.

  • At this point a blank jffs2 filesystem has been created, the next step will be to create a mount point for it, then to actually mount it. In this example, we will use the mount point /mnt/nand
mkdir /mnt/user_nand
mount -t jffs2 /dev/mtdblock1 /mnt/user_nand

This mounts the filesystem that can be accessed at /mnt/user_nand. A symbolic link can be used to make this new filesystem accessible elsewhere in the system, such as /user/home.

  • It is customary to have the system automatically mount the new file system once it has been created. In Linux, the file /etc/fstab contains the list of filesystems to be mounted at startup. In order to add this new filesystem to fstab add the following line to it's contents. Note that the noatime option instructs the kernel to not update the access time portion of the file attributes for any file on the filesystem. Having this enabled would cause repeated writes to the NAND flash adding additional and unnecessary wear to the media.
/dev/mtdblock1       /mnt/user_nand       jffs2      rw,noatime     0  0

Note that TI has additional information on creating and mounting filesystems TI Filesystem Wiki Page

How do I make my application run automatically at startup [INIT.d]?

When the linux operating system starts up, it enters a specific run level. These run levels are designed to allow you control over the overall state of the machine (i.e. single user mode for maintenance, etc). Each run level has a corresponding directory of scripts ( /etc/rcN.d ) that the system will run when entering or leaving that run level. These directories are really full of symbolic links to the real scripts, which reside in the /etc/init.d directory. To make your application run at startup, you should put a script that will setup and start your application in the /etc/init.d.

There are a number of thorough descriptions of the Linux startup process out there on the internet, such as

I suggest you familiarize yourself with it... you won't regret it.

The script will be called with one argument... start or stop (other values can be used in your script, but only start and stop are used by the OS)
If you look at one of the files currently in the /etc/init.d directory there are plenty of examples.
Once you have the script working to your satisfaction, run the following command to install the links to /etc/rcN.d

update-rc.d <scriptname> defaults

Note that scriptname is just the name of the script, not the complete path. There are options to update-rc.d to allow you to control the boot order.

A few points to ponder...
  • As your root filesystem (should be) is read-only (when deployed), it is a good idea to have the /etc/init.d script turn around and call another script that is on a r/w filesystem to do the heavy lifting. That way you can update the script without having to touch the root filesystem.
  • Make sure your program or script puts itself in the background otherwise the boot process will not proceed past starting your app.
  • When started at init time, your application will not have a controlling terminal, so do not try to interact with stdin, etc.

MMC boot is failing with Cannot open root device "mmcblk0p1"

VFS: Cannot open root device "mmcblk0p1" or unknown-block(179,1)
Please append a correct "root=" boot option; here are the available partitions:
1f00          131072 mtdblock0  (driver?)
1f01          131072 mtdblock1  (driver?)
1f02              64 mtdblock2  (driver?)
1f03             512 mtdblock3  (driver?)
1f04              64 mtdblock4  (driver?)
1f05              64 mtdblock5  (driver?)
1f06             320 mtdblock6  (driver?)
1f07            3072 mtdblock7  (driver?)
1f08            2048 mtdblock8  (driver?)
1f09            2048 mtdblock9  (driver?)
b300         3858432 mmcblk0  driver: mmcblk
  b301         3857408 mmcblk0p1 00000000-0000-0000-0000-000000000mmcblk0p1
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,1)
[<c000d518>] (unwind_backtrace+0x0/0xe0) from [<c0325d6c>] (panic+0x58/0x188)
[<c0325d6c>] (panic+0x58/0x188) from [<c0530bf4>] (mount_block_root+0x1bc/0x1fc)
[<c0530bf4>] (mount_block_root+0x1bc/0x1fc) from [<c0530dcc>] (mount_root+0xa0/0xc0)
[<c0530dcc>] (mount_root+0xa0/0xc0) from [<c0530f48>] (prepare_namespace+0x15c/0x1bc)
[<c0530f48>] (prepare_namespace+0x15c/0x1bc) from [<c0530858>] (kernel_init+0xe8/0x11c)
[<c0530858>] (kernel_init+0xe8/0x11c) from [<c0009cb8>] (kernel_thread_exit+0x0/0x8)

There was a typo in our bootargs for booting from mmc. Make sure your bootargs has a space and not a comma between rw and rootwait.

Note: You may not run into this if you have "ip=dhcp" as this provides enough time for the mmc to enumerate.

mem=96M console=ttyS1,115200n8 mtdparts=nand:128M(rootfs),-(userfs) root=/dev/mmcblk0p1 rw rootwait ip=dhcp

Building library which uses autotools

Note if you grab the tarball instead of using git then you should be able to skip the git and the autogen.sh command.

git clone git://github.com/stephane/libmodbus
cd libmodbus/
. /usr/local/oecore-i686/environment-setup-armv5te-angstrom-linux-gnueabi
./autogen.sh
./configure --host=arm-angstrom-linux-gnueabi
make
make install DESTDIR=$PWD/ARM

See build log libmodbus_build.log

The --host provided to configure, this should match your cross compiler.
The DESTDIR= was added to "make install", this ensures the files are copied to the "current directory"/ARM. See the build log for what gets placed in this ARM folder.

To copy built files to L138

In VM:

cd ARM/
tar czf libmodbus_arm_lib.tar.gz

On L138, assumes you've copied file to home directory
cd /
tar xvzf /home/root/libmodbus_arm_lib.tar.gz

Go to top
Add picture from clipboard (Maximum size: 1 GB)