Alberto Embedded & Open experience

Notes on my experience on Open Source Embedded Systems

Archive for the ‘linux-arm’ Category

OpenOCD with Amontec JtagKey2 support

leave a comment »

Recently I bought an Amontec JtagKey-2 debug probe for my embedded projects. This Jtag probe have great features over a relative little buying cost: over other low cost Jtag probes, this one supports the RTCK signal and nominal speeds are really interesting.

What this post will describe is how to setup a useful JTAG debug environment:

libftd2xx

The JtagKey2 is based on FTDI FT2232 usb interface. Drivers for this chip can be found here:
http://www.ftdichip.com/Drivers/D2XX.htm

Choose your arch (for me Linux x86_64) and  download the archive in  $PRJROOT/openocd.
Then:

$ cd $PRJROOT/openocd
$ tar -xvf libftd2xx0.4.16_x86_64.tar.gz

OpenOCD

OpenOCD can be downloaded from its public git repository:

$ cd $PRJROOT
$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd openocd

Then, move to the opnocd directory and configure with:

$ cd openocd
$ ./bootstrap
$ # If you need, choose the right prefix with --prefix=DIR
$ ./configure --enable-maintainer-mode --enable-ft2232_ftd2xx \
  --with-ftd2xx-linux-tardir=libftd2xx0.4.16_x86_64
$ # n: Numbers of cores in your machine
$ make -j n

At this point the OpenOCD build process fire a linker error, this because  libtool mess up the library order when linking main.c so, let we do the right command:

$ cd src/

$ gcc -std=gnu99 -g -O2 -I/media/dati/android/openocd/libftd2xx0.4.16_x86_64 \
  -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter \
  -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror \
  -o openocd main.o ./.libs/libopenocd.a \
  /media/dati/android/openocd/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 \
  -ldl -lpthread
$ cd ..
$ make -j 6

And at the end, install:

$ sudo make install

Using OpenOCD

OpenOCD is completely configurable: the server must be started with a number of “-f ” options that points to the necessaries configuration files.
Normally must be given two configuration files: The interface config and a board config.
So OpenOCD can be started with:

$ sudo openocd -f interface/jtagkey2.cfg -f board/your_board.cfg

We have to use sudo because of permissions needs on using an usb device, otherwise an udev rule must be set.

Advertisements

Written by Alberto!

16/03/2010 at 12:11 pm

Posted in linux-arm

Tagged with ,

NAND Flash Support

leave a comment »

In the CPU board there is a 2 Gb NAND Flash chip organized in :

1 Device = (2K+64)Bytes x 64Pages x 2048 Blocks = 2112Mbits

This chip is connected to the i.MX31 Application Processor through the Nand Flash Controller Interface with an 8 bit data bus. The in kernel driver “drivers/mtd/nand/mxc_nand.c” can easily support it registering the nand device in the machine code with the follow platform data:

static struct mxc_nand_platform_data imx31pdk_nand_flash_pdata = {
       .width          = 1, /* 1 Byte data bus */
       .hw_ecc         = 1, /* No suppress hardware ECC */
};

The mxc_nand.c driver is enabled by default with a $ make mx3_defconfig

What can be enabled is the MTD Partitioning support with support for RedBoot partition table parsing where the Location of RedBoot partition table is the number of the Flash page where it is stored the RedBoot “FIS directory” that for me start at 0x80000, so it is the fourth page (4).

The resulting patch:

Subject: [PATCH 2/2] MXC: imx31pdk: Add support for on board NAND Flash.

Signed-off-by: Alberto Panizzo <alberto.panizzo@gmail.com>
---
arch/arm/mach-mx3/mx31pdk.c |   10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-mx3/mx31pdk.c b/arch/arm/mach-mx3/mx31pdk.c
index 0f7a2f0..ca1fe5d 100644
--- a/arch/arm/mach-mx3/mx31pdk.c
+++ b/arch/arm/mach-mx3/mx31pdk.c
@@ -34,6 +34,7 @@
#include <mach/board-mx31pdk.h>
#include <mach/imx-uart.h>
#include <mach/iomux-mx3.h>
+#include <mach/mxc_nand.h>
#include "devices.h"

/*!
@@ -53,6 +54,14 @@ static int mx31pdk_pins[] = {
IOMUX_MODE(MX31_PIN_GPIO1_1, IOMUX_CONFIG_GPIO),
};

+/*
+ * NAND Flash
+ */
+static struct mxc_nand_platform_data imx31pdk_nand_flash_pdata = {
+    .width        = 1,
+    .hw_ecc        = 1,
+};
+
static struct imxuart_platform_data uart_pdata = {
.flags = IMXUART_HAVE_RTSCTS,
};
@@ -241,6 +250,7 @@ static void __init mxc_board_init(void)
"mx31pdk");

mxc_register_device(&mxc_uart_device0, &uart_pdata);
+    mxc_register_device(&mxc_nand_device, &imx31pdk_nand_flash_pdata);

if (!mx31pdk_init_expio())
platform_device_register(&smsc911x_device);
--
1.6.3.3

Written by Alberto!

04/12/2009 at 4:45 pm

Posted in imx31pdk

Tagged with , ,

imx31pdk Initial Support path

leave a comment »

On the imx31 PDK CPU board there are mainly those chips:

Device Description Connected through
Application processor:
i.MX31
RAM Memory:
128 MB (1 Gb) DDR
iMX31 EMI
NAND Flash:
256 MB (2 Gb)
iMX31 NFC
Power Management and Audio IC:
MC13783
iMX31 SPI2
USB transceiver:
ISP 1504
iMX31 USB OTG

RAM memory is native managed by the iMX31 External Memory Interface, then the first chip that can be supported is the NAND Flash. Then we must to go through the support for the Power management chip to go ahead with all other devices because MC13783 hold the entire power supply management, with its Regulator interface.

Written by Alberto!

04/12/2009 at 4:12 pm

Posted in imx31pdk

Tagged with , , ,

i.MX 31 PDK developing

leave a comment »

In those days I am involved in supporting the Freescale i.MX PDK developing board in the mainline kernel.

This is not a simple job because there are (at first seeing) a lot of holes in mainline kernel.

Stay tuned for news!

Written by Alberto!

04/12/2009 at 11:12 am

Posted in imx31pdk

Tagged with ,

Developing kernel on a Virtual Machine (the solution)

leave a comment »

I am working now on Ubuntu Karmic Koala.

As I said in my previous post, Qemu is a complete platform emulator that can emulate the Integrator ARM machine platform (CPU and devices!).

In Karmic Koala the latests Qemu version (0.11.0) is shipped within Ubuntu repositories so with this line we can install it:

# sudo apt-get install qemu qemu-kvm qemu-kvm-extras

ARM test images

From the Qemu home page we can download a Linux 2.6 ARM example image builded by Paul Brook and extracting it in $PRJROOT/images, we can find the README file where it is written how to launch the test platform:

# cp DownloadDirectory/arm-test-0.2.tar.gz $PRJROOT/images
# cd $PRJROOT/images
# tar -xvf arm-test-0.2.tar.gz
# cd arm-test
# cat README

So, with or without the graphical interface we can test the qemu arm installation with the followings:

# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img
or
# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \
  -nographic -append "console=ttyAMA0"

A suitable Linux config file

Over the test purpose , executing the test image can give the kernel configuration file stored in /proc/config.gz ! so:

# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \
  -nographic -append "console=ttyAMA0"
Uncompressing Linux...............................................
........................... done, booting the kernel.
Linux version 2.6.17-rc3 (paul@wren) (gcc version 4.1.0 (CodeSourcery ARM))
 #53 Thu May 4 15:05:18 BST 2006
CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
Machine: ARM-IntegratorCP
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-through cache
CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets
CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets
Built 1 zonelists
Kernel command line: console=ttyAMA0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total

...

Log in as root with no password.
qemu login: root
# cp /proc/config.gz .
# tar -xvf config.gz
# vi config.gz

With this file we can configure the mainline linux kernel! (copying from screen, copying within net, scrolling the options with a near mainline make menuconfig window).

ARMv5te Toolchain to build the kernel

The machine emulated by qemu-arm is based on the core ARMv5te , so I need the correct toolchain for build all the necessary code.

The Pengutronix OSELAS environment can do that in the OSELAS toolchain project. Similarly at what described in Initializing a Linux Embedded Development Host Machine moving in $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/ we can select the suitable ptxdist configs with:

# cd $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/
# ls ptxconfigs/
arm-1136jfs-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig
arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig.old
arm-cortexa8-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
armeb-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
armeb-xscale-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
...
arm-v4t-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-v4t-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-v5te-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-v5te_vfp-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
arm-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig
arm-xscale-linux-gnueabi_gcc-4.2.3_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
...
# ptxdist select ptxconfigs/\
  arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig
# ptxdist menuconfig

In the menuconfig, all can live as it is but in “misc->prefix for installation” we can choose $PRJROOT/tools where $PRJROOT must be manually extended. So with:

# ptxdist go

A part from minor dependencies that we can solve installing software with apt-get, the toolchain is built and the correct prefix will be:

CROSS_COMPILE_OSELAS_v5=$PRJROOT/tools/OSELAS.Toolchain-1.99.3/arm-v5te-linux-gnueabi/\
   gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin/arm-v5te-linux-gnueabi-

If we assign the environmental variable CROSS_COMPILE=CROSS_COMPILE_OSELAS_v5 the kernel configured by the upper config file and compiled with this toolchain is a good kernel to execute within the qemu-system-arm emulator!

A suitable Root Filesystem

Ok we have a good kernel ad a small initrd filesystem, but we have to develop application to run in the emulated device!

We can use the OSELAS.BSP Phytec phyCORE project installed following the description in Initializing a Linux Embedded Development Host Machine.

Download the platform_config file platformconfig-qemu and the ptxconfig one ptxconfigThiny (that is the normal ptxconfig removing all graphic subsystem for a speedier compilation)

Every two configuration file must be placed in $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/configs so with:

# cd $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/
# ptxdist select configs/ptxconfigThiny
# ptxdist platform configs/platformconfig-qemu
# ptxdist toolchain $CROSS_COMPILE_OSELAS_v5
# ptxdist go
# ptxdist images

In  $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/ we will find the root.ext2 image, ready to be the SD/MMC image of the qemu device!

Running qemu

If in the $PRJROOT directory we create the images/phyCORE directory and we put all the necessary:

# cd $PRJROOT
# mkdir -p images/phyCORE
# cp (kernel_path)/arch/arm/boot/zImage images/phyCORE/
# cp $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/root.ext2\
  images/phyCORE/

then we can start qemu:

# qemu-system-arm -kernel images/phyCORE/zImage -sd images/phyCORE/root.ext2 \
  -nographic -append "console=ttyAMA0 root=/dev/mmcblk0"

Results

In results we have a complete developing environment: emulator, toolchain, kernel, software ecosystem.

Kernel modification that do not deal with the hardware abstraction layer can be well developed in the emulator and tested by ad-hoc software inserted in the phyCORE-qemu distribution!

Written by Alberto!

25/11/2009 at 5:01 pm

USB Host support!

with one comment

Dear all,
today I’ve reached USB host support for OTG and USB Host2 port too!
This was done adapting and correcting the Daniel Mack RFC for MX3 EHCI support.
Wait some more for a deep description on changes :p

Bye!
Alberto!

Written by Alberto!

15/06/2009 at 3:08 pm

Posted in Armadillo

Tagged with , , , ,

Updates, NOR and NAND flash support.

leave a comment »

Modifications on mx3fb driver are not to be accepted because of the maintainer won’t add machine specific code in that file.. Nevermind, I keep the patch in my hand waiting for another solution 🙂

In those days I worked on NOR & NAND flash support:
NOR flash device is mounted on the CPU credit card and it works well with physmap mapping driver.
NAND flash device is mounted on the motherboard and supporting it was a bit harder:
In tree there is a NAND flash driver for MXC architecture mxc_nand.c derived from original freescale driver and corrected over coding style and kernel way of doing by Sascha Hauer . Unfortunately this driver do not support flash devices with large page size (2kB wide, over 512 B of small page size devices) and upgrading it was over my capability..
The solution came from a graceful guy called Vladimir Barinov from linux-mtd list where I posted the problem. He gave me the right patch that merged with my work make the NAND flash device working!

So now I can store data in all memory devices mounted on the board! Great!

Alberto!

Written by Alberto!

25/05/2009 at 12:52 pm

Posted in Armadillo

Tagged with , , , ,