Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3- vs. 4-Byte-Adressing: Flashing a MT25QL256 attached to Cyclone 10CL025 fails #467

Open
kawk opened this issue Jun 30, 2024 · 4 comments

Comments

@kawk
Copy link

kawk commented Jun 30, 2024

Hi,

I tried to program a QSPI Flash (MT25QL256) attached to a Intel 10LP (10CL025YU256I7G) using openFPGALoader (branch master as of today, 1b00940). The output indicates a successful upload of the spiOverJtag config (spiOverJtag_10cl025256.rbf) and writing to flash (identified as Micron N25Q256).

However, the content of the flash is only "touched", but not correctly copied from the input RPD: Mostly 0xFF, with contiguous blocks of 256 zero bytes at 0 and then repeated every 64 kByte. Only the last byte of these blocks sometimes is neither 0 or 0xff...

Command: openFPGALoader -v -c usb-blaster -B spiOverJtag_10cl025256.rbf --external-flash top_auto.rpd

I normally program the device using Quartus Programmer with "Factory default enhanced SFL image" for "10CL025Y" and device "MT25QL256". Does specific information about this flash have to be added somewhere?

Kolja

@kawk
Copy link
Author

kawk commented Jun 30, 2024

I learned that Quartus Programmer changes the flash NVCFG from 0xFFFF to 0x8FEE when programming it for the first time. That changes initial addressing mode, for example, and is also needed for further operation (a NIOS2 running from this flash). I suspect that the addressing mode might cause such issues.

@kawk
Copy link
Author

kawk commented Jun 30, 2024

Indeed: After the nonvolatile config register (NVCFG) was forced back to 0xFFFF, programming with openFPGALoader succeeded. Now however my NIOS can't run. Even if it's possible to change the logic and firmware to run with NVCFG 0xFFFF, that would make it incompatible with boards programmed with Quartus Programmer.. Maybe the flash programming code should be enhanced to observe the addressing mode currently active?

@kawk kawk changed the title Flashing a MT25QL256 attached to Cyclone 10CL025 fails (mostly) 3- vs. 4-Byte-Adressing: Flashing a MT25QL256 attached to Cyclone 10CL025 fails Jun 30, 2024
@kawk
Copy link
Author

kawk commented Jun 30, 2024

I validated two possible approaches for the case that flash is configured with default 4-byte adressing in NVCFG:

  • Issue "EXIT 4-BYTE ADDRESSING (0xB7)" once at the very beginning (I put it at the end of read_id()) to put the flash in 3-byte addressing mode (volatile, until next reset), or
  • If flash is currently in 4-byte addressing mode (LSB of flag status register is set), use 4-byte address commands even if address is below 2^24 (no manipulation of active configuration).

Either way, I additionally have to implement some method to change the NVCFG register, because I need to have it changed from the factory default for normal operation, when flashing brand new chips for the first time. What would be be an appropriate way to provide such functionality? An extra command line argument?

@kawk
Copy link
Author

kawk commented Jun 30, 2024

Nb - the NVCFG may put the flash into much more exotic operational modes that prevent programming, such as automatic address wraparound after so many bytes (e.g. 32). I presume it might be a good idea to check for these and disable them at least volatile. However, I don't have an overview what flash chips provide what modes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant