Uploaded
↧
7zip-1.jpg
↧
reVISION Getting Started Guide 2017.2
...
J113: 1-2{zcu102_reVISION_2017.1.png}
5.2
Download and
...
version (ES2 When prompted to confirm file replace, select ‘Auto Rename’
{7zip-1.jpg}
The final status screen shows one error, saying 'Can not open output file:...'. Click 'Close' and ignore the message
{7zip-2.jpg}
5.3 Run the Application
Run the Dense Optical Flow sample application
Copy all files from the release package directory
↧
↧
reVISION Getting Started Guide 2017.2
↧
pfm-3.jpg
Uploaded
↧
pfm-2.jpg
Uploaded
↧
↧
pfm-1.jpg
Uploaded
↧
reVISION Getting Started Guide 2017.2
...
Please refer to UG1233, page 8 for instructions.6 Tool Flow Tutorials
...
Windows version. Further, it is
...
extracted its The top-level directory
Before starting SDx, set the SYSROOT environment variable to point to the Linux root file system delivered with the EV platform, for example:
Linux:
...
Leave the "Use default location" box checked, hit Next>, this opens the "Choose Hardware Platform" page.Select the platform. The very first time you do this for a new workspace, you must hit Add Custom Platform..., and browse to ./zcu102_[es2_]rv_ss, hit OK, note that "zcu102_[es2_]rv_ss (custom)" now appears in the Name column.
Select your newly added custom platform "zcu102_[es2_]rv_ss (custom)", hit Next>, this opens the "Choose Software Platform and Target CPU" page.
Leave everything as is, hit Next>, this opens the "Templates" page.
Select Dense Optical Flow (2PPC), hit Finish
The dialog box closes, and you now see the SDx Project Settings pane in the center of the SDx GUI. Notice the progress bar in the lower right border of the pane, saying "C/C++ Indexer" - wait a few moments for this to finish. Locate the "Active build configuration:" in the upper right corner of the pane, which says "Debug" - click it and select Release. Your window should now look something like this:
{sdx_project.png}
↧
pfm-4.jpg
Uploaded
↧
reVISION Getting Started Guide 2017.2
...
Please refer to UG1233, page 8 for instructions.6 Tool Flow Tutorials
...
Windows version.Further,
Further, it is
...
section 5.2).The top-level directory name of the platform is 'zcu102_[es2_]rv_ss'.
Before starting SDx, set the SYSROOT environment variable to point to the Linux root file system delivered with the EV platform, for example:
...
{pfm-3.jpg} The dialog box closes, and you now see the SDx Project Settings pane in the center of the SDx GUI. Notice the progress bar in the lower right border of the pane, saying "C/C++ Indexer" - wait a few moments for this to finish. Locate the "Active build configuration:" in the upper right corner of the pane, which says "Debug" - click it and select Release. Your window should now look something like this:
{pfm-4.jpg}
{sdx_project.png}
In the left hand "Project Explorer" pane, select the of2 project, click right on it, then select Build Project. In the small Build Project dialog that opens, you may hit the "Run in Background" button. That causes the small dialog box to disappear, though you can still see a progress icon in the lower right part of the GUI, showing that work is in progress. Select the Console tab in the lower central pane of the GUI to observe the steps of the build process as it progresses. The build process may take tens of minutes, up to several hours, depending on the power of your host machine, whether you are running on Linux or Windows, and of course the complexity of your design. By far the most time is spent processing the routines that have been tagged for realization in hardware - note the "HW functions" window in the lower part of the SDx Project Settings pane. In our example above, the routines read_optflow_input, xFDenseNonPyrLKOpticalFlow, and write_optflow_output are tagged to be built in hardware. The synthesis of the C code found in these routines into RTL, and the Placement and Routing of that RTL into the programmable logic in the Zynq MPSoC, are the steps that take most of the time.
↧
↧
QEMU for Windows
...
$ cd openembedded-core$ git clone git://git.openembedded.org/bitbake
...
git clone $ git clone https://git.yoctoproject.org/git/meta-xilinx
NOTE: These branches and repos above are not release branches and instead are the latest avaliable code. This means that it is possible that the steps here will need to be changed or even break depending on the current upstream state.
↧
reVISION Getting Started Guide 2017.2
...
The dialog box closes, and you now see the SDx Project Settings pane in the center of the SDx GUI. Notice the progress bar in the lower right border of the pane, saying "C/C++ Indexer" - wait a few moments for this to finish. Locate the "Active build configuration:" in the upper right corner of the pane, which says "Debug" - click it and select Release. Your window should now look something like this:{pfm-4.jpg}
In the left hand "Project Explorer" pane, select the of2 project, click right on it, then select Build Project. In the small Build Project dialog that opens, you may hit the "Run in Background" button. That causes the small dialog box to disappear, though you can still see a progress icon in the lower right part of the GUI, showing that work is in progress. Select the Console tab in the lower central pane of the GUI to observe the steps of the build process as it progresses. The build process may take tens of minutes, up to several hours, depending on the power of your host machine, whether you are running on Linux or Windows, and of course the complexity of your design. By far the most time is spent processing the routines that have been tagged for realization in hardware - note the "HW functions" window in the lower part of the SDx Project Settings pane. In our example above, the routines read_optflow_input, xFDenseNonPyrLKOpticalFlow, and write_optflow_output are tagged to be built in hardware. The synthesis of the C code found in these routines into RTL, and the Placement and Routing of that RTL into the programmable logic in the Zynq MPSoC, are the steps that take most of the time.
Once the Build completes, you will find an sd_card directory has been created, with all the files you need to copy to your SD card and run your application on the zcu102 board, as explained in section 5.2 above. This directory is found in:
↧
QEMU - Zynq UltraScalePlus
...
Running a Zynq UltraScale+ Linux Kernel Image On Xilinx's ARM QEMUBelow is an example of booting a Linux image on a ARM only Zynq UltraScale+ machine (ZCU102). This use case relies on the linux-boot.elf binary which is created by PetaLinux. To avoid requiring this binary use the u-boot boot flow shown below. The kernel should start booting and a shell prompt should be displayed. Control a-x will exit QEMU.
NOTE: This does not start the PMU and will not work with kernels that require the PMU FW (PetaLinux kernels after 2017.1).
$ ./aarch64-softmmu/qemu-system-aarch64 -M arm-generic-fdt -serial mon:stdio -serial /dev/null -display none \
-device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 \ # Un-reset the A53
-device loader,file=./pre-built/linux/images/bl31.elf,cpu-num=0 \ # ARM Trusted Firmware
-device loader,file=./pre-built/linux/images/Image,addr=0x00080000 \ # Linux kernel
-device
-device loader,file=./build/linux/misc/linux-boot/linux-boot.elf \ # A light boot loader, compiled by PetaLinux
-hw-dtb ./pre-built/linux/images/zynqmp-qemu-arm.dtb # HW Device Tree that QEMU uses to generate the model
...
Running a Zynq UltraScale+ U-boot Image On Xilinx's ARM QEMUBelow is an example of booting a u-boot elf image on a ARM only Zynq UltraScale+ machine (ZCU102).
NOTE: This does not start the PMU and will not work with kernels that require the PMU FW (PetaLinux kernels after 2017.1).
$ ./aarch64-softmmu/qemu-system-aarch64 -M arm-generic-fdt -serial mon:stdio -serial /dev/null -display none \
-device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 \ # Un-reset the A53
...
Running a Zynq UltraScale+ Linux Kernel Image On Xilinx's ARM/PMU QEMUThis example allows you to start two instances of QEMU, one with the ARM cores and one with the MicroBlaze PMU core. NOTE that the QEMU hardware device trees are only supplied with PetaLinux 2016.1 and later BSPs.
If you are having issues starting QEMU, you can run petalinux-boot --qemu to see an example command line.
In the first terminal, start the ARM cores
$ ./aarch64-softmmu/qemu-system-aarch64 -M arm-generic-fdt -serial mon:stdio -serial /dev/null -display none \
-device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 \ # Un-reset the A53
-global xlnx,zynqmp-boot.cpu-num=0 -global xlnx,zynqmp-boot.use-pmufw=true \ # Setup multi-boot
-device loader,file=./pre-built/linux/images/bl31.elf,cpu-num=0 \ # ARM Trusted Firmware
-device loader,file=./pre-built/linux/images/Image,addr=0x00080000 \ # Linux kernel
-device
-device loader,file=./build/linux/misc/linux-boot/linux-boot.elf \ # A light boot loader, compiled by PetaLinux
-hw-dtb ./pre-built/linux/images/zynqmp-qemu-multiarch-arm.dtb \ # HW Device Tree that QEMU uses to generate the model
...
$ microblazeel-softmmu/qemu-system-microblazeel -M microblaze-fdt -nographic \-hw-dtb ./pre-built/linux/images/zynqmp-qemu-multiarch-pmu.dtb \
-kernel
--device loader,file=/images/zynqmp/petalinux-v2017.1/pmufw.elf \ # PMU FW
-machine-path ./qemu-tmp # A shared directory the two instances can communicate. This must be the same directory for each instance
Debugging the A53s and the R5s from GDB
...
You can open the QEMU port when starting QEMU using this argument:-gdb tcp::1234
...
shown above.If QEMU is already running you can use the gdbserver command from the QEMU prompt to open the GDB server port.
To simplify this connection you can add a function to GDB. To do this edit your .gdbinit file (located in your home directory) and add something like this:
↧
QEMU - Zynq UltraScalePlus
...
-machine-path ./qemu-tmp # A shared directory the two instances can communicate. This must be the same directory for each instanceIn a second terminal start the PMU instance. You will need to have an image prepared
$
-hw-dtb ./pre-built/linux/images/zynqmp-qemu-multiarch-pmu.dtb \
-kernel ./images/zynqmp/petalinux-v2017.1/pmu_rom_qemu_sha3.elf \ # PMU ROM
↧
↧
QEMU - Zynq-7000
...
Below is an example of booting a Linux image on a Zynq machine. The Linux kernel should start booting and a shell prompt should be displayed. Control A-X will exit QEMU.$ ./aarch64-softmmu/qemu-system-aarch64 \
-M
-serial /dev/null -serial mon:stdio -display none \
-kernel <path>/uImage -dtb <path>/devicetree.dtb --initrd <path>/uramdisk.image.gz
...
Below is an example of booting a Linux ELF image on a Zynq machine. The Linux kernel should start booting and a shell prompt should be displayed. Control A-X will exit QEMU.$ ./aarch64-softmmu/qemu-system-aarch64 \
-M
-serial /dev/null -serial mon:stdio -display none \
-kernel <path>/image.elf -dtb <path>/system.dtb
↧
channel.png
Uploaded
↧
channel.png
Uploaded
↧
channel.png
Uploaded
↧
↧
channel_new.png
Uploaded
↧
Install and run applications through Smart on target
...
is completely Updating packages on target using smart is experimental as of now
Pre-requisites
ZCU102 pre-built images from here(http://www.wiki.xilinx.com/Zynq_2017.2_Release).
...
should have an internet connection.Verify channels by running smart channel --show
Update package list by running smart update
Run smart query <package_name> to search for a specific package's availability.
NOTE:
...
up seeing{2017-05-01 14_26_23-COM9 - Tera Term VT.png} smart install
When installing packages, always install packagegroups over single packages when available. For example:
To run qt, install packagegroup-petalinux-qt instead of qtbase.
To run GCC, install packagegroup-core-sdk instead of GCC
packagegroup-petalinux-xen and packagegroup-petalinux-openamp will not work and should not be installed.
As an example consider how to install Qt and run it.
Qt installation
We need to install packagegroup-petalinux-x11 and packagegroup-petalinux-qt to run qt applications on target.
...
If you see dual mouse pointers while testing, export QT_QPA_EGLFS_HIDECURSOR=1 to hide one cursor and restart your application.export QT_QPA_EGLFS_HIDECURSOR=1
We need to install packagegroup-core-sdk to be able to compile on target
smart install packagegroup-core-sdk
GCC/G++ testing
Once, SDK is installed, you should be able to use GCC/G++ compiler and build your programs on the target directly.
To test this, there are 2 sample programs attached below. Go ahead and download those onto your target. You can compile and build them as shown below.
To compile use:
{compile.png} GCC/G++ commands to compile examples.
Run the generated executable and verify the output:
{test.png} expected output for example programs
{hello_world.c} {vector-test.cpp}
Related Links
https://labix.org/smart
↧
compile.png
Uploaded
↧