Attempting to install 2021.2 Xilinx tools
Hi
I'm using v2.5.0-beta.1 with Ubuntu 20.04.6LTS.
I thought from the install guide that Vivado/Vitis/Petalinux 2021.2 was a supported combination. I'd previously tried v2.4.6 with Ubuntu 18.04 and 2019.2 Xilinx tools but had an issue with "ocpiadmin install platform xsim" and then subsequently saw some reports of compatibility issues at Ubuntu 18.04/Vivado 2019.2 combination.
So, I've subsequently tried 2021.2; xsim installs without error, but in the v2.5.0-beta.1 there's no folder ./projects/core/rcc/platforms/xilinx21_2_aarch64. I tried creating by looking at the differences between xilinx17_2_aarch64 and xilinx19_2_aarch64, (so limited renaming from 19_2 to 21_2, and removal of the alternative git tag in the 19_2). After going round a loop of re-running "make cleaneverything" and "./scripts/install-opencpi.h" then trying to "ocpiadmin install platform xilinx21_2_aarch64" I get the process eventually fails in ImportSDKartifacts.sh.
The platform is nonetheless visible with "ocpidev show rcc platforms".
The last lines of the build are:-
make[1]: Leaving directory '/tools/Xilinx/git/linux-xlnx'
---==========================
Capturing the built Linux uImage file and the zynq device trees in directory: /home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64/gen/kernel-artifacts
---==========================
Preparing the kernel-headers tree based on the built kernel.
Removing .cmd
Removing x86_64 binaries
rm kernel-headers/scripts/kallsyms
rm kernel-headers/scripts/sorttable
rm kernel-headers/scripts/basic/fixdep
rm kernel-headers/scripts/asn1_compiler
rm kernel-headers/scripts/extract-cert
rm kernel-headers/scripts/kconfig/conf
rm kernel-headers/scripts/mod/mk_elfconfig
rm kernel-headers/scripts/mod/modpost
rm kernel-headers/scripts/dtc/dtc
Restoring source to removed binaries
Removing unused large headers
Creating the compressed archive for kernel headers
The kernel-headers has been created.
WARNING: Cannot locate libstdc++.so in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libgcc_s.so* in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate ld-.so in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libpthread*.so* in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
cp: cannot stat '/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/gdbserver': No such file or directory
make: *** [/home/gareth/opencpi/cdk/include/xilinx/xilinx-rcc-platform.mk:109: gen/sdk-artifacts.done] Error 1
make: Leaving directory '/home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64'
ocpidev show rcc platforms
| Platform | Package-ID | Target |
| ------------------ | ---------------------------- | ------------------- |
| macos11_4 | ocpi.core.macos11_4 | macos-11_4-x86_64 |
| macos11_3 | ocpi.core.macos11_3 | macos-11_3-x86_64 |
| macos12_5 | ocpi.core.macos12_5 | macos-12_5-x86_64 |
| xilinx13_3 | ocpi.core.xilinx13_3 | linux-x13_3-arm |
| macos12_3 | ocpi.core.macos12_3 | macos-12_3-x86_64 |
| macos13_0 | ocpi.core.macos13_0 | macos-13_0-x86_64 |
| macos12_1 | ocpi.core.macos12_1 | macos-12_1-x86_64 |
| xilinx19_2_aarch64 | ocpi.core.xilinx19_2_aarch64 | linux-19_2-aarch64 |
| macos13_1 | ocpi.core.macos13_1 | macos-13_1-x86_64 |
| macos12_0 | ocpi.core.macos12_0 | macos-12_0-x86_64 |
| macos10_15 | ocpi.core.macos10_15 | macos-10_15-x86_64 |
| macos10_14 | ocpi.core.macos10_14 | macos-10_14-x86_64 |
| ubuntu18_04 | ocpi.core.ubuntu18_04 | linux-u18_04-x86_64 |
| macos12_6 | ocpi.core.macos12_6 | macos-12_6-x86_64 |
| xilinx13_4 | ocpi.core.xilinx13_4 | linux-x13_4-arm |
| xilinx17_1_aarch32 | ocpi.core.xilinx17_1_aarch32 | linux-17_1-aarch32 |
| ubuntu20_04 | ocpi.core.ubuntu20_04 | linux-u20_04-x86_64 |
| centos8 | ocpi.core.centos8 | linux-c8-x86_64 |
| xilinx17_2_aarch64 | ocpi.core.xilinx17_2_aarch64 | linux-17_2-aarch64 |
| mint21_1 | ocpi.core.mint21_1 | linux-m21_1-x86_64 |
| xilinx21_2_aarch64 | ocpi.core.xilinx21_2_aarch64 | linux-21_2-aarch64 |
| macos11_1 | ocpi.core.macos11_1 | macos-11_1-x86_64 |
| xilinx13_4_arm | ocpi.core.xilinx13_4_arm | linux-13_4-arm |
| macos11_5 | ocpi.core.macos11_5 | macos-11_5-x86_64 |
| macos11_6 | ocpi.core.macos11_6 | macos-11_6-x86_64 |
| macos11_2 | ocpi.core.macos11_2 | macos-11_2-x86_64 |
| xilinx17_1_aarch64 | ocpi.core.xilinx17_1_aarch64 | linux-17_1-aarch64 |
| ubuntu22_04 | ocpi.core.ubuntu22_04 | linux-u22_04-x86_64 |
| xilinx19_2_aarch32 | ocpi.core.xilinx19_2_aarch32 | linux-19_2-aarch32 |
| rocky8 | ocpi.core.rocky8 | linux-r8-x86_64 |
| macos12_2 | ocpi.core.macos12_2 | macos-12_2-x86_64 |
| xilinx17_2_aarch32 | ocpi.core.xilinx17_2_aarch32 | linux-17_2-aarch32 |
| macos10_13 | ocpi.core.macos10_13 | macos-10_13-x86_64 |
| macos12_4 | ocpi.core.macos12_4 | macos-12_4-x86_64 |
| centos7 | ocpi.core.centos7 | linux-c7-x86_64 |
| xilinx18_3_aarch64 | ocpi.core.xilinx18_3_aarch64 | linux-18_3-aarch64 |
The Vitis folder structure around where the copy is failing is:-
/tools/Xilinx/Vitis/2021.2/gnu/aarch64
└── lin
├── aarch64-linux
│ ├── aarch64-xilinx-linux
│ ├── bin
│ └── x86_64-petalinux-linux
└── aarch64-none
├── aarch64-xilinx-elf
├── bin
└── x86_64-oesdk-linux
The files in lin/aarch64-linux/bin (such as aarch64-linux-gnu-cpp) seem to suggest for 21_2 the library output directories are ../aarch64-xilinx-linux and searching the files seem to end up in usr/lib.
Would it be a reasonable approach to modify ./runtime/hdl-support/Xilinx/importSDKartifacts.sh to add usr/lib into "places" at line 32, then create another variable for e.g. OcpiCrossCompileLibraryOutput in ./runtime/hdl-support/Xilinx and pass this to importSDKartifacts.sh as an extra parameter (which would be either set as empty or the same as OcpiCrossCompile for versions < 21_2)?
Obviously the error itself is a missing gdbserver; which doesn't seem to exist for the aarch64 target in Vitis 2021_2 as far as I can see. I did see a comment on previous versions that gdbserver is deprecated and may be removed in future versions of Vitis.
Has anyone resolved this already? Are there any other big "gotchas" with targeting 2021.2 as a rcc or vhdl platform?
Kind regards
Gareth Cavaciuti
www.allenvanguard.comhttp://www.allenvanguard.com/
gareth.cavaciuti@allenvanguard.commailto:gareth.cavaciuti@allenvanguard.com
Allen-Vanguard Corporation
IMPORTANT NOTICE:
This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately and delete it from your system. This system and communications using this system are monitored and recorded to secure its effective operation and for other lawful business purposes.
Hi Gareth,
An open MR for xilinx21_1 can be found here:
https://gitlab.com/opencpi/opencpi/-/merge_requests/1015
I'd suggest taking that and adapting it for xilinx21_2 if you want to
commit to it (it appears to fix the importSDKartifacts.sh issues).
I would however be very cautious about using newer Xilinx Tools and the
v2.5.0 branch.
Note: I can see that xilinx21_2 is listed in the 2.5.0 installation guide
but not the 2.4.6 one:
https://opencpi.gitlab.io/releases/v2.4.6/docs/OpenCPI_Installation_Guide.pdf
.
Other assorted ramblings:
The tracking issue for 2021.2 support is still open:
https://gitlab.com/opencpi/opencpi/-/issues/2608
I had a discussion on the following issue a few months back with somebody
asking about support for newer Xilinx versions:
https://gitlab.com/opencpi/opencpi/-/issues/3537
Here is my issue detailing some OS and Xilinx pairings that definitely
work: https://gitlab.com/opencpi/opencpi/-/issues/3520
I believe since then I did try several newer ones, but I don't appear to
have updated the issue.
Cheers,
D. Walters
On Mon, May 22, 2023 at 5:53 PM Gareth Cavaciuti <
Gareth.Cavaciuti@allenvanguard.com> wrote:
Hi
I’m using v2.5.0-beta.1 with Ubuntu 20.04.6LTS.
I thought from the install guide that Vivado/Vitis/Petalinux 2021.2 was a
supported combination. I’d previously tried v2.4.6 with Ubuntu 18.04 and
2019.2 Xilinx tools but had an issue with “ocpiadmin install platform xsim”
and then subsequently saw some reports of compatibility issues at Ubuntu
18.04/Vivado 2019.2 combination.
So, I’ve subsequently tried 2021.2; xsim installs without error, but in
the v2.5.0-beta.1 there’s no folder
./projects/core/rcc/platforms/xilinx21_2_aarch64. I tried creating by
looking at the differences between xilinx17_2_aarch64 and
xilinx19_2_aarch64, (so limited renaming from 19_2 to 21_2, and removal of
the alternative git tag in the 19_2). After going round a loop of
re-running “make cleaneverything” and “./scripts/install-opencpi.h” then
trying to “ocpiadmin install platform xilinx21_2_aarch64” I get the process
eventually fails in ImportSDKartifacts.sh.
The platform is nonetheless visible with “ocpidev show rcc platforms”.
The last lines of the build are:-
make[1]: Leaving directory '/tools/Xilinx/git/linux-xlnx'
---==========================
Capturing the built Linux uImage file and the zynq device trees in
directory:
/home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64/gen/kernel-artifacts
---==========================
Preparing the kernel-headers tree based on the built kernel.
Removing *.cmd
Removing x86_64 binaries
rm kernel-headers/scripts/kallsyms
rm kernel-headers/scripts/sorttable
rm kernel-headers/scripts/basic/fixdep
rm kernel-headers/scripts/asn1_compiler
rm kernel-headers/scripts/extract-cert
rm kernel-headers/scripts/kconfig/conf
rm kernel-headers/scripts/mod/mk_elfconfig
rm kernel-headers/scripts/mod/modpost
rm kernel-headers/scripts/dtc/dtc
Restoring source to removed binaries
Removing unused large headers
Creating the compressed archive for kernel headers
The kernel-headers has been created.
WARNING: Cannot locate libstdc++.so* in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libgcc_s.so* in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate ld-.so in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libpthread*.so* in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
cp: cannot stat
'/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/gdbserver':
No such file or directory
make: *** [/home/gareth/opencpi/cdk/include/xilinx/
xilinx-rcc-platform.mk:109: gen/sdk-artifacts.done] Error 1
make: Leaving directory
'/home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64'
ocpidev show rcc platforms
| Platform | Package-ID | Target |
| ------------------ | ---------------------------- | ------------------- |
| macos11_4 | ocpi.core.macos11_4 | macos-11_4-x86_64 |
| macos11_3 | ocpi.core.macos11_3 | macos-11_3-x86_64 |
| macos12_5 | ocpi.core.macos12_5 | macos-12_5-x86_64 |
| xilinx13_3 | ocpi.core.xilinx13_3 | linux-x13_3-arm |
| macos12_3 | ocpi.core.macos12_3 | macos-12_3-x86_64 |
| macos13_0 | ocpi.core.macos13_0 | macos-13_0-x86_64 |
| macos12_1 | ocpi.core.macos12_1 | macos-12_1-x86_64 |
| xilinx19_2_aarch64 | ocpi.core.xilinx19_2_aarch64 | linux-19_2-aarch64 |
| macos13_1 | ocpi.core.macos13_1 | macos-13_1-x86_64 |
| macos12_0 | ocpi.core.macos12_0 | macos-12_0-x86_64 |
| macos10_15 | ocpi.core.macos10_15 | macos-10_15-x86_64 |
| macos10_14 | ocpi.core.macos10_14 | macos-10_14-x86_64 |
| ubuntu18_04 | ocpi.core.ubuntu18_04 | linux-u18_04-x86_64 |
| macos12_6 | ocpi.core.macos12_6 | macos-12_6-x86_64 |
| xilinx13_4 | ocpi.core.xilinx13_4 | linux-x13_4-arm |
| xilinx17_1_aarch32 | ocpi.core.xilinx17_1_aarch32 | linux-17_1-aarch32 |
| ubuntu20_04 | ocpi.core.ubuntu20_04 | linux-u20_04-x86_64 |
| centos8 | ocpi.core.centos8 | linux-c8-x86_64 |
| xilinx17_2_aarch64 | ocpi.core.xilinx17_2_aarch64 | linux-17_2-aarch64 |
| mint21_1 | ocpi.core.mint21_1 | linux-m21_1-x86_64 |
| xilinx21_2_aarch64 | ocpi.core.xilinx21_2_aarch64 | linux-21_2-aarch64 |
| macos11_1 | ocpi.core.macos11_1 | macos-11_1-x86_64 |
| xilinx13_4_arm | ocpi.core.xilinx13_4_arm | linux-13_4-arm |
| macos11_5 | ocpi.core.macos11_5 | macos-11_5-x86_64 |
| macos11_6 | ocpi.core.macos11_6 | macos-11_6-x86_64 |
| macos11_2 | ocpi.core.macos11_2 | macos-11_2-x86_64 |
| xilinx17_1_aarch64 | ocpi.core.xilinx17_1_aarch64 | linux-17_1-aarch64 |
| ubuntu22_04 | ocpi.core.ubuntu22_04 | linux-u22_04-x86_64 |
| xilinx19_2_aarch32 | ocpi.core.xilinx19_2_aarch32 | linux-19_2-aarch32 |
| rocky8 | ocpi.core.rocky8 | linux-r8-x86_64 |
| macos12_2 | ocpi.core.macos12_2 | macos-12_2-x86_64 |
| xilinx17_2_aarch32 | ocpi.core.xilinx17_2_aarch32 | linux-17_2-aarch32 |
| macos10_13 | ocpi.core.macos10_13 | macos-10_13-x86_64 |
| macos12_4 | ocpi.core.macos12_4 | macos-12_4-x86_64 |
| centos7 | ocpi.core.centos7 | linux-c7-x86_64 |
| xilinx18_3_aarch64 | ocpi.core.xilinx18_3_aarch64 | linux-18_3-aarch64 |
The Vitis folder structure around where the copy is failing is:-
/tools/Xilinx/Vitis/2021.2/gnu/aarch64
└── lin
├── aarch64-linux
│ ├── aarch64-xilinx-linux
│ ├── bin
│ └── x86_64-petalinux-linux
└── aarch64-none
├── aarch64-xilinx-elf
├── bin
└── x86_64-oesdk-linux
The files in lin/aarch64-linux/bin (such as aarch64-linux-gnu-cpp) seem to
suggest for 21_2 the library output directories are ../aarch64-xilinx-linux
and searching the files seem to end up in usr/lib.
Would it be a reasonable approach to modify
./runtime/hdl-support/Xilinx/importSDKartifacts.sh to add usr/lib into
“places” at line 32, then create another variable for e.g.
OcpiCrossCompileLibraryOutput in ./runtime/hdl-support/Xilinx and pass this
to importSDKartifacts.sh as an extra parameter (which would be either set
as empty or the same as OcpiCrossCompile for versions < 21_2)?
Obviously the error itself is a missing gdbserver; which doesn’t seem to
exist for the aarch64 target in Vitis 2021_2 as far as I can see. I did
see a comment on previous versions that gdbserver is deprecated and may be
removed in future versions of Vitis.
Has anyone resolved this already? Are there any other big “gotchas” with
targeting 2021.2 as a rcc or vhdl platform?
Kind regards
Gareth Cavaciuti
gareth.cavaciuti@allenvanguard.com
Allen-Vanguard Corporation
IMPORTANT NOTICE:
This message is intended only for the use of the individual or entity to
which it is addressed. The message may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If the reader of this message is not the intended recipient, you are
notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify me immediately and delete it from
your system. This system and communications using this system are monitored
and recorded to secure its effective operation and for other lawful
business purposes.
discuss mailing list -- discuss@lists.opencpi.org
To unsubscribe send an email to discuss-leave@lists.opencpi.org
PSB: I suggest reading the comments on the !1015 MR.
You may encounter further kernel driver issues.
On Mon, May 22, 2023 at 8:20 PM Dominic Walters waltersdom@googlemail.com
wrote:
Hi Gareth,
An open MR for xilinx21_1 can be found here:
https://gitlab.com/opencpi/opencpi/-/merge_requests/1015
I'd suggest taking that and adapting it for xilinx21_2 if you want to
commit to it (it appears to fix the importSDKartifacts.sh issues).
I would however be very cautious about using newer Xilinx Tools and the
v2.5.0 branch.
Note: I can see that xilinx21_2 is listed in the 2.5.0 installation guide
but not the 2.4.6 one:
https://opencpi.gitlab.io/releases/v2.4.6/docs/OpenCPI_Installation_Guide.pdf
.
Other assorted ramblings:
The tracking issue for 2021.2 support is still open:
https://gitlab.com/opencpi/opencpi/-/issues/2608
I had a discussion on the following issue a few months back with somebody
asking about support for newer Xilinx versions:
https://gitlab.com/opencpi/opencpi/-/issues/3537
Here is my issue detailing some OS and Xilinx pairings that definitely
work: https://gitlab.com/opencpi/opencpi/-/issues/3520
I believe since then I did try several newer ones, but I don't appear to
have updated the issue.
Cheers,
D. Walters
On Mon, May 22, 2023 at 5:53 PM Gareth Cavaciuti <
Gareth.Cavaciuti@allenvanguard.com> wrote:
Hi
I’m using v2.5.0-beta.1 with Ubuntu 20.04.6LTS.
I thought from the install guide that Vivado/Vitis/Petalinux 2021.2 was a
supported combination. I’d previously tried v2.4.6 with Ubuntu 18.04 and
2019.2 Xilinx tools but had an issue with “ocpiadmin install platform xsim”
and then subsequently saw some reports of compatibility issues at Ubuntu
18.04/Vivado 2019.2 combination.
So, I’ve subsequently tried 2021.2; xsim installs without error, but in
the v2.5.0-beta.1 there’s no folder
./projects/core/rcc/platforms/xilinx21_2_aarch64. I tried creating by
looking at the differences between xilinx17_2_aarch64 and
xilinx19_2_aarch64, (so limited renaming from 19_2 to 21_2, and removal of
the alternative git tag in the 19_2). After going round a loop of
re-running “make cleaneverything” and “./scripts/install-opencpi.h” then
trying to “ocpiadmin install platform xilinx21_2_aarch64” I get the process
eventually fails in ImportSDKartifacts.sh.
The platform is nonetheless visible with “ocpidev show rcc platforms”.
The last lines of the build are:-
make[1]: Leaving directory '/tools/Xilinx/git/linux-xlnx'
---==========================
Capturing the built Linux uImage file and the zynq device trees in
directory:
/home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64/gen/kernel-artifacts
---==========================
Preparing the kernel-headers tree based on the built kernel.
Removing *.cmd
Removing x86_64 binaries
rm kernel-headers/scripts/kallsyms
rm kernel-headers/scripts/sorttable
rm kernel-headers/scripts/basic/fixdep
rm kernel-headers/scripts/asn1_compiler
rm kernel-headers/scripts/extract-cert
rm kernel-headers/scripts/kconfig/conf
rm kernel-headers/scripts/mod/mk_elfconfig
rm kernel-headers/scripts/mod/modpost
rm kernel-headers/scripts/dtc/dtc
Restoring source to removed binaries
Removing unused large headers
Creating the compressed archive for kernel headers
The kernel-headers has been created.
WARNING: Cannot locate libstdc++.so* in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libgcc_s.so* in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate ld-.so in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libpthread*.so* in
/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu
in any of these dirs below: libc/lib libc/usr/lib lib
cp: cannot stat
'/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/gdbserver':
No such file or directory
make: *** [/home/gareth/opencpi/cdk/include/xilinx/
xilinx-rcc-platform.mk:109: gen/sdk-artifacts.done] Error 1
make: Leaving directory
'/home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64'
ocpidev show rcc platforms
| Platform | Package-ID | Target
|
| ------------------ | ---------------------------- | -------------------
|
| macos11_4 | ocpi.core.macos11_4 | macos-11_4-x86_64
|
| macos11_3 | ocpi.core.macos11_3 | macos-11_3-x86_64
|
| macos12_5 | ocpi.core.macos12_5 | macos-12_5-x86_64
|
| xilinx13_3 | ocpi.core.xilinx13_3 | linux-x13_3-arm
|
| macos12_3 | ocpi.core.macos12_3 | macos-12_3-x86_64
|
| macos13_0 | ocpi.core.macos13_0 | macos-13_0-x86_64
|
| macos12_1 | ocpi.core.macos12_1 | macos-12_1-x86_64
|
| xilinx19_2_aarch64 | ocpi.core.xilinx19_2_aarch64 | linux-19_2-aarch64
|
| macos13_1 | ocpi.core.macos13_1 | macos-13_1-x86_64
|
| macos12_0 | ocpi.core.macos12_0 | macos-12_0-x86_64
|
| macos10_15 | ocpi.core.macos10_15 | macos-10_15-x86_64
|
| macos10_14 | ocpi.core.macos10_14 | macos-10_14-x86_64
|
| ubuntu18_04 | ocpi.core.ubuntu18_04 | linux-u18_04-x86_64
|
| macos12_6 | ocpi.core.macos12_6 | macos-12_6-x86_64
|
| xilinx13_4 | ocpi.core.xilinx13_4 | linux-x13_4-arm
|
| xilinx17_1_aarch32 | ocpi.core.xilinx17_1_aarch32 | linux-17_1-aarch32
|
| ubuntu20_04 | ocpi.core.ubuntu20_04 | linux-u20_04-x86_64
|
| centos8 | ocpi.core.centos8 | linux-c8-x86_64
|
| xilinx17_2_aarch64 | ocpi.core.xilinx17_2_aarch64 | linux-17_2-aarch64
|
| mint21_1 | ocpi.core.mint21_1 | linux-m21_1-x86_64
|
| xilinx21_2_aarch64 | ocpi.core.xilinx21_2_aarch64 | linux-21_2-aarch64
|
| macos11_1 | ocpi.core.macos11_1 | macos-11_1-x86_64
|
| xilinx13_4_arm | ocpi.core.xilinx13_4_arm | linux-13_4-arm
|
| macos11_5 | ocpi.core.macos11_5 | macos-11_5-x86_64
|
| macos11_6 | ocpi.core.macos11_6 | macos-11_6-x86_64
|
| macos11_2 | ocpi.core.macos11_2 | macos-11_2-x86_64
|
| xilinx17_1_aarch64 | ocpi.core.xilinx17_1_aarch64 | linux-17_1-aarch64
|
| ubuntu22_04 | ocpi.core.ubuntu22_04 | linux-u22_04-x86_64
|
| xilinx19_2_aarch32 | ocpi.core.xilinx19_2_aarch32 | linux-19_2-aarch32
|
| rocky8 | ocpi.core.rocky8 | linux-r8-x86_64
|
| macos12_2 | ocpi.core.macos12_2 | macos-12_2-x86_64
|
| xilinx17_2_aarch32 | ocpi.core.xilinx17_2_aarch32 | linux-17_2-aarch32
|
| macos10_13 | ocpi.core.macos10_13 | macos-10_13-x86_64
|
| macos12_4 | ocpi.core.macos12_4 | macos-12_4-x86_64
|
| centos7 | ocpi.core.centos7 | linux-c7-x86_64
|
| xilinx18_3_aarch64 | ocpi.core.xilinx18_3_aarch64 | linux-18_3-aarch64
|
The Vitis folder structure around where the copy is failing is:-
/tools/Xilinx/Vitis/2021.2/gnu/aarch64
└── lin
├── aarch64-linux
│ ├── aarch64-xilinx-linux
│ ├── bin
│ └── x86_64-petalinux-linux
└── aarch64-none
├── aarch64-xilinx-elf
├── bin
└── x86_64-oesdk-linux
The files in lin/aarch64-linux/bin (such as aarch64-linux-gnu-cpp) seem
to suggest for 21_2 the library output directories are
../aarch64-xilinx-linux and searching the files seem to end up in usr/lib.
Would it be a reasonable approach to modify
./runtime/hdl-support/Xilinx/importSDKartifacts.sh to add usr/lib into
“places” at line 32, then create another variable for e.g.
OcpiCrossCompileLibraryOutput in ./runtime/hdl-support/Xilinx and pass this
to importSDKartifacts.sh as an extra parameter (which would be either set
as empty or the same as OcpiCrossCompile for versions < 21_2)?
Obviously the error itself is a missing gdbserver; which doesn’t seem to
exist for the aarch64 target in Vitis 2021_2 as far as I can see. I did
see a comment on previous versions that gdbserver is deprecated and may be
removed in future versions of Vitis.
Has anyone resolved this already? Are there any other big “gotchas” with
targeting 2021.2 as a rcc or vhdl platform?
Kind regards
Gareth Cavaciuti
gareth.cavaciuti@allenvanguard.com
Allen-Vanguard Corporation
IMPORTANT NOTICE:
This message is intended only for the use of the individual or entity to
which it is addressed. The message may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If the reader of this message is not the intended recipient, you are
notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify me immediately and delete it from
your system. This system and communications using this system are monitored
and recorded to secure its effective operation and for other lawful
business purposes.
discuss mailing list -- discuss@lists.opencpi.org
To unsubscribe send an email to discuss-leave@lists.opencpi.org
Hi Dominic
Thanks for the replies. I’ve got Vitis 2020.2 on another machine and it looks like the same directory structure as 2021.2 (and no gdbserver for target). Whilst the file locations is easily managed, the threat of issues with the kernel driver is enough to push me to move to Centos at least for the time being.
Thanks
Gareth
From: Dominic Walters waltersdom@googlemail.com
Sent: 22 May 2023 20:24
To: Gareth Cavaciuti Gareth.Cavaciuti@allenvanguard.com
Cc: discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Attempting to install 2021.2 Xilinx tools
PSB: I suggest reading the comments on the !1015 MR.
You may encounter further kernel driver issues.
On Mon, May 22, 2023 at 8:20 PM Dominic Walters <waltersdom@googlemail.commailto:waltersdom@googlemail.com> wrote:
Hi Gareth,
An open MR for xilinx21_1 can be found here: https://gitlab.com/opencpi/opencpi/-/merge_requests/1015
I'd suggest taking that and adapting it for xilinx21_2 if you want to commit to it (it appears to fix the importSDKartifacts.sh issues).
I would however be very cautious about using newer Xilinx Tools and the v2.5.0 branch.
Note: I can see that xilinx21_2 is listed in the 2.5.0 installation guide but not the 2.4.6 one: https://opencpi.gitlab.io/releases/v2.4.6/docs/OpenCPI_Installation_Guide.pdf.
Other assorted ramblings:
The tracking issue for 2021.2 support is still open: https://gitlab.com/opencpi/opencpi/-/issues/2608
I had a discussion on the following issue a few months back with somebody asking about support for newer Xilinx versions: https://gitlab.com/opencpi/opencpi/-/issues/3537
Here is my issue detailing some OS and Xilinx pairings that definitely work: https://gitlab.com/opencpi/opencpi/-/issues/3520
I believe since then I did try several newer ones, but I don't appear to have updated the issue.
Cheers,
D. Walters
On Mon, May 22, 2023 at 5:53 PM Gareth Cavaciuti <Gareth.Cavaciuti@allenvanguard.commailto:Gareth.Cavaciuti@allenvanguard.com> wrote:
Hi
I’m using v2.5.0-beta.1 with Ubuntu 20.04.6LTS.
I thought from the install guide that Vivado/Vitis/Petalinux 2021.2 was a supported combination. I’d previously tried v2.4.6 with Ubuntu 18.04 and 2019.2 Xilinx tools but had an issue with “ocpiadmin install platform xsim” and then subsequently saw some reports of compatibility issues at Ubuntu 18.04/Vivado 2019.2 combination.
So, I’ve subsequently tried 2021.2; xsim installs without error, but in the v2.5.0-beta.1 there’s no folder ./projects/core/rcc/platforms/xilinx21_2_aarch64. I tried creating by looking at the differences between xilinx17_2_aarch64 and xilinx19_2_aarch64, (so limited renaming from 19_2 to 21_2, and removal of the alternative git tag in the 19_2). After going round a loop of re-running “make cleaneverything” and “./scripts/install-opencpi.h” then trying to “ocpiadmin install platform xilinx21_2_aarch64” I get the process eventually fails in ImportSDKartifacts.sh.
The platform is nonetheless visible with “ocpidev show rcc platforms”.
The last lines of the build are:-
make[1]: Leaving directory '/tools/Xilinx/git/linux-xlnx'
---==========================
Capturing the built Linux uImage file and the zynq device trees in directory: /home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64/gen/kernel-artifacts
---==========================
Preparing the kernel-headers tree based on the built kernel.
Removing .cmd
Removing x86_64 binaries
rm kernel-headers/scripts/kallsyms
rm kernel-headers/scripts/sorttable
rm kernel-headers/scripts/basic/fixdep
rm kernel-headers/scripts/asn1_compiler
rm kernel-headers/scripts/extract-cert
rm kernel-headers/scripts/kconfig/conf
rm kernel-headers/scripts/mod/mk_elfconfig
rm kernel-headers/scripts/mod/modpost
rm kernel-headers/scripts/dtc/dtc
Restoring source to removed binaries
Removing unused large headers
Creating the compressed archive for kernel headers
The kernel-headers has been created.
WARNING: Cannot locate libstdc++.so in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libgcc_s.so* in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate ld-.so in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
WARNING: Cannot locate libpthread*.so* in /tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/../aarch64-linux-gnu in any of these dirs below: libc/lib libc/usr/lib lib
cp: cannot stat '/tools/Xilinx/Vitis/2021.2/gnu/aarch64/lin/aarch64-linux/bin/gdbserver': No such file or directory
make: *** [/home/gareth/opencpi/cdk/include/xilinx/xilinx-rcc-platform.mk:109https://gw3062.fortimail.com/fmlurlsvc/?fewReq=:B:JVs5MjU3OSV1PjEtMyVqZz4zMjkzMiVwamRtYnd2cWY+ZzQ0NDpiNzFhN2dhNjFlYGU7YDBhZWVhZWY0YmZgNWdiYjUyZmE6MiV3PjI1Ozc0OzA3NjMlcmpnPjA3TklMO2VrMzM0OzE6LjA3TklMO2VpMzM0OzE6JXFgc3c+RGJxZndrLUBidWJganZ3akNib29mbXVibWR2YnFnLWBsbiVgPjozJWtnbz4z&url=http%3a%2f%2fxilinx-rcc-platform.mk%3a109: gen/sdk-artifacts.done] Error 1
make: Leaving directory '/home/gareth/opencpi/projects/core/rcc/platforms/xilinx21_2_aarch64'
ocpidev show rcc platforms
| Platform | Package-ID | Target |
| ------------------ | ---------------------------- | ------------------- |
| macos11_4 | ocpi.core.macos11_4 | macos-11_4-x86_64 |
| macos11_3 | ocpi.core.macos11_3 | macos-11_3-x86_64 |
| macos12_5 | ocpi.core.macos12_5 | macos-12_5-x86_64 |
| xilinx13_3 | ocpi.core.xilinx13_3 | linux-x13_3-arm |
| macos12_3 | ocpi.core.macos12_3 | macos-12_3-x86_64 |
| macos13_0 | ocpi.core.macos13_0 | macos-13_0-x86_64 |
| macos12_1 | ocpi.core.macos12_1 | macos-12_1-x86_64 |
| xilinx19_2_aarch64 | ocpi.core.xilinx19_2_aarch64 | linux-19_2-aarch64 |
| macos13_1 | ocpi.core.macos13_1 | macos-13_1-x86_64 |
| macos12_0 | ocpi.core.macos12_0 | macos-12_0-x86_64 |
| macos10_15 | ocpi.core.macos10_15 | macos-10_15-x86_64 |
| macos10_14 | ocpi.core.macos10_14 | macos-10_14-x86_64 |
| ubuntu18_04 | ocpi.core.ubuntu18_04 | linux-u18_04-x86_64 |
| macos12_6 | ocpi.core.macos12_6 | macos-12_6-x86_64 |
| xilinx13_4 | ocpi.core.xilinx13_4 | linux-x13_4-arm |
| xilinx17_1_aarch32 | ocpi.core.xilinx17_1_aarch32 | linux-17_1-aarch32 |
| ubuntu20_04 | ocpi.core.ubuntu20_04 | linux-u20_04-x86_64 |
| centos8 | ocpi.core.centos8 | linux-c8-x86_64 |
| xilinx17_2_aarch64 | ocpi.core.xilinx17_2_aarch64 | linux-17_2-aarch64 |
| mint21_1 | ocpi.core.mint21_1 | linux-m21_1-x86_64 |
| xilinx21_2_aarch64 | ocpi.core.xilinx21_2_aarch64 | linux-21_2-aarch64 |
| macos11_1 | ocpi.core.macos11_1 | macos-11_1-x86_64 |
| xilinx13_4_arm | ocpi.core.xilinx13_4_arm | linux-13_4-arm |
| macos11_5 | ocpi.core.macos11_5 | macos-11_5-x86_64 |
| macos11_6 | ocpi.core.macos11_6 | macos-11_6-x86_64 |
| macos11_2 | ocpi.core.macos11_2 | macos-11_2-x86_64 |
| xilinx17_1_aarch64 | ocpi.core.xilinx17_1_aarch64 | linux-17_1-aarch64 |
| ubuntu22_04 | ocpi.core.ubuntu22_04 | linux-u22_04-x86_64 |
| xilinx19_2_aarch32 | ocpi.core.xilinx19_2_aarch32 | linux-19_2-aarch32 |
| rocky8 | ocpi.core.rocky8 | linux-r8-x86_64 |
| macos12_2 | ocpi.core.macos12_2 | macos-12_2-x86_64 |
| xilinx17_2_aarch32 | ocpi.core.xilinx17_2_aarch32 | linux-17_2-aarch32 |
| macos10_13 | ocpi.core.macos10_13 | macos-10_13-x86_64 |
| macos12_4 | ocpi.core.macos12_4 | macos-12_4-x86_64 |
| centos7 | ocpi.core.centos7 | linux-c7-x86_64 |
| xilinx18_3_aarch64 | ocpi.core.xilinx18_3_aarch64 | linux-18_3-aarch64 |
The Vitis folder structure around where the copy is failing is:-
/tools/Xilinx/Vitis/2021.2/gnu/aarch64
└── lin
├── aarch64-linux
│ ├── aarch64-xilinx-linux
│ ├── bin
│ └── x86_64-petalinux-linux
└── aarch64-none
├── aarch64-xilinx-elf
├── bin
└── x86_64-oesdk-linux
The files in lin/aarch64-linux/bin (such as aarch64-linux-gnu-cpp) seem to suggest for 21_2 the library output directories are ../aarch64-xilinx-linux and searching the files seem to end up in usr/lib.
Would it be a reasonable approach to modify ./runtime/hdl-support/Xilinx/importSDKartifacts.sh to add usr/lib into “places” at line 32, then create another variable for e.g. OcpiCrossCompileLibraryOutput in ./runtime/hdl-support/Xilinx and pass this to importSDKartifacts.sh as an extra parameter (which would be either set as empty or the same as OcpiCrossCompile for versions < 21_2)?
Obviously the error itself is a missing gdbserver; which doesn’t seem to exist for the aarch64 target in Vitis 2021_2 as far as I can see. I did see a comment on previous versions that gdbserver is deprecated and may be removed in future versions of Vitis.
Has anyone resolved this already? Are there any other big “gotchas” with targeting 2021.2 as a rcc or vhdl platform?
Kind regards
Gareth Cavaciuti
www.allenvanguard.comhttp://www.allenvanguard.com/
gareth.cavaciuti@allenvanguard.commailto:gareth.cavaciuti@allenvanguard.com
Allen-Vanguard Corporation
IMPORTANT NOTICE:
This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately and delete it from your system. This system and communications using this system are monitored and recorded to secure its effective operation and for other lawful business purposes.
discuss mailing list -- discuss@lists.opencpi.orgmailto:discuss@lists.opencpi.org
To unsubscribe send an email to discuss-leave@lists.opencpi.orgmailto:discuss-leave@lists.opencpi.org
Allen-Vanguard Corporation
IMPORTANT NOTICE:
This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately and delete it from your system. This system and communications using this system are monitored and recorded to secure its effective operation and for other lawful business purposes.