02-03-2018 05:33 AM
I would like to implement very simple two input AND gate on z-tun board 7020. I would like to connect inputs to SW0 (R19), and SW1 (T19) and the output to the Red RGB LED (R14). The switches SW0 and SW1, and the RGB LED are connected to the PL side of the ZYNQ. This application does not need ZYNQ PS. The I/O port connections are in attachment. I have generated bitstream which is bit file. I have copied the bit file to the SD card but the program does not work. The jumper settings are correct for booting z-turn from SD card. Am I missing anything here ? Do I need to include ZYNQ PS even I am not using it ?
02-09-2018 05:24 AM
@Anonymous, 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 :
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 ....'
02-09-2018 05:41 AM
@Anonymous 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.
02-11-2018 03:26 AM
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.
02-11-2018 03:37 AM
@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.
02-12-2018 03:06 AM - edited 02-12-2018 06:31 AM
@Anonymous, 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)
02-12-2018 06:39 AM
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
02-12-2018 07:03 AM
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.
02-12-2018 07:25 AM - edited 02-12-2018 07:25 AM
@Anonymous. 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.
02-12-2018 08:03 AM - edited 02-12-2018 08:55 AM
@Anonymous, 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. :
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) :
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.
02-12-2018 08:41 AM - edited 02-12-2018 08:57 AM
@Anonymous, 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.
02-13-2018 01:55 AM
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.
02-13-2018 02:50 AM
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
02-13-2018 03:01 AM - edited 02-13-2018 03:02 AM
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
02-13-2018 03:35 AM - edited 02-13-2018 04:13 AM
02-13-2018 04:43 AM - edited 02-13-2018 05:15 AM
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"
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 ?
02-13-2018 05:01 AM
@Anonymous, 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
02-13-2018 05:19 AM - edited 02-13-2018 05:24 AM
@Anonymous, 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
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' !!)
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.
02-13-2018 06:22 AM
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
02-14-2018 01:37 AM
@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.
02-14-2018 02:12 AM - edited 02-14-2018 02:14 AM
great to hear that @Anonymous,
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.
02-14-2018 03:45 AM
02-14-2018 05:45 AM
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.
02-14-2018 09:22 PM
02-15-2018 12:54 AM - edited 02-15-2018 12:54 AM
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 @Anonymous, 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.