Actions
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 312 subscribers
  • Views 538 views
  • Users 0 members are here
Related

PL Fabric Reconfiguration from PS

Former Member

All right. I must be dumb.

I have two MMP hardware designs 'A' and 'B'. My software application runs both of them fine.

I need to be able to run 'A' and then on command, switch to 'B'. 

I have two .bit files on the SD card. I load the desired file into DDR and then run the "xdevcfg_polled_example.c" code to upload the new bit file to the fabric.

As far as I can tell, it is successful, but nothing happens. I continue to run the existing hardware.

I have:

  •   BIT_STREAM_LOCATION 0x00420001
  •   BIT_STREAM_SIZE_WORDS 2177058
  •   FILESIZE 17416462
Obviously, I am missing something, but what?
 
Craig
  • 0

    Does it need to be done without JTAG?

    Do I need to reset anything first?

  • 0

    Hello Craig,

    Which MMP are you using? The Zynq based MMP or the Kintex based MMP?

    Where did you get your example file from? Is it this? https://forums.xilinx.com/xlnx/attachments/xlnx/zaps/13040/1/xdevcfg_polled_example.c

    If so that code indicates that the bitstream needs to be non-secure, is that the case for your file?

    What modiciations did you make to your example file? What did you do to make it trigger? What indicates you were sucessful? Are you using the example code to load your initial image?

    Also this may be of some help

    https://forums.xilinx.com/xlnx/attachments/xlnx/zaps/13040/1/xdevcfg_polled_example.c

    --Josh

  • 0 in reply to jafoste4
    Hi Josh
    1.   We are using the Zynq 7Z100 based MMP. using Vivado 15.2.1
    2.   I am indeed using "xdevcfg_polled_example.c" but mine (from my install) is different from yours. The version is the same, but the code varies quite a bit. For example, mine has a whole bunch of stuff about partial reconfiguration (PartialCfg) in it.
    3.   I checked, and, AFAIK, the bitstream is unencrypted.
    4.   I am running in debug mode from JTAG. I have tried a few time from SD, but no luck either. Is JTAG an issue?

     

    My BAREMETAL methodology is as follows:
    1.   I have boot.bin file containing the default FSBL, bitstream, and application on the SD card
    2.   Upon power up, I read a .cfg file into memory and parse some information.
    3.   I then initialize the system for Ethernet, SPI, etc.
    4.   I have a main loop (taken from the echo server example) handling tcp_fasttmr, tcp_slowtmr, and xemacif_input
    5.   When I receive a command from the PC (via Ethernet), parse the information, perform actions, and reply with some data to the PC. This is all done from within the Ethernet callback routine. 

    This worked until recently when I attempted to run UART interrupts and discovered that interrupts are disabled in the callback. I am currently looking at redoing my code for this, but that is a separate issue that I will post later.

    I have two hardware designs. A standard resolution design, and a hires design. I need to switch between them upon command from the PC.
     
    Currently:
    1.   I took the .bit file from each design (in my sdk folder), and using the SDK command "Create Zynq Boot Image", generated .bin files. These files show as "17422240 bytes" or "17432576 bytes on disk"...I am using 17422240 bytes in my code.
    2.   I placed these two files into the SD card's root folder.
    3.   When I receive the command to switch, I load the appropriate file into DDR memory using:
        f_open(&fil2, SD_File2, FA_READ) and f_read(&fil2, (void*)BIT_STREAM_LOCATION, FileSize, &NumBytesRead);
    where BIT_STREAM_LOCATION = 0x00420001 and FileSize = 17422240
    1.   I then used the function XDcfgPolledExample() unmodified from xdevcfg_polled_example.c (my version)
    2.   It returns with "XST_SUCCESS". I then expect the PL to be running the new design, but nothing happens. The system continues to run with the old design as if nothing changed.
     
    One thing I don't get is what this means from the example: /*This is where the virtual address would be used, this example uses physical address.*/
     
    I will try your example code and report back
     
    Thanks for your assistance. My BOSS and I REALLY appreciate it!
     
    Craig
  • 0 in reply to Former Member

    Your example is almost the same as mine. I had to modify it as it calls a readback function. I added:

    XDcfg_SetControlRegister(DcfgInstPtr, XDCFG_CTRL_PCFG_PROG_B_MASK); // Reset PL
    XDcfg_ClearControlRegister(DcfgInstPtr, XDCFG_CTRL_PCFG_PROG_B_MASK); // Init PL
    while((XDcfg_IntrGetStatus(DcfgInstPtr) & XDCFG_STATUS_PCFG_INIT_MASK) != 0);
    XDcfg_SetControlRegister(DcfgInstPtr, XDCFG_CTRL_PCFG_PROG_B_MASK); // Reset PL
    while((XDcfg_ReadReg(DcfgInstPtr->Config.BaseAddr, XDCFG_STATUS_OFFSET) & XDCFG_STATUS_PCFG_INIT_MASK) != XDCFG_STATUS_PCFG_INIT_MASK);
     
    before the line: /* Check if DMA command queue is full */
     
    And, as expected it does clear the PL, but it still won't program. The current drops when the fabric is cleared and then stays. The PS continues to run until it trys to access the hardware, and then it "flys off to space" because there is no hardware attached. 
     
    Could it be something with the .bin file?
     
    Craig
  • 0

    Thanks for your help. I think I got it working now. Ended up going in a different direction though.