I’m probably using VisionFive beyond the basic use cases. I’m basically playing around with running bare metal software after allowing the boot loader to run. I do not have an SD card installed, so the boot stops and does not bring up Linux.
Then, I use OpenOCD and a JTAG probe to load an elf file into DRAM and run something. This works fine. I made a mistake where I accidentally wrote into the QSPI XIP space 0x2000_0000. This corrupted the boot loader. First of all, I’m really surprised that writes to this address range are not dropped. Second, the writes do not happen correctly. Basically, each bit in the flash is AND’ed with the data written. Since I did not initiate an erase operation, this resulted in basically corrupt data (not original boot loader or what I accidentally wrote).
To reproduce with OpenOCD, you can do:
mwd phys 0x20000000 1
Warning, this will corrupt your boot loader.
If you write all 1’s, you will see the original data at 0x2000_0000 is retained. If you write something like 0xA5A5_A5A5, you will get some other data pattern stored at the location.
I’m curious if there is any insight into why writes to the QSPI XIP space is enabled at all. I’m also curious if this is considered a bug and the boot firmware should be patched to disable writes completely or at least into XIP address space.