cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
maxdz8
Adventurer
Adventurer
377 Views
Registered: ‎01-08-2018

Error building platform project

Jump to solution

An alternative title could be "Vitis 2020.2 and Windows, a match not to be made"?

I am at growing pains with Windows and leaving the historical reasons aside I'm still stuck with it. Some days ago I had the unfortunate idea to upgrade my 2019.2 to 2020.2.

Now here is the situation: I made my own .xsa+bitstream from Vivado block design.

In Vitis:

  1. File>New>Application project.
  2. Next. Select "Create a new platform from hardware (XSA)".  Click the "Browse" button.
  3. Pointed to my .xsa file
  4. For reference, let's say platform is my_plt
  5. Next
  6. Application project name. For reference, my_sa
  7. Processor is ps7_cortexa9_0. Next.
  8. Domain: don't touch. Next.
  9. Templates. Select lwIP TCP Perf Client.
  10. Finish

After the magic happens, in Linux...

  1. In the assistant tab, under my_sa_system [System] > my_sa [Application] right-click on debug and select Build from the Menu.
  2. Wait for the magic
  3. A green tick appeared on the previous "debug"
  4. Plug my board
  5. Right-click on previous "debug", currently selected and just built, from the menu Debug > Launch on Hardware
  6. Vitis goes into debug mode, breaking on the first application line
  7. Confirm I can set breakpoints, seems to work (sort of).

I am considering buying another hard drive to multi-boot but in the meanwhile, I need to work in Windows. The project is created in the same way as previously i.e. I create the application project and let Vitis deduce what I need. At first glance, everything seems to be ok. I build the application. I can see something red in the build console for my_plt. Red x everywhere in the assistant tab. An extract of the build is...

"Compiling myaxidevice..."

myaxidevice_selftest.c: In function 'MYAXIDEVICE_Reg_SelfTest':
myaxidevice_selftest.c:52:60: warning: comparison of integer expressions of different signedness: 'u32' {aka 'long unsigned int'} and 'int' [-Wsign-compare]
52 | if ( MYAXIDEVICE_mReadReg (baseaddr, read_loop_index*4) != (read_loop_index+1)*READ_WRITE_MUL_FACTOR){
| ^~
myaxidevice_selftest.c:36:6: warning: unused variable 'Index' [-Wunused-variable]
36 | int Index;
| ^~~~~
arm-none-eabi-ar: creating ../../../lib/libxil.a
arm-none-eabi-ar: *.o: Invalid argument
make[2]: *** [Makefile:19: libs] Error 1
make[1]: *** [Makefile:46: ps7_cortexa9_0/libsrc/sha3scanner_v1_0/src/make.libs] Error 2
make: *** [Makefile:18: all] Error 2
make: Leaving directory 'C:/vitis-workspace/sha3p12scan_plt/zynq_fsbl/zynq_fsbl_bsp'

I suspect this will give me troubles. Build continues nonetheless and after a while I can see...

arm-none-eabi-gcc -o fsbl.elf sd.o nand.o nor.o image_mover.o md5.o fsbl_hooks.o main.o rsa.o qspi.o ps7_init.o pcap
.o fsbl_handoff.o -MMD -MP -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=vfpv3 -mfloat-abi=hard -
Wl,-build-id=none -specs=Xilinx.spec -lrsa -Wl,--start-group,-lxil,-lgcc,-lc,--end-group -Wl,--start-group,-lxilffs,-lxil,-lgc
c,-lc,--end-group -Wl,--start-group,-lrsa,-lxil,-lgcc,-lc,--end-group -Wl,--gc-sections -Lzy
nq_fsbl_bsp/ps7_cortexa9_0/lib -L./ -Tlscript.ld

c:/xilinx/vitis/2020.2/gnu/aarch32/nt/gcc-arm-none-eabi/x86_64-oesdk-mingw32/usr/bin/arm-xilinx-eabi/../../libexec/arm-xilinx-eabi/gcc/arm-xilinx-eabi/9.2.0/real-ld.exe: cannot find -lrsa
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:27: fsbl.elf] Error 1

This surely can't be good yet build carries on. After a while the error about my axi device repeats, I assume the build system re-attempts to build the failing makefile since it later fails right away.

Can this be partially caused by Windows' infamous path-length limitation?

I will be investigating somewhat more next but I have decided to write in advance because I'm not sure where to poke the thing.

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
maxdz8
Adventurer
Adventurer
349 Views
Registered: ‎01-08-2018

A possible solution.

The error message above is rather clear after all so I matched against all include files and I found three:

  • $vitis_workspace/my_plt/hw/drivers/myaxidevice_v1_0/src/Makefile
  • $vitis_workspace/my_plt/zynq_fsbl/zynq_fsbl_bsp/$ps7_contexa9_0/libsrc/myaxidevice_v1_0/src/Makefile
  • $vitis_workspace/my_plt/ps7_cortexa9_a/standalone_ps7_cortex9a/bsp/ps7_contexa9_0/libsrc/myaxidevice_v1_0/src/Makefile

They all look the same

COMPILER=
ARCHIVER=
CP=cp
COMPILER_FLAGS=
EXTRA_COMPILER_FLAGS=
LIB=libxil.a

RELEASEDIR=../../../lib
INCLUDEDIR=../../../include
INCLUDES=-I./. -I${INCLUDEDIR}

INCLUDEFILES=*.h
LIBSOURCES=*.c
OUTS = *.o

libs:
echo "Compiling myaxidevice..."
$(COMPILER) $(COMPILER_FLAGS) $(EXTRA_COMPILER_FLAGS) $(INCLUDES) $(LIBSOURCES)
$(ARCHIVER) -r ${RELEASEDIR}/${LIB} ${OUTS}
make clean

include:
${CP} $(INCLUDEFILES) $(INCLUDEDIR)

clean:
rm -rf ${OUTS}

Notice the emphasis. Most likely file this under "death by the █ windows terminal" failing at substitutions (even though I would expect the pipeline to run on some mingw console of sort).

Now, $(ARCHIVER) is used only in another ... module? Library? Let's take a look at xilffs Makefile. I will spare you the details, let's just say the file list is built more carefully there.

Modify the makefiles above as follows:

COMPILER=
ARCHIVER=
CP=cp
COMPILER_FLAGS=
EXTRA_COMPILER_FLAGS=
LIB=libxil.a

RELEASEDIR=../../../lib
INCLUDEDIR=../../../include
INCLUDES=-I./. -I${INCLUDEDIR}

INCLUDEFILES=*.h
LIBSOURCES=*.c
MYAXIDEVICE_SRCS := $(wildcard *.c)
MYAXIDEVICE_OUTS = $(MYAXIDEVICE_SRCS:%.c=%.o)

libs:
echo "Compiling myaxidevice..."
$(COMPILER) $(COMPILER_FLAGS) $(EXTRA_COMPILER_FLAGS) $(INCLUDES) $(LIBSOURCES)
$(ARCHIVER) -r ${RELEASEDIR}/${LIB} ${MYAXIDEVICE_OUTS}
make clean

include:
${CP} $(INCLUDEFILES) $(INCLUDEDIR)

clean:
rm -rf ${MYAXIDEVICE_OUTS}

Go back into Vitis. Build the platform. Seems ok enough? Let's build the app...

You might get a situation like the picture attached.

Fear not. Just run debug like there's no tomorrow. Looks like working to me, but I'd like to get some further investigation as I'm pretty sure I see some errors in the build and I'm not well aware of possible consequences.

View solution in original post

silly.png
0 Kudos
1 Reply
maxdz8
Adventurer
Adventurer
350 Views
Registered: ‎01-08-2018

A possible solution.

The error message above is rather clear after all so I matched against all include files and I found three:

  • $vitis_workspace/my_plt/hw/drivers/myaxidevice_v1_0/src/Makefile
  • $vitis_workspace/my_plt/zynq_fsbl/zynq_fsbl_bsp/$ps7_contexa9_0/libsrc/myaxidevice_v1_0/src/Makefile
  • $vitis_workspace/my_plt/ps7_cortexa9_a/standalone_ps7_cortex9a/bsp/ps7_contexa9_0/libsrc/myaxidevice_v1_0/src/Makefile

They all look the same

COMPILER=
ARCHIVER=
CP=cp
COMPILER_FLAGS=
EXTRA_COMPILER_FLAGS=
LIB=libxil.a

RELEASEDIR=../../../lib
INCLUDEDIR=../../../include
INCLUDES=-I./. -I${INCLUDEDIR}

INCLUDEFILES=*.h
LIBSOURCES=*.c
OUTS = *.o

libs:
echo "Compiling myaxidevice..."
$(COMPILER) $(COMPILER_FLAGS) $(EXTRA_COMPILER_FLAGS) $(INCLUDES) $(LIBSOURCES)
$(ARCHIVER) -r ${RELEASEDIR}/${LIB} ${OUTS}
make clean

include:
${CP} $(INCLUDEFILES) $(INCLUDEDIR)

clean:
rm -rf ${OUTS}

Notice the emphasis. Most likely file this under "death by the █ windows terminal" failing at substitutions (even though I would expect the pipeline to run on some mingw console of sort).

Now, $(ARCHIVER) is used only in another ... module? Library? Let's take a look at xilffs Makefile. I will spare you the details, let's just say the file list is built more carefully there.

Modify the makefiles above as follows:

COMPILER=
ARCHIVER=
CP=cp
COMPILER_FLAGS=
EXTRA_COMPILER_FLAGS=
LIB=libxil.a

RELEASEDIR=../../../lib
INCLUDEDIR=../../../include
INCLUDES=-I./. -I${INCLUDEDIR}

INCLUDEFILES=*.h
LIBSOURCES=*.c
MYAXIDEVICE_SRCS := $(wildcard *.c)
MYAXIDEVICE_OUTS = $(MYAXIDEVICE_SRCS:%.c=%.o)

libs:
echo "Compiling myaxidevice..."
$(COMPILER) $(COMPILER_FLAGS) $(EXTRA_COMPILER_FLAGS) $(INCLUDES) $(LIBSOURCES)
$(ARCHIVER) -r ${RELEASEDIR}/${LIB} ${MYAXIDEVICE_OUTS}
make clean

include:
${CP} $(INCLUDEFILES) $(INCLUDEDIR)

clean:
rm -rf ${MYAXIDEVICE_OUTS}

Go back into Vitis. Build the platform. Seems ok enough? Let's build the app...

You might get a situation like the picture attached.

Fear not. Just run debug like there's no tomorrow. Looks like working to me, but I'd like to get some further investigation as I'm pretty sure I see some errors in the build and I'm not well aware of possible consequences.

View solution in original post

silly.png
0 Kudos