This is our new webpage. If you prefer the old one, it's here. If something's not working right, let us know at contact@antmicro.com or use the contact form. Thanks!
 

Logo

 
 
 
 
 
 
 

Search

 
 
 
 
 
 
 

Partners & associations:

 
 
 
 
 
 

Archive for the ‘Operating Systems’ Category

May
14
2012
May 14th, 2012
SD controller driver for OpenRISC eCos

[If you are unfamiliar with the OpenRISC architecture or just want some help on setting up your OpenRISC work environment, we recommend the great tutorial from our friend Sven-Åke, working for our partner, Realtime Embedded.]

This week we are going to deal with SD card support for the OpenRISC eCos port, enabling the developer to have easily replacable, persistent storage for the platform, a welcome addition to any system. SD card support is generally scarce for the OpenRISC so this should be a good reference implementation for SD support on other OSs.

The SD Host controller used in ORPSoC is the sdcard_mass_storage_controller project from OpenCores. We have written a driver for the OpenRISC eCos that connects itself to the disk layer and commited it to the main OpenRISC eCos repository.

Thus it is very easy to configure eCos to support a filesystem on the SD card out of the box. In the Open Source eCos version we can choose between two popular filesystems: jffs2 and FAT.

For example, to prepare an eCos build with the FAT filesystem support, the following lines are necessary:

1
2
3
4
5
6
ecosconfig new orpsoc default
ecosconfig add CYGPKG_IO_DISK
ecosconfig add CYGPKG_IO_FILEIO
ecosconfig add CYGPKG_FS_FAT
ecosconfig add CYGPKG_BLOCK_LIB
ecosconfig add CYGPKG_LINUX_COMPAT

Before compilation it might be a good idea to configure some options, especially the name of the disk device, which defaults to /dev/mmcdisk0.

Once we’re ready, just like in last week’s post, we issue:

1
ecosconfig tree make

getting a compiled eCos with SD support. Also here the API is POSIX-compliant, which makes writing programs manipulating filesystems on SD cards easy and straightforward. A good example can be found in: packages/fs/fat/current/tests/fatfs1.c.

Note that in addition to the opencores repository, we’re now mirroring it on our github account for greater availability.

Tags: , ,
Posted in FPGA, OpenRISC, Operating Systems, Softcore, eCos | No Comments »

May
09
2012
May 9th, 2012
OpenRISC Ethernet driver for eCos RTOS

We have been maintaining the eCos real-time OS for openRISC for some time now, but what has been an obstacle to use it in a wider array of applications was the lack of suitable driver support enabling the construction of a platform featuring a richer set of interfaces.

In a series of posts, we have decided to amend this situation by writing, contributing and showing how to use drivers for some essential peripherals for ORPSoC.

The first peripheral we are going to work with is Ethernet.

We have written drivers to support OpenCores ethmac Ethernet controller (http://opencores.org/project,ethmac). It is already commited to main OpenRISC eCos repository which we’re maintaining.

The driver for the Ethernet controller will be automatically added to the eCos build if we select any network stack. We can pick from the following:

– TCP/IP stack from OpenBSD
– TCP/IP stack from FreeBSD (including KAME IPv6)
– Lightweight TCP/IP stack: lwIP (note: originally created by Adam Dunkels at the Center for Networked Systems at SICS, with whom we cooperate)

For example, in order to build eCos with the FreeBSD stack, the following steps have to be taken:

1
2
3
4
5
ecosconfig new orpsoc default
ecosconfig add CYGPKG_NET
ecosconfig add CYGPKG_NET_FREEBSD_STACK
ecosconfig add CYGPKG_IO_FILEIO
ecosconfig add CYGPKG_IO_ETH_DRIVERS

Before we proceed to compilation, we need to do some additional configuration of the driver and the network stack. The most important configuration options are of course the MAC address of the Ethernet controller itself as well as the IP address (either static or dynamically allocated via DHCP) of the device. The configuration can be done in two ways: either using the GUI program, configtool, or via editing ecos.ecc.

When we are done, we should issue:

1
2
ecosconfig tree
make

which results in a compiled eCos with Ethernet and TCP/IP support. The nice thing is that the network services API in eCos is POSIX-compliant, so the networking programs look and work just like Linux ones. It is best to look at some examples, residing in the packages/net/common/current/tests/ directory – especially ping_test.c and server_test.c are worth noting.

Note: the code described in this post is available here.

Tags: , , ,
Posted in FPGA, News, OpenRISC, Operating Systems, Softcore, eCos | No Comments »

Mar
23
2012
March 23rd, 2012
eCos-3.0 port to OpenRISC tracking mainline

Recently we have ported eCos-3.0 for the openRISC, and in other posts described how to reset the ordb2 board and how to build programs for it in the eCos.

We are hoping that this will be a solid piece of help for those who want to work with OpenRISC with a real-time operating system, and for those who want to use the new devboard from opencores.

Now the port has been updated to track the eCos mainline, thoroughly tested – passing all tests on the ordb2 board – and is hosted on OpenCores SVN.

Detailed instructions on using the port are published on the official wiki page.

Tags: , ,
Posted in OpenRISC, eCos | No Comments »

Mar
13
2012
March 13th, 2012
Running eCos on the OpenRISC ordb2 board

UPDATE: the eCos for OpenRISC is now tracking mainline eCos and more configurations are tested, so the whole procedure was a bit simplified!

Downloading the new version of eCos will be described in a new note and linked to here.

Ant Micro is maintaining and developing the eCos port for OpenRISC – you can find the wiki page of the port at the opencores server.

So far, the port was being tested in the or1ksim simulator which is considered a golden model of the OpenRISC1000 architecture. However, it’s always best to see how a port performs on real hardware.

Recently, ORSoC shared the new ordb2 development board with us. The board is based on Altera Cyclone IV E FPGA chip and is equipped with all popular interfaces.

To verify that everything works fine, we tested the eCos port on the board by running a set of eCos tests and simple multi-threaded programs.

Below are the instructions how to run eCos programs on ordb2 board. UPDATE: Not all configuration options are yet supported, but the default configuration is well tested and stable, so the .ecc file provided previously is no longer needed.

In order to build eCos for ordb2, follow these instructions:

1
2
3
4
5
6
mkdir ecos_openrisc
cd ecos_openrisc
ecosconfig new orpsoc
ecosconfig tree
make
make tests

After issuing these commands tt is possible to run eCos tests on the board. In order to upload the binaries using GDB, the or_debug_proxy program is needed.

Please note that FT4232 support was added to or_debug_proxy on 16th september 2011 – older builds will not work.

To establish a connection with board, issue the following command:

1
or_debug_proxy -r 50001

This will open a tcp port for the GDB RSP connection.

It is now possible to open a UART connection. Please note, that it is better to open the UART connection after starting or_debug_proxy. It is because or_debug_proxy causes the system to reorder USB devices when connected to the FTDI chip.

The configuration file assumes that the UART is running at a 115200 baud rate.

To open a UART device using picocom, issue the following command:

1
picocom -b 115200 /dev/ttyUSB1

The number next to ttyUSB may be different across systems.

Everything is ready to upload a test binary. We will use GDB and connect to or_debug_proxy.

1
2
3
4
5
or32-elf-gdb [test binary]
target remote :50001
load
spr npc 0x100
c

Now that we know how to connect to the board, let’s make a simple hello world application. A minimal eCos hello world program looks pretty standard:

1
2
3
4
5
#include <stdio.h>
int main(void) {
  printf("hello world\n");
  return 0;
}

To build the program, use the following flags with or32-elf-gcc:

1
2
3
4
5
6
7
or32-elf-gcc \
   -g \
   -Iecos_openrisc/install/include \
   -Lecos_openrisc/install/lib \
   -nostdlib \
   -Tecos_openrisc/install/lib/target.ld \\
   main.c

It is now possible to upload the resulting binary file the same way described above. Have fun programming for eCos on the openRISC devboard!

Tags: , ,
Posted in OpenRISC, eCos | No Comments »

Oct
31
2011
October 31st, 2011
eCos-3.0 port for OpenRISC

During our work with the OpenRISC platform we were missing our favourite real-time operating system – eCos. Although some porting work had been performed earlier, the eCos port was no longer supported. With the development of the OpenRISC project, as a result of toolchain and other changes, it had stopped working.

Also, it was based on the now obsolete 2.0 version of eCos.

We decided that a freshly updated eCos port could be useful both in our work and for the OpenRISC community, and here it is!

On http://opencores.org/or1k/ECos you will find the associated wiki page and from there you can download the code, of which Piotr Skrzypek is the maintainer.

Tags: ,
Posted in OpenRISC, eCos | 2 Comments »

Aug
25
2010
August 25th, 2010
Customizing Microblaze in QEMU

The Microblaze QEMU port contributed in 2009 by Edgar E. Iglesias from Axis Communications AB (Sweden) makes QEMU a very useful tool for Microblaze OS prototyping.

The problem is that the port is limited to emulating a fixed set of hardware (Petalogix s3adsp1800 Spartan3a board) with fixed addresses in memory, interrupt controller, timers, UARTs, ETH, etc.
Of course, you could adapt your application (e.g. Linux or eCos kernel) to take this limitation into consideration, but why make things harder than they should be? We’ve decided to simplify this process by removing the need to tamper with the kernel code. Instead, by making a few simple alterations to the QEMU, we allowed it to use an external “peripherial” file (“mb.per”) with hardware definitions.
An example “mb.per” file for the Petalogix board (think of it as the “default” file, as these are the settings QEMU originally starts with):

1
2
3
4
5
6
7
8
9
10
#
# petalogix s3adsp1800 board microblaze definition
#
fpgaid 0x0C000000
ddr 0x90000000 134217728
irq 0x81800000 0
sysbus xilinx,uartlite 0x84000000 3
timer 0x83C00000 0 2 62000000
eth 0x81000000 1
flash 0xA0000000 16777216

When QEMU is launched with the file above, it will run Microblaze @ spartan3adsp with 128MB of DDR memory mapped @ 0×90000000, irq controller @ 0×81800000, one UARTLITE serial @ 0×84000000, IRQ=3, two 62 MHz timers @ 0x83C00000, IRQ=2, one ethlite @ 0×81000000, IRQ=1 and 16MB flash driver @ 0xA0000000.
The idea is very simple, and the general shape of the .per file is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# fpgaid id
#    0x04000000 : Virtex2
#    0x05000000 : Virtex2pro
#    0x06000000 : Spartan3
#    0x07000000 : Virtex4
#    0x08000000 : Virtex5
#    0x09000000 : Spartan3e
#    0x0A000000 : Spartan3a
#    0x0B000000 : Spartan3an
#    0x0C000000 : Spartan3adsp
#    0x0D000000 : Spartan6
#    0x0E000000 : Virtex6
# ddr addr size
# irq addr sys_irq
# sysbus name addr irq
# timer addr irq count clock_speed
# eth addr irq
# flash addr size

Using this “fix” we’ve successfully started eCos and Linux kernels prepared by us for other targets (Spartan6).
All this data can be retrieved from the .dts/.dtb Device Tree file, so one idea for the future would be to make QEMU read the necessary information from the mb.dtb file.

Attached .diff file: qemu.diff.zip

Tags: , , ,
Posted in Linux, Microblaze, Operating Systems, eCos | No Comments »

Blog

Welcome to our blog. Explore it to find tutorials, open source contributions and reflections on our travels and events in which we participate.

 

About

Products

Services

Open Source

Contact

  • Ant Micro, Poznanska 62/34
  • 60-853 Poznan, POLAND
  • email: contact@antmicro.com
  • tel. (PL): +48 616 711 537
  • tel. (SE): +46 (0)8 559 22 557
 

Copyright © 2009 - 2012 ant micro. All rights reserved. | Design: Duind.com