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: 
Scholar ronnywebers
Scholar
3,898 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081, can you try the following : 

 

using the method in the first pdf (the one where hello world is not working) : before you click 'create boot image' -> delete the design_1_wrapper.bit file from the image, so you only have :

 

1) ZYNQ_FSBL

2) ZYNQ_PL

 

I think your hello world will then work (because you removed the .bitstream). I think the FSBL is stuck on loading the .bitstream for some reason. Can you confirm that please?

 

btw, did you notice the FSBL output on the serial console? It says something like 'Xilinx First Stage Boot Loader ... Boot mode is SD ....'

** kudo if the answer was helpful. Accept as solution if your question is answered **
Scholar ronnywebers
Scholar
3,895 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081 if you look into your helloworld app, and right click on 'init_platform()' -> open declaration 

 

-> there you'll read in the comments why including the ps7_init files works. Instead of copy/pasting the files, you can also unocmment the 2 lines as explained there (acutally you should do that and not copy.

 

as long as you work in SDK, and download your code from there using JTAG, the ps7_init scripts are executed by SDK before launching your firmware. But when your application runs outside SDK, which is the case when you boot from SD card, SPI, ... your helloworld app must first initialize all registers as needed. Hence you need to uncomment these 2 lines.

 

xilinx should place this comment in the 'helloworld.c' file too, right above the call to init_platform, because many people don't look in the function.

 

What you then also must know, is that the bootloader will actually also call ps7_init(), you can see that if you open main.c of the bootloader. So, if you use a bootloader, then your helloworld app doesn't need to call the ps7_init() necessarily. 

 

however, you must make sure in that case that the FSBL's bsp  get's updated all the time when your .hdf file / bitstream changes, otherwise it's ps7_init() might not cover all new changes. 

 

This is probably the case, as you share the BSP between your FSBL and your application. I never did this before, and always created a BSP for the application separately. But I guess there's no harm in doing it your way.

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Explorer
Explorer
3,877 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

I perform two tests. Kindly see attachment. 

 

It look like that while creating Boot Image whenever I have a second file partition (elf or bit) as datafile then the application does not work (test 1) but if I have only one partition i.e. bootloader and generate BOOT.BIN using the bootloader partition then it works as shown in test 2.  

0 Kudos
Explorer
Explorer
3,875 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

@ronnywebers Thank you for nice explanation. It makes concept clear. This means that for application running outside SDK ( using SD card or QSPI Flash) if there is FSBL application then there is no need to call ps7_init() because main.c already call it in FSBL but if there is only Hello World application then ps7_init() has to uncomment along with it's header ps7_init.h in the file where init_platform() is defined.  

0 Kudos
Highlighted
Scholar ronnywebers
Scholar
3,845 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081, I think you attached 2 identical log files. The logfiles you attached show that the FSBL builds correctly.

 

I'm not sure if you complete get the purpose of setting the -DFSBL_DEBUG flag (?). It has nothing to do with the .log file you attach.

 

setting the -DFSBL_DEBUG flag enables extra printf's in the FSBL code, so you can follow in detail on the serial port (where 'hello world' is printed, what the FSBL is doing. I'm interested in that output, so what comes out of the serial port before the 'helloworld' message.

 

Also, I just checked, and it's even better to set -DFSBL_DEBUG_INFO, that will send even more detailed info to the serial port. So can you adjust that in your FSBL project settings please, and then let me know what you see on the serial port.

 

Also, what you try to do with your hello world app without an FSBL is not standard use - normally you always use an FSBL, because it contains the code to read the SD-card partition etc, so I'm actually surprised that you can get the helloworld application boot from SD-card without an FSBL, but looks like it does. But anyway, the helloworld would never load your bitstream, that's a task for the FSBL.

 

So a Zynq generally starts up as follows :

1) Bootrom : this is ROM code inside the Zynq, that checks the boot jumpers to see from where it must boot : QSPI, SD-card, ...

2) in your case the bootrom reads the boot.bin from the sd-card, and hands over control to the FSBL

3) FSBL initializes some stuff, does some tests, then checks if there is a bitstream to load. if so it does load the bistream

4) after loading the bitstream (if it was present), the application 'helloworld' is loaded, and FSBL hands over control to the 'helloworld' application

 

But, I can tell you there seems to be a problem with the bitstream - I can see it too (and that might be a bug in Vivado...I'm checking this further). So if you can try these 2 cases :

 

1) boot.bin with FSBL, bitstream and helloworld app

2) boot.bin with only FSBL and helloworld app (so no bitstream, delete it before you click 'create image') (you can add the bitstream again, but make sure it's 2nd in position, the order matters in the boot image)

 

 

for both cases, I'd like to see the serial port output (with -DFSBL_DEBUG_INFO set)

** kudo if the answer was helpful. Accept as solution if your question is answered **
Scholar ronnywebers
Scholar
3,826 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

a succesfull boot looks like this : 

 

Xilinx First Stage Boot Loader 
Release 2017.1	Feb 11 2018-11:27:08
Devcfg driver initialized 
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done 
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 2
Partition Number: 1
Header Dump
Image Word Len: 0x00002002
Data Word Len: 0x00002002
Partition Word Len:0x00002002
Load Addr: 0x00100000
Exec Addr: 0x00100000
Partition Start: 0x000065D0
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFDF37C8
Application
Handoff Address: 0x00100000
In FsblHookBeforeHandoff function 
SUCCESSFUL_HANDOFF
FSBL Status = 0x1
** kudo if the answer was helpful. Accept as solution if your question is answered **
Explorer
Explorer
3,821 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

I just try the first case (without PL) by making new project in Vivado. Kindly see attachment. 

0 Kudos
Explorer
Explorer
3,815 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

I end up with non successful boot with Hello World project. No idea what's the reason that FSBL is not properly working when I have Hello World Application using existing FSBL BSP.

 

Actually I also have something more interesting to share which is a project (using two AXI BRAM Controllers) that I have tested two weeks ago on the same board using bit file at second position in BOOT.BIN partition but with separate BSP, it works well, it is surprising that it works with FSBL_ELF, BIT File and BRAM_ELF. Kindly see attachment. 

0 Kudos
Scholar ronnywebers
Scholar
3,806 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081. the method in your last pdf (with the BRAMs) is how I always work : 1 BSPfor the FSBL , 1 BSP for the application. I never tried sharing the BSP.

 

In general you want to keep the BSP for the bootloader limited to the bare minimum, it doesn't need to know about any IP in your design or PS peripheral drivers that the FSBL doesn't use (like USB, ethernet, ..), so it doesn't need to include all the drivers. Hence a simple, separate FSBL. I also let SDK generate it for me, so it includes the necessary libraries to access the SD card.

 

The BSP for the fsbl needs 2 extra libraries (xilffs and xilrsa) to access the SD card. 

 

The BSP for the application is in general much larger : it contains drivers for PS peripherals (ethernet, usb, ...) and PL IP.

 

hence 2 BSPs is a better way of working.

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Scholar ronnywebers
Scholar
3,790 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081, coming back to your previous post, where you shared the pdf file (hello_world_n_fsbl(without bitstream).pdf) with 4 log files :

 

I see now where some of your problems are coming from : you think that there is no PL in your design, when you only instantiate a Zynq in your block design. But ... you do connect FCLK_CLK0 back to M_AXI_GP0_ACLK. : 

 

FCLK.png

And - strange as it may seem to be, this connection is made in the PL :-) Actually, FCLK0 goes from the PS to a BUFG clock buffer in the PL, and then back to the AXI port .... so you DO need a bitstream here, otherwise the axi interface has no clock.

  

You can check the connection in the floorplanner, in my device it looks like this (edit : updated image) :

 

floorplan.png

 

 

edit : you can either add a bitstream to your boot image, or disable the M AXI GP0 interface in your zynq ps, so you don't need to connect FCLK0, and there is really nothign used in the PL

 

edit2 : if I delete the bitstream from the boot.bin, I still get a 'hello world' message. So in this particular case, having no bitstream in the boot.bin works fine, because the firmware does not access the GP0. The moment you would do that, your system will hang as there is no clock on the GP0. So it would be bad practice not having a bitstream in this case.

** kudo if the answer was helpful. Accept as solution if your question is answered **
Scholar ronnywebers
Scholar
4,255 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081, in your last pdf :

 

step 18 - Create new Hello World application (using existing BSP) -> I woud create a new bsp here, don't use the bsp of the FSBL, just leave it as it is.

 

I explained in a previous reply why.

** kudo if the answer was helpful. Accept as solution if your question is answered **
Explorer
Explorer
4,243 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

I include bitstream while exporting hardware in Vivado and also added bitstream in BOOT.BIN at second partition. The Hello World does not work. Kindly see attachment. 

 

I have not tried Hello World without bitstream because if I exclude FCLK_CLK 0 and M_AXI_GP0 in the ZYNQ PS than still there exist FCLK_RESET0_N which I do not know how to remove.  

0 Kudos
Scholar ronnywebers
Scholar
4,235 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

ok - now at least we have a clean FSBL error code : 0xA008

 

 

in fsbl.h you can see that this means 'NO_DDR' -> DDR is missing.

 

you seem to have removed the DDR in your design. I'm not sure why the FSBL absolutely requires the DDR, but I guess without external memory, and only the internal cache, you won't run far with a Cortex A9 processor.

 

So can you try enabling it again, or does your board not have DDR?

 

Then let me know the FSBL output

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Scholar ronnywebers
Scholar
4,229 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

Once you have the DDR enabled, you might get an FSBL status 0xA009, which would mean 'SD init fail'

 

I asume your z turn board has a micro SD card. If you get the 0xA009 error, you'll need to connect the write protect line through EMIO to GND. This is described in AR# 61064

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Explorer
Explorer
4,219 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

Yes the board has 1GB DDR3 SDRAM (2 x 512MB, 32-bit). I will enable DDR in ZYNQ PS. 

 

I have now enabled the DDR in ZYNQ PS. Kindly see the results of 'FSBL_DEBUG_INFO' flag in attachment. 

0 Kudos
Explorer
Explorer
4,207 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

I just read something about the SD version for the Z-turn board from MYIR

 

"some problems are existing on SD V2.3 driver, so you should reset it to version 2.2"

 

https://community.arm.com/b/d93cec259d374627a52f0f2caeafd036/posts/start-from-zero-zynq7000--hello-world-1 

 

Also in section 1.10 of the attached PDF it describe the same. 

 

I able to open the file system.mss as shown in attachment and click Modify this BSP Settings. Under Drivers I found ps7_sd_0 whose driver is 3.3. I am not able to change this to 2.2. 

 

In both sources (ARM and MYIR) I see that they Generate Output Products first and then Create HDL Wrapper but I am doing other way. Which one has to run first ? 

 

0 Kudos
Scholar ronnywebers
Scholar
7,494 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081, I have seen the same issue as you have now : FSBL says 'DMA Done!', and then only a line of dots ... 

 

I have no real clue where the FSBL is stuck. but normally it shoud continue to spit out some messages, load your Hello World app, and finally you should see the 'hello world'.

 

I've seen the issue too a few times, but could not reproduce it in a systematic way. I 'fixed' this somehow by deleting the whole .sdk folder, and starting over from the .hdf export. But it's weird that this solved the issue. You can try that also.

 

I would recommend to keep a copy of your current project's status (archive / zip it), start a new topic, under 'Embedded Boot and Configuration' . As title you could say : Zynq FSBL stuck after 'DMA Done !' message. Shortly describe your problem, put a copy of the screenshot of the serial port in your post too, so people immediately see where the FSBL is stuck, and add your pdf with the detailed steps too. We need to know where the FSBL is stuck, and what the dots mean. Looks like a DMA hang / timeout to me. 

 

You could also try to add for example an AXI GPIO IP, and connect 1 output to a led, and see if that fixes something. It may sound weird, but maybe it has something to do with the 'almost empty' PL

** kudo if the answer was helpful. Accept as solution if your question is answered **

View solution in original post

Scholar ronnywebers
Scholar
4,191 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

@joniengr081, the url you provided regarding the SD driver points to nothing (?)

 

it could be an issue with the driver, but if I look in the fsbl_bsp ->  system.mss file ->  modify bsp settings -> drivers ->  I see driver version 3.2 next to ps7_sd_x, so guess the forum thread you refer to is rather old. But still, it can be a driver issue.

 

it's also worth trying to regenerate the BSP sources (double click the .mss files in both bsps -> re-generate bsp sources', and after thatcleaning all your projects, as during all the edits in Vivado / SDK, something might have gone out of sync - this happens sometimes with the tools. If you're really in doubt, delete the entire sdk folder, export the .hdf again, and repeat all step. Worsed case, you could also clean everything in Vivado : delete the hdl wrapper, generate it again, re-do bitstream generation, and export. Sometimes this fixes weird Vivado bugs (that existed in older versions of Vivado), dough most of these have been fixed in 2017.3 and on.

 

if you're using a micro-sd card, you could also try to connect the SD card WP line to GND through EMIO, as described in AR# 61064.

 

it says 'For a Micro-SD card, the Write protect (WPn) signal is not present (does not exist) at the SD card slot as well as at the physical card in the form of a switch button like in a standard SD/SDIO card.
Define the MIO/EMIO dummy signal with an external pull-down 1K ohm resistor to ensure that the Micro-SD card will be in Write Enable mode, otherwise the Micro-SD card will be in Write Protect mode.'

 

now you don't need the external pull-down, you can also use an EMIO pin, and connect this to GND in the PL.

 

if you double click the Zynq -> MIO config -> check if SD0 WP line is connected to something. This depends on the board config for your z turn board. If there is nothing, you should connect this line to GND in the PL like this :

 

1) enable the 'WP', select 'EMIO', and close the dialog

 

WP pin to EMIO.png

 

in your BD, click on the SDIO_0 to make the WP line visible, and connect it to a constant with value '0' (make sure to double click on the constant, and set it's value to '0', as it defaults to '1' !!)

WP pin to gnd.png

 

rebuild bitstream, export to SDK, and try again. maybe delete the .sdk folder and start over, just to make sure sdk is not fooling you.

 

 edit : AR# 59476 Zynq-7000 AP SoC: SD Programming/Booting Checklist gives an overview of possible SD-card issues, you can check these too. A potential one is '5. Is the SD running at a supported frequency?', because it's a kind of weird hang.

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Scholar ronnywebers
Scholar
4,176 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

by the way, a succesfull boot on my board looks like this :

 

Xilinx First Stage Boot Loader 
Release 2017.1	Feb 11 2018-14:38:10
Devcfg driver initialized 
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done 
Flash Base Address: 0xE0100000
Reboot status register: 0x60400000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 3
Partition Number: 1
Header Dump
Image Word Len: 0x000F6EC0
Data Word Len: 0x000F6EC0
Partition Word Len:0x000F6EC0
Load Addr: 0x00000000
Exec Addr: 0x00000000
Partition Start: 0x000065D0
Partition Attr: 0x00000020
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFD14B7E
Bitstream
In FsblHookBeforeBitstreamDload function 
PCAP:StatusReg = 0x40000A30
PCAP:device ready
PCAP:Clear done
Level Shifter Value = 0xA 
Devcfg Status register = 0x40000A30 
PCAP:Fabric is Initialized done
PCAP register dump:
PCAP CTRL 0xF8007000: 0x4C00E07F
PCAP LOCK 0xF8007004: 0x0000001A
PCAP CONFIG 0xF8007008: 0x00000508
PCAP ISR 0xF800700C: 0x0802000B
PCAP IMR 0xF8007010: 0xFFFFFFFF
PCAP STATUS 0xF8007014: 0x00005A30
PCAP DMA SRC ADDR 0xF8007018: 0x00100001
PCAP DMA DEST ADDR 0xF800701C: 0xFFFFFFFF
PCAP DMA SRC LEN 0xF8007020: 0x000F6EC0
PCAP DMA DEST LEN 0xF8007024: 0x000F6EC0
PCAP ROM SHADOW CTRL 0xF8007028: 0xFFFFFFFF
PCAP MBOOT 0xF800702C: 0x0000C000
PCAP SW ID 0xF8007030: 0x00000000
PCAP UNLOCK 0xF8007034: 0x757BDF0D
PCAP MCTRL 0xF8007080: 0x30800100

DMA Done ! 

FPGA Done ! 
In FsblHookAfterBitstreamDload function 
Partition Number: 2
Header Dump
Image Word Len: 0x00002002
Data Word Len: 0x00002002
Partition Word Len:0x00002002
Load Addr: 0x00100000
Exec Addr: 0x00100000
Partition Start: 0x000FD490
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Checksum: 0xFFCFC8F8
Application
Handoff Address: 0x00100000
In FsblHookBeforeHandoff function 
SUCCESSFUL_HANDOFF
FSBL Status = 0x1
Hello World
** kudo if the answer was helpful. Accept as solution if your question is answered **
Explorer
Explorer
4,154 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

@ronnywebers Thanks for your post.

 

Now Hello World Works !! 

 

As suggested I just restarted the Vivado and created new hello world project, please see attachment. This time I have first  Generated Output Products and then I created HDL Wrapper. The SDK program has two separate BSP. I have no idea why it was stuck at DMA Done ! .... before. Now it continues and print Hello World at the end. 

 

Now I would like to include my Logic IP (two input and gate), I already package it. I just need to include it in the Block Diagram and make the I/O External.  

Scholar ronnywebers
Scholar
3,537 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

great to hear that @joniengr081

 

you ran into a strange Vivado issue, which Xilinx should fix in fact, but as it's hard to systematically reproduce, I would just forget about it, and go on. 

 

sometimes after many edits, sdk gets kind of 'out of sync' with the .hdf file or bsp's, and just recreating everything from scratch is then a good idea. 

 

also, what you try to do is not so 'standard' (having a PS, and 'separated' PL logic), most of the time you'll have a PS connected to some PL stuff through AXI etc. Then you won't see this kind of issues imho.

 

i.e. check this AR about having only PL, and no PS 

 

edit: you could though still post the issue with the dots, to understand where exactly the FSBL is stuck, it would be interesting to know, I couldn't find out in the FSBL code where exactly these dots are produced.

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Explorer
Explorer
3,530 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

Yes it also works. Hello World also print on the Serial Terminal after debug flag output, and FPGA Done LED is also ON but the output is OR Gate with SW0 and SW1 and I have implemented AND Gate in the logic_ip. 

0 Kudos
Scholar ronnywebers
Scholar
3,511 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

ok great to hear, think you can close this case now by accepting one of the reply's as answer. 

 

it will be hard in this case :-) But pick one that you think was the breakthrough to fix your problem.

 

Some last info I want to share, here's a post that I started yesterday. Check in the post also for  AR51207, it explains a bit more about running PL without the PS.

 

 

 

 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Moderator
Moderator
3,501 Views
Registered: ‎07-31-2012

Re: ZYNQ PL Programming

Jump to solution

Hi,

 

Not sure but see if this design helps...

 

Regards

Praveen


-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Scholar ronnywebers
Scholar
3,488 Views
Registered: ‎10-10-2014

Re: ZYNQ PL Programming

Jump to solution

thanks @pvenugo, it gives some more details about the internal connections not used in the Zynq device during PL mode.

 

I think we do pretty much identical stuff in Vivado, boot image looks identical. The only issue that was left at the end, was an unrepeatable issue with the FSBL getting stuck somewhere between bitstream load and application handover, I couldn't find out exactly where the FSBL is hanging, I should try to debug it with JTAG, but currently lack the time to do that.

 

The OP has created a dedicated post for this isue here, can you please check that out? We'll need an FSBL specialist to tell us what exactly the dots mean (check the attaced pdf in that post). It looks like a timout or something on a DMA transaction.

 

I reproduced this issue myself, I had the same 'dots / hang' as @joniengr081, but when you delete the entire .sdk folder, and start all over, sometimes the issue gets resolved. So it will be a tough one to find.

** kudo if the answer was helpful. Accept as solution if your question is answered **
Explorer
Explorer
3,477 Views
Registered: ‎01-13-2018

Re: ZYNQ PL Programming

Jump to solution

@ronnywebers, yes true when I start over (restart my computer and create new project by following same steps as before) the issue DMA Stuck get resolved. 

0 Kudos