coding » arm

BeagleBoard and Ubuntu 11.04 (beta 1) headless install

Tiago Maluta — Tue, 12 Apr 2011 03:57:45 +0000

Ubuntu OMAP team is doing a really good job by adding a headless installation of 11.04 release. I had a good impression trying on BeagleBoard (revC) and the process is straightforward (read the documentation) but I needed made a slight change at u-boot bootcmd env, so I decided share:

mmc init
mmc rescan 0
fatload mmc 0 0×82000000 boot.scr
source 0×82000000

After install… I put a usb/ethernet dongle and got fully supported by APT syncing from ports.ubuntu.com

I suggest try it.

Installing Buildroot toolchain for Nuttx

Tiago Maluta — Wed, 08 Sep 2010 06:44:42 +0000

On my previous post I discussed some stats using Buildroot toolchain to build Nuttx. Today I’ll add the necessary steps to build on Ubuntu. Ubuntu is de-facto GNU/Linux distribution (although I’m Gentoo user) and many users, from different areas, uses it [they are not necessary command line experts] so I decided to publish my raw tutorial. If you are familiarized installing files from source-code you probably won’t need this…

1. Dependencies

$ sudo apt-get install libncurses5-dev
$ sudo apt-get install bison
$ sudo apt-get install flex
$ sudo apg-get install libgmp3-dev
$ sudo apg-get install libmpc-dev
$ sudo apg-get install libmpfr-dev
$ sudo apg-get install binutils-dev

2. Download

$ mkdir Nuttx
$ cd Nuttx

$ wget http://sourceforge.net/projects/nuttx/files/nuttx/nuttx-5.10/nuttx-5.10.tar.gz/download
$ wget http://sourceforge.net/projects/nuttx/files/buildroot/buildroot-1.8/buildroot-1.8.tar.gz/download

$ ls
buildroot-1.8.tar.gz nuttx-5.10.tar.gz

3. Install

$ tar zxf buildroot-1.8.tar.gz
$ tar zxf nuttx-5.10.tar.gz

$ cd misc/
$ ln -s ../nuttx-5.10 nuttx

You need define some Nuttx files before:

$ cd nuttx/
$ cd tools/
$ ./configure.sh nucleus2g/nsh # or ./configure
$ cd -

$ cd ../misc

I’m building a toolchain for arm cortex-m3 but check configs/ to other configuration files.

$ cd buildroot-1.8/
$ cp configs/cortexm3-defconfig-4.3.3 .
$ mv cortexm3-defconfig-4.3.3 .config

$ make menuconfig
[If you don't have any changes, just click on 'exit' and save the configuration]

$ make
[will download and build all necessary files]

$ cd build_arm_nofpu/staging_dir/bin
$ export PATH=`pwd`:$PATH
$ cd -

$ cd ../nuttx
[use normally]

I usually create an script to (re)define the $PATH for necessary building tools, something like:

$ echo “export PATH=\”"$PATH”\”" > compiler.sh

Compiler for Nuttx

Tiago Maluta — Mon, 06 Sep 2010 21:09:41 +0000

I was following this thread on Nuttx maillist on recommended compiler to build Nuttx RTOS. As a matter of practicality I guess that many users use CodeSourcery arm-none-linux-gnueabi but today I decided test the code generated for Cortex-M3 (LPC1768) using the toolchain from Buildroot. As Greg Nutt said (text adapted):

They were configured using OABI [old arm ABI], but I prefer them because (1) they are not EABI and reliably link code with -O3 or -Os, making it up to half the size, and (2) include nuttx “built in” — they really should be called arm-nuttx-gcc tools.

Here my stats (defconfig):

$ arm-none-eabi-size nutt
text data bss dec hex filename
71000 324 2248 73572 11f64 nuttx

$ arm-elf-size nuttx
text data bss dec hex filename
56172 330 2248 58750 e57e nuttx

The final .bin has an delta of 16K. As I’m using one parallel JTAG (flash rates @ 0.2 KiB/S) this means almost 1 minute reduction in each flash write_image. If you check Make.defs note that MAXOPTIMIZATION for CodeSourcery isn’t using optimize for size option (-Os). As explained on config//README.txt it doesn’t work with this kind of optimization level [tested with 2009q1].

Opcode stats

Tiago Maluta — Fri, 25 Jun 2010 00:09:50 +0000

I was trying some GCC options and decided see how they affect assembly code generated. I’ve created a simple Python script that parses .s output and put in a human readable way. Suppose the classical Hello World program. The output will be something like:

$ python stats_opcodes.py file

For Cortex-m3 (check previous post):

At my laptop (x86):

Download the script here.

Cortex-M3 and Qemu

Tiago Maluta — Wed, 23 Jun 2010 15:08:10 +0000

Just a small tip to test code generated for ARM Cortex-M3 using QEmu:

$ arm-none-eabi-gcc main.c -ggdb -mcpu=cortex-m3 -mthumb -T generic-m-hosted.ld
$ qemu-arm -cpu cortex-m3 ./a.out

You can download Code Sourcery toolchain here and QEmu here (also available from package management system of your favorite Linux distribution). Just unpack the toolchain associating the arm-201XqX/bin with your $PATH and run qemu.

Stellaris EKK-LM3S9b96 Evaluation Kit (1)

Tiago Maluta — Tue, 06 Apr 2010 03:15:21 +0000

O blog do Jê foi um dos canais brasileiros que anunciou o concurso promovido pela Texas Instruments e a revista Circuit Cellar. Como sempre tive curiosidade nos microcontroladores de 32bits da ARM resolvi me inscrever no concurso para receber o KIT. Com uma proposta semelhante (mas sem o concurso) a NXP, a um tempo atrás, distribuiu alguns microcontroladores da família LPC. Conheço muitos “hobbistas” que pediram as amostras mas assim que chegaram os custos para fazer uma placa (mesmo que um design simples para testar a funcionalidade) tornou o projeto inviável. A idéia do kit de desenvolvimento, na minha opinião, tende a popularizar melhor o uso (principalmente para quem gosta de fuçar).

Sinceramente já tinha esquecido da inscrição quando chegou na minha casa na semana passada… e só consegui fazer o hands on neste final de semana.

Veio com todas o itens para você começar a desenvolver, a placa principal com a MCU fabricada pela Luminary é a maior na foto, sendo a outra basicamente a interface USB com o computador (utiliza o chip da FTDI). Imagino que seja possível aproveitar em outros projetos. No kit há essencialmente:

80-MHz LM3S9B96 MCU
Ethernet MAC+PHY
CAN
USB OTG,
SafeRTOS na ROM, com uma cópia limitada do Keil RealView Microcontroller Development Kit
cables (USB e rede)
CD com documentação e software
Pendrive de 256MB

Vou descrever aqui as novidades que for aprendendo. A meta é testar no final de semana o SafeRTOS. Acredito que a presença do PHY Ethernet vai permitir implementações interessantes. Se você tiver alguma idéia sugira nos comentários.

First prototype for Beagle Board box

Tiago Maluta — Sat, 30 Jan 2010 15:14:51 +0000

After drawing a sketch for BeagleBoard this week I coud try something real. The board fit perfectly inside the box.

The whole for DVI-D would be a little bigger, the way it is the user need stick the connector well to don’t loose image quality.

The entries for USB and MMC fits together in the same whole. I put RS232 output because it’s a prototype, if you are developing something for an end-user you don’t need that. The box in my tests don’t heated

I’m using this box to show a “general purpose” computer to others. Inside the memory card I had some GNU/Linux distributions like: Angstron, Ubuntu and Gentoo. But Symbian and Maemo are in the roadmap. Other tests include running linus-git kernel done with CodeSourcery toolchain (2009q1 and 2009q3) and playing with armv7a instructions.

Check more photos on Flickr!

Byte Order

Tiago Maluta — Thu, 28 Jan 2010 22:03:58 +0000

In the book about Linux Kernel Programming the author Robert Love demonstrated a trick to check your hardware endianness.

int x = 1;
if (*(char *)&x == 1)
/* little endian */
else
/* big endian */

Using GCC you can use -mbig-endian or -mlittle-endian to generate appropriate endianess. Remember to check man pages section on your architecture (i.e: i386 and x86-64 don’t implement this option whilst IA-64 and ARM yes)

One interesting point regards on byte swapping. Suppose that you have a file that starts with 0xaabbccdd referring to little endian and 0xddccbbaa referring to big endian (note that I took these values and order arbitrarily). In order to use one kind of byte order in your code we need check what endianness your file was generated and if necessary rectify. This C++ code exemplifies.

class Endian {
 
     int _byteSwapped;
 
public:
 
     Endian(unsigned long dw) {
 
        if (0xaabbccddL == dw) _byteSwapped = 1;
        else if (0xddccbbaaL == dw)  _byteSwapped = 0; 
        else throw "error";
 
     }
 
     long rectify(long dw) const {
 
        if (!_byteSwapped) return dw;
        char result[4] = {((char*) &dw)[3],((char*) &dw)[2],((char*) &dw)[1],((char*) &dw)[0]};
        return (*((long*) result));
 
     }
};

Another way to do byte swapping is using an macro. The following example swap two bytes:

#define SwapTwoBytes(data) ( (((data) >> 8) & 0x00FF) | (((data) << 8) & 0xFF00) )

One of the best practices is provide one software that will work correctly no matter which processor Endian-architecture the code is executed on, eliminating the need to rewrite the code. Intel has a interesting paper on Converting Endian-specific to Endian-neutral Code (pg. 15-16).