UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jasonweb
Visitor
15,129 Views
Registered: ‎01-27-2016

XAPP1079 in Vivado 2015.4

Hello.

I´m trying to update my project in Vivado 2014.4 to 2015.4.

In this project, I use both ARMs CPUs, using BSP source for SDK 2014.2.

 

But in XAPP1079 only are available BSP sources for Vivado 2015.2, and I can´t run the second ARM.

Are there any advance about this for Vivado 2015.4??

 

Thank you.

0 Kudos
31 Replies
Visitor netas_fpga1
Visitor
14,406 Views
Registered: ‎12-29-2015

Re: XAPP1079 in Vivado 2015.4

Hi everyone,

 

I have the same problem. I have started new project with licenced Vivado and SDK 2015.4 but we have not started the second core with default fsbl project.

 

thanks your helps.

0 Kudos
13,198 Views
Registered: ‎05-12-2015

Re: XAPP1079 in Vivado 2015.4

Hi jasonweb,

 

I am interested too in using xapp1079 into Vivado 2015.4, but only the SDK part.

I used the update to Vivado 2015.2 but i see there are problems with the drivers of cdma and vdma: it doesn't recognize xil_types.h

 

Did you find any solution?

 

Thank you.

 

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
13,043 Views
Registered: ‎08-01-2008

Re: XAPP1079 in Vivado 2015.4

I would suggest:
1. Compare the AMP BSP provided by Xapp1079 and the Xilinx standard BSP, mark the difference between them.
2. Then try to modify the standard BSP with the version you are using.
3. Make a repository folder and add it to the SDK repository.
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Xilinx Employee
Xilinx Employee
12,930 Views
Registered: ‎02-01-2008

Re: XAPP1079 in Vivado 2015.4

As balkris suggests:

  1. copy the latest version of standalone bsp found at <sdk_install>/data/embeddedsw/lib/bsp/standalone_v5_3 to your local sdk repository (sdk_repo)
  2. rename it to standalone_v5_39
  3. modify data/standalone.mld and change OPTION DESC to something meaningfull and change OPTION VERSION to 5.39
  4. I presume you are using the gcc compiler so diff src/cortexa9/gcc/boot.S with the same file in your older standalone from sdk_repo and merge all of the differences into your new boot.S. The changes should include: adding the globals _cpu0_catch, _cpu1_catch, OKToRun and EndlessLoop0, and changing the beginning assembly code from the #if XPAR_CPU_ID sections to /* test which processor is running and jump to the catch address.......
  5. Also merge the differences of src/cortexa9/gcc/asm_vectors.S. The changes include: adding xparameters.h, the above mentioned globals, and adding the #if XPAR_CPU_ID code at the end of the vector table.
  6. For the extra icing on the cake, you could add the timer fix which prevents the global timer from being re-initialized by each cpu. This fix contains a #ifdef USE_AMP in src/cortexa9/xtime_l.c.

I've attached a zip file that contains just the above mentioned modified files for standalone_v5_39. Rename the attached to .zip.

Contributor
Contributor
12,587 Views
Registered: ‎10-21-2012

Re: XAPP1079 in Vivado 2015.4

Hi johnmcd,

 

    I'm also still having trouble running the application on CPU1 in 2015.4.

 

I've done the following:

Step Overview:

  • Created the FSBL as described in the original PDF
  • Created app_cpu0_bsp using the 5.39 BSP
  • Created app_cpu0 as an 'Empty Application' selecting the 'Use existing' to point to the newly created 5.39 BSP, imported files from the Vivado 2015.2 app
  • Created app_cpu1_bsp using the 5.39 BSP, and added the extra_compiler_flags value to contain '-g -DUSE_AMP=1'
  • Created app_cpu1 as an 'Empty Application' selecting the 'Use existing' to point to the newly created 5.39 BSP, imported files from the Vivado 2015.2 app
  • Generated the BOOT.bin using the (fsbl.elf, system.bit, app_cpu0.elf, app_cpu1.elf)

Only the application on CPU0 is running. Do you see anything that might be wrong?

 

Thanks!

0 Kudos
Visitor markkoenig
Visitor
11,942 Views
Registered: ‎02-05-2014

Re: XAPP1079 in Vivado 2015.4

Any luck?  I'm stuck at the same point.

 

Mark Koenig

(408) 891-3401

0 Kudos
Xilinx Employee
Xilinx Employee
11,802 Views
Registered: ‎02-01-2008

Re: XAPP1079 in Vivado 2015.4

FSBL does not need to be modified anymore. After opening your SDK project and adding the standalone BSP repository, create FSBL. As part of the zip located on the wiki for 2015.2, there is a readme that contains the instructions. The only difference will be the new BSP that you have created.

0 Kudos
Highlighted
7,241 Views
Registered: ‎01-20-2014

Re: XAPP1079 in Vivado 2015.4

I got it solved.

i used this sdk_repo.zip and unzip it.

copy the "standalone_v5_3" folder from "C:\Xilinx\SDK\2015.4\data\embeddedsw\lib\bsp" to sdk_repo folder(local Project repo".

replace the each files from sdk_repo/bsp/standalone_v5_39 to sdk_repo/standalone_v5_3

delete the bsp folder in sdk_repo and rename the "standalone_v5_3"  "standalone_v5_39".

and follow all the steps in XAPP1079. to get the results.

first i tried with running the both cpu app in debug mode.

to run and check in debug mode you need to follow the below steps

1.in app_cpu0.c comment " Reset and start CPU1 code " completely.

2.when you launch the debug config in system debugger bode.

specify the both apps in application. and for for CPU1 check the stop at entry point.

and launch the debug.

3.cpu0 app with stop at entry point and cpu1 at bootfs.S file.

4.put trigger at the entry point of cpu1 and run the cpu1.

5.and also run the cpu0.

6. you must get both the prints on UART.

 

 

cheers.,

Manjunath BK

0 Kudos
Visitor rmbendig
Visitor
6,674 Views
Registered: ‎03-09-2017

Re: XAPP1079 in Vivado 2015.4

Hey johnmcd,

 

I am trying to recreate XAPP1079 in Vivado 2016.2. I tried to perform the diff and merge solution you proposed with the XAPP for Vivado 2015.2 but I am getting many errors trying to build the bsp in SDK (mostly relating to missing header files, despite using the current standalone bsp as my base... which is apparently standalone v5_5).

 

Is there a 2016.2 version of XAPP1079 coming out anytime or do you have any knowledge as to why I cannot convert the 2015.2 files up to 2016.2?

 

Best,

Rudi

0 Kudos
Visitor vic
Visitor
5,215 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

Hi,

 

I am sorry if this is not the proper thread to post my question. Feel free to move it if needed.

 

I am trying to run the XAPP 1079 on a Zynq Board (xc7z010clg400-1). Because the profile is not originally made for this specific board, I had to make some changes. I follow all the insructions for the Vivado and the SDK, but in the end after the board boots from the microSD card I don't see anything in the terminal. I was wondering first if the changes that I made are correct and if anymore are needed.

 

I have uploaded the create_bd and creat_proj tcl scripts that I have modified.

0 Kudos
Xilinx Employee
Xilinx Employee
5,190 Views
Registered: ‎07-29-2011

Re: XAPP1079 in Vivado 2015.4

Hi,

 

Are you still facing issue

I do have a tcl file for 2016.4 for zc706 incase that helps

 

 

0 Kudos
Visitor vic
Visitor
5,185 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

Hi,

 

I already have the files for ZC702 and ZC706. What I am trying to do is tweak them, so that I can run the profile in a Digilent Zynq Board. Any help with the tweaks that I have and the checking of what I already have done is appreciated. Also, what is the best way to achieve it? Should I try to make a new project and do everything manually or is it easier to tweak the files? Are there any other resources that I can use? Either that have an already working example of bare-metal applications running on both ARM cores, or that highlight the differences between the boards, so that I have some guide at least.

 

The biggest hurdle that I have encountered is that almost all the examples are made for the ZC702 board, and not the Zybo.

0 Kudos
Xilinx Employee
Xilinx Employee
5,108 Views
Registered: ‎07-29-2011

Re: XAPP1079 in Vivado 2015.4

Hi,

I see that you are facing issue with your design (board related)

Can you check , if the basic hello world example works with default BSP - without modifications for XAPP1079

 

Regards

Madhubala

 

0 Kudos
Visitor vic
Visitor
5,086 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

If you mean using the default files given from the Vivado website, I have tried the ones for the ZC702 board with no result. Nothing appears on the terminal screen.
0 Kudos
Visitor dragonfly_
Visitor
4,937 Views
Registered: ‎05-06-2017

Re: XAPP1079 in Vivado 2015.4

Hi, I had this problem on the UART because on the BSP settings I had to set the fields stdin and stdout to ps7_uart_1 (it was none by default).

Hope this can help.

0 Kudos
Visitor vic
Visitor
4,840 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

Sadly, it wasn't this. They were already set to ps7_uart_1.

 

I have tried some things but none of these worked. I tried completely removing Config.preset [] or changing it to Config.preset[Default] but neither of them worked. I tried including in the property list of the instance of processing_system7, a bunch of configs that I found in a separate Zybo PS Preset that I found here, just like the Zedboard file (see attachment) of the 1079 profile. This did not work either.

 

The only iteration that loads on the fpga (but still shows nothing on the terminal), is the one that I simply change the board parts from ZC702 to Zybo, but I leave the Config.Preset [ZC702].

 

Do you have any advice as to what part of the script or the entire process I should look next in order to find the reason it does not work? I have thought about doing all the steps manually, but I do not see how anything would change. It would rather be one more thing to try.

0 Kudos
Visitor dragonfly_
Visitor
4,788 Views
Registered: ‎05-06-2017

Re: XAPP1079 in Vivado 2015.4

Hi, as I just wanted to see the "helloworld" and didn't need the interrupt from PL (as should do the .tcl script), I just followed the instructions here VivadoHelloworld to create a basic PL design.

As for the SDK, I mixed what was with the XAPP1079 with the bsp created on 2015.4 (consider I'm using ZC702 board).

I'll attach the sources folder of the project, in case you want to check if something is missing.

 

 

0 Kudos
Visitor dragonfly_
Visitor
4,775 Views
Registered: ‎05-06-2017

Re: XAPP1079 in Vivado 2015.4

Sorry, the prevoius link doesn't work, this one should http://ece-research.unm.edu/jimp/codesign/Vivado/VivadoHelloWorldTutorial.pdf

0 Kudos
Visitor vic
Visitor
4,428 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

Hi again,

 

I tried with the 2015.4 version of Vivado with no luck. It passes the stages of Vivado and SDK fine but again I don't see anything on the console. I tried using the 5.39 standalone bsp that was posted in a zip in the previous page of this thread. Everything seems to go just fine, until the terminal.

 

I used these drivers, in case there is a problem. As a reminder I am using this board by Digilent.

 

What else could have gone wrong? It is possible that the problem with the 2017.1 version that I was using before was the bsp that was not for that version specifically, although I do not know for sure. But it should be working just fine with the 2015.4 version.

0 Kudos
Xilinx Employee
Xilinx Employee
4,557 Views
Registered: ‎02-01-2008

Re: XAPP1079 in Vivado 2015.4

From your last post, it is unclear if you are using 2015.4 or 2017.1.

 

For xapp1079, the modified standalone BSP only adds the capability for cpu0 to reset and restart cpu1. Also, for 2015.4, there was a modification to prevent reinitialization of the global timer.

 

But, you could ignore the BSP changes and do a one time start of cpu1 by relying on the fact that cpu1 starts by running a WFE loop in OCM instead of handling the cpu1 reset vector and resetting cpu1.

 

You would replace the C code in app_cpu0.c that is enclosed with brackets that starts with:

   {
        /*
         *  Reset and start CPU1
         *  - Application for cpu1 exists at 0x00000000 per cpu1 linkerscript
 ...

...

...

}

 

and replace it with:

 

    print("CPU0: writing startaddress for cpu1\n\r");
    Xil_Out32(CPU1STARTADR, 0x00200000);
    dmb(); //waits until write has finished

    print("CPU0: sending the SEV to wake up CPU1\n\r");
    sev();

 

 

One other thing that isn't clear about your problem, is: does either cpu0 or cpu1 print to their uarts?

 

If cpu0 isn't printing to the uart, try creating a simple hello world that prints to uart0 and test it using sdk to debug the app. The PL doesn't need to be programmed for this simple test.

0 Kudos
Visitor vic
Visitor
4,555 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

I am currently using the 2015.4 version. If I am understanding correctly what you are saying is that the modified bsp only adds some extra capabilities that are not necessary for the program to run. (In the 2017.1 version, I tried with both the 5.39 and the 6.12 - if I recall the number correctly - version). So theoretically it should be fine even if I used 5.3.

 

As far as the uarts, neither core prints anything to the console. In order to create a simple hello world, what are the changes that are required?

 

- Do I choose Hello World when creating the app_cpu0 instead of Empty application and then loading the extra files?

- I presume it doesn't need any changes in Vivado.

 

Sorry for the peppering of questions.

0 Kudos
Xilinx Employee
Xilinx Employee
4,547 Views
Registered: ‎02-01-2008

Re: XAPP1079 in Vivado 2015.4

You are correct. Use the hello world template instead of 'empty application'.

 

User guide UG1165 is an embedded design tutorial that may help answer some of your unasked questions.

 

So try these steps (I presume you have already exported the design from vivado to SDK):

- file new->application project

- set project name to 'hello'

- verify processor selected is a9-0, and the correct hardware platform is selected (usually you will only have one hardware platform that was exported from vivado)

- next

- select 'hello world' then finish

- once sdk finishes creating and compiling the projects:

- right click on 'hello_bsp' and select 'board support settings'

- select overview->standalone

- verify stdin and stdout are set to the uart you are using

- click ok

- right click on 'hello' and select debug_as->debug_configurations

- create a new debug configuration by double clicking on 'xilinx c/c++ application (system debugger)

- you should be able to use the defaults. Notice that run ps7_init is selected

- before selecting 'debug', power up your board, and figure out the uart number that is connected to the uart to usb bridge. Then start a terminal program using that com port. Set baud to 115200

- now in sdk, press the 'debug' button for your debug configuration. Select yes to change perspectives

- Note that the PL shouldn't need to be loaded at this point since you are only running an application on the PS

- At this point, SDK will download the hello.elf to the board, set a break point at main, and then start running hello.elf. The cpu will then hit the breakpoint and SDK should display your hello.c with an arrow beside the line of code where the break point was hit.

- now press the 'step over' icon a few times until the print "hello world" line of code is executed. You should see an output on your terminal

 

You could also modify hello.c to place a while(1) {} around the print.

 

0 Kudos
Visitor vic
Visitor
4,513 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

Everything goes alright until after the question about changing perspective. After i click yes to that, a new message appears.

 

"FPGA configuration is not done on the target. Do you still want to continue launching application?"

 

After I click ok on that, the debug window opens, but firstly the step over button is grayed out and I don't see anything on the terminal.

 

I have attached the SDK log file.

0 Kudos
Visitor vic
Visitor
4,394 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

I tried some things in the past weeks. I made some changes to the board design and the sdk part. I have some questions.

 

Firstly, I changed the tcl script in the property list of the Zynq processing system.I used a preset file of Zybo and copied and pasted the configs into that part of the script. I have attached the file.

 

As I understand the Zybo board from Digilent is close to the Microzed board from Avnet. Both are "part xc7z010clg400-1". And I also read in another thread in this forum, that the board design tcl script for Microzed for the 1078 profile also works for the 1079 profile. The difference between the Zedboard file (which is officially one of the supported boards of the 1079 profile) and the Microzed one is this.

 

Zedboard

 

set ila_0 [ create_bd_cell -type ip -vlnv xilinx.com:ip:ila:6.2 ila_0 ]
  set_property -dict [ list CONFIG.C_ENABLE_ILA_AXI_MON {false} CONFIG.C_MONITOR_TYPE {Native} CONFIG.C_NUM_OF_PROBES {4}  ] $ila_0

Microzed

 

 

set ila_0 [ create_bd_cell -type ip -vlnv xilinx.com:ip:ila:6.2 ila_0 ]
  set_property -dict [ list CONFIG.C_MONITOR_TYPE {Native} CONFIG.C_NUM_OF_PROBES {4}  ] $ila_0

 

What does CONFIG.C_ENABLE_ILA_AXI_MON {false} do?

 

As far as the SDK, I tried what you proposed and changed the part of initialization of the second core. I tried both debugging and booting via the SD, but I still don't see a Hello World in the terminal. I tried some "hello world" examples with only the first core or with microblaze and they work just fine.

0 Kudos
Xilinx Employee
Xilinx Employee
4,382 Views
Registered: ‎02-01-2008

Re: XAPP1079 in Vivado 2015.4

C_ENABLE_ILA_AXI_MON may be a left over from a previous version of ILA and would have been used to configure the ILA for axi mode or native where axi is used to monitor a complete axi bus and native allows you to monitor random signals.

 

If you are using SDK to debug and you are using the example src from the xapp, it will be important to make sure that the PL is downloaded because the program tries to access a peripheral in the PL. If you are only trying hello world on cpu0 and cpu1 in SDK, then the PL doesn't need to be loaded.

 

So you have verified that you can get 'hello world' from cpu0 when using sdk. Can you also print 'hello world' from cpu1 using sdk to download and run cpu1 (remember to choose the second cpu when creating the hello example)?

 

Also, you can use sdk to debug when booting from SD. Create a SDK debug configuration for attaching to a running target. Once your card boots from SD, start the debug configuration in SDK. SDK will switch to the debug perspective (or you can manually switch using the icons near the upper right of the SDK gui). In the debug perspective, you will see both processors. Select one and then press the pause button. You should see an assembly view of what code the cpu is running.

 

Also, FSBL can print a bunch of debug info if you set a define for 'FSBL_DEBUG_INFO' in the fsbl application symbols settings. Or, you can add the define to xfsbl_debug.h.

 

There are times when I want to use SDK to connect to a running target that is booting from SD but I don't want to miss anything so I will add a huge for loop in xfsbl_main.c under the 'case XFSBL_STAGE2' line. This is late enough that fsbl has ran ps7_init.c but early enough that you can control the fsbl flow. When you boot the card, and fsbl starts running the for loop, you can use SDK to connect to the running target, then pause cpu0. If you see assembly code and not source, right click on cpu0 and select the option that has to do with symbol files. Add fsbl.elf and now you should see the fsbl src. Right click on the next line after the for loop and choose 'move here'. Now you can set a breakpoint at XFsbl_Handoff() and continue to this function. Single stepping will continue through the handoff to the point that the cpu jumps to the start of your hello application. Once again, add hello.elf as a symbol file, and then you can set a breakpoint at main() within your hello application and resume until cpu0 hits that breakpoint.

 

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
4,379 Views
Registered: ‎02-01-2008

Re: XAPP1079 in Vivado 2015.4

Presuming you are using the Zybo board, I downloaded the zybo board files from https://github.com/Digilent/vivado-boards, and then moved the downloaded directory vivado-boards-master/new/board_files to windows x:\xapp1079\my_boardRepo\boards\board_files.

 

  • Open vivado 2017.2 (the Digilent board files were updated 2days ago so it appears they target 2017.2)
  • before creating a project, entered the following command in the vivado tcl console
    set_param board.repoPaths {x:\xapp1079\my_boardRepo};
  • then use vivado to create a new project and select the zybo board from the board options instead of device
  • source the attached bd.tcl
  • etc

 

0 Kudos
Visitor vic
Visitor
4,362 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

I just made the simplest example to test if I can see Hello World from both cores. I only included the Zynq processor in the block design. Then in the SDK, I made two Hello World applications projects for the two cores. I am able to see both Hello Worlds when I run the .elf files, so this works fine. I couldn't make it work, so that I run the first .elf and it automatically runs the second.

 

I made an empty application for the first core and used the modified app_cpu0.c file that you proposed. Then when I make the second application project is where the problem lies. I can either make it empty and import the app_cpu1.c file of the profile or make it a Hello World application. In the first case, there are problems because the c file has stuff about the IRQ generator which I have not included in the block design. In the second case, I don't think the Core 1 elf starts, as I don't see anything on the console. I have attached the modified app_cpu0.c file.

 

My end goal is to run either an image processing or an encryption algorithm, that divides tasks between the two cores, so I don't think that I will need the reset features for the second core etc, that require more stuff in the block design. With the current setup, I will probably need to be able to tranfer data between the two cores and see the result in the terminal.

0 Kudos
Xilinx Employee
Xilinx Employee
4,283 Views
Registered: ‎02-01-2008

Re: XAPP1079 in Vivado 2015.4

I took a quick look at your modified app_cpu0.c and it looks good. I presume you have modified the linkerscript file for app_cpu1 such that the starting address is 0x00200000. And I presume you have checked to make sure the linkerscript for app_cpu0 doesn't use the same address space as cpu1.

 

BTW: app_cpu0 doesn't need to disable cache for the fsbl vector table since you are using the wfe loop to start cpu1.

 

So, you could try debugging your startup this way:

  • Start debugging app_cpu0 in sdk
  • once the debugger stops at main(), go to the xsct window and download your app_cpu1.elf using the 'dow' command. You should be able to verify app_cpu1 exists at 0x00200000 using xsct 'mrd' command. BTW you may need to use the 'tar' or 'targets' command to change the xsct focus to cpu0.
  • change sdk focus from cpu0 to cpu1. Do a couple single steps and you should notice that cpu1 is running a wfe loop somewhere around 0xffffff00 and the loop is jumping to the address stored at 0xfffffff0 (which by default is set to near the beginning of the wfe loop.
  • Note: when the debugger is connected to cpu1, it will appear to fall through the wfe since the debugger is essentially creating an event when you single step.
  • either change focus back to cpu0 and single step past the write to 0xfffffff0, or use xsct to do 'mwr 0xfffffff0 0x00200000'. Now 0xfffffff0 contains the starting address of app_cpu1
  • In sdk, change focus back to cpu1 and continue single stepping. You should see cpu1 read 0x00200000 from 0xfffffff0 and then jump to 0x00200000.
  • Now cpu1 will start running the code found in app_cpu1 boot.S. At this point, you will not have source code debug. Right click on cpu1 and choose 'add symbol file' (or something like that) and add your app_cpu1.elf. Do not populate the address and offset ranges. You only need the file added. Now you will see the source code debug of boot.S as you single step.
  • Within the first aprox 10 lines of code ran by cpu1, from boot.S, will check what cpu (number 0 or 1) the code is running on and if you accidentally created app_cpu1 for cpu0, boot.S will enter a wfe loop forever. If you created the app correctly for cpu1, then boot.S should continue to run, then crt and then main.
0 Kudos
Visitor vic
Visitor
4,165 Views
Registered: ‎04-27-2017

Re: XAPP1079 in Vivado 2015.4

I managed to make the application note run on Zybo, but with some minor problems.

 

I am now trying to run a program or two from the ParMibench (or here). I started with basicmath. As I understand, it uses threads. But is it possible to have threads in a bare-metal application, or is it necessary to install a version of Linux on Zybo?

I tried making a blank application project in the SDK and then importing the files that are in the basic math folder. In one of the files the pthread.h file is included, but as this is a bare-metal application there is no pthread.h from the operating system. Is it possible at all to run such an application in the current setup (with some moderate changes) or is it a given that I should install a Linux distribution?

0 Kudos