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: 
Explorer
Explorer
490 Views
Registered: ‎12-11-2017

SPI Flash reconfiguration - a modest proposal

Jump to solution

I have recently run up against the need / desire to use in-system reconfiguration for SPI Flash. I've been looking around this a bit, and although I see some promising work, I haven't yet unearthed all the pieces I need to get this done in one working package.

Why would I want to do this? Glad you asked. Several reasons:

1.  Field upgrades (in-dwelling SPI block has access ot the NOR)

2.  Supporting flashes currently not supported by Vivado via JTAG indirect method (in-dwelling SPI, or temporarily load SPI-enabled bitstream)

3.  Reloading an encrypted platform that has JTAG-to-SPI Flash access disabled (!) (temporarily load SPI-enabled bitstream)

The proposal - Use these pieces or their equivalents:

 - Generic Linux-based driver package for the front end (e.g., https://github.com/torvalds/linux/tree/master/drivers/mtd/spi-nor)
 - XML-driven flash definition (used on some programmers, i.MX/NXP platforms and Broadcom stuff)
 - SPI IP (PG153) driver layer (https://github.com/Xilinx/linux-xlnx/blob/master/drivers/spi/spi-xilinx.c)

 .... and of course, the STARTUPE2 primitive to let the SPI block control CCLK.

The result is a working NOR flash stack that is somewhat platform neutral (can work with Zynq, Microblaze, external host) that can:

  * Process an MCS or binary flash image
  * Download it into the target device
  * Whose parameters defined from a common XML file

My particular need is to do this over PCIe / AXI. I'm sure someone has done this for the Xilinx world somewhere... right?

0 Kudos
1 Solution

Accepted Solutions
Scholar dgisselq
Scholar
430 Views
Registered: ‎05-21-2015

Re: SPI Flash reconfiguration - a modest proposal

Jump to solution

@vortex1601,

I've built something similar many times over, but not quite as you describe.  My own approach has a couple of parts.  First, I control a bus within the design from an external source--usually a UART simply because that's what I have available to me.  I also use Wishbone for that bus controller, although there's no reason why you couldn't use anything else, I tend to do all my work in Wishbone.  Then, on the Wishbone bus, I have two slaves of a particular interest.  One controls an ICAPE2 core which I can use to start the design from any location in flash memory using the WBSTAR (warm boot start .address) and the IPROG (initiate the program cycle) commands.  The second slave is a flash driver which can be used to erase/program the flash.

I've always been scared, along the way, that I will somehow brick the board so bad that it needs to come back home for reconfiguration.  To keep this from happening, I keep a "golden" design loaded into the beginning of the flash that will always boot up. I can then use the golden design to load a second design onto the flash, and to switch to this second design.

You can examine one such project of my here, using the Artix-7 "Arty A7" board from Digilent.

Dan

View solution in original post

2 Replies
Scholar dgisselq
Scholar
431 Views
Registered: ‎05-21-2015

Re: SPI Flash reconfiguration - a modest proposal

Jump to solution

@vortex1601,

I've built something similar many times over, but not quite as you describe.  My own approach has a couple of parts.  First, I control a bus within the design from an external source--usually a UART simply because that's what I have available to me.  I also use Wishbone for that bus controller, although there's no reason why you couldn't use anything else, I tend to do all my work in Wishbone.  Then, on the Wishbone bus, I have two slaves of a particular interest.  One controls an ICAPE2 core which I can use to start the design from any location in flash memory using the WBSTAR (warm boot start .address) and the IPROG (initiate the program cycle) commands.  The second slave is a flash driver which can be used to erase/program the flash.

I've always been scared, along the way, that I will somehow brick the board so bad that it needs to come back home for reconfiguration.  To keep this from happening, I keep a "golden" design loaded into the beginning of the flash that will always boot up. I can then use the golden design to load a second design onto the flash, and to switch to this second design.

You can examine one such project of my here, using the Artix-7 "Arty A7" board from Digilent.

Dan

View solution in original post

Explorer
Explorer
410 Views
Registered: ‎12-11-2017

Re: SPI Flash reconfiguration - a modest proposal

Jump to solution

That's a good start on getting the flash infrastrucure together, I could probably adapt this to the AXI SPI IP with some effort. I'd like to see Xilinx step up to the plate on this too.

0 Kudos