Posts Tagged ‘FPGA’

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.

February 11th, 2013
Meet Ant Micro in Hall 4A at Embedded World 2013!


As every year, we are visiting Embedded World to talk to our customers, partners, as well as see — and possibly influence — whichever way the embedded world is going.

This year you can actually find us all over the place, as we’re involved with many activities that are in focus of EW 2013.

Most importantly, we’re co-exhibiting with our partner, Enclustra, in booth 4A-107 — there should be someone there at all times so if you can’t find us elsewhere, head to hall 4A. We’ll be more than glad to talk to you! We’ll be showing off our ports of eCos and Android on Enclustra’s Zynq platform as well as other cool things.

Look for the sign to the right!

You can also book a meeting with us at the SafeConect booth (4-109 in Hall 4), an initiative for safety and security in embedded systems we’ve been part of for quite some time now (see our previous post about SafeConnect).

If that’s not enough, we will participate in the International B2B meeting organised by several European clusters, where you can meet relevant persons in chosen companies who are willing to talk, exchange ideas and cooperate.

Lastly, together with our main Swedish partner, Realtime Embedded, we will also be presenting at the Virtual Platform workshop — stay tuned for additional information!

This will be a busy end of February but we’ll be very happy to meet you. Feel free to just come and see us but it’s even better if you call Michael at +48 504 631 956 and arrange a meeting.

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.

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)!

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.

August 24th, 2011
Support for AMONTEC-compatible JTAG cables in Advanced Debug System

Advanced Debug System is a project that enables debugging capabilities in the OpenRISC architecture.
It is used mainly in the MinSoC project.
Advanced Debug System supports a variety of cables, including those based the on FT2232 chip.
However, the program didn’t seem to work with AMONTEC ARM JTAG cable.
AMONTEC established a standard followed by other manufacturers and there are many inexpensive AMONTEC-compatible cables used for ARM microcontrollers.

After some research we identified the problem: AMONTEC cable has an additional line, called JTAG_OE_N.
This output-enable line needs to be driven low.
Here is a small patch that enables JTAG_OE_N signal.

1
2
3
4
5
6
7
8
9
10
11
--- A/cable_ft2232.c    2011-08-24 11:19:46.042680534 +0200
+++ B/cable_ft2232.c    2011-08-24 11:19:58.003648945 +0200
@@ -824,7 +824,7 @@

     buf[0]= SET_BITS_LOW;
     buf[1]= 0x00;
-    buf[2]= 0x0b;
+    buf[2]= 0x1b;
     buf[3]= TCK_DIVISOR;
     buf[4]= 0x01;
     buf[5]= 0x00;

Please note, that you may also need to adjust the product id to match your cable.
The product id is hardcoded in the cable_ft2232.c file:

1
2
3
4
5
6
7
usbconn_cable_t usbconn_ft2232_mpsse_CableID2= {
  "CableID2",         /* cable name */
  "CableID2",         /* string pattern, not used */
  "ftdi-mpsse",       /* default usbconn driver */
  0x0403,             /* VID */
  0x6010              /* PID */
};

The product id can be read by issuing lsusb command. In out case, we had to change 0×6010 to 0xCFF8 as we are using a And-Tech ARM JTAG cable.

Hope it helps!

June 9th, 2011
FDT support for QEMU/Microblaze

As mentioned in the previous note on Customizing Microblaze emulation, the original microblaze/qemu provided support for a Petalogix Spartan3adsp1800 board only. Thanks to the modifications introduced in that note it was possible to create an external configuration file which listed the peripherals to be included in the emulation, thus enabling the support of any other Microblaze configuration.

As promised in the summary of the note, we have greatly improved this mechanism, so that all the information is extracted directly from the .dtb (Flattened Device Tree file) file and the mb.per file is no longer needed.

To modify the .dtb file simply decompile it with Device Tree Compiler using the following command:

1
dtc -I dtb -O dts mb.dtb > mb.dts

Once the modifications are performed, the altered data can be compiled back to .dtb file using the following command:

1
dtc -I dts -O dtb mb.dts > mb.dtb

For example, the uartlite UART is described using Flattened Device Tree file format in the following way:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
RS232_Uart_1: serial@84000000 {
    clock-frequency = <125000000>;
    compatible = "xlnx,xps-uartlite-1.00.a";
    current-speed = <115200>;
    device_type = "serial";
    interrupt-parent = <&xps_intc_0>;
    interrupts = < 3 0 >;
    port-number = <0>;
    reg = < 0x84000000 0x10000 >;
    xlnx,baudrate = <0x1c200>;
    xlnx,data-bits = <0x8>;
    xlnx,family = "virtex5";
    xlnx,odd-parity = <0x0>;
    xlnx,use-parity = <0x0>;
} ;

In our modification, only the “compatible”, “interrupts” and “reg” fields are taken into consideration.

The attached .diff file is compatible with the latest QEMU 0.14.1

To include the change, QEMU must be compiled with libfdt support.

It modifies the original petalogix_s3adsp1800_mmu.c so that instead of adding default peripherals it loads the dtb file and dynamically adds peripherals basing on the data from the Flattened Device Tree file.

This modification is released under the GPL.

Attached .diff file: qemu_microblaze_fdt.diff.gz

 

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