An Open Source ARM 4 Implementation

The ARM (Application Response Measurement) standard has been around for many years; first as a standard of the Computer Measurement Group (CMG) [CMG1], then as a standard of the Open Group [OPEN1]. Although it is currently in its fourth major revision, adoption by the industry has been limited at best.

One of the key limiting factors in the past has been the burden on the programmers to write code to the standard. This introduced a level of overhead that many coders found unacceptable, both in terms of coding cost and effort, and in terms of run time overheads. It's certainly possible to run programs coded to the standard without the overhead of measurement, but this involves either relinking against an empty library, or reconfiguring the collection agents.

The latest trend in the industry is to embed the instrumentation in the application containers, such as the web server [APACHE1,CART2004], the application server, or key system components such as the database server[MYARM1]. These efforts have proven much more successful and are starting to become the norm. Coders don't have to worry about a new API, and measurements can be taken at the discretion of the systems administrator or the capacity manager. In fact, they lead to a new class of tools that allow management software to adjust system resources to meet changing systems requirements [EWLM04].

Like all engineering efforts, fixing one issue usually shifts the problem to a different area. The successful development of new technologies that will effect the measurement of application response times still depends on the availability of a data collector. Many of the tools currently developed have depended on the developers also producing an ARM agent. For many, this is an undesirable exercise that is secondary to their primary development goal. Similarly, many in the open source community who've depended on inexpensive tools to continue their development have been without an adequate tool to collect ARM measurements. The ARM4.org project was instigated to address this glaring need.

Project Goals

The primary goal of this project is to provide an open source implementation of the ARM 4.0 [ARMC04,ARMJ04] and ARM 4.1[ARMC07,ARMJ07] standards. As the standard evolves, the project would continue to evolve along with it.

The target audience can be broken down into 2 main groups:

  • Developers – these are the people developing new tools and technologies, or those who wish to code applications that interface with the agent directly.

  • Enterprise Administrators – these are the people who just wish to use the data collector within their organization to manage their applications.

In its pre-production phases (pre 1.0), the tool will primarily be usable by the developers as architectures are fleshed out and management tools developed.

Portability is a primary design goal. Since the final product is intended to be used in production environments, the tool should be able to run on as many platforms as possible.

The tool should be as non-invasive as possible. Running the tool shouldn't consume so much of the systems resources that the tool becomes too cumbersome for wide scale deployment. Nor should it have such a significant impact on the instrumented applications that it becomes an unacceptable overhead.

Project Overview

Early development efforts were geared more towards building a solid and stable application architecture than to building a standards compliant collector. Different technologies were examined including message queuing and shared memory technologies, before the project finally settled on a hybrid architecture that used the best elements of each. Through all of this, portability was tested across a variety of platforms.

At this point, portability is limited to UNIX style platforms. It has been testes on Solaris 10, various flavors of Linux, and Mac OS X. With updates to the build system, it is likely to run on HP/UX, AIX, and other UNIX variants with minimal porting issues, but this has not been tested. Porting to Windows based platforms will follow once basic stability and performance issues are addressed.

At the time of this writing, version 0.6 of the agent is being prepared for release. This version will be of primary use to application developers, and isn't yet ready for enterprise deployment.

Architecture

The piece the application developer sees is the libarm4 library. This is a shared library that gets linked against the application that manages communications between the application and the agent. It's also capable of detecting when no agent is active. This has the effect of insulating the instrumented application from the agent in cases where problems with the agent might impact the application. Similarly, it also means the agent can be administered independently of the application.

Similarly, the piece the systems administrator sees is the arm4_daemon program, which is the actual collector.

Communications between the two elements is controlled by the shared memory region. Messages are passed from libarm4 to arm4_daemon using standard UNIX message queues, and the results sent back to the agent via data structures in the shared memory region. Synchronization objects are also contained in the shared memory region.

The key to operation is the shared memory region. Information from the agent is returned to the instrumented application by way of the shared memory. Inter-process communications are synchronized using semaphores contained in this region.

The data store keeps a permanent record of the measured data. While future versions will support multiple data stores, the current version uses the Berkeley DB data store. This is a fast, robust data store that allows for concurrent access from multiple threads and processes, and is available on many platforms.

There are also a number of support utilities that control the operation of the agent, and provide some rudimentary reporting. These are minimal at present and are designed to provide only the most basic functions for program control, debugging, and development.

Multi-Thread Support Issues

The system as designed is inherently multi-threaded. In the case of the arm4_daemon program, this improves concurrency and reduces latency. For libarm4, it becomes necessary to coordinate access to the shared memory region. No effort has been made to explicitly support single threaded applications. While this may cause some conflicts with single-threaded libraries on some systems, most applications should be able to link against the library with little difficulty.

Multi-Agent Support

The agent is designed to support multiple independent instances on a single system. Each instance gets its own shared memory region, and data store instance. In the case of the instrumented application, the instance is controlled by setting the ARM4_INSTANCE environment variable. The agent selects the instance through the instance parameter in its configuration file.

Access is controlled by the operating system. Both the instrumented application and the agent need access to the shared memory region. On the UNIX operating system, this is normally done through the use of group permissions. It is also possible to run the collector and the instrumented application in user space. This means a user can run a development environment without having systems administration privileges.


Program Control

The arm4_control program allows the systems administrator to control data collection without having to restart the agent or the application.

Some of the commands available are:

  • archive – create a dated archive of the data store. In addition to providing a data backup, it also allows the agent to age the data and prevent the data store from growing indefinitely.

  • collect – turn data collection on or off. This gives the administrator some discretion in terms of when data is collected.

  • remove – removes the shared memory region and synchronization objects leaving the database intact. This may be necessary when upgrading from one program version to another.

  • wipe – similar to remove, but also removes the database from the system.

  • status – verify the run state of a collector instance

  • stop – shut down the collector.


3.5 Reporting and Debugging

At this point in development, reporting is minimal. This will be expanded as the project progresses.

The arm4_report program provides two types of reports. The detailed report provides details on all transactions recorded by the system, while the summary report gives some overall statistics for all transaction instances.

The arm4_dump program gives a raw and unfiltered look at the internal databases. It is intended for debugging only.


Current Standard Support

The collector currently implements the C version of the 4.0 standard. While it should be possible to collect Java measurements using available Java libraries, this hasn't been tested. Java support, and 4.1 standard support, will be added in future releases.

Future Development

This project is still in its infancy and needs a number of features to make it an enterprise quality application. Development priorities in the order of importance are:


  1. Operational stability – the agent should run consistently, stably, and securely with minimal impact on the instrumented applications, and minimal resource requirements.

  2. Standards compliance – full implementation of the ARM 4.0 and 4.1 standards. This includes full Java and C language support. This may also include support for ARM 2[ARMC02] and ARM 3[ARMJ02] collection as well.

  3. Reporting – the ability to generate rich and complete reports on the applications across multiple tiers.

  4. Troubleshooting – generate alerts when an application fails to meet performance goals.

While the priorities can be summed up in these four simple points, the number of tasks left to accomplish is much larger. Details about the current project road map and development milestones can be obtained from the ARM4.org website[ARMORG1].

Summary

The ARM4.org project is well on its way to developing an ARM tool that developers and systems administrators can enjoy. While not yet an enterprise class application, it can provide the basis for the development of other ARM based tools. Of course, as an open source project, the price is right.

At this point, the field is wide open for a variety of projects based on ARM. Open source projects such as the MySQL database server, or the Geronimo application server could be instrumented. Instrumentation libraries for web languages such as PHP, or scripting languages such as PERL or Python would add a whole new dimension to performance management. Developers can now rest assured that the ARM tools they need will be available to them and to the users of their software.

References

[ARMC02] ARM 2.0 Technical Standard, available from http://www.opengroup.org/management/arm.htm/

[ARMC04] ARM Issue 4.0 Version 2 - C Binding, available from http://www.opengroup.org/management/arm.htm/

[ARMC07] ARM Issue 4.1 Version 1 - C Binding, available from http://www.opengroup.org/management/arm.htm/

[ARMJ02] ARM 3.0 Java Binding Technical Standard, available from http://www.opengroup.org/management/arm.htm/

[ARMJ04] ARM Issue 4.0 Version 2 - Java Binding, available from http://www.opengroup.org/management/arm.htm/

[ARMJ07] ARM Issue 4.1 Version 1 - Java Binding, available from http://www.opengroup.org/management/arm.htm/

[ARMORG1] ARM4.org Project Web Site, http://www.arm4.org/

[APACHE1] mod_arm4

https://svn.apache.org/repos/asf/httpd/mod_arm4/trunk/

[CART2004] D. Carter, “ARMing Apache”, CMG Proceedings (2004)

[CMG1] CMG. ARM Working Group

http://regions.cmg.org/regions/cmgarmw/index.html

[EWLM04] Enterprise Workload Manager, available from http://publib.boulder.ibm.com/infocenter/eserver/v1r1/en_US/index.htm?info/ewlminfo/kickoff.htm

[JOHN2004] M. Johnson, “Monitoring and Diagnosing Applications with ARM 4.0”, CMG Proceedings (2004)

[MYARM1] MySQL Instrumentation, http://myarm.de/solutions/mysql.html

[OPEN1] The Open Group. Application Response Measurement

http://www.opengroup.org/management/arm.htm/


Open-source ARM simulators

What's new?

2 May 2008
There is a more recent list of ARM simulators here.
17 Jan 2006
Added QEMU and SimpleScalar
4 Nov 2005
Added "ARMem" ARMulator derivative and ARMphetamine processor simulators

Summary

For internal development and for customers' use it would be useful to be able to simulate Sim-One in software.

The project that is closest to simulating the Sim-One is "skyeye" (see below), which succeeds in simulating the EP9312 development board, the big brother of our own EP9307, to run uclinux, armlinux and ucosii.

This document is a survey of all the simulators that I have looked at.

Types of simulator

The simulators fall into three categories:

  • Processor simulators: Those capable of running an ARM executable (an application) within an operating system running on a non-ARM processor by simulating a single-process memory space and the logical operation of the processor upon it. These permit the testing of single ARM programs.
    Examples are: GNU ARM simulator, Simit-ARM.
  • System simulators: Those capable of running an ARM operating system on a non-ARM processor within a different operating system by simulating the processor, physical RAM banks and the logical operation of peripheral devices. These permit the testing of entire operating systems on simulated development boards or computers.
    Examples are: skyeye, SID.
  • Physical simulators: Those that take a list of components and the connections between them and simulate their operation at an electrical level. The simulation may be digital, analog or a mixture of the two. These permit the testing of hardware designs from their schematics.
    Examples are: ngspice.

1. Processor simulators

GNU Arm Simulator

Also called "GNUPRO Arm Simulator" or "ARMulator".

gdb contains an ARM simulator, which simulates ARM7TDMI architecture and probably others.

You run binaries produced by gcc by using gdb and saying:

gdb> target sim
a derivative is ArcEm which also simulates the hardware of the Acorn Archimedes computer.

Simit-arm

Produced by the Gigascale Research Centre, it compiles to binaries called
  • ema ARM instruction set simulator
  • ema_count ARM instruction set simulator, counting use of each type of instruction
  • sima ARM cycle-accurate simulator
It does indeed run ARM linux executables in an x86 linux environment.

It does:

  • read ELF32 little-endian arm-linux binaries,
  • emulate the SA-1100 processor,
  • emulate ARM floating-point instructions (by Netwinder FPE library)
  • cycle-accurate timing

It doesn't do:
  • Thumb instructions
There is (or was) a multi-processor version of it called "arm-sim" from the same organisation, but it is no longer actively developed and you need a gigascale login to get it, which is only available to the organisations that fund Gigascale Research.

ARMphetamine

"is an on-going project by Julian Brown to develop a fast ARM emulator, including dynamic recompilation of ARM instructions to the host processor, currently x86. The source code is available under the GNU GPL."

SimpleScalar

An open-source commercial product with free license for non-commercial use. Emulation is said to produce highly detailed timing reports, widely used ni academic community for research projects.

QEMU

A free open-source simulator that can run as a processor simulator or as a system simulator. It runs under Linux or Windows and and simulates several types of processor including x86, x86_64, ARM, SPARC and PowerPC. Under it you can run (among others) FreeDOS, GNU/Linux, OS/2, NetBSD and Windows 3.11, 95, 98SE, ME, 2000 and XP.

2. System simulators

skyeye

Produced in China, it seems to be based on the GNU ARM simulator, and includes support for the Cirrus Logic EP9312 chip which is the same as Sim-One's main chip, the EP9307, plus an IDE interface.

It runs uclinux, armlinux, uC/OS-II ond FreeBSD, and they provide drivers for simulated LCD panel, n2k network device and more for these operating systems.

I have succeeded in compiling and running skyeye-0.8.7 (5 Jun 2003), but I have not tried running an OS on it.

SID

Available from sources.redhat.com/sid

SID is a complete pin-level system simulator containing a library of system components including the ARM7T architecture (Thumb instructions only, no 32-bit ARM, and no Floating Point).

I found this more understandable than skyeye (which remains a mystery to me) but it would need a lot more work to emulate Sim-One's ARM920 and our peripherals.

3. Circuit simulators

ngspice

Based on the venerable Spice circuit simulator from Berkeley, now entirely open-source. Available from Part of the gEDA project.

Does mixed digital and analog-mode simulation.

Higher-level suites

Several projects aim at uniting the circuit design and simulation programs into a single design environment. All are based on ngspice as the circuit simulator and PCB as the layout tool.

gEDA

Convergence

http://bach.ece.jhu.edu/~tim/programs/convergence/convergence.html

Using Visualization Tools to Study the Atmosphere:
The ARM Project

Instruments at the SGP Site


Balloon-Borne Sounding System (BBSS)

These weather balloons are released from the ARM sites. As they ascend they measure and transmit air pressure, temperature, relative humidity, and can help determine wind speed and wind direction. From this information scientists can also derive dew point, latitude and longitude of the balloon, and other components of wind.

Student Lesson and Activity


Surface Meteorological Observation System (SMOS)

This system uses conventional weather instruments to make surface measurements of wind speed, wind direction, air temperature, relative humidity, barometric pressure, and precipitation. Snow depth can also be measured at the SMOS.

Student Lesson and Activity


Radiometers

Radiometers measure radiant energy. The type of radiometer shown is from the Solar Infrared Radiation Station (SIRS) and is used to measure both solar and atmospheric radiation. The radiation can be coming from above (downwelling) or upward from the surface (upwelling).

Student Lesson and Activity


Millimeter Wave Cloud Radar (MMCR)

The MMCR transmits a radar pulse directly overhead to determine the tops and bottoms of clouds. It can also serve as a type of Doppler radar in measuring up and down particle movements within a cloud.

Student Lesson and Activity


Radiometric Calibration Facility (RCF)

The value of any scientific data is dependent upon the accuracy of the instrument through which it was measured. The RCF is used for accurate calibration of radiometers.


Microwave Water Radiometer (MWR)

This instrument is a microwave receiver that measures columns of water vapor and liquid water in the air.

Student Lesson and Activity


Micropulse Lidar (MPL)

This instrument uses lidar (light detection and ranging) which is similar to radar. A pulse of energy is transmitted and reflected back. The measured time delay between the original pulse and the reflection is used to determine cloud altitude.

Student Lesson and Activity


Radar Wind Profiler (RWP)

This instrument measures wind profiles ( cross-sections ) up to 5 km and temperature profiles up to 1.5 km. It does this by transmitting both electromagnetic signals and sound waves into the air.

Student Lesson and Activity


The Aerosol Observing System (AOS)

This instrument makes surface measurements of aerosols which are tiny solid or liquid particles suspended in the air. Some examples would be smoke, dust, or fog. Scientists hope to use this data to better understand how these particles may interact with solar radiation and influence the earth's radiation balance and climate system.


Energy Balance Bowen Ratio (EBBR)

This is a system of senors which monitor the exchange of heat between the ground and the air above it.


60 Meter Tower

Temperature and relative humidity sensors are located at 25 meters and 60 meters on this tower to supplement other surface measurements.

GNU ARM toolchain

GNU ARM toolchain for Cygwin, Linux and MacOS

Welcome! In this page you will find a pre-compiled binary distribution for the (hopefully) latest GNU ARM/Newlib toolchain for Cygwin, Linux and MacOS.

The toolchain consists of the GNU binutils, compiler set (GCC) and debugger (Insight for Windows and Linux, GDB only for MacOS). Newlib is used for the C library. The toolchain includes the C and C++ compilers. Details of the build process appear here. The Windows installer executable files are generated with Inno Setup. The MacOS toolchain is bundled with Apple's PackageMaker.

If you have any problems using these files please use the mailing list for community-based support.

Check out our resources section for useful pointers, projects and tools. Contact us if you wish your site to be listed there.

Please note: Some people have been asking us for permission to re-distribute the GNUARM installer and associated files along with their commercial products. This is totally encouraged provided that the software licenses are fulfilled and that there are no charges except for, possibly, a small fee for the media and handling. In this way you will be helping both the GNUARM project and your customers.

News

[2006-08-01]
GNUARM 4.1.1 for Windows released.
[2006-03-15]
GNUARM 4.1.0 for Windows released.
[2006-02-18]
GNUARM 4.0.2 for Linux x68_64 is available.
[2006-01-28]
GNUARM 4.0.2 for Windows uploaded.
[2005-07-17]
GNUARM 4.0.1 for Windows and Linux x86_64 uploaded.
[2005-04-27]
GNUARM 4.0.0 for Windows uploaded.
[2004-11-12]
GNUARM 3.4.3 uploaded.

Debian GNU/Linux on ARM

On these pages you'll find information about the ongoing effort of porting Debian GNU/Linux to the ARM architecture which is often found in embedded systems.

Current Status

Debian fully supports a port to little-endian ARM. The ARM EABI (armel) port has been integrated in Debian and the old (arm) port is deprecated.

As of our latest release, Debian GNU/Linux 5.0.0, the following ARM sub-architectures are fully supported:

  • footbridge: we fully support Netwinder machines and Simtec's CATS evaluation board
  • iop32x: we support some IOP32x based Network Attached Storage (NAS) devices, such as the Thecus N2100 and GLAN Tank
  • ixp4xx: we support the popular Linksys NSLU2 device.
  • orion5x: we support Marvell's new Orion platform and we have specific support for a number of devices, including the QNAP Turbo Station (TS-109, TS-209, TS-409) and HP mv2120.

General Information about ARM

Please see the release notes and installation manual for more information.

Available Hardware for Debian Developers

agnesi.debian.org (arm) and agricola.debian.org (armel) are available to Debian developers for ARM porting work. The machine have development chroot environments which you can access with dchroot. Please see the machine database for more information about these machines.

Contacts

Mailing lists

The Debian ARM port mailing list is located at debian-arm@lists.debian.org. If you wish to sign up, send a message with the word subscribe as the subject to debian-arm-request@lists.debian.org. The list is archived at the debian-arm list archives.

It's also a good idea to sign up with the linux-arm mailing list.

IRC

You can find us on IRC on irc.debian.org on the channel #debian-arm.

People

This is a list of significant people who are currently involved in the Debian ARM port.

Available Projects and Information (Content)

"Last updated" may be just additional information not always a new version of a software-package. All presented LPC2106, LPC2129 and LPC2138 projects should work with minimal modifications in the linker-scripts and source-code on all Philips LPC2xxx controllers. Most of the code should also work on other ARM7TDMI controllers after small modifications.

If you think that I could help you with your projects: just send an e-mail. I'm looking for "freelance"-jobs.


If you send me an e-mail: Please use your full name (your _real_ full name). And it's always nice to get some kind of feedback if an answer to a question did help or did not help. I often spend a lot of time answering e-mails and would at least like to know if my suggestions did or did not help solving a problem.



WinARM

WinARM is a collection of GNU and other tools to develop software for the ARM-family of controllers/processors on MS-Windows-hosts. Unlike other collections WinARM does not depend on a cygwin or mingw-environment. All needed tools are in the distribution-package. WinARM has been tested with Philips LPC2106, Philips LPC2129, Philips LPC2138, Philips LPC2148 and Atmel AT91SAM7S64, AT91SAM7S256, AT91RM9200 ARM7TDMI(-S) controllers (the list is based on own tests and user feedback). The gnu-toolchain and the supplied tools should work with all microcontrollers based on ARM(-TDMI/Thumb etc.) architecture. WinARM has been made in the spirit of WinAVR which is a collection for Atmel AVR 8bit-Controllers.

WinARM includes in Version 20060606:

  • GNU-C/C++-Compiler (cross compiler/linker/assembler arm-elf-*) Version 4.1.1 incl. stdlib3. Compiled from the FSF-Sources The configuration supports ARM-Mode, Thumb-Mode and Mixed(ARM/Thumb)-Mode, little/big-endian and floating point-emulation
  • GNU-Binutils Version Version CVS 20060606 FSF-Sources
  • newlib Version 1.14.0 (build for reentrant syscalls)
  • newlib-lpc Rel.5a (reentrant syscalls for newlib and Philips LPCs)
  • GNU-Utils to support the compiler/linker (make, sh etc. from the mingw-project)
  • ARM header-files (register-defintions) from gnuarm.org and others
  • Example applications with full source-code, makefiles, linker-scripts and startup-code for Philips LPC2000, ADuC7k and Atmel AT91SAM7 ARM7TDMI controllers. More Examples on my ARM-Projects pages.
  • Programmers Notepad Editor Version 2.0.6.1
  • The lpc21isp in-system-programming-software for Philips LPC2xxx and the Analog Devices ADUC 70xx family by Martin Maurer. Included Versions: 1.31 and 1.37(BETA)
  • Bray Terminal by Vlado Brajer
  • Insight-GDB 6.5.50-20060517 - Win32-Native from devkitpro.org
  • gdb (command-line without Insight) GNU gdb 6.4.50.20060226-cvs from Codesourcery
  • Setup-Exe of Macraigor's OCDRemote (Wigger-gdb interface, Ver. 2.16)
  • Open On-Chip debugger (OpenOCD, SVN Version 65) made by Dominic Rath, update available further down.
  • H-JTAG (Ver. 0.2.1 beta 20060402) made by "twentyone"
  • J-Link gdb-Server V1.0 from the gnuarm yahoo-group

Planned extensions:

  • Installer

User-Forum: A support-forum for WinARM/arm-elf-gcc and the example-projects. You are invited to visit this forum and ask questions or help others.

Download by right-click->save as, please download only one of the archives either the zip or the self-extracting-archive. The contents is the same. Please respect all licenses of the included components. WinARM itself has no additional license.

or

  • Download the same version but packed with a different packer (7zip) and available as self-extracting-archive here (just ca. 44 Megabytes).

Please do not use download-managers with more than 5 parallel connections! (There are people who use >30 parallel connections.) Download only one of the archives (zip or the self-extracting archive). Both archives have the same content, which has just been packed with a different method. I will be forced to throttle the server and use traffic-shaping if this habbits do not stop.

Mirror sites:

Updates and Add-Ons:

  • Gérald/dupon jean has sent a ARM makefile-generator similar to Jörg Wunsch's mfile (for AVR). It can be downloaded here.
  • Michael Fischer modified gdb to improve compatibilty with Eclipse. His gdb-Version is available here.
  • A zip-Archive with Dominic Rath's OpenOCD (including some drivers and information) built for Win32 (using MinGW/msys) is available here (ARM7/ARM9/Cortex-M3/XScale for ParPort and FTDI FT2232 interfaces, Mainline/Trunk SVN994). Some packages of older versions can be found here
  • OpenOCD (MS-Windows "native build") including an installer is available from Michael Fischer's Yagarto pages.
  • lpc2129_adc_stdio example-update
  • Updated AT91SAM7s-examples
  • MS Windows-binary of lpc21isb V1.43 (beta).
  • Test-release WinARM 20070505: release-notes, Download (self-extracting archive created with 7-zip, 118MB(!)), Download (zip-Archive, 180MB(!))
  • Another test-release: WinARM 20080331. Based on GNU Binutils 2.18.5, GNU gcc 4.3.0 (C/C++), newlib 1.16, GNU gdb 6.8 (with XML and TUI support), OpenOCD SVN527. The precompiled toolchain offers thumb2 support (i.e. for Cortex-M3 like LuminaryMicro LM3S and STMicro STM32.) Again: just a test-release, preliminary tests with examples for LM3S811 and STM32F103 worked as expected. Download the 20080331 test-release [here] (ca. 37MB, no examples included)

WinARM and Keil/ARM uVision

Jaroslav Ban from the Technical University Kosice kindly contributed some files which help to integrate the GNU-Tools from WinARM (arm-elf-gcc/arm-elf-as) into the Keil/ARM uVision IDE. There is a readme-file in the archive with installation- and usage-instructions. (Update mthomas 20070913: objcopy-"glue" for "create hex-file"). [Download] (glue-package version 20070913).

WinARM and Microsoft Vista

Adriaan Beluga has sent the following e-mail: Thanks for your suggestions. With them I managed to get everything to work again under Vista ! ;-) In the end I only needed to modify the path in my batch file which starts "pn.exe". Here is what it looks like now:

@echo off
set ARM=c:\WinARM
set PATH=%ARM%\libexec\gcc\arm-elf\4.1.1;%ARM%\bin;%ARM%\arm-elf\bin;%ARM%\utils\bin;
start /b pn

Thanks to Adriaan for testing WinARM with Vista (I currently do not have access to a PC running Vista). Users who do not use a batch-file to start Programmers-Notepad or another editor may add the entries to the system search-path from the Workplace properties. So where Windows NT/2K/XP users just added C:\WinARM\bin;C:\WinARM\utils\bin Vista users add C:\WinARM\libexec\gcc\arm-elf\4.1.1;C:\WinARM\bin;C:\WinARM\arm-elf\bin;C:\WinARM\utils\bin .

Information from Michael Langfort: I’m using the 20060606 version of WinARM on Vista Home Premium. When I tried to build a WinARM-based project (that builds fine on WinXp), I got an error:

1>arm-elf-objdump -h -S -C app.elf > app.lss
1>/usr/bin/sh: /c/winarm/bin/arm-elf-objdump: Invalid argument

FreeBSD/ARM Project

Introduction

This page contains information about the FreeBSD port to the ARM architecture and hardware. Discussion of the ARM port takes place on the freebsd-arm mailing list.

Table Of Contents

Status

ARM is officially a Tier 2 architecture, as the FreeBSD project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena. However, FreeBSD/ARM is being actively developed and maintained, is well supported, and provides an excellent framework for building ARM-based systems.

FreeBSD/ARM Hardware Notes

FreeBSD should work on the i80321 based Intel XScale® devboards, which includes the IQ31244 and IQ80321 boards. Support is still minimal, covering only the CPU, PCI-X bus, em(4) Ethernet adapters, the UART and timer devices.

The i80219 XScale processor is supported, as is the EP80219 devboard.

The IXP425 is supported, as is the Avila GW2348-4 devboard.

The Atmel AT91RM9200 CPU/Microcontroller range is supported. Support is provided for the Kwikbyte KB9202 devboard range, the BWCT board and the Hot-e HL200 thin client device.

Minimal support for the StrongARM 1100 CPU is provided, but only within the limits of what Simics emulate: CPU, UART and clock. It is theoretically possible to boot on the Assabet board, the one Simics emulates; no attempts, successful or unsuccessful, have been reported.

Additionally, support for the Technologic Systems TS-7200 devboard is in the works, as is support for the Atmel AT91SAM926x CPU and the Mavell Orion ARM SoC, the Samsung S3C2XX0 range, and Cirrus Logic EP93XX CPUs.

What Needs To Be Done

  • SATA support needs to be added.
  • Other devices, such as watchdog, i2c and bus should be merged from NetBSD.

FreeBSD/ARM Related Links

Mini-Install guide

Olivier Houchard (cognet@FreeBSD.org) has written a mini-install guide for the current FreeBSD source. It is available here.

FreeBSD/ARM mailing list

To subscribe to this list, send mail to or visit mailman interface.

ARM Boot Projects

ARMboot is an Open-Source firmware suite for ARM based platforms. ARMboot is heavily based on the sister-project PPCboot, which provides similar functionality on PowerPC based systems. ARMboot shall be a common, easy-to-use and easy-to-port boot platform
Overview ARMboot 1.1.1
ARMboot is a firmware monitor/bootloader for embedded systems based on ARM or StrongARM CPUs. The primary objectives for this software is to be easily porTABLE to new platforms while being as powerful as possible. To date it is the only GPL'ed ARM firmware capable of supporting multiple types of flash memory, network download via bootp, dhcp, tftp, PCMCIA CF booting and more.

ARMboot is heavily based on the sister project PPCboot. It is planned, to move both projects even close together to increase their robustness and mutual benefit.

Getting ARMboot ARMboot 1.1.1

ARMboot is hosted on Sourceforge: http://www.sourceforge.net/projects/armboot Please also refer to navigations on the left.

The latest version can always be obtained via the anonymous CVS access of Sourceforge. Tarballs are released sporadically, and can be downloaded from the same site.

Features / Supported Hardware ARMboot 1.1.1

Ports are available for the following platforms:
StrongARM - LART, SSV DNP1110, Shannon (Tuxscreen)
ARM720T - implementaA7, CLEP7312
PXA250 - Lubbock, Cradle

Supported Hardware
Board Configuration Notes
LART
SSV DNP1110
Shannon
implementa impA7
CLEP7312
S3C2400X
SDMK2410X
EPXA1DB
Cradle
Lubbock
lart_config
dnp1110_config
shannon_config
impa7_config
ep7312_config
samsung_config
sdmk2410_config
epxa1db_config
cradle_config
lubbock_config
"Linux ARM Radio Terminal"
SSV DilNET PC (with flash support)
Tuxscreen (with support for IrDA keyboard, LCD screen)
EP7211 based
Cirrus Logic EP7312 Dev. Board
Samsung S3C2400X
Samsung SMDK2410X Eval Board
Altera EPXA1 Development Board
HHP PXA250 Infrared to Ethernet router
Intel PXA250 Development Platform

Building ARMboot ARMboot 1.1.1

The following informations are also included as README when downloading the TGZ.

To configure and build ARMboot you will need a GNU cross development tool-chain configured for arm-linux. You should NOT need any linux header files. If so, please report this on the mailing list.

The cross development tools usually have a target specific prefix. For instance, your cross compiler may be called "arm-linux-gcc" or "arm_armv4-gcc". This prefix can be passed to the Makefile by setting the CROSS_COMPILE variable, which defaults to "arm-linux-".

The following example is for the "LART" board:
1. Configure
sh# make lart_config
rm -f include/config.h include/config.mk
Configuring for lart Board...

2. Build
sh# make all
...
arm_armv4-objcopy -O srec armboot armboot.srec
arm_armv4-objcopy -O binary armboot armboot.bin

Essential ARM Cortex-M3 assembly language ideas for embedded systems programmers

Cortex-M3 processors are designed to be easy to program in C; but it is important that we gain some understanding of the processor instruction set.

The best way to get started is to read the code which the C compiler generates.

Register basics

Cortex-M3 processors support instructions which are 16 bits or 32 bits long; the instruction set is called Thumb-2.

Cortex-M3 processors have 13 general purpose registers (r0 to r12). Register r13 is treated as the stack pointer, r14 as the link register and r15 as the program counter.

There are three special purpose program status registers - the Application PSR, Interrupt PSR and Execution PSR. They can be accessed as individual registers, any combination of two from three, or a combination of all three using the instructions MRS (move to register from status) and MSR.

The Application PSR holds the condition flags, the Interrupt PSR contains the number of the exception currently active.

Restrictions on register usage

Registers r0 to r7 can be used by all instructions that specify a general purpose register.

Registers r8 to r12 are accessible by all 32 bit instructions which need a register argument - but these registers are not accessible to all 16 bit instructions.

The least significant two bits of the value in SP are always zero - this makes it auto-aligned to 4 byte boundaries. The least significant bit of PC is zero - so instructions have to be aligned at 2 byte or 4 byte boundaries.

The Link Register (LR) holds the return address after a Branch and Link (BL) or a Branch and link with exchange (BLX)

Understanding the working of a few important instructions

Reading the assembly code produced by the compiler helps us identify the important instructions. Putting a few such instructions in an asm file and tracing the code with gdb gives us a good idea as to how these instructions work.

Here is an example program:

       .syntax unified

.cpu cortex-m3
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 6
.eabi_attribute 18, 4
.thumb
.file "b.c"
.word 0x20001000
.word main
.thumb
.text
.align 2
.global main
.thumb
.thumb_func
.type main, %function
fun1:
mov r5, #0x23
bx lr
main:
.L2:
mov r0, #0
mov r1, #0
mov r2, #0x10
mov r3, #0x55
movw r7, #0x0
movt r7, #0x2000
movw r0, #0x1234
movt r0, #0x5678
mov r1, #1
push {r0, r1}
add r0, r0, r1
add r0, r1, r2

sub r0, r2, #2
str r0, [r7, #12]

bl fun1

mov r0, #0
mov r1, #0
pop {r0, r1}

b .L2
.size main, .-main
.ident "GCC: (Sourcery G++ Lite 2008q3-66) 4.3.2"

Here is part of the output produced by objdump:

a.out:     file format elf32-littlearm


Disassembly of section .text:

00000000 -0x8>:
0: 1000 asrs r0, r0, #32
2: 2000 movs r0, #0
4: 000f lsls r7, r1, #0
...

00000008 :
8: f04f 0523 mov.w r5, #35 ; 0x23
c: 4770 bx lr

0000000e
:
e: f04f 0000 mov.w r0, #0 ; 0x0
12: f04f 0100 mov.w r1, #0 ; 0x0
16: f04f 0210 mov.w r2, #16 ; 0x10
1a: f04f 0355 mov.w r3, #85 ; 0x55
1e: f240 0700 movw r7, #0 ; 0x0
22: f2c2 0700 movt r7, #8192 ; 0x2000
26: f241 2034 movw r0, #4660 ; 0x1234
2a: f2c5 6078 movt r0, #22136 ; 0x5678
2e: f04f 0101 mov.w r1, #1 ; 0x1
32: b403 push {r0, r1}
34: 4408 add r0, r1
36: eb01 0002 add.w r0, r1, r2
3a: f1a2 0002 sub.w r0, r2, #2 ; 0x2
3e: 60f8 str r0, [r7, #12]
40: f7ff ffe2 bl 8
44: f04f 0000 mov.w r0, #0 ; 0x0
48: f04f 0100 mov.w r1, #0 ; 0x0
4c: bc03 pop {r0, r1}
4e: e7de b.n e
Instruction: movw r0, #0x1234

Action: set r0 = 0x00001234
Instruction: movt r0, #0x5678
Action: set r0 = 0x56781234
Note: The movw/movt combination is used to move a 32 bit constant into a register
Instruction: push {r0, r1}

Action: Stack pointer register's value gets decremented by 4 and content of r1 gets stored at the location pointed to by sp;
sp gets decremented by 4 once again and value of r0 gets stored at the location pointed to by sp.
Instruction: pop {r0, r1}
Action: The 4 byte value at the location pointed to by sp is copied to r0 and sp is incremented by 4.
The 4 byte value at the new location pointed to by sp gets copied to r1 and sp is once again incremented by 4.

Instruction: add r0, r1, r2
Action: r0 = r1 + r2
Instruction: sub r0, r2, #2
Action: r0 = r2 - 2
Instruction: str r0, [r7, #12]

Action: store content of r0 to memory location whose address is computed by taking the value in r7 and adding 12 to it.
Instruction: bl fun1

Action: This instruction transfers control to //fun1// and sets the //link registers// value to the return address.
Instruction: bx lr
Action: Copies the content of lr to //pc//, the //program counter//.

Let's check out the code which the compiler generates for the following C program:

int fun1(int a, int b)

{
return a + b;
}

main()
{
int i;
i = fun1(10, 20);
}

Here is the assembly language output generated by running:

arm-none-eabi-gcc  -mcpu=cortex-m3 -mthumb -S a.c
fun1:

@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
push {r7}
sub sp, sp, #12
add r7, sp, #0
str r0, [r7, #4]
str r1, [r7, #0]
ldr r2, [r7, #4]
ldr r3, [r7, #0]
add r3, r2, r3
mov r0, r3
add r7, r7, #12
mov sp, r7
pop {r7}
bx lr
.size fun1, .-fun1
.align 2
.global main
.thumb
.thumb_func
.type main, %function
main:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 1, uses_anonymous_args = 0
push {r7, lr}
sub sp, sp, #16
add r7, sp, #0
mov r0, #10
mov r1, #20
bl fun1
mov r3, r0
str r3, [r7, #12]
add r7, r7, #16
mov sp, r7
pop {r7, pc}
.size main, .-main
.ident "GCC: (Sourcery G++ Lite 2008q3-66) 4.3.2"

Register r7 is used as a frame pointer. The first instruction in main pushes lr and r7 onto the stack. The last line in main restores r7 from the stack and also copies the saved value of lr to pc, transferring control back to the function which called main.

The instruction:

sub sp, sp, #16

creates space on the stack to hold local variables in main. r7 is made to point to the new top-of-stack. The arguments to fun1 are stored in r0 and r1 and control gets transferred to fun1. Within fun1, sp is again decremented to create space on the stack to hold the parameters 10 and 20. The two instructions:

str r0, [r7, #4]

str r1, [r7, #0]

copy r0 and r1 to two consecutive locations on the stack.

The next two instructions fetch these values from memory into the registers r2 and r3:

ldr r2, [r7, #4]

ldr r3, [r7, #0]

sums up the two values and stores the result in r3, which is then copied to r0 (r0 is the register which holds return values).

The stack pointer is taken back to its original value:

add     r7, r7, #12

mov sp, r7

And contrl goes back to main:

bx      lr

The value returned from fun1 gets copied to a position on the stack corresponding to the integer variable i:

mov     r3, r0

str r3, [r7, #12]

ARM Phetamine

Overview

ARMphetamine is a project to create a fast and accurate ARM processor emulator. A technique known as "dynamic recompilation" will be used so that the highest possible speed can be achieved for emulated code - ARM code programs are translated into native code as they are being emulated. The current development platform is Linux/x86.

It is possible to configure ARMphetamine at compile time to support different processor revisions and hardware models. Check out the CVS source to find out more. ARMphetamine is currently not being written very much.

There is currently no projected release date. It would be a foolish thing to try to guess. If you'd be interested in building an emulator around ARMphetamine or incorporating it in an existing project, feel free to get in touch.


News

Early 2003

You may have noticed the dynarec.com site is dead and gone. Cheers Neil, I've said it before, but thanks for hosting my site for all that time.

As for the code, I think some of the dependency problems which crept in after reorganisation have mostly gone away now. Update your CVS tree if you haven't already.

22 November 2002

There's very much internal reorganisation of the ARMphetamine sources, so that now all the parts of it are separated into nice logical units. There are multiple makefiles for the different "personalities" that the emulator is capable of assuming (LART emulation, Riscose backend, etc.). There are even some basic instructions, in the README file.

21 September 2002

You might have noticed there hasn't been much news about ARMphetamine recently. I've been busy doing other things. In the small amount of time I've dedicated to the project, the focus has been attempting to boot a Linux kernel - this means quite a lot of fiddly code needs to be written and bugfixed. If I get it going, this will be the place I report it. If you have in-depth knowledge of ARM Linux or the SA-1100 chip, maybe you'd be interested in grabbing the code from CVS and hacking it a bit, I'd be grateful for help (in the form of patches, preferably). I'm using blob, kernels and ramdisk from the LART project.

The furthest it's got so far is (failing) to mount a root filesystem under interpretive emulation. To try it, obtain the right versions of blob, a kernel and ramdisk image from the LART page, name them appropriately and type "make lartrun" in a suitable environment. Enjoy!



Status

Some preliminary (very old!) comparative benchmarks are available:

Processor [recomp] Compiler/OS Platform Dhrystones/sec
ARMphetamine [off] GCC/NetBSD Linux/x86 5527
12MHz ARM250 Norcroft/RISC OS RISC OS/arm26 6169
ARMphetamine [on] GCC/NetBSD Linux/x86 34843
233MHz StrongARM GCC/NetBSD NetBSD/arm32 275482
450MHz AMD K6-2 GCC/Linux Linux/x86 823045

These benchmarks were obtained using the standard (if aging) "Dhrystone" program (higher numbers are better). As you may infer, the emulator currently runs somewhere around the speed of an ARM610 on my development machine. Performance increases are expected.


Documentation

There are two main documents describing ARMphetamine. The first is older and more likely to be out-of-date, the second is the dissertation I wrote as part of the university project ARMphetamine was written for.

  • View the older HTML document here.
  • Download the postscript dissertation here.
  • My thoughts on further work to be done on the project here.
  • The new intermediate representation.
  • ARMphetamine 2 information.
  • Pheta3 information (soon - 4 March '03... pheta2 is good 'til I want to support more architectures I think)

Download

The preferred way of getting hold of ARMphetamine now is by anonymous CVS from Sourceforge. Follow this link for instructions. The modulename is "armphetamine".

You can download a tarball of the ARMphetamine source code here, but it might not be the absolute latest version (in fact it's a very, very old version).

Download armphetamine-0.2.tar.gz.

Enjoy...


Feedback

You can get in contact with me about ARMphetamine at brown@cs.bris.ac.uk. If that doesn't work for whatever reason, you could try julesb@btinternet.com instead. I'd appreciate it if you didn't send mail in HTML format.


Links

A few links relating to dynamic recompilation and ARM emulation in general...