CFI Flash software driver Support for 32-bits Flash

[Altera_Forum]

Hi, 

 Does the CFI flash software driver support 32-bits flash? My QSYS system is having 32-bits ext flash. When I tried memory test from Eclipse template, it always fails to open the flash. It seems like the HAL API couldn't open my 32-bits flash.  I've ensured all the pins connections are done. Anyone faced this problem before?   Thanks, Carid-

[Altera_Forum]

should be supported! 

 cause the address bus connect,must be avalon A2 to flash A0(flash no byte enable)

[Altera_Forum]

Thanks for the reply. 

 Did you mean I have to turn on the 'byteenable' signal for my ext_flash? If yes, where should this signal be connected to in my top level?  I've ensured both fsm_a[0] and fsm_a[1] are left unconnected as it's 32-bit flash. The signal connection begins with fsm_a[2] and so on.   Thank you.  Carid-

[Altera_Forum]

If your flash memory only supports 32bit accesses, you should leave byteenable signals unconnected. 

addr[2] from the tristate bus should be connected to A0 pin on flash memory, addr[3] to flash A1, and so on. If your flash memory also supports 8 and 16bit modes, you may need to connect tristate addr[n] to flash A[n] because the flash memory itself uses byte addressing. Refer to flash datasheet

[Altera_Forum]

Also, if the 32bit flash is actually made from two 16bit parts you need to take special care during any write/erase operations to ensure that not only are both devices given the requests, but that the driver actually waits for both parts to finish, 

(Fixing that bug was the first thing I had to do to some test environment for a strongarm development board.)

[Altera_Forum]

The Stratix-V FPGA devkit board is actually using 16bitx2 CFI. 

Quartus Programmer works fine. PFL configuration work fine too. In terms of NIOS tools, such as nios2-flash_programmer, it should have been fixed after Q11.1 and should work.

[Altera_Forum]

Thanks all. 

 Yes, my 32-bits flash is made up of 2 16-bits single flash. The data lines are from d[0] - d[15] for 1st flash and d[16] - d[31] for 2nd flash. I've ensured that add[2] is connected to the FIRST address pin on flash memory chip.  "you need to take special care during any write/erase operations to ensure that not only are both devices given the requests, but that the driver actually waits for both parts to finish" Is Altera CFI software driver able to do this?  Which Stratix V FPGA devkit did you mean? As far as I'm concerned, Altera.com has the latest SV devkit which is 100g development kit, stratix v gx edition (http://www.altera.com/products/devkits/altera/kit-stratix-v-gx-100g.html). This devkit only has 1 CFI flash.  Did you mean that as of now, Altera nios tools couldn't support 16bits x 2 CFI?  Thanks.

[Altera_Forum]

The s5devkit is not yet on the web. However, you can see the info from here. 

 Kit Installer: ftp://ftp.altera.com/outgoing/devkit/11.1/stratixvgx_5sgxea7kf40es_fpga_v11.1.2.exe Reference Manual: http://www.altera.com/literature/manual/rm_svgx_fpga_dev_board.pdf User Guide: http://www.altera.com/literature/ug/ug_svgx_fpga_dev_kit.pdf

[Altera_Forum]

Thanks nekojiru. Looks like the BUP software files have been modified for the 16bits x 2 CFI flash. E.g. instead of writing 0x98, it has now become writing 0x00980098 for the 2x 16-bits CFI flash. Am I right?

[Altera_Forum]

That is the sort of thing it must do (I can't remember the command values!). 

There is also likely to be a loop where it waits for a bit to change - indicating that the write/erase is complete. That code must wait for the bit to change in both the high and low halves of the word - so that both chips have finished.

[Altera_Forum]

@nekojiru, do you know which version of ACDS will start supporting the 16bits x2 CFI? There is a IP folder containing the 16bits x2 CFI drivers in the BUP design folder. Perhaps, I will have a look on how it's implemented.

[Altera_Forum]

It looks like the BUP on this release is not yet working. 

As far as I know, Q11.1 or later version of the nios2-flash-programmer for x32 is working fine.

[Altera_Forum]

I see. Can you please tell me what's the problem with the BUP? As I am currently doing a project targets on 32-bits flash (16bits x 2), I just want to confirm if Altera CFI HAL software drivers couldn't work for 32-bits flash while the nios2-flash-programmer is working OK for 32-bits CFI flash? Reason being I am always failed with opening the ext_flash by using the HAL API 'alt_flash_open_dev'. But if using nios2-flash-programmer for --debug, it is able to recognize the 32-bits flash with x16 | x16 mode.

[Altera_Forum]

Stratix V FPGA flash status short-story: 

 Stratix V FPGA Dev Kit has two x16 flash devices U10 & U11 arranged as an option to use U10 lower data bits as a standard CFI 16 bit flash ~or~ U10 (lower) & U11 (upper) data bits as a suedo x32 bit flash device (a.k.a. x16x16).   Quartus II Programmer and PFL supports this fro x32 HW configuration. nios2-flash-programmer supports either (intelligently by first detecting x16x16) but there are no HAL drivers provided for x16x16 flash and the BUP driver support (which tries to use x16x16) has a buffer-write bug which is currently being debugged. The solution should be released at the S V dev kit page and this forum thread will be updated once it’s tested and approved.    Here’s the long-story:   SV could use one x16 flash: Using just U10 x16 (lower data bits) is an option and would enable existing HAL drivers to function normally. A BUP example could be rendered that accommodates that HW arrangement leaving out the upper U11 16bits.   BUP x16x16 buffer-writing has a bug: The current x16x16 drivers for BUP example design still have a bug buffer-writing flash which is finally on the front burner to be resolved and updated to the currently posted installer ASAP (as fast as can be debugged). Sorry to say, the demand to release the kit was greater than the concern over the x16x16 flash bug, thus it released with readme notes (under-the-wire).   x16x16 HAL driver incompatibility work-around (band-aid): When using x16x16 with BUP, UCOS needs to register a HAL driver for alt_sys_init.c  so I put a dummy driver “altera_avalon_cfi_flash1616” into the design ip folder and entered it into the Generic Tristate component for BSP to load. That adhock/custom HAL driver “altera_avalon_cfi_flash1616” only fixes the alt_sys_init portion that queries flash so that alt_sys_init.c doesn’t leave flash in an error state. Then the BUP can proceed with its use of flash. This custom driver could be filled-in or have routines added to take the place of the standard CFI HAL driver if the x16x16 flash is detected at the software build.   nios2-flash-programmer works with x16x16: nios2-flash-programmer, being a separate entity entirely, works without a hitch because we had a mandate to apply resources and get that working for x16x16. I haven’t heard any complaints about that.   I think the next items towards progress in order of priority would be to: 1. Fix the buffer-writing part of the BUP driver 2. Add life to the dummy custom HAL driver “altera_avalon_cfi_flash1616” 3. Recommend the x16x16 HAL technique to whoever cares about the Nios II EDS tools   I will update this thread when status changes or progress is made with the x16x16 flash support.

[Altera_Forum]

I forgot to specify that the x16x16 support in nios2-flash-programmer and in the currently debugging x16x16 BUP are all for Intel algorithm devices (command set 1). No AMD command set (2) support for x16x16 is available at this time.