ZipCPU
commented
6 years ago Hmm ... the flash works for me. That's not helpful, I know.
My problem is that your description above is not (yet) enough information for me to help you or fix the problem. Care to engage in some debugging to figure out what's going on?
If you run wbregs version, can you verify that the design is properly loaded initially? The command should return the date found in the builddate.v file. Likewise, you should be able to check that you can read from the flash at all by reading the ID from the flash. You can do this with wbregs qspiid. (My guess is that it will return the wrong ID, but lets see ...)
You should be able to step through the sequence of commands necessary to program the flash using the wbregs command line interface. If you look in the sw/host/regdefs.h file, you'll see the names of a series of flash registers mapped to wbregs register names. A quick look in flashdrvr.cpp finds the failing line as line 190. It's trying to read the volatile configuration register from the flash device. You can read it yourself by issuing the command, "wbregs qspiv". It then tries to write to that register, and fails. This is really a catastrophic failure. Nothing will work if the volatile configuration register on the flash is mis-set. There's a similar non-volatile configuration register that you should also be able to read with "wbregs qspinv". These two are related. Indeed, it might help us to figure out what's going on if you read all of these registers: qspiv qspinv qspis qspiev qspilock and qspiflag (will require one call to wbregs to read each of these). I recommend not writing to these registers accidentally until you (or we) understand what's going on.
My best guess as to what is going on is that the chip is in a different mode from the one the controller thinks it is in. The QSPIID register will help to clear that up--if that's the problem.
The flash chip used on the Arty board also has some design flaws. Specifically, it has a state associated with it that isn't necessarily reset upon a soft-reset or a reload, and sometimes not even on a power up. My point is, you may find a power cycle is required to get the flash back to an appropriate configuration. (This isn't supposed to happen, but the chip doesn't provide any easy hardware protections as I recall.) Sometimes reading from the first address can kick it out of this mode: "wbregs flash; wbregs flash" can do that IIRC.
If all else fails, there's a define in busmaster.v that's commented out: FLASH_SCOPE. If you uncomment this flag, a WB Scope will be placed into your design that we can use next to debug what's actually traversing across the various wires to your flash. If you put the scope in and rebuild, you can then use the eqspiscope program in sw/host to get a trace of what the flash is doing.
Let me know what you find out, and I'll see if I can't help you further.
Dan
tomtor
I've got openarty running on the bigger 100 version, but flash access is not working, eg:
I had the same issue with the FS-Boot of Petalinux (does hang on reading the flash), so something is different compared to the Arty A7 35 model with SPI access.
An alternative would be to only use block and SD RAM for programs by changing the arty.ld configuration and/or bootloader.
I changed arty.ld to do that and disabled the bootloader,
See: https://github.com/tomtor/openarty/tree/Arty100
so the flash issue is a minor issue now.