08-17-2018 05:29 AM
I want to program the flash memory, with a baremetal application. Currently i am booting from the SD card without a problem, but this is just a temporary solution. Debugging works fine as well. My program started with the Echo server template. While trying to program the flash, it runs the programm but stopps at:
if (!xemac_add(echo_netif, &ipaddr, &netmask, &gw, mac_ethernet_address, PLATFORM_EMAC_BASEADDR))
it neither fails, nor succeeds, i set LEDs before, after and inbetween.
I am using the zynq 7020 on a custom board. this is what the console has to say:
****** Xilinx Program Flash
****** Program Flash v2018.1 (64-bit)
**** SW Build 2188600 on Wed Apr 4 18:40:38 MDT 2018
** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn1
Target 1 : jsn-DLC10-00001a058d0f01
Device 0: jsn-DLC10-00001a058d0f01-4ba00477-0
Retrieving Flash info...
Initialization done, programming the memory
===== mrd->addr=0xF800025C, data=0x00000005 =====
BOOT_MODE REG = 0x00000005
WARNING: [Xicom 50-100] The current boot mode is SD.
If flash programming fails, configure device for JTAG boot mode and try again.
Finished running FSBL.
===== mrd->addr=0xF8000110, data=0x000FA240 =====
READ: ARM_PLL_CFG (0xF8000110) = 0x000FA240
===== mrd->addr=0xF8000100, data=0x00030008 =====
READ: ARM_PLL_CTRL (0xF8000100) = 0x00030008
===== mrd->addr=0xF8000120, data=0x1F000400 =====
READ: ARM_CLK_CTRL (0xF8000120) = 0x1F000400
===== mrd->addr=0xF8000118, data=0x001452C0 =====
READ: IO_PLL_CFG (0xF8000118) = 0x001452C0
===== mrd->addr=0xF8000108, data=0x0001E008 =====
READ: IO_PLL_CTRL (0xF8000108) = 0x0001E008
Info: Remapping 256KB of on-chip-memory RAM memory to 0xFFFC0000.
===== mrd->addr=0xF8000008, data=0x00000000 =====
===== mwr->addr=0xF8000008, data=0x0000DF0D =====
MASKWRITE: addr=0xF8000008, mask=0x0000FFFF, newData=0x0000DF0D
===== mwr->addr=0xF8000910, data=0x000001FF =====
===== mrd->addr=0xF8000004, data=0x00000000 =====
===== mwr->addr=0xF8000004, data=0x0000767B =====
MASKWRITE: addr=0xF8000004, mask=0x0000FFFF, newData=0x0000767B
U-Boot 2018.01-06471-g083ee72 (Mar 12 2018 - 10:57:50 -0600)
Model: Zynq CSE QSPI Board
Board: Xilinx Zynq
DRAM: 256 KiB
WARNING: Caches not enabled
Using default environment
Zynq> sf probe 0 0 0
SF: unrecognized JEDEC id bytes: 00, 00, 00
Failed to initialize SPI flash at 0:0 (error -2)
the programming fails even harder when i try to start not with SD boot. In 2017.4 programming said it succeeded, but always failed when adding blank or verify check. (it didn't succeed at all). Now i am using 2018.1 and get to the error above, which i can't really interpret.
thanks in advance
08-17-2018 06:55 AM
I would start with AR 59174. Specifically, the QSPI Standalone example. Verify your QSPI is connected correctly in your schematic. From what you showed, the QSPI device is not getting recognized from the sf probe 0 0 0 call, that should return the QSPI device ID.
08-22-2018 09:56 PM
To add more info, you can check your flash is supported or not from below user guide,
Don't forget to reply, kudo, and accept as solution.
08-30-2018 07:02 AM
Thanks for your reply. it is a good start.
Just use "Add memory configuration device" in vivado, right ?
1) yes s25fl256s. Is there a way to make w25q256jveq work as well ? (no priority)
2) xsct% mrd 0xF8007080
Invalid target. Use "targets" command to select a target
3) xsct% targets
2 ARM Cortex-A9 MPCore #0 (Breakpoint)
3 ARM Cortex-A9 MPCore #1 (Suspended)
4) nothing from UART
i highly doubt that i am doing this right. Thank you for helping.
08-30-2018 08:00 AM
Look at the tutorial UG1165 it shows how to program QSPI in Linux, uBoot, and bare metal with SDK tools.
09-05-2018 05:29 AM
Regular SD Boot gives now following info via UART
Xilinx First Stage Boot Loader
Release 2017.4 Aug 30 2018-15:45:18
Devcfg driver initialized
Silicon Version 3.1
Boot mode is SD
SD: rc= 0
SD Init Done
Flash Base Address: 0xE0100000
Reboot status register: 0x60600000
Multiboot Register: 0x0000C000
Image Start Address: 0x00000000
Partition Header Offset:0x00000C80
Partition Count: 3
Partition Number: 1
Image Word Len: 0x000F6EC0
Data Word Len: 0x000F6EC0
Partition Word Len:0x000F6EC0
Load Addr: 0x00000000
Exec Addr: 0x00000000
Partition Start: 0x000075D0
Partition Attr: 0x00000020
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
In FsblHookBeforeBitstreamDload function
PCAP:StatusReg = 0x40000A30
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: 0x00000A30
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
Image Word Len: 0x0000B004
Data Word Len: 0x0000B004
Partition Word Len:0x0000B004
Load Addr: 0x00100000
Exec Addr: 0x00100000
Partition Start: 0x000FE490
Partition Attr: 0x00000010
Partition Checksum Offset: 0x00000000
Section Count: 0x00000001
Handoff Address: 0x00100000
In FsblHookBeforeHandoff function
FSBL Status = 0x1
09-05-2018 07:32 AM
What is in your bif? From your log, the FSBL runs, loads the PL, then hands off, all of that looks to be correct.
09-10-2018 03:04 AM
//arch = zynq; split = false; format = BIN
I made the project again from the new version of the Echo server template. No difference. I just found out that apparantly since changing to 2018.1 i cannot do Xil_In8(baseAddress+0x08); (0x42004000). it just hangs. if i try to debug there, i get to a state where i need to restart the hardware(remove power), to use it again.
hdf file says: 0x4200400 - 0x42005fff S_AXI REGISTER
is there anything else i can check about that ?
09-10-2018 07:58 AM
To help isolate the issue, I would suggest you remove the echo.elf and replace that with a hello_world. It appears the issue is with your echo server. Do the versions of Vivado, SDK, and echo server all match?
09-14-2018 08:50 AM
Is it just Xil_In8(0x42004000) or any other access to the PL that hangs?
Can you try Xil_In32 ? I am wondering if something changed in the compiler.
09-19-2018 04:17 AM
resynthesized again in 2017.4 and re-generated the bitstream and exported it. same problem. hdf file still says the correct addresses. xil_in32 and xil _out32 have the same issue. interestingly other addresses work.
09-21-2018 09:31 AM
I think you should drop an ILA (Chipscope) on that AXI port and take a look at the AXI transaction.
Maybe the PL logic is still under reset or the PS-PL level shifters are not released.
09-25-2018 07:29 AM
Hi，we designed a board with ZYNQ 7z020 and S25FL256SAGNFI001(QSPI) ，the QSPI interface is 3.3V。In the online debugging mode, the board peforms good.When Program Flash with SDK ，I checked “Blank check after erase” and “verify after flash”，the reports the programing process is successful, as follows: Verify Operation successful. Flash Operation Successful
But ,when re-power on the board, it boots failed ,inclue ARM and FPGA。 And when read 0xF800_0258，the slcr.REBOOT_STATUS，the value was 0x0048600c。Refer to the datasheet，48 means bits 22 and 19 were set 1。
I think POR should be the last reset，but why slc soft reset were also set 1?
Otherwise,bits[15:0] is BOOTROM error code, I know value 0x600C is 0x200C plus bits 14。BUT I do not understand the solution：
And why does bit 14 set 1？Someone suggestted bit 14 indicates FSBL_PPK_FAILURE_ERROR. Then，I added #define FSBL_DEBUG_INFO in src/fsbl_debug.h，debug the fsbl。From UART1,it print like this：
I do not know how did I enable RSA，and I do not know how to disable it either。In which phase of booting Zynq is failing? BootROM or FSBL?Look forward to your reply.
09-25-2018 07:36 AM
Bit 15 looks to be set, that is FSBL_SPK_FAILURE_ERROR. Check your power-up and power-down sequence, possibly you have accidentally blown some eFuses. AR65240
09-26-2018 08:17 AM
what is FSBL_SPK_FAILURE_ERROR？I can not find anything about FSBL_SPK_FAILURE_ERROR in datasheet。
I did not intend to use efuse，and if my power-up and power-down sequence were ok，what other factors may caused the efuse？I can see the value of bootrom header parameters at the address 0x028 is 0x00000000,so can I judge it
was not in efuse state?
09-26-2018 08:34 AM
The error is the SPK was not found / is incorrect. It is based on RSA eFuses being programmed. If you did not intentionally program them, then go through AR 65240 in close detail to ensure you do not have a power-up / power-down issue. The encryption status you show is for the software image, and does not reflect the hardware state. The tcl scripts in the AR will return information on efuses being blown.
09-26-2018 06:18 PM
09-27-2018 05:54 AM
eFuses are permanent