Gumstix User Wiki - User contributions [en]

Xenomai - Mini Howto

2009-02-21T12:55:28Z

Hik:

=== Xenomai ===

The following quick guide gives a rough overview how I got Adeos & Xenomai (real-time extension for Linux) running on the verdex.

=== Quick Install Guide ===

==== Step 1: Gumstix OE setup ====

At first, [http://www.gumstix.net/Software/view/Getting-started/Quick-start/111.html setup the build environment].

Note, that the step

<pre>
$ cat gumstix-oe/extras/profile >> ~/.bashrc
</pre>

defines environment variables - amongst others, it sets the directory for USERBRANCH which is used to provide our custom bitbake package.

==== Step 2: Custom Configuration ====

Download the [http://omnibus.uni-freiburg.de/~zitteret/files/gumstix/xeno-user-collection.tar.bz2 user.collection to build Xenomai for Gumstix OE]. Unpacking the file in the Gumstix OE root directory will give the following structure:

<pre>
user.collection
user.collection/conf
user.collection/conf/machine
user.collection/conf/machine/include
user.collection/packages
user.collection/packages/xenomai
user.collection/packages/xenomai/xenomai-2.4.6
user.collection/packages/linux
user.collection/packages/linux/gumstix-xenomai-kernel-2.6.24
user.collection/packages/linux/gumstix-xenomai-kernel-2.6.24/gumstix-custom-verdex
</pre>

==== Step 3: (Re-)build the kernel and system ====

<pre>
$ bitbake gumstix-xenomai-kernel
$ bitbake -c rebuild task-base-gumstix
$ bitbake -c rebuild gumstix-basic-image
</pre>

==== Step 4: Images ====

The kernel and root filesystem image can be found in tmp/deploy/glibc/images.

== Troubleshooting ==

=== Xenomai for verdex with Qemu ===

It is also possible to run the real-time kernel within Qemu. However, it might be necessary to slow down the clock of the emulated system (Probably, as your host computer is too slow).

The following steps can help:

Alter the file <tt>hw/pxa2xx_timer.c</tt> in the Qemu sources:

1. Change all occurences of <tt>qemu_get_clock(vm_clock)</tt> to <tt>PXA2XX_QEMU_GET_CLOCK()</tt>

2. Define the macro
<pre>
#define PXA2XX_QEMU_GET_CLOCK() (qemu_get_clock(vm_clock) >> 4) /* also try 2,3 or use a divider */
</pre>

Xenomai - Mini Howto

2009-02-21T12:52:35Z

Hik:

=== Xenomai ===

The following quick guide gives a rough overview how I got Adeos & Xenomai (real-time extension for Linux) running on the verdex.

=== Quick Install Guide ===

==== Step 1: Gumstix OE setup ====

At first, [http://www.gumstix.net/Software/view/Getting-started/Quick-start/111.html setup the build environment].

Note, that the step

<pre>
$ cat gumstix-oe/extras/profile >> ~/.bashrc
</pre>

defines environment variables - amongst others, it sets the directory for USERBRANCH which is used to provide our custom bitbake package.

==== Step 2: Custom Configuration ====

Download the [http://omnibus.uni-freiburg.de/~zitteret/files/gumstix/xeno-user-collection.tar.bz2 user.collection to build Xenomai for Gumstix OE]. Unpacking the file in the Gumstix OE root directory will give the following structure:

<pre>
user.collection
user.collection/conf
user.collection/conf/machine
user.collection/conf/machine/include
user.collection/packages
user.collection/packages/xenomai
user.collection/packages/xenomai/xenomai-2.4.6
user.collection/packages/linux
user.collection/packages/linux/gumstix-xenomai-kernel-2.6.24
user.collection/packages/linux/gumstix-xenomai-kernel-2.6.24/gumstix-custom-verdex
</pre>

==== Step 3: (Re-)build the kernel and system ====

<pre>
$ bitbake gumstix-xenomai-kernel
$ bitbake -c rebuild task-base-gumstix
$ bitbake -c rebuild gumstix-basic-image
</pre>

==== Step 4: Images ====

The kernel and root filesystem image can be found in tmp/deploy/glibc/images.

== Troubleshooting ==

=== Clock issues (Xenomai on verdex with Qemu) ===

It is also possible to run the real-time kernel within Qemu. However, it might be necessary to slow down the clock of the emulated system (Probably, as your host computer is too slow).

The following steps can help:

Alter the file <tt>hw/pxa2xx_timer.c</tt>:

1. Change all occurences of <tt>qemu_get_clock(vm_clock)</tt> by <tt>PXA2XX_QEMU_GET_CLOCK()</tt>

2. Define the macro
<pre>
#define PXA2XX_QEMU_GET_CLOCK() (qemu_get_clock(vm_clock) >> 4) /* also try 2,3 or use a divider */
</pre>

Xenomai - Mini Howto

2009-02-21T12:52:20Z

Hik:

=== Xenomai ===

The following quick guide gives a rough overview how I got Adeos & Xenomai (real-time extension for Linux) running on the verdex.

=== Quick Install Guide ===

==== Step 1: Gumstix OE setup ====

At first, [http://www.gumstix.net/Software/view/Getting-started/Quick-start/111.html setup the build environment].

Note, that the step

<pre>
$ cat gumstix-oe/extras/profile >> ~/.bashrc
</pre>

defines environment variables - amongst others, it sets the directory for USERBRANCH which is used to provide our custom bitbake package.

==== Step 2: Custom Configuration ====

Download the [http://omnibus.uni-freiburg.de/~zitteret/files/gumstix/xeno-user-collection.tar.bz2 user.collection to build Xenomai for Gumstix OE]. Unpacking the file in the Gumstix OE root directory will give the following structure:

<pre>
user.collection
user.collection/conf
user.collection/conf/machine
user.collection/conf/machine/include
user.collection/packages
user.collection/packages/xenomai
user.collection/packages/xenomai/xenomai-2.4.6
user.collection/packages/linux
user.collection/packages/linux/gumstix-xenomai-kernel-2.6.24
user.collection/packages/linux/gumstix-xenomai-kernel-2.6.24/gumstix-custom-verdex
</pre>

==== Step 3: (Re-)build the kernel and system ====

<pre>
$ bitbake gumstix-xenomai-kernel
$ bitbake -c rebuild task-base-gumstix
$ bitbake -c rebuild gumstix-basic-image
</pre>

==== Step 4: Images ====

The kernel and root filesystem image can be found in tmp/deploy/glibc/images.

== Troubleshooting ==

=== Clock issues (Xenomai on verdex with Qemu) ===

It is also possible to run the real-time kernel within Qemu. However, it might be necessary to slow down the clock of the emulated system (Probably, as your host computer is too slow).

The following steps can help:

Alter the file <tt>hw/pxa2xx_timer.c</tt>:

1. Change all occurences of <tt>qemu_get_clock(vm_clock)</tt> by <tt>PXA2XX_QEMU_GET_CLOCK()</tt>

2. Define the macro
<pre>
#define PXA2XX_QEMU_GET_CLOCK() (qemu_get_clock(vm_clock) >> 4) /* also try 2,3 or use a divider */
</pre>

[[Running_qemu#Xenomai_on_verdex_with_Qemu.29]]

Making qemu images

2009-02-21T12:30:33Z

Hik:

= Preparing flash / disk images for qemu =

== Flash images ==

You need a kernel and root filesystem for your Gumstix board. Additionally, download one of the [http://www.gumstix.net/feeds/u-boot/ u-boot images] for your platform.

=== Verdex ===

The flash image emulates the flash memory on the Gumstix motherboard. It's a single file that has the size of the emulated flash memory (32MB in the case of the verdex board emulated by qemu). It will contain the same images as the real flash, at the same offsets:

* The u-boot image at offset 0
* The root file system image at offset 256kB
* The kernel image at the end of the image offset 31MB

The following 3 files are needed

* <tt>u-boot-verdex-400-r1587.bin</tt> - u-boot
* <tt>gumstix-basic-image-gumstix-custom-verdex.jffs2</tt> - root file system
* <tt>uImage-2.6.21-r1-gumstix-custom-verdex.bin</tt> - kernel.

Except for the u-boot image which is not yet built by openembedded, those files can be found in the <tt>tmp/deploy/glibc/images/</tt> sub-directory of <tt>gumstix-oe</tt> after running bitbake.

To assemble the image <tt>flash.img</tt> run the following commands:

<pre>
$ dd of=flash.img bs=128k count=256 if=/dev/zero
$ dd of=flash.img bs=128k conv=notrunc if=u-boot-verdex-400-r1587.bin
$ dd of=flash.img bs=128k conv=notrunc seek=2 if=gumstix-basic-image-gumstix-custom-verdex.jffs2
$ dd of=flash.img bs=128k conv=notrunc seek=248 if=uImage-2.6.21-r1-gumstix-custom-verdex.bin
</pre>

=== Connex ===

For Connex boards with 16MB flash the steps slightly differ:

<pre>
$ dd of=cflash.img bs=128k count=128 if=/dev/zero
$ dd of=cflash.img bs=128k conv=notrunc if=u-boot-connex-400-r1604.bin
$ dd of=cflash.img bs=128k conv=notrunc seek=2 if=gumstix-basic-image-gumstix-custom-connex.jffs2
$ dd of=cflash.img bs=128k conv=notrunc seek=120 if=uImage-2.6.21-r1-gumstix-custom-connex.bin"
</pre>

== mmc/CF images ==

Those images are used to emulate the flash memory cards that are present on netmicroSD, netMMC, netCF... expansion boards. It is possible to
boot from them or just to store more data in them.

On the Linux host, the <tt>losetup</tt>(1) utility is used to access those images as real block devices,

/!\ The current qemu version seems to be limited to 1GB card images. The examples presented here will thus use 1GB images.

* Creating the empty image

dd of=mmc.img bs=1M count=1024 if=/dev/zero

* Creating a block device for the whole image

losetup /dev/loop0 mmc.img

* Running fdisk to partition the card

fdisk /dev/loop0

=== Partitionning the card ===

In the most simple case, one single partition (VFAT, ext2 or ext3) can cover the whole card. However, in order to boot from the card and use it for the root file system, at least 2 partitions, one small VFAT to hold the kernel and the u-boot script, and a bigger one, ext2 for the root file system. The folloing example shows a basic setup (using fdisk 'p' command):

<pre>
Command (m for help): p

Disk /dev/loop0: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x25c4dea4

Device Boot Start End Blocks Id System
/dev/loop0p1 1 7 56196 6 FAT16
/dev/loop0p2 8 130 987997+ 83 Linux
</pre>

=== Accessing the partitions ===

In order to access the partitions, 2 more loop devices have to be created with losetup. The offsets into the main loop device (<tt>/dev/loop0</tt>) need to be specified. For this, use <tt>fdisk -ul</tt> to find the starting block of your partitions:
<pre>

Disk /dev/loop0: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders, total 2097152 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x25c4dea4

Device Boot Start End Blocks Id System
/dev/loop0p1 63 112454 56196 6 FAT16
/dev/loop0p2 112455 2088449 987997+ 83 Linux
</pre>

Partition 1 starts at block 63 (which is 63*512 = 32256 bytes) and partition 2 starts at block 112455 (which is 112455*512 = 57576960 bytes).

The following commands will then create the 2 loop devices:

losetup -o 32256 /dev/loop1 /dev/loop0
losetup -o 57576960 /dev/loop2 /dev/loop0

/dev/loop1 and /dev/loop2 will now access the 2 partitions.

=== Formatting and mounting ===

mkfs -t vfat /dev/loop1
mkfs -t ext2 /dev/loop2

mkdir /mnt/1
mkdir /mnt/2

mount /dev/loop1 /mnt/1
mount /dev/loop2 /mnt/2

=== Copying data ===

The kernel image (called <tt>uImage</tt> on the docs on using root on MMC/SD), the u-boot script <tt>gumstix-factory.script</tt> are needed on /mnt/1.

To transfer the root filesystem to /mnt/2, un-tar the <tt>gumstix-basic-image-gumstix-custom-verdex.tar.gz</tt> found in the <tt>tmp/deploy/glibc/images/gumstix-custom-verdex/</tt> directory.

=== Cleaning up ===

Before starting qemu, both partitions should be un-monted and the 3 loop devices should be un-configured. Failing to do that will almost certainly corrupt the images.

umount /mnt/2
umount /mnt/1
losetup -d /dev/loop2
losetup -d /dev/loop1
losetup -d /dev/loop0

[[Category:How_to_-_qemu]]

Xenomai - Mini Howto

2009-02-21T11:43:53Z

Hik: New page: === Xenomai === The following quick guide gives a rough overview how I got Adeos & Xenomai (real-time extension for Linux) running on the verdex. === Quick Install Guide === ==== Step 1...