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.