Forum Discussion

JButt5's avatar
JButt5
Icon for New Contributor rankNew Contributor
6 years ago

Custom Buildroot based Linux system for Cyclone V SoC fails to work with OpenCL RTE: "Board name /dev/acl0 is not available"

As described in some other post here, I need a Linux System with up-to-date stdlibs for my OpenCL-Based application targeting a Terasic DE10-Standard board.

As the well working Linux image available from terasic does not fulfill my needs, I followed some instructions on Rocketboards.org to build a Linux for the SoC based on an up-to-date Linux kernel and compiler Toolchain. The system boots up and works as expected.

After that I followed the steps described in here and recompiled the kernel driver to use OpenCL. I had to do minor changes to the source code to be compatible with the latest kernel headers (changing struct siginfo_t to struct kernel_siginfo_t) but then all compiled successfully. I copied the rte folder with the compiled driver to the target and created an init_opencl.sh script. After successfully sourcing the script, I ran aocl diagnose. However, this fails with "Board name /dev/acl0 is not available".

What kind of misconfiguration could be the source of this error?

3 Replies

  • FawazJ_Altera's avatar
    FawazJ_Altera
    Icon for Frequent Contributor rankFrequent Contributor
    6 years ago

    Hello,

    We are not supporting this kind of modifications.

    OpenCL run by SoC is restricted, specially when modifying the kernel headers.

    We recommend to use the OpenCL image supported by Terasic.

    thanks

    • JButt5's avatar
      JButt5
      Icon for New Contributor rankNew Contributor
      6 years ago

      Thank you for your reply,

      ​

      however, I don't quite get the intention of your answer. A development board normally is the starting point for first prototypes, but then usually a next step is the design of a custom hardware which comes with a application tailored Linux to run on this custom hardware. At least this point in the development flow it is absolutely necessary to set up a custom Linux for a custom system. So while maybe a development board with a pre-built image provided by Terasic might be a starting point for a prototype, what workflow and resources does Intel recommend when it comes to setting up a custom System that wants to use OpenCL for a real world product not targeting a development board?

      ​

      Nevertheless, I found a solution to my problem which I'd like to share with all readers of this thread running into a similar problem.

      It turns out that there was a change in how the Linux kernel handles FPGA devices somewhere with the transition from the 3.x Kernel version to the 4.x Kernel version, especially a renaming from sys/class/fpga-bridge to sys/class/fpga_bridge that breaks the behavior of the OpenCL RTE. You'll find several posts on this in the Rocketboards forums. I'm no expert in this field, however the solution I tried with fixing the changed types in the kernel module sources (By the way, I never modified my kernel headers as you said in your answer) made it possible to compile the module against current kernel headers without compilation errors but obviously lead to runtime errors described in the post as the driver infrastructure tries to find device information in paths that seem to be invalid for current kernel versions. In the end I got it working by using a 3.18 kernel as used in the Terasic Image and building an up-to-date GCC 8 toolchain with buildroot against the old kernel headers. This gives me a system that runs stable with the current OpenCL RTE but has the ability to run modern C++ applications compiled with this custom toolchain.

      However, as the 3.18 kernel is quite old now, are there any plans from Intel to update the OpenCL RTE to support a more up-to-date Kernel?