Using alt_flash_open_dev with 'enable_reduced_device_drivers'

[Altera_Forum]

I'd like to use on-chip RAM (69KB) for a small nios app to execute in-system-programming code. The only way I could get the code to fit is by enabling the reduced driver option. 

 The problem I'm having though, is that the call to alt_flash_open_dev returns a null handle to the flash.  As a test, if I execute out of external sram, the same code returns a proper handle and I can read/write to the flash.  Since I want the nios app to be self contained, without relying on the external flash or external ram for booting itself, how can read/write to the flash with 'enable_reduced_device_drivers'?

[Altera_Forum]

You probably won't manage to (sensibly) write to flash unless you just use the low level functions. 

IIRC the higher level ones (probably still in the middle of the stack you are trying to use) will do a sector erase before every write - which means that you'll need a sector sized buffer (probably 64k or larger) to do writes. The flash itself (probably) allows single word writes provided that they only change 1s to 0s. The other fubar is that the flash 'block' always contains the boot code - even if you don't need it. I also suspect that you can directly bit-bang the (EPCS) flash from the nios almost as fast as the hadware block accesses it.

[Altera_Forum]

From what I've read, implementing the CFI interface doesn't look too bad, but getting the timing to work could be problematic.. 

 Interstingly, without enabling the reduced driver option, the program size is 149KB, so a little more than twice what I've created in qsys.  However, the compilation report shows logic utilization is < 25%, and memory utilization at 33%.. unfortunately, if I try increasing the onchip memory size, the design doesn't fit! In theory there's enough memory there, but yet it won't synthesize a contiguous space larger than 69KB.. why?

[Altera_Forum]

You also need to allow for the stack any malloc()ed data. The latter will be considerable.... 

 Getting the bit-bang timing valid is easy, the most you'd need to do is write the same value to the io port a few times. However a 100MHz nios probably can't do things too quickly anyway, especially since Avalon bus writes are synchronous (unless they've changed that for teh new version).  The 'memory utilisation' of 33% only include the used parts of the memory blocks - even though the rest of the blocks is typically unusable.