Cross compile Libmetal for ARM64 Linux

2,240 views
Skip to first unread message

ruka

unread,
Feb 6, 2018, 10:16:45 AM2/6/18
to open-amp
Hi Guys,

now I am building Linux with Openamp and libmetal in it for arm64 using Buildroot,which will run on A53. So I want to cross compile the libmetal first on my PC Ubuntu, then pack them into rootfs. My toolchain file is as follows:
set (CMAKE_SYSTEM_PROCESSOR "aarch64"           CACHE STRING "")
set (MACHINE                "zynqmp_a53"        CACHE STRING "")
set (CROSS_PREFIX           "aarch64-linux-gnu-" CACHE STRING "")
set (CMAKE_C_FLAGS          ""                  CACHE STRING "")

include (cross-linux-gcc)

# vim: expandtab:ts=2:sw=2:smartindent

But whenever I take this "cmake /home/rk/libmetal -DCMAKE_TOOLCHAIN_FILE=/home/rk/libmetal/cmake/platforms/zynqmp-a53-linux.cmake" in the terminal, the result always shows like below:
rk@ubuntu:~/libmetal/build$ cmake /home/rk/libmetal -DCMAKE_TOOLCHAIN_FILE=/home/rk/libmetal/cmake/platforms/zynqmp-a53-linux.cmake 
-- Build type:  Debug
-- Host:    Linux/x86_64
-- Target:  Linux/aarch64
-- Machine: zynqmp_a53
-- Could NOT find LIBSYSFS (missing:  LIBSYSFS_LIBRARY) 
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find LibRt (missing: LIBRT_LIBRARIES)
Call Stack (most recent call first):
  /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindLibRt.cmake:36 (find_package_handle_standard_args)
  cmake/depends.cmake:22 (find_package)
  CMakeLists.txt:15 (include)


-- Configuring incomplete, errors occurred!
See also "/home/rk/libmetal/build/CMakeFiles/CMakeOutput.log".
See also "/home/rk/libmetal/build/CMakeFiles/CMakeError.log".

Does anybody know why?  I have installed libsysfs lib in my PC Ubuntu. 

Thanks in advance!

Jiaying Liang

unread,
Feb 6, 2018, 1:54:48 PM2/6/18
to open...@googlegroups.com

Hi Ruka,

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of ruka
Sent: Tuesday, February 06, 2018 7:17 AM
To: open-amp <open...@googlegroups.com>
Subject: [open-amp] Cross compile Libmetal for ARM64 Linux

 

Hi Guys,

 

now I am building Linux with Openamp and libmetal in it for arm64 using Buildroot,which will run on A53. So I want to cross compile the libmetal first on my PC Ubuntu, then pack them into rootfs. My toolchain file is as follows:

set (CMAKE_SYSTEM_PROCESSOR "aarch64"           CACHE STRING "")

set (MACHINE                "zynqmp_a53"        CACHE STRING "")

set (CROSS_PREFIX           "aarch64-linux-gnu-" CACHE STRING "")

set (CMAKE_C_FLAGS          ""                  CACHE STRING "")

 

include (cross-linux-gcc)

 

# vim: expandtab:ts=2:sw=2:smartindent

 

But whenever I take this "cmake /home/rk/libmetal -DCMAKE_TOOLCHAIN_FILE=/home/rk/libmetal/cmake/platforms/zynqmp-a53-linux.cmake" in the terminal, the result always shows like below:

rk@ubuntu:~/libmetal/build$ cmake /home/rk/libmetal -DCMAKE_TOOLCHAIN_FILE=/home/rk/libmetal/cmake/platforms/zynqmp-a53-linux.cmake 

-- Build type:  Debug

-- Host:    Linux/x86_64

-- Target:  Linux/aarch64

-- Machine: zynqmp_a53

-- Could NOT find LIBSYSFS (missing:  LIBSYSFS_LIBRARY) 

[Wendy] libmetal uses libsysfs functions to access sysfs, you will need to build libsysfs

CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):

  Could NOT find LibRt (missing: LIBRT_LIBRARIES)

[Wendy] libmetal uses librt for shm_open(), you will need to build librt too

Call Stack (most recent call first):

  /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)

  cmake/modules/FindLibRt.cmake:36 (find_package_handle_standard_args)

  cmake/depends.cmake:22 (find_package)

  CMakeLists.txt:15 (include)

 

 

-- Configuring incomplete, errors occurred!

See also "/home/rk/libmetal/build/CMakeFiles/CMakeOutput.log".

See also "/home/rk/libmetal/build/CMakeFiles/CMakeError.log".

Does anybody know why?  I have installed libsysfs lib in my PC Ubuntu. 

[Wendy] As you are building the libmetal for A53, you will need to build libsysfs and librt for A53

 

Best Regards,

Wendy

 

Thanks in advance!

 

--
You received this message because you are subscribed to the Google Groups "open-amp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-amp+u...@googlegroups.com.
To post to this group, send email to open...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Message has been deleted
Message has been deleted

ruka

unread,
Feb 9, 2018, 4:58:16 AM2/9/18
to open-amp

Hi Wendy,
thanks a lot for your reply. Besides the sysfs and rt, what about the hugetlbfs? Should I also build it for A53. I downloaded it from the git https://github.com/libhugetlbfs/libhugetlbfs. Whenever I run the make command, the results show as below. Should that be some problems with the Makefile? Thanks!


wendy...@xilinx.com

unread,
Mar 2, 2018, 2:31:38 PM3/2/18
to open-amp
Hi Ruka,


On Friday, February 9, 2018 at 1:58:16 AM UTC-8, ruka wrote:

Hi Wendy,
thanks a lot for your reply. Besides the sysfs and rt, what about the hugetlbfs? Should I also build it for A53. I downloaded it from the git https://github.com/libhugetlbfs/libhugetlbfs. Whenever I run the make command, the results show as below. Should that be some problems with the Makefile? Thanks!
Sorry for my late reply, I use my company email to monitor the group, but recently, i didn't received emails from the openamp group from my company's email from early Feb. I should have checked the group directly. the hugetlbfs provides APIs to access hugepages through hugetlbfs virtual file system. the libmetal auto detect if you have hugeTLBfs installed, if not , it will not compile with it. the libsysfs is required but the libhugetlbfs is optional.


Best Regards,
Wendy

ruka

unread,
Apr 3, 2018, 7:32:53 AM4/3/18
to open-amp
Hi Wendy,
 thanks a lot for your reply! Now I have sucessfully built libmetal for Linux for arm 64. My toolchain is as below:

set (CMAKE_SYSTEM_PROCESSOR "aarch64"            CACHE STRING "")
set (CROSS_PREFIX           "aarch64-linux-gnu-" CACHE STRING "")
set (CMAKE_FIND_ROOT_PATH /home/ruka/openamp/buildroot-2017.02.10/output/host/usr/aarch64-buildroot-linux-gnu/sysroot)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
include (cross-linux-gcc)

# vim: expandtab:ts=2:sw=2:smartindent

Then I tried to build Openamp library on top of libmetal with the toolchain:

set (CMAKE_SYSTEM_PROCESSOR "arm64")
set (CROSS_PREFIX           "aarch64-linux-gnu-")
set (MACHINE                "zynqmp" CACHE STRING "")
set (CMAKE_FIND_ROOT_PATH /home/ruka/openamp/buildroot-2017.02.10/output/host/usr/aarch64-buildroot-linux-gnu/sysroot)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

include (cross_linux_gcc)

But the built result still shows that sysfs/libsysfs.h No such file or directory. Should it be already included in the build-process of libmetal(in the build-process of libmetal It was found sucessfully)? Why does it be searched again in the build-process of openamp? The cmake command I used for building openamp is : 

cmake .. -DCMAKE_TOOLCHAIN_FILE=/home/ruka/openamp/open-amp-master/cmake/platforms/zynqmp_linux.cmake -DCMAKE_INCLUDE_PATH=/home/ruka/openamp/install/libmetal/usr/local/include -DCMAKE_LIBRARY_PATH=/home/ruka/openamp/install/libmetal/usr/local/lib -DWITH_APPS=ON

And the whole build result is as below:

make VERBOSE=1 DESTDIR=/home/ruka/openamp/install/openamp/ install/usr/bin/cmake -H/home/ruka/openamp/open-amp-master -B/home/ruka/openamp/open-amp-master/build-openamp --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/ruka/openamp/open-amp-master/build-openamp/CMakeFiles /home/ruka/openamp/open-amp-master/build-openamp/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/ruka/openamp/open-amp-master/build-openamp'
make -f lib/CMakeFiles/open_amp-shared.dir/build.make lib/CMakeFiles/open_amp-shared.dir/depend
make[2]: Entering directory '/home/ruka/openamp/open-amp-master/build-openamp'
cd /home/ruka/openamp/open-amp-master/build-openamp && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/ruka/openamp/open-amp-master /home/ruka/openamp/open-amp-master/lib /home/ruka/openamp/open-amp-master/build-openamp /home/ruka/openamp/open-amp-master/build-openamp/lib /home/ruka/openamp/open-amp-master/build-openamp/lib/CMakeFiles/open_amp-shared.dir/DependInfo.cmake --color=
Dependee "/home/ruka/openamp/open-amp-master/build-openamp/lib/CMakeFiles/open_amp-shared.dir/DependInfo.cmake" is newer than depender "/home/ruka/openamp/open-amp-master/build-openamp/lib/CMakeFiles/open_amp-shared.dir/depend.internal".
Dependee "/home/ruka/openamp/open-amp-master/build-openamp/lib/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/ruka/openamp/open-amp-master/build-openamp/lib/CMakeFiles/open_amp-shared.dir/depend.internal".
Scanning dependencies of target open_amp-shared
make[2]: Leaving directory '/home/ruka/openamp/open-amp-master/build-openamp'
make -f lib/CMakeFiles/open_amp-shared.dir/build.make lib/CMakeFiles/open_amp-shared.dir/build
make[2]: Entering directory '/home/ruka/openamp/open-amp-master/build-openamp'
[  1%] Building C object lib/CMakeFiles/open_amp-shared.dir/common/hil.c.o
cd /home/ruka/openamp/open-amp-master/build-openamp/lib && /home/ruka/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc  -Dopen_amp_shared_EXPORTS -I/home/ruka/openamp/install/libmetal/usr/local/include -I/home/ruka/openamp/open-amp-master/lib/include  -Wall -Wextra -g -fPIC     -o CMakeFiles/open_amp-shared.dir/common/hil.c.o   -c /home/ruka/openamp/open-amp-master/lib/common/hil.c
In file included from /home/ruka/openamp/install/libmetal/usr/local/include/metal/sys.h:111:0,
                 from /home/ruka/openamp/install/libmetal/usr/local/include/metal/dma.h:47,
                 from /home/ruka/openamp/open-amp-master/lib/include/openamp/virtqueue.h:42,
                 from /home/ruka/openamp/open-amp-master/lib/include/openamp/virtio.h:34,
                 from /home/ruka/openamp/open-amp-master/lib/include/openamp/hil.h:45,
                 from /home/ruka/openamp/open-amp-master/lib/common/hil.c:47:
/home/ruka/openamp/install/libmetal/usr/local/include/metal/system/linux/sys.h:61:10: fatal error: sysfs/libsysfs.h: No such file or directory
 #include <sysfs/libsysfs.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.
lib/CMakeFiles/open_amp-shared.dir/build.make:62: recipe for target 'lib/CMakeFiles/open_amp-shared.dir/common/hil.c.o' failed
make[2]: *** [lib/CMakeFiles/open_amp-shared.dir/common/hil.c.o] Error 1
make[2]: Leaving directory '/home/ruka/openamp/open-amp-master/build-openamp'
CMakeFiles/Makefile2:101: recipe for target 'lib/CMakeFiles/open_amp-shared.dir/all' failed
make[1]: *** [lib/CMakeFiles/open_amp-shared.dir/all] Error 2
make[1]: Leaving directory '/home/ruka/openamp/open-amp-master/build-openamp'
Makefile:138: recipe for target 'all' failed



Best regards,
Fei

Jiaying Liang

unread,
Apr 3, 2018, 12:32:08 PM4/3/18
to open...@googlegroups.com

[Wendy] From the log, I didn’t see your buildroot sysroot has been added to the include path, you can try cmake  -DCMAKE_INCLUDE_PATH=”=/home/ruka/openamp/install/libmetal/usr/local/include;<path_to_where_sysfs/libsysfs.h_is>

 

Best Regards,

Wendy

ruka

unread,
Apr 4, 2018, 4:13:09 AM4/4/18
to open-amp
Hi Wendy,

thanks a lot for your reply. I re-cmake the openamp again with:
ruka@ubuntu:~/openamp/open-amp-master/build$ cmake .. -DCMAKE_TOOLCHAIN_FILE=/home/ruka/openamp/open-amp-master/cmake/platforms/zynqmp_linux.cmake -                                                 DCMAKE_INCLUDE_PATH="/home/ruka/openamp/buildroot-2017.02.10/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/;/home/ruka/openamp/install/libmetal/usr/local/include" -                  DCMAKE_LIBRARY_PATH="/home/ruka/openamp/buildroot-2017.02.10/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/lib64;/home/ruka/openamp/install/libmetal/usr/local/lib" -DWITH_APPS=ON
-- The C compiler identification is GNU 7.2.1                                                                                                                                                                                                                                                              
-- Check for working C compiler: /home/ruka/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc                                                                                                                   
-- Check for working C compiler: /home/ruka/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -- works                           
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Host:    Linux/x86_64
-- Target:  Linux/arm64
-- Machine: zynqmp
-- C_FLAGS :  -Wall -Wextra
-- Found LIBMETAL: /home/ruka/openamp/install/libmetal/usr/local/lib/libmetal.so  
-- Looking for include file stdatomic.h
-- Looking for include file stdatomic.h - found
-- Looking for include file fcntl.h
-- Looking for include file fcntl.h - found
-- Configuring done
-- Generating done                                                                                                      
-- Build files have been written to: /home/ruka/openamp/open-amp-master/build

And then I ran the command: make VERBOSE=1 DESTDIR=/home/ruka/openamp/install/openamp/ install
But still I got the same error:  /home/ruka/openamp/install/libmetal/usr/local/include/metal/system/linux/sys.h:61:10: fatal error: sysfs/libsysfs.h: No such file or directory
 #include <sysfs/libsysfs.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.


Best regards,
Ruka

wendy...@xilinx.com

unread,
Apr 4, 2018, 2:42:16 PM4/4/18
to open-amp


On Wednesday, April 4, 2018 at 1:13:09 AM UTC-7, ruka wrote:
Hi Wendy,

[Wendy] Did you find "sysfs/libsysfs.h" in "home/ruka/openamp/buildroot-2017.02.10/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/" and did you see "home/ruka/openamp/buildroot-2017.02.10/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/" in your include path while you are compiling your files (That is did you see -Ihome/ruka/openamp/buildroot-2017.02.10/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/ in your compilation log when you compile OpenAMP?

Best Regards,
Wendy

Jim Henderson

unread,
Mar 8, 2019, 7:44:12 PM3/8/19
to open-amp
All - 

I am using a Xilinx ZU27 RFSoC in my design and need to cross compile the metal library for the 64-bit A53 ARM processor running Petalinux.  This is needed so that I can use the Xilinx RFdc driver, which is built atop metal.  Would you be so kind as to distill the instructions to accomplish this into a post in this thread?  I am having difficulty understanding the process from the myriad posts in this thread, some of which have been deleted.  

Thanks in advance.  

wendy...@xilinx.com

unread,
Mar 10, 2019, 1:37:54 AM3/10/19
to open-amp


On Friday, March 8, 2019 at 4:44:12 PM UTC-8, Jim Henderson wrote:
All - 

I am using a Xilinx ZU27 RFSoC in my design and need to cross compile the metal library for the 64-bit A53 ARM processor running Petalinux.  This is needed so that I can use the Xilinx RFdc driver, which is built atop metal.  Would you be so kind as to distill the instructions to accomplish this into a post in this thread?  I am having difficulty understanding the process from the myriad posts in this thread, some of which have been deleted.  
Thanks for pointing out that some posts have been deleted. I don't know why they got deleted.

We compile libmetal with yocto for PetaLinux. And thus, we don't have any issues. As the libmetal recipe has specified the dependency, and yocto solves package dependencies issues.
The post you have quoted is to cross compile libmetal without yocto, and thus, it requires to compile the required sysfs util dev package manually.

James Henderson

unread,
Mar 10, 2019, 11:55:11 AM3/10/19
to open...@googlegroups.com
Wendy - 

Thank you for responding.  

Since my previous post, I have generated SDK files using petalinux-build --sdk.  This creates a new subtree in <petalinux-proj>/build/tmp/sysroots-components/aarch64 that contains numerous target headers and libraries (including libmetal and libsysfs).  Judicious inclusion of these in addition to the RFdc source allows my target ZU27 example code to successfully build and link.  So, it appears that cross-development of code employing the RFdc library code is possible.  

Unfortunately, I was forced to employ a work-around.  The RFdc library uses function metal_linux_get_device_property() which is not present in the  --sdk build of the Petalinux libmetal library (libmetal.a).  I was forced to copy the source code for this function into my copy of the RFdc source code which called that function in order to generate the .elf executable.  

Is this overall approach the most efficient to utilize the RFdc driver under Linux?  If not, please direct me to a link or documentation which details the preferred approach to cross-development of Linux applications code using the RFdc library.  

Jim
Jim

Jiaying Liang

unread,
Mar 11, 2019, 7:31:16 PM3/11/19
to open...@googlegroups.com

Hi James,

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of James Henderson
Sent: Sunday, March 10, 2019 8:55 AM
To: open...@googlegroups.com
Subject: Re: [open-amp] Cross compile Libmetal for ARM64 Linux

 

Wendy - 

 

Thank you for responding.  

 

Since my previous post, I have generated SDK files using petalinux-build --sdk.  This creates a new subtree in <petalinux-proj>/build/tmp/sysroots-components/aarch64 that contains numerous target headers and libraries (including libmetal and libsysfs).  Judicious inclusion of these in addition to the RFdc source allows my target ZU27 example code to successfully build and link.  So, it appears that cross-development of code employing the RFdc library code is possible.  

Unfortunately, I was forced to employ a work-around.  The RFdc library uses function metal_linux_get_device_property() which is not present in the  --sdk build of the Petalinux libmetal library (libmetal.a).  I was forced to copy the source code for this function into my copy of the RFdc source code which called that function in order to generate the .elf executable.  

[Wendy] function “metal_linux_get_device_property()” is from libmetal library. Not sure if it is due to the library is not got successfully linked to your application.

You can login Xilinx support portal https://www.xilinx.com/support.html#serviceportal to raise the issue

 

Is this overall approach the most efficient to utilize the RFdc driver under Linux?  If not, please direct me to a link or documentation which details the preferred approach to cross-development of Linux applications code using the RFdc library.  

[Wendy] I don’t think you need to copy the source code to compile your driver. I am not clear on how the “petalinux-build –sdk” work. I think it will generate a sysroot includes all the devel packages. And I think it should be sufficient to use to compile the RFdc driver. Please raise this issue with Xilinx support portal.

 

Thanks,

Wendy

 

Jim

Jim Henderson

unread,
Mar 14, 2019, 2:03:10 PM3/14/19
to open-amp
Wendy - 

I have successfully built libmetal into my ZU27 target image using Petalinux.  The test-metal example, automatically built by petalinux into my target image, runs successfully on my target, producing: 

root@PXIE-1000:~# test-metal
metal: debug:     added page size 4096 @/tmp
metal: debug:     registered platform bus
metal: info:      running [atomic]
metal: info:      result [atomic]............................ pass
metal: info:      running [mutex]
metal: info:      result [mutex]............................. pass
metal: info:      running [shmem]
metal: info:      result [shmem]............................. pass
metal: info:      running [condition]
metal: info:      result [condition]......................... pass
metal: info:      running [spinlock]
metal: info:      result [spinlock].......................... pass
metal: info:      running [alloc]
metal: info:      result [alloc]............................. pass
metal: info:      running [irq]
metal: info:      result [irq]............................... pass
metal: info:      running [version]
metal: info:      result [version]........................... pass
metal: debug:     metal_linux_irq_shutdown
metal: debug:     unregistered platform busroot@PXIE-1000:~# test-metal
metal: debug:     added page size 4096 @/tmp
metal: debug:     registered platform bus
metal: info:      running [atomic]
metal: info:      result [atomic]............................ pass
metal: info:      running [mutex]
metal: info:      result [mutex]............................. pass
metal: info:      running [shmem]
metal: info:      result [shmem]............................. pass
metal: info:      running [condition]
metal: info:      result [condition]......................... pass
metal: info:      running [spinlock]
metal: info:      result [spinlock].......................... pass
metal: info:      running [alloc]
metal: info:      result [alloc]............................. pass
metal: info:      running [irq]
metal: info:      result [irq]............................... pass
metal: info:      running [version]
metal: info:      result [version]........................... pass
metal: debug:     metal_linux_irq_shutdown
metal: debug:     unregistered platform bus

Next, I successfully rebuilt the metal-test example source code within a new Xilinx SDK project.  This code runs successfully on my target from within the SDK if launched using Run As | Launch on Hardware (System Debugger):  

metal-testRunAs.png


However, when I attempt to debug this example by launching it via Debug As | Launch on Hardware (System Debugger), it does not run to completion.  Rather, it is suspended as shown below within some system call: 

test-metal Debug As.png


The code will not run to completion, even if both threads are resumed in the debugger.  Due to absence of kernel source, I can't penetrate why the code is suspended.  A clue as to the failure mode is provided by the ps command run in a terminal session on the target: 

ps.png



Note the last two lines of the ps output read: 
2501 root       0:00 /mnt/metal-test.elf
2502 root       0:00 sh -c modprobe vfio-pci > /dev/null 2>&1

I suspect that the example program is failing after executing this modprobe, but I don't understand why it would succeed when launched via Run As, while failing when launched via Debug As.  

Can you provide any insight as to this failure condition?

Thanks in advance, 
Jim

Jim Henderson

unread,
Mar 14, 2019, 8:15:15 PM3/14/19
to open-amp
I found the solution.  The SMMU module must be added to the Petalinux image. 

Jim
Reply all
Reply to author
Forward
0 new messages