Epiphany SDK Driver and Library Sources Published on GitHub

By February 22, 2013 Parallella Blog 22 Comments

Today we completed the publication of the last remaining Epiphany SDK source tree repositories to the Adapteva GitHub account, including all the drivers and library files. The two repositories can be found at: http://github.com/adapteva

epiphany-sdk

This repo is the master archive that integrates the various Epiphany-SDK components into a release/installation tree. It contains the master eSDK build script (build-sdk.sh) and some non-binary and non-runtime critical components like the documentation and examples.

epiphany-libs

This repo contains all the Epiphany SDK source code (minus the the Epiphany GNU compiler and binutils which can be found in the Parallella GitHub repository)

1. The e-hal library (the Epiphany Hardware Abstraction Layer, or simply “driver”), which is required to transfer data from the host to the Epiphany and back;

2. The e-loader library used by a host application to load a program to the Epiphany accelerator;

3. The e-xml library, which is the parser of an .xml text file (“Hardware Description File” – HDF) containing information about the hardware platform;

4. The e-server, which is our implementation of a remote-serial-protocol (RSP) gdb debug server, used to bridge between the e-gdb frontend and the hardware. The gdb <-> server communications works over TCP/IP and enables remote debugging of an Epiphany program;

5. The e-lib library, which is the Epiphany run-time library;

6. The e-utils directory, which contains wrapper scripts for some GNU binutils.

7. The bsps directories, which contain the files specific to each system configuration – HDF, LDF’s and a driver.

The epiphany-libs repo contains a master build script, called build-libs.sh that builds the above packages. Each buildable package is given as an Eclipse project that one can import to an Eclipse workspace for convenience.

All source repos are released under the GNU Public License v3 (GPL) or Lesser GPL (LGPL). See the license files in each project for specific licensing details.

Note that the repos reflect the current, in-the-works status of these packages, and will be modified in the future. Also note that in order to obtain the complete eSDK, one needs to download the Epiphany GNU sources, currently posted at the Parallella GitHub page. In the near future, we will integrate these packages within one streamlined build package.

Enjoy!

22 Comments

  • Hi – you say “This repo contains all the Epiphany SDK source code (minus the the Epiphany GNU compiler and binutils which can be found in the Parallella GitHub repository)” but I can’t find the repository on github. Do you have a link handy?

    Thanks

  • Oh – sorry – found it 🙂

  • samjbarney says:

    Soooo…. Assuming I was designing an operating system for the Parallela, what kernel functions would I need to implement to use the epiphany-libs?

  • Yaniv Sapir says:

    @SamjBarney, I see that by now you already posted at the relevant Parallella forum, which is probably the best place for such discussions.

    Anyway, if you mean an O/S that runs on the Epiphany, then I guess any kernel function you implement can call the e-lib APIs, as long as you have a form of static C linkage.

    Note that out of the epiphany-libs repo, only the e-lib (libe-lib.a) is built for the Epiphany. The other libraries (driver, loader, etc.) are meant for the host side.

  • Albert Netymk says:

    I build all the projects from https://github.com/Adapteva and https://github.com/parallella, but I am still missing the e-loader binary. Where could I find it?

  • Yaniv Sapir says:

    Albert, the various eSDK projects are maintained as one eclipse workspace. The standard place for the e-loader binaries are in …./e-loader/Release/libe-loader.{so,a}

  • Albert Netymk says:

    @Yaniv Thanks for the quick reply. I indeed get libe-loader.{so,a} after building. However, I thought e-loader is one executable to load the SREC file to the board. Is this one also open sourced?

  • Yaniv Sapir says:

    The standalone loader was implemented on the EMEK platform. I assume you found that from the eSDK book. This is considered obsolete.

    On the Parallella platform (and hopefully from now on), loading is performed from within the host application using the e_load() and e_load_group() APIs. You can find some description of the alpha API implementation on the “Programming the Zynq based system” document that was downloadable from the FTP site.

    Note that the new driver release will include a somewhat updated version of the commands, but the main idea still holds.

  • Albert Netymk says:

    @Yaniv There’s indeed one e_load() function in e_loader.c. I suppose this is the one host has to call to perform loading. Is there any host code sample for how to call it. The FTP site requires username and password, but I didn’t see any place to register. I registered for the forum, but it seems that it uses different authentication system from the FTP site.

  • Yaniv Sapir says:

    Albert – the FTP site access is for registered Kickstarter backers (I am not sure if all of them, or just early adopters, though). There should be a usage example in the matmul code example.

    … I see that it was not included in the repos. Try digging in the parallella.org website, I vaguely remember posting that example here.

  • Albert Netymk says:

    @Yaniv I have found one example on how to use the e_load API in [here](http://forums.parallella.org/viewtopic.php?f=13&t=193). After some tweaking, the code is build successfully. However, there’s some problem when I try it with the hardware. I am using this [board](http://www.adapteva.com/products/eval-kits/emek3/). It seems that there have been major change after this. Firstly, e-server is expecting hdf instead of xml, but it still could not parse the hdf either for the one I write mimicking the one from repository or the one from [repository] (https://github.com/Adapteva/epiphany-libs/blob/master/bsps/zed_E64G4_512mb/zed_E64G4_512mb.hdf). I am stuck in here.

    BYW, since there are so many changes, where could I find the latest docs?

  • Albert Netymk says:

    @Yaniv The -hdf option of e-server is quite misleading. After reading the source code for e-server, I realize that it’s still expect XML despite the name. Therefore, we could just provide the original xml file. Then it parses the xml correctly. Next, it’s compiling for lacking of libftdi_target.so. In fact, I didn’t encounter any instructions on building this one. Where am I missing it?

  • Yaniv Sapir says:

    The “hdf” – Hardware Description File – is a generic name that we chose for that file. Currently, the e-server expects an xml format file – but xml is just the format, not a description of the nature of the file. In the future, it may change to some other format.

    If you look at the xml file, you’ll see the “libftdi_target.so” mentioned. This should actually be “libe-hal.so”.

  • Albert Netymk says:

    @Yaniv Thanks for the explanation and the instruction. After replacing ftdi with e-hal, it complains:

    e-server: e_init(): Program must be invoked with superuser privilege (sudo).
    e-server: e_alloc(): Program must be invoked with superuser privilege (sudo).
    e-server: e_open(): Program must be invoked with superuser privilege (sudo).

    After adding sudo, it complains:

    Using the HDF file: ~/tmp//bsps/emek3/emek3.xml
    e-server: e_init(): No Hardware Definition File (HDF) is specified.
    e-server: e_alloc(): mmap failure.
    e-server: e_open(): Platform was not initialized. Use e_init().

    The need for sudo is kind of unnecessary. Besides, what shall I do next?

  • Yaniv Sapir says:

    “The need for sudo is kind of unnecessary” – you say this because…?

    OK, I was afraid of that, but I was not sure what was the state of the eSDK. Now, as for e-server, I am now really not sure if the specific version on GitHub will run. I actually have a new SDK ready for release, preparing the docs.

    However – if you want to try, the reason e_init() it looks for the HDF is that this is basically the Epiphany driver, that should get an idea of the underlying hardware. The e_init() function looks for an HDF of a simplified type (non-XML). It looks for the file whose name is in the EPIPHANY_HW_DEF_FILE environment variable. In the bsp directory you should find a compatible HDF to use.

    Note that you generally need to set the LD_LIBRARY_PATH and EPIPHANY_HW_DEF_FILE variables in the invocation line, b/c sudo clears portions of the environment.

  • Yaniv Sapir says:

    There’s also a Tag repo for the elibs repo that is a frozen version of an earlier release that you can try to use.

  • Albert Netymk says:

    # EPIPHANY_HW_DEF_FILE=”directory-to-emek3.hdf”;
    # echo $EPIPHANY_HW_DEF_FILE;
    directory-to-emek3.hdf
    # directory-to-e-server -hdf /home/albert/tmp/bsps/emek3/emek3.xml
    Using the HDF file: /home/albert/tmp/bsps/emek3/emek3.xml
    e-server: e_init(): No Hardware Definition File (HDF) is specified.
    e-server: e_alloc(): mmap failure.
    e-server: e_open(): Platform was not initialized. Use e_init().
    Cannot initialize target device. Bailing out!

  • Albert Netymk says:

    Are you refering to this [one](https://github.com/Adapteva/epiphany-libs)
    616016a – (HEAD, e-hal_API_v.2.0, origin/master, origin/HEAD, master)
    It seems it’s the lastest commit on maste.

  • Albert Netymk says:

    It’s probably better to wait for the new release. @Yaniv, thank you very much for all the support.

  • Yaniv Sapir says:

    Albert,

    The latest docs will be released with the new eSDK release, hopefully in a day or two.

    Regarding the hdf/xml formats and e-server – the original e-server, written for the EMEK, was used as a centralized point for host-device communications. It was, effectively, the HAL. It is written in C++ code and includes an XML parse implemented in C++ as well. Moving on to Parallella, the e-server is now required only for debug, as e-gdb’s backend RSP server. It still uses the same XML parser.

    OTOH, the new hardware driver was intentionally written in C. As such, we did not want to base it on the C++ XML parser. So I used a simple HDF format as a placeholder until we integrate a C based parser.

    For this, when using e-server, two HDF files are actually required. One is the legacy XML file (used by the server) and the second is the simple HDF used by the underlying driver. This is explained in the new documentation as well, and a usage example will be given.

  • What’s up, I desire to subscribe for this blog to get most
    up-to-date updates, thus whsre can i do it please
    help.

  • Apps that expedite performance for users, instead of those that are trying
    to sell something, are our forte.

Leave a Reply