Archive for the ‘FPGA’ Category

March 13th, 2013
Preview of Android for the Enclustra ZX3 Zynq module

It’s been some time since we last wrote about the Zynq, which is not to say that we have stopped to deal with this great technology. It’s interesting to see the process of its adoption and how it brings people from two neighbouring worlds – embedded software and FPGA – together.

Just to whep up your appetite on what we are doing now, a video of Android running on the Enclustra Mars ZX3 module.

The Zynq module running our port of Android was presented at or joint stand with Enclustra at Embedded World 2013 in Nurnberg, and gathered a lot of positive feedback, since the dual-core ARM Processing System of Zynq is more than capable of running the system smoothly, and the Programmable Logic gives a lot of additional possibilities.

Alongside the physical hardware, we also demoed our virtual platform solution, Emul8, running the same Android binary on a PC. We were positively surprised with the interesting conversations and leads this sparked up!

A full account of Embedded World, with all the developments in the industry that might be of interest as well as our impression on where the market is going will follow soon.

As for the Android port, soon we will be publishing it while continuing our work on our GitHub, courtesy of Enclustra.

January 28th, 2013
Booting Mars ZX3 eCos binary from RedBoot over TFTP

tftboot

We’re continuing our series of posts on using eCos and RedBoot on Enclustra’s ZX3 Zynq module – this time with a practical scenario which you might find useful.

It’s a typical case — you’d like to load binaries of eCos apps with RedBoot via TFTP; how to get going on that?

We assume that you have RedBoot running on the board and have an eCos binary ready to roll. If not, see the instructions on our github on how to compile those and use them with the board.

First you have to do is to set up a TFTP server so that you are sure your binary is available from the module. On a Debian Wheezy installation (and probably any other Linux distro) you might use the instructions from Timesys.

With one exception: if you do not have a ‘tftp’ file in ‘/etc/xinetd.d’ siply create one and paste the content from the site into it.

Now you should boot up RedBoot to the prompt. Of course by then it’s nice to have a console window (for example, minicom) with a connection to the board open.

If you had the Ethernet cable attached during boot you’ll probably get IP address via DHCP (if RedBoot is configured to use that, which it is by default) — this was the case in the example from the attached screenshot, where the board received an IP address of 192.168.1.27. You should be able to see the IP information as one of the first messages RedBoot prints to the console.

If a network connection wasn’t configured automatically during startup you should configure it manually with:

1
ip_address -l <xxx.xxx.xxx.xxx> (where xxx.xxx.xxx.xxx is IP address)

for a static IP, or

1
ip_address -d

to get an IP over DHCP (for example, it you forgot to plug in a cable before bootup).

The next step is to set a default server IP address (= where the eCos binary will be downloaded from) with:

1
ip_address -h <xxx.xxx.xxx.xxx>

(where xxx.xxx.xxx.xxx is the server IP address — in our case, 192.168.1.70)

You could use ping to check if the connection is configured properly. To do that use:

1
ping -h <xxx.xxx.xxx.xxx>

(where xxx.xxx.xxx.xxx is the host IP just like above)

Note that in RedBoot the ping program is not what you would normally expect in Linux or Windows — for example it does not show any progress or state messages. You have to wait until it exits, and if you interrupt it, you will see information about how many ICMP packets were received out of the 10 to be sent.

If the connection works properly, you can now download a test application from the TFTP server with:

1
load <name_of_application_binary>

(in our case, this was clock0, a standard eCos clock test).

With the default setting the board should use the TFTP protocol and the server IP set earlier, but if you want to change some parameter see the relevant section of the eCos documentation.

You should now see som information about entry point address ranges of the loaded binary.

To run the app you just loaded simply type:

1
go

And you’re ready! See the attached screen for the result.

January 17th, 2013
eCos port for Enclustra’s ZX3 Zynq module ready

Mars ZX3

Last year we announced the beginning of the work to port eCos to Enclustra’s Mars ZX3 Zynq module.

While most of the work was complete after the summer, the tedious task of cleaning it up, writing appropriate documentation, and testing, testing, testing is always longer than you think.

Zynq is still a very exciting platform which we believe will gain more attention as time goes on, and an RTOS to run on the Processing System will be a good addition to the OSs it can run.

On the attached image you can see the RedBoot bootloader, which is a significant side-effect of the porting effort, loading an eCos test binary over TFTP. We’re excited to see other applications run on the Zynq with time.

tftboot

The port is still undergoing review from Enclustra, but we agreed to open-source it now so that we can benefit from feedback from the community. Already after the port was first announced, we’ve had some very valuable comments, especially as to the usage scenarios, planned projects, hopes and fears associated with the Zynq.

Internally we have been testing and using the port successfully for quite a while, and it is definitely ready for evaluation purposes. It would also be quite interesting to see some benchmarking.

The code is available on our github – head there to check it out, use it in your new application and give us feedback, especially on the documentation and use scenarios.

October 16th, 2012
OpenRISC Conference Stockholm 2012

The great thing about open source communities is that hundreds of people around the globe can collaborate on fascinating software and hardware projects without ever meeting one another.

An even better thing about such communities is that they can also meet up and discuss their shared fascinations!

Last weekend a part of the openRISC community (including us) did just that, at a fantastic meetup hosted by our main partner – Realtime Embedded – in their office at Sveavägen in central Stockholm. The three of us attended as relative newcomers to the openRISC bunch, some of whom have been out and about for many years now, but I think we managed to arouse much interest with our presentation of eCos as a new addition to the openRISC ecosystem. We were pleased to hear a number of insightful remarks and requests; as one of the never-too-many actively supported OS’s for the openRISC our eCos port got also quite a few mentions during the other presentations.

We have already started putting the suggested changes into life as time permits us – check Peter’s description how to compile a program in eCos in an (insanely) easy way! (Makefile included.) In the nearest future, watch out for new eCos for openRISC notes.

Unfortunately, as Murphy’s Law would have it, our presentation was not recorded due to a technical glitch – damn you, AAA batteries! – but you will soon find the slides on the project meeting website.

As for the other presentations, all of them were very interesting to listen to but one of them, a status report on the (now functional) dynamic linking support for openRISC LLVM by Stefan Kristiansson – was absolutely brilliant. The best moment was when the boring slides ended, and… check out what came later at the extremely cool demo. (The other videos are easily found in the attached playlist.)

Don’t trust Stefan when he says “I don’t know about this stuff for real” :)

The meetup was also a very good forum to talk about our priorities, open source processes in general and other related interesting developments – including Parallella from Adapteva, which we are very excited about. For those of you who don’t know the project, it’s an attempt to raise $750000 (or more) by giving away development platforms (called Parallella) for an already complete 16-64 core (called Epiphany) to as many people as possible for as little as $99. We love the idea, since the guys at Adapteva have from the beginning been very open about their history, process and willingness to actually get people to find the proper applications for the hardware, not the other way around!

See the short pitch I prompted for Parallella at the openRISC meeting, by Jeremy Bennett from Embecosm:

And buy one yourself to get parallel computing out into the open!

July 20th, 2012
Running RedBoot on Enclustra’s ZX3 Zynq module

For the past few weeks we have been busy porting eCos to Encustra’s Zynq module, with a partial sponsorship from the Swiss company. The initial version of the port is ready, eCos passes most tests and it is possible to run RedBoot – the eCos bootloader – on the board.

With the ability to directly download and boot ELF files, RedBoot is definitely an interesting alternative to U-Boot, typically used to boot Linux for the Zynq. RedBoot is also a handy tool when it comes to debugging the application code. RedBoot can be loaded automatically by Xilinx’s first stage bootloader, using the boot header mechanism.
RedBoot on the ZX3 Zynq module
Currently, our version of RedBoot has limited functionality, but it will evolve as we go on to provide a complete set of drivers and some interesting functionalities that we will show in upcoming posts.

ITR GmbH has donated some of the basic platform code for Zynq, which was valuable help.

June 20th, 2012
Ant Micro porting eCos to Enclustra’s Zynq module – Mars ZX3

The connection between the two worlds of embedded and FPGA is becoming more and more apparent – all the more so with solutions such as Xilinx Zynq, which combines a general-purpose dual-core ARM with programmable logic allowing for dedicated processing in a single chip.

As a company active in both fields, we were quite eager to lay our hands on Zynq chips, to get the feel of the module and how it works in practice.

Following our visit to X-Fest in Oslo we were talking with Enclustra, the Swiss FPGA company and producer of FPGA modules to give us an early sample so that we can be one of the first few companies able to work with physical Zynq chips. They agreed to partially sponsor the port of the eCos real-time operating system for the module, and so, here it is:

The module is excellent, just as well made as the previous board we got from Enclustra, coming in the popular (and small!) SO-DIMM format. It allows you to integrate Zynq into your design quickly, with much less effort than to design from scratch.

The port is scheduled for release early Q4 2012. Go to Enclustra’s website for updates, other operating systems as well as to subscribe for the Beta program and get the boards for yourself. If you already decided to use Zynq or are leaning towards it, we can help you with integrating it into your own designs and products.

Follow our blog if you want to learn of our progress and let us know if you want to use eCos on the Zynq. A note on running RedBoot on the ZX3 module as an alternative to U-Boot will follow soon, so as always – stay tuned (and enjoy the summer)!

June 7th, 2012
SPI driver for OpenRISC eCos

After a short break, this week we are going to deal with SPI support for the OpenRISC eCos port,

To add the driver to the eCos build, the CYGPKG_IO_SPI package has to be added as follows:

1
ecosconfig add CYGPKG_IO_SPI

ECos requires that each device connected to the SPI bus is properly described. Our driver provides a macro for this purpose:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CYG_DEVS_SPI_OPENCORES_SIMPLE_SPI_DEVICE(
  name,        // handler name of the device
  bus,         // SPI bus, numbering starts at 0
  cs,          // CS line, numbering starts at 0
  polarity,    // polarity (1 or 0)
  phase,       // phase (1 or 0)
  freq,        // maximum SCK frequency measured in hertz
  cs_to_tran,  // minimum delay between CS signal and start
               // of the transmission, measured in microseconds
  tran_to_cs,  // minimum delay between the end of the transmission
               // and the release of CS signal, measured in microseconds
  tran_to_tran // minimum delay between transmission of consecutive
               // bytes, measured in microseconds
);

For example, to add a m25pxx flash memory, fairly common on FPGA boards, connected to bus 0 chip-select 0, we can describe it as follows:

1
2
3
CYG_DEVS_SPI_OPENCORES_SIMPLE_SPI_DEVICE(
  m25pxx_spi, 0, 0, 0, 0, 1000000, 1, 1, 1
);

It is worth noting that eCos already has a driver for this memory type. To use it you have to add the CYGPKG_DEVS_FLASH_SPI_M25PXX package:

1
ecosconfig add CYGPKG_DEVS_FLASH_SPI_M25PXX

And connect the SPI device to it:

1
2
3
CYG_DEVS_FLASH_SPI_M25PXX_DRIVER (
  m25pxx_drv, 0, &m25pxx_spi
);

Note: Get the relevant code from our mirror of eCos-openrisc on Ant Micro’s github account.

The eCos provided by Ant Micro now supports:

  • UART
  • SPI
  • Ethernet
  • SDIO

Stay with us for more updates about OpenRISC, FPGA and open source in embedded systems.

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
2
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.

May 13th, 2012
Xilinx X-Fest 2012 in Oslo – time for Zynq

Oslo is always a good and familiar place to visit, especially if it means bumping into some old friends from the FPGA world and making a few new ones on a Xilinx X-Fest. The one we attended was held in Sandvika in suburban Oslo on May 8, but you can still participate in several other places around Europe and the world if you wish – check the event website!

This year, X-Fest is dominated by the new Cortex-A9+FPGA hybrid – Zynq, with one track and most exhibitor’s booths dedicated exclusively to this technology. And rightly so!

The “Processing System + Programmable Logic” combination, a dual-core general-purpose CPU with the ability to delegate tasks which are computationally heavy and prone to parallelising onto a dedicated block synthesised within the FPGA is just brilliant. Sure, not all applications will benefit from this, but if you know what you are doing and are able to identify bottlenecks in your product, you can get your software to run some 10x faster.

It’ll be good to verify this claim in practice – after all, ground-breaking technologies are more often announced than functional – but this time it looks that Xilinx’s has really done a good job. There are limitations such as power-up time or the speed of the CPU (the dual-core Cortex-A9 is clocked only around 600 MHz for now, 800 MHz in future chips) but none of them seem to be deal-breakers.

We will see if the tools available allow the ecosystem to suck up ‘traditional’ software developers in addition to the FPGA guys, but it seems that Xilinx is aware of the fact that SW engineers require a different approach and are working with ARM provide tools necessary to facilitate the transfer from plain-ol’ CPU systems to a CPU+FPGA hybrid.

We have already been running the Zynq QEMU port out of curiosity, but this of course gives little feel of what the real stuff behaves like. However, with a bit of luck we will get our hands on physical modules as early as in June.

Follow our blog where we will describe our work with the Zynq technology and our thoughts on how useful it really is in practice. If you have ideas on how your applications can benefit from using Zynq or want to ask a question about it, be sure to leave a comment!

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.

 

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