So maybe try:
Now I came across this, apparently JEDEC standard JESD252 specifies a method to reset an SPI flash chip. If I understand the figure correctly, CLK is held low (in mode 0) and CS is used to clock the chip. The data line must carry 0-1-0-1 for a reset to happen:
mmc part, and it it lists partitions, do "boot".
Ok, I've done a bit more reading and also scanned the ISSI datasheet. You guys probably already thought of all the below, but just to make sure. My current understanding of the "all cases covered" reset sequence is as follows:
Larry Wall once observed that "given enough eye balls, all bugs are shallow". It seems to me we don't have enough eye balls yet :^)
@ThomasHornschuh What OS is the machine with the SDCard reader natively using?
It is my Laptop with Windows 10 and an internal SD card reader, but I think I will give @lawrie recommendation of using an USB reader I try. VMWare can pass USB transparently to VMs (it works e.g. with USB disk drives), but the SD Card reader in Laptops are often a Realtek PCIE chip
This may be an option: https://www.balena.io/etcher/
It has binaries for Win, Lin & Mac
Ok. Thanks for the link. I used a different tool Win32DiskImager. It was sucessfull. Still no idea why my first SD card died...
ecppll -i 25 -o 96 --highres -f /dev/stdoutsome code you contributed annotates
(* FREQUENCY_PIN_CLKOP="96" *). Am I missing something or should that frequency actually be
ffeedbackas calculated here? https://github.com/YosysHQ/prjtrellis/blob/74f2c76/libtrellis/tools/ecppll.cpp#L317
ecppll --highresoutput it caused nextpnr errors because it had connected
CLKOSto the same net