Honored ContributorHi,
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-
Honored ContributorIt 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.Honored ContributorI 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.
Honored ContributorStratix 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.Honored ContributorI 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.
