• Rechercher un mot :

Beginning with the Calao USB-A9G20 embedded system board

I just bought a Calao USB-A9G20-C01 embedded system board and I spent some time figuring out how to use it.

The idea was to be able to use it with my Linux host machine (Ubuntu 8.10 Intrepid Ibex, stock kenel 2.6.27-11-generic x86_64 SMP). The following instructions are my notes to do this.

The following instructions would probably also apply to the other Calao products as well, such as the USB-A9260-C02 or the USB-A9263-C02.

Thanks to my friend Thomas Petazzoni for having indicated me the existence of these boards. And congratulations to the Calao people for developing them.

Basic setup

Just plug the usb development port (the one alone on its side) to a host computer. This provides the host with 2 new serial interfaces controlled by the ftdi_sio Linux kernel module (you might need a fairly recent version of the kernel on the host for that). Check what dmesg tells you on the host; you should see lines like:
usb 2-2.3: FTDI USB Serial Device converter now attached to ttyUSB0
usb 2-2.3: FTDI USB Serial Device converter now attached to ttyUSB1

The numbers 0/1 for ttyUSB0/1 give you the name of the /dev/ttyUSBX device node to use when you want to use external programs to dial with the device:
Instead of 0/1, some hosts may report other numbers such as 1/2 or 2/3, etc. when there are other USB serial devices connected to the machine.

First contact

After some time, the LED "User" should resemble a heartbeat (blink, blink, pause, blink, blink, pause, etc.).

Make sure screen is installed on your host, then start screen /dev/ttyUSB1 115200. It is also possible to use minicom or gtkterm or cuteterm (in 115200 bds 8N1) but the best terminal emulation I achieved was with screen. Once connected with screen or any other terminal emulator connected to the serial port, type enter. The usual Linux login prompt should (re-)appear:
Welcome to the Erik's uClibc development environment.

uclibc login:

The login is root on their default Linux installation. That's it, you are logged onto the embedded Linux ! Have fun. Nothing really original in this Linux, besides the fact it's based on busybox. It's even a bit disappointing: everything is working out of the box, nothing strange to do, nothing strange happens: you just plug it and it works. Even ethernet (ifconfig is your friend: no bootp/dhcp client to my knowledge) and the USB host ports (got it to mount a USB key) work out of the box. I didn't test the USB device port (the small usb connector on the bottom side of the PCB).

Bouh, where is the romantism of having to plug a logic analyzer to debug the system ?

RTFM for screen to learn how to disconnect from the serial connection, etc.

If you issue a reboot command at the device Linux root shell prompt, you should be able to see the usual boot sequence in the screen output, with the U-Boot prompt, etc.
uclibc login: root
# reboot
The system is going down NOW!
Sending SIGTERM to all processes
Requesting system reboot
Restarting system.

U-Boot 1.1.5 (Jan 24 2009 - 16:24:55)

DRAM:  64 MB
NAND:  NAND device: Manufacturer ID: 0xec, Chip ID: 0xda ( NAND 256MiB 3,3V 8-bit)
NAND: Pagesize: 2048, Blocksize: 128K, OOBsize: 64
256 MiB
In:    serial
Out:   serial
Err:   serial
DP83848 PHY Detected
No link
MAC: error during RMII initialization
Hit any key to stop autoboot:  0

Loading from device 0: NAND 256MiB 3,3V 8-bit (offset 0xa0000)
   Image Name:   Linux-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1483192 Bytes =  1.4 MB
   Load Address: 20008000
   Entry Point:  20008000
Automatic boot of image at addr 0x21000000 ...
## Booting image at 21000000 ...
   Image Name:   Linux-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1483192 Bytes =  1.4 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK

Starting kernel ...

Uncompressing Linux............................................................................................... done, booting the kernel.
Linux version (ghermant@ghermant-desktop) (gcc version 4.2.4) #10 Sat Jan 24 15:56:49 CET 2009
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
Machine: CALAO USB_A9G20
Memory policy: ECC disabled, Data cache writeback
Clocks: CPU 399 MHz, master 133 MHz, main 12.000 MHz
CPU0: D VIVT write-back cache
Welcome to the Erik's uClibc development environment.

uclibc login:

Refer to the "Getting started" guide for the USB-A9260-C01 (yes, it more or less applies to the A9G20 as well) for more information on what you can do with U-Boot, instructions on how to flash a new kernel, etc.

Instructions and training on how to build a toolchain, a Linux kernel, a root file system, etc. are given by the Free Electrons people for example.


It is possible to use the JTAG through the same usb port as the main device system connection, but using the other device node on the host (ie. /dev/ttyUSB0). However, for now I only found one tool to access this JTAG chain, it's not exactly via the /dev/ttyUSB0 device node but via libftdi, which bypasses the ftdi_sio kernel driver via the libusb library. It's not really clean imho, but it works.

The tool I'm using for that is openocd (http://openocd.berlios.de/web/), the one available on my host system (Ubuntu: sudo aptitude install openocd). The basic configuration files seem to work fine. To start openocd (the cfg file is in fact located in /usr/lib/openocd, and you might have to use the "-c02.cfg" file for the "C02" devices):
sudo openocd -f interface/calao-usb-a9260-c01.cfg

This will give you 2 ways to interract with the device through the JTAG chain (internet socket servers on localhost):

Note: If openocd fails to connect to the device (complaining that it cannot find it), double-check the value of the ft2232_device_desc directive. It should match the iProduct strings given by lsusb as root for example (or directly look at the contents of /sys/bus/usb/devices/..../idProduct). In my case, this string was USB-A9260 even though I really have a USB-A9G20 (well, at least that's what I believed when I received the invoice: I didn't try to decipher the labels on the CPU chip ;).

Compilation of a toolchain

Here, I want to use the ARM EABI instead of the OABI.

I ran into troubles while trying buildroot for the EABI, so I gave up and adopted crosstools-ng instead.

Using crosstools-ng (Ok)

Here is what I did, and at least I could compile everything:
shell> sudo aptitude install automake-1.10 libtool libncurses5-dev texinfo
shell> MYCTNGDIR=/tmp/moufmouf
shell> wget http://ymorin.is-a-geek.org/download/crosstool-ng/crosstool-ng-1.3.3.tar.bz2
shell> tar xjvf crosstool-ng-1.3.3.tar.bz2
shell> cd crosstool-ng-1.3.3
shell> ./configure --prefix=$MYCTNGDIR
shell> make
shell> make install

# I chose to put my dev dir inside MYCTNGDIR, that's probably not the best idea
# The important thing is to make sure the disk volume will be large enough for a
# full compilation:
shell> export PATH=$PATH:$MYCTNGDIR/bin
shell> cd $MYCTNGDIR
shell> mkdir mybuild
shell> cd mybuild
shell> cp ../lib/ct-ng-1.3.3/samples/arm-unknown-linux-uclibcgnueabi/* .
shell> cp crosstool.config .config
shell> ct-ng menuconfig # or vi .config
# At least make sure CT_PREFIX_DIR points to the desired dest dir
# eg. the value of $MYCTNGDIR/mybuild
shell> ct-ng build.2 # 2-way SMP build
# Go for a walk, have a beer, come back and enjoy !

The next steps will be to compile busybox and then use scratchbox for everything else.

Tentative with buildroot (I gave up in the middle of it)

I wanted to use the EABI instead of OABI, and this caused me trouble with gcc and then uClibc in buildroot.

Basically, to fix the first problems, I told buildroot to compile for a arm926t target arch with the EABI abi, and then had to force the following variables in the .config:
Once gcc is ready, buildroot fails. I needed to add a bunch of symlinks in staging_dir/bin so that new arm-linux-uclibc-* symlinks point to the arm-linux-uclibcgnueabi-* binaries.

In the end... uClibc complains about undefined variables related to ldso and fails to build. I gave up there. I didn't try very hard to dive into the details of buildroot. Feel free to document how to generate the whole world for an EABI arm toolchain with buildroot.

Miscellaneous information

Calao Systems provides the CPU specs for the AT91 used in the board, which appears to be an upgraded version of the A9260 used in their first boards. This probably means that most things working on the A9260 will work the same way on the A9G20 (?). At least the boot process, I/O and mem mapping specs would probably be similar. The schematics of the USB-A9G20-C01 board could be useful too. At least it helped me figure out what was this JTAG chain and how to access it.

There are also application notes which could be useful, most notably the led blinking demo available in their application notes ftp, and which would probably allow to implement a basic non-Linux embedded system.