raw FLASH option needed about openfpgaloader

[trabucayre]

Hi,
all prerequisites are present (-o / --offset to provides base address and I've fixed a bug in spiFlash the last week) but this option was only tested with cyc1000 board.
So, I need to create a design to check behaviour before unlocking this feature (for ECP5 in a first time).
Currently since erase is done by sector it's a 64k offset. But I must improving erase and flash algorithm to handle smallest size as possible.
In fact this feature is in my ASAP todolist.
Thank to motivate me to hurry about that ;)

[emard]

There should not be any hurry. Of course my primary interest
should be ecp5-ft231x :) but I can also test and report what
happens on ft4232 based boards with ecp5-85, artix7-100, and cyclone5-49

[trabucayre]

In fact the interface is not a problem. If it's work with one of them, it will work with all.
I need to enable this feature FPGA per FPGA since flash access is a bit different for each vendor:

• flash access is tranparent for anlogic eagle_s20 and ECP5 (it's only mandatory to write a specific instruction before)
• one bitstream must be loaded in RAM to provide a bridge for xilinx and cyclone devices. An in this situation it's mandatory to have as much as bitstream as FPGA model (artix, spartan6/7, cyclone 10/5) and size. Bitstreams are available for artix A35t and A50t).
• for the specific case of cyc1000 I use the second interface of FT2232 (interface B) to emulate SPI (bitstream is just connexion between pins on the Ftdi side and pins on the Flash side). I must updating this to have jtag<->SPI interface like for xilinx FPGA.

In a first time, I focus to ecp5 (colorlight and ecp5_evn).

[emard]

I kinde understand everything mentioned.
I have a board with ecp5 and 256-mbit flash, the one with 4-byte
address and openFPGALoader works while I know it uses only
3-byte legacy addresses. That's great

I know for every artix anc cyclone, a different jtag-spi passthru
bitstream must be prepared. Not only this but there's more, cyclone5
or MAX10 i htink have some internal flash that is used to initialize
BRAM content so the programmer needs to handle this thing also.

[trabucayre]

I know I need to improve spiFlash support to handle both 4 and 3-bytes address.

For artix and spartan7 se same implementation may be used (@Fatsie has added spartan7 support). For altera I need to first reworks the passthru to use jtag <-> spi instead.

With FPGAs with internal flash it's a bit more easy because in most case the flash is only dedicated for bitstream and it's not possible to add something else.

I have locally unlocked the ability to flash a raw data, a read after write show correct data but I'have a problem with my test design. I'm waiting to fix this before updating lattice support.

[emard]

OK! I have some jtagoverspi for artix7 that works for xc3sprog, do you think it can work for openfpgaloader? I don't know how can I actually try it? If I pass -f option, it still sends bitstream to SRAM instead of FLASHing it Raw option is great, sometimes there's need to write cpu bootloader of vfat image on some higher addresses than bitstream

…

On 9/3/20, Gwenhael Goavec-Merou ***@***.***> wrote: I know I need to improve spiFlash support to handle both 4 and 3-bytes address. For artix and spartan7 se same implementation may be used ***@***.*** has added spartan7 support). For altera I need to first reworks the passthru to use jtag <-> spi instead. With FPGAs with internal flash it's a bit more easy because in most case the flash is only dedicated for bitstream and it's not possible to add something else. I have locally unlocked the ability to flash a raw data, a read after write show correct data but I'have a problem with my test design. I'm waiting to fix this before updating lattice support. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

Yesterday I'have fixed my design for my ECP5_EVN:

• an riscV is written at the beginning of the FLASH
• the CPU firmware is written at 0x200000
  After fixing some issue it's works -> openFPGALoader is able for ECP5 to write something everywhere in flash \o/
  Now it's time to cleanup openFPGALoader and the design before pushing it.

for ECP5 you have to known file format: bit and mcs.

• mcs is written in flash
• bit is loaded in RAM if -m (or nothing) and written in flash if -f

For the jtagofspi, xc3sprog bitstreams are not compatible. I use a piece of HDL I've written. But to support new xilinx FPGA you have just to update the Makefile and add corresponding xdc file.

[emard]

HI I always like something simple, raw binary file and offset - a binary file just written there without any conversion. Of course mcs parser is great for tools that output such formats. Also great would be an option to read flash content back to file, very useful at troubleshooting. When the new stuff is ready for ECP5 I will test Thanx for info - xc3sprog is not compatible, a fresh spioverjtag should be compiled so I started in this direction... compiler needs significant disk free, 38GB free to download, 38GB free to unpack download, 100GB free to install = total 1-2 days of setup is over. After small vacation, I can proceed to compile spi-jtag bitstream from source so no hurry there :) When compressed with gzip -9 I expect to get some small file of 3.3KB long :)

…

On 9/4/20, Gwenhael Goavec-Merou ***@***.***> wrote: Yesterday I'have fixed my design for my ECP5_EVN: - an riscV is written at the beginning of the FLASH - the CPU firmware is written at 0x200000 After fixing some issue it's works -> openFPGALoader is able for ECP5 to write something everywhere in flash \o/ Now it's time to cleanup openFPGALoader and the design before pushing it. for [ECP5](https://github.com/trabucayre/openFPGALoader#lattice-ecp5-colorlight-5a-75b-lattice-ecp5-5g-evaluation-board-ulx3s) you have to known file format: bit and mcs. - mcs is written in flash - bit is loaded in RAM if -m (or nothing) and written in flash if -f For the jtagofspi, xc3sprog bitstreams are not compatible. I use a piece of [HDL](https://github.com/trabucayre/openFPGALoader/blob/master/spiOverJtag/xilinx_spiOverJtag.vhd) I've written. But to support new xilinx FPGA you have just to update the [Makefile](https://github.com/trabucayre/openFPGALoader/blob/master/spiOverJtag/Makefile#L2) and add corresponding xdc file. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

It's true for read back mainly because it's possible to check write task. In fact I've already this (to read back content just after write) to verify the read everywhere.
If I have artix's details I'm able to update the Makefile to produce required bitstream if you want.
For gzip, as mentionned here, It's not clear for me if it's for storage or to increase write speed task.

[emard]

for artix7 board, this is the source that works for xc3sprog: https://github.com/f32c/f32c/tree/master/rtl/proj/xilinx/ffm-a7100/ffm_a7100_jtag_spi_bridge I'm a bit puzzled on why is it incompatible and how to convert to spioverjtag about spioverjtag*.bit.gz - yes it is just to significantly reduce storage size, imagine you support say 10-20 different artix chips, each bitstream will be uncompressed 2-4MB size and compressed 3-4KB size. Speed difference at decompressing on stardard PC is so small, few ms, nobody can notice.

…

On 9/4/20, Gwenhael Goavec-Merou ***@***.***> wrote: It's true for read back mainly because it's possible to check write task. In fact I've already this (to read back content just after write) to verify the read everywhere. If I have artix's details I'm able to update the Makefile to produce required bitstream if you want. For gzip, as mentionned [here](47), It's not clear for me if it's for storage or to increase write speed task. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[emard]

I was experimenting with esp32 micropython programmer
using xc3sprog bscan and got it working, it uploads bscan7.bit.gz
first and then writes the flash. It first reads a flash block, compares
with to-be-written block content and decides if it must erase or write or
nothing, thus reducing flash wear and working faster.

Sometimes (about 1 in 20), after uploading bscan7,
flash write fails on first block (erase, write, verify
retried 3 times and give up).

If you need some inspiration or reference, here it is:

https://github.com/emard/esp32ecp5/tree/master/rbp

BTW is there spioverjtag source for altera?

[trabucayre]

Okay I will seeing this. Thanks
In fact I have written my spiOverJtag in early time of this project. Maybe I must move to xc3sprog version. I will compare both.
For altera I need to find where I have stored this (but It has no real interest since it use interfaceB of the ft2232, and consequently limited to cyc1000). My idea is to rewrite this (or adapt the xc3sprog passthru) to use the JTAG interface.

I've updated the repository with support for writing raw data at an arbitrary offset (readback is currently missing).
My test design is an adaptation to picosoc

[emard]

Great, I will pull your code, compile and test. About artix, I was looking at C source and I found difference between spioverjtag for openFPGALoader and xc3sprog: xc3sprog, after SIR USER1 sends SDR 4 "magic" bytes 0x59,0xA6,0x59,0xA6 and then the bit-length and SPI data While openFPGALoader code I didn't see that it sends magic bytes, but maybe it actually sends them somehow but I have just overlooked C code

…

On 9/5/20, Gwenhael Goavec-Merou ***@***.***> wrote: Okay I will seeing this. Thanks In fact I have written my spiOverJtag in early time of this project. Maybe I must move to xc3sprog version. I will compare both. For altera I need to find where I have stored this (but It has no real interest since it use interfaceB of the ft2232, and consequently limited to cyc1000). My idea is to rewrite this (or adapt the xc3sprog passthru) to use the JTAG interface. I've updated the repository with support for writing raw data at an arbitrary offset (readback is currently missing). My test design is an adaptation to [picosoc](https://github.com/trabucayre/picorv32) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

My bridge has nothing to do with that of xc3sprog. This why both are incompatible.
If you read xilinx_spiOverJtag this piece of code just adapts JTAG signals to SPI.
I need to compare both speed to move to xc3sprog bridge.

[emard]

I see! xc3sprog is then probably not better than yours just different. It has 2KB buffer, to issue USER1 first as magic bytes and request and clock dummy bytes for future response, and then issue USER1 without magic bytes and take the response repeating that for each 2KB of data. I think xc3sprog "knows" how to pipeline that and take response with 1 step delayed

…

On 9/5/20, Gwenhael Goavec-Merou ***@***.***> wrote: My bridge has nothing to do with that of xc3sprog. This why both are incompatible. If you read [xilinx_spiOverJtag](https://github.com/trabucayre/openFPGALoader/blob/master/spiOverJtag/xilinx_spiOverJtag.vhd) this piece of code just adapts JTAG signals to SPI. I need to compare both speed to move to xc3sprog bridge. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

Sorry for delay.
I've updated xilinx support to write raw data in arbitrary address (tested again with picosoc) and added bitstream for xc7a100 device. If you can try it.
ASAP I must compare for bridge to see if I need to move to xc3sprog version. But usually SPI communication is quite small (for tx there are no overhead, for rx with a delay of one bit I need to read one byte more and reconstruct byte).

[emard]

I'm currently away from artix7-100 board but in few days I could test this I'm very curious to try how it works :) This board has spansion 32MB flash and I think only 64K erase block works. I have tried 4K erase block, datasheet says its supported but for me it doesn't work reliable. Few 4K blocks OK but then I got some corruption For 64K erase block, spansion works always ok

…

On 9/22/20, Gwenhael Goavec-Merou ***@***.***> wrote: Sorry for delay. I've updated xilinx support to write raw data in arbitrary address (tested again with picosoc) and added bitstream for xc7a100 device. If you can try it. ASAP I must compare for bridge to see if I need to move to xc3sprog version. But usually SPI communication is quite small (for tx there are no overhead, for rx with a delay of one bit I need to read one byte more and reconstruct byte). -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

OK. No problem. It's not hurry at all.
Currently, openFPGALoader use only 64K erase block. (I know it's sometime overkill and the algorithm needs to be improved).

[emard]

I have artix-7 100 with ft4232 interface and compiled latest openFPGALoader but what options do activate flashing? It prints Flash SRAM but it is not writing to flash but to SRAM ./openFPGALoader --cable ft4232 -f artix7.bit load program Flash SRAM: [===================================================] 100.000008% Done

…

On 9/23/20, Gwenhael Goavec-Merou ***@***.***> wrote: OK. No problem. It's not hurry at all. Currently, openFPGALoader use only 64K erase block. (I know it's sometime overkill and the algorithm needs to be improved). -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

To write a bitstream in flash you need to convert the bit to mcs.
In fact I've not tried to write a bit to flash (If it so, i'll update openFPGALoader to allows this)

[emard]

but *.bit is simple - just write it raw to flash similar as lattice bit does

…

On 9/24/20, Gwenhael Goavec-Merou ***@***.***> wrote: To write a bitstream in flash you need to [convert](https://github.com/trabucayre/openFPGALoader/blob/master/README.md#spi-flash-only-for-arty) the bit to mcs. In fact I've not tried to write a bit to flash (If it so, i'll update openFPGALoader to allows this) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[emard]

does -o option imply raw image writing? (so I can write bit to flash with options:) openFPGALoader --cable ft4232 -o 0x000000 -f artix7.bit

…

On 9/24/20, D EMARD ***@***.***> wrote: but *.bit is simple - just write it raw to flash similar as lattice bit does On 9/24/20, Gwenhael Goavec-Merou ***@***.***> wrote: > To write a bitstream in flash you need to > [convert](https://github.com/trabucayre/openFPGALoader/blob/master/README.md#spi-flash-only-for-arty) > the bit to mcs. > In fact I've not tried to write a bit to flash (If it so, i'll update > openFPGALoader to allows this) > > -- > You are receiving this because you authored the thread. > Reply to this email directly or view it on GitHub: > #45 (comment)

[trabucayre]

I've tried with a .bit: It didn't work in flash.
lattice .bit and xilinx .bit are not same...
Lattice .bit contains instructions to drive the FPGA in configuration phase.
I suspect this is not true for xilinx .bit file this is why it's mandatory to use mcs (maybe .bin)
In openFPGALoader, xilinx class don't use -f and -m.
if file is .mcs -> FLASH
if file is .bit -> RAM
if file is xxx -> FLASH with a sanity checking about offset
It's true this mean a file with .bit can't be written at an offset > 0x00

[emard]

Hmmm as for quick test it's not easy for me to setup complete build env and compile all (45 minutes on normal PC just compilation with vivado) I have recorded some *.bit files (maybe they are *.bin inside who knows). I know something from my esp32ecp5 project. ESP32 would be very slow if it had to parse bitstream, so I found best option is just to upload raw bit content directly to SRAM or FLASH addr 0 using SPI to JTAG in MSB first order. It works great for xilinx and lattice. Same binary can be uploaded to SRAM or flashed from address 0 and it also works. For altera it works for SRAM if "bit" is extracted from *.svf FLASH I don't know JTAG sequence how to write on altera yet, so I don't know will such bit work. Anyway I will try to convert my artix7 bit to mcs on some linux lighter tool than vivado and try again

…

On 9/25/20, Gwenhael Goavec-Merou ***@***.***> wrote: I've tried with a .bit: It didn't work in flash. lattice .bit and xilinx .bit are not same... Lattice .bit contains [instructions](https://prjtrellis.readthedocs.io/en/latest/architecture/bitstream_format.html) to drive the FPGA in configuration phase. I suspect this is not true for xilinx .bit file this is why it's mandatory to use mcs (maybe .bin) In openFPGALoader, xilinx class don't use -f and -m. if file is .mcs -> FLASH if file is .bit -> RAM if file is xxx -> FLASH with a sanity checking about offset It's true this mean a file with .bit can't be written at an offset > 0x00 -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[emard]

Can I somehow use objcopy to convert? I tried to convert .bin to .mcs using this: objcopy -I binary artix7.bit -O ihex artix7.mcs but openfpgaloader complains rror: unknown type Parse file FAIL the bit converted to mcs file with objcopy starts like this :1000000000090FF00FF00FF00FF000000161003158 :10001000616D6967615F66666D5F61373130303B86 :100020005573657249443D305846464646464646F5

…

On 9/25/20, D EMARD ***@***.***> wrote: Hmmm as for quick test it's not easy for me to setup complete build env and compile all (45 minutes on normal PC just compilation with vivado) I have recorded some *.bit files (maybe they are *.bin inside who knows). I know something from my esp32ecp5 project. ESP32 would be very slow if it had to parse bitstream, so I found best option is just to upload raw bit content directly to SRAM or FLASH addr 0 using SPI to JTAG in MSB first order. It works great for xilinx and lattice. Same binary can be uploaded to SRAM or flashed from address 0 and it also works. For altera it works for SRAM if "bit" is extracted from *.svf FLASH I don't know JTAG sequence how to write on altera yet, so I don't know will such bit work. Anyway I will try to convert my artix7 bit to mcs on some linux lighter tool than vivado and try again On 9/25/20, Gwenhael Goavec-Merou ***@***.***> wrote: > I've tried with a .bit: It didn't work in flash. > lattice .bit and xilinx .bit are not same... > Lattice .bit contains > [instructions](https://prjtrellis.readthedocs.io/en/latest/architecture/bitstream_format.html) > to drive the FPGA in configuration phase. > I suspect this is not true for xilinx .bit file this is why it's > mandatory > to use mcs (maybe .bin) > In openFPGALoader, xilinx class don't use -f and -m. > if file is .mcs -> FLASH > if file is .bit -> RAM > if file is xxx -> FLASH with a sanity checking about offset > It's true this mean a file with .bit can't be written at an offset > 0x00 > > -- > You are receiving this because you authored the thread. > Reply to this email directly or view it on GitHub: > #45 (comment)

[emard]

So I renamed bit file to xxx and this seems to work and pass verify
only I'd like to be able to flash raw binary exactly at offset 0,
currently it accepts other offsets than 0.
I edited the source and removing checking for address 0,
have written *.bit raw bitstream there and it works!

./openFPGALoader --cable ft4232 -o 0 /tmp/artix7.xxx
load program
Flash SRAM: [===================================================] 100.000008%
Done
parsing 3825900

file length 30607200
Parse file DONE
Detail:
Jedec ID : 01
memory type : 60
memory capacity : 19
EDID + CFD length : ff
EDID : ffff
CFD :
Erasing: [==================================================] 100.000000%
Done
Writing: [===================================================] 100.000008%
Done

[emard]

I can test something similar (same cable ft4232 and 32MB spansion flash)
with cyclone5, part 5CEBA4F23C7N

[trabucayre]

After comparing .bit file from xilinx and mcs file from xilinx too, it's true the .bit file should work with the flash. I need to redo my tests, I'have missed something, but not now I'm not at home and hav'nt my arty with me.
For .mcs produces by using objcopy, I suppose my implementation don't cover all possible type... I've added this in my (long) TODO list.
For rawData at offset 0x0, I've (it's maybe an error) forbid this behavior considering only a valid bitstream could be write in this area.
I have never tested with CycloneV, I need to redo bridge (currently cyc1000 only). For SRAM you need to use a svf file. .sof file is just not documented, quartus do a magic thing before sending bitstream data...

[emard]

issue with *.bit bitstreams could be 8-bit reverse of each byte. For ecp5 and artix7 *.bit file should be shifted over JTAG as MSB in each byte first, opposite as e.g. SVF commands which are shifted LSB first. Bitstream has a header and footer with CRC so for lattice and I guess artix) it tolerates few bits but not too much like 1K of junk before its beginning and tolerates any amount of junk after its end. Option to ignore *.bit parsing and upload to SRAM or FLASH raw file should be there. There are a lot of internal checks inside of FPGA chip so if bitstream is incorrect, nothing will happen. We can initially assume similar raw *.bit to FLASH could work with altera. Currently I have a python script that extracts *.bit from *.svf and at least such image works for cyclone5 SRAM. Original formats like *.sof and similar are currently too difficult to understand.

…

On 9/25/20, Gwenhael Goavec-Merou ***@***.***> wrote: After comparing .bit file from xilinx and mcs file from xilinx too, it's true the .bit file should work with the flash. I need to redo my tests, I'have missed something, but not now I'm not at home and hav'nt my arty with me. For .mcs produces by using objcopy, I suppose my implementation don't cover all possible type... I've added this in my (long) TODO list. For rawData at offset 0x0, I've (it's maybe an error) forbid this behavior considering only a valid bitstream could be write in this area. I have never tested with CycloneV, I need to redo bridge (currently cyc1000 only). For SRAM you need to use a svf file. .sof file is just not documented, quartus do a magic thing before sending bitstream data... -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

I've redo test and now it's possible to write a .bit in flash (In fact my previous tests have failed due to an inconscient in parser...)
Yes sof are too difficult... Tried to analyse this file but fails...

[emard]

Great! Besides *.sof, there is option to create *.rbf file what means like "raw binary flash file" but I tried to upload it to SRAM and there it doesn't work. Uploading to FLASH I can't yet try as I don't have JTAG protocol. rbf file looks similar to extracted data from svf but it doesn't work for SRAM while svf works. Similar thing would work for lattice and artix. Most obvious difference is that bits of *.rbf in each byte are 8-bit reversed compared to that what is be extracted from *.svf, both files begin the same but are not equal. obviously, there's still something more that we don't understand on those formats...

…

On 9/25/20, Gwenhael Goavec-Merou ***@***.***> wrote: I've redo test and now it's possible to write a .bit in flash (In fact my previous tests have failed due to an inconscient in parser...) Yes sof are too difficult... Tried to analyse this file but fails... -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

I've planned to study .rbf. This format is used by Linux, for cycloneV Soc, to program the FPGA. I suppose this filetype is more or less documented (at least enough to be usable).
If it's possible to use them, it's maybe better (or simplier) than using .svf

[emard]

Is altera (cyclone-5 + epc flash = 5CEBA4F23C7 + EPCS64) supported?
I see there's some code to load bridge and read/write flash.

there's possible misspelling at sram write, it prints message
"Flash SRAM" maybe it should print message "Write SRAM".

[trabucayre]

altera cycloneV are supported to write SPI flash.
This model must be added in spiOverJtag. Have you a ref board? I could update accordingly.

[emard]

Yes of course I have ref boards with mentioned chip part numbers Boards have FT4232 port "A", connected as JTAG. Boards are not mass produced, few specimens exist, motherboard name is "FFC" (older model) and "RBP" (newer model), Boards accept modules "FFM" with FPGA which can be plugged. I have modules with altera cyclone-5 50kLUT, lattice ecp5 85kLUT, and xilinx artix-7 100kLUT

…

On 10/21/21, Gwenhael Goavec-Merou ***@***.***> wrote: altera cycloneV are supported to write SPI flash. This model must be added in spiOverJtag. Have you a ref board? I could update accordingly. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

Thanks.
rbf are a bit large :-/ (and it's not possible to use compression since jtag+real time uncompress is not supported by cyclone devices)
Before adding this file to openFPGALoader repo could you try:

1. download this bridge into spiOverJtag directory.
2. add in src/part.hpp idcode for your device
3. make install
4. use openFPGALoader -c ft4232 --fpga-part 5ce423 -f yourRBF.rbf

Thanks

[emard]

My part is 5CEBA4 and it is already in part.hpp, but seems that I have to use 5CE423. It recognized flash chip ID, started programming and chip content is erased or modified somehow, old bitstream is not there after flashing but new from .rbf file is not working or I don't know how to create rbf file. I created it from .sof like this: quartus_cpf -c $(PROJECT).sof $(PROJECT).rbf from same sof i can create .svf file which openFPGALoader correctly uploads: quartus_cpf -c -q $(OPENOCD_SVF_CLOCK) -g 3.3 -n p $(PROJECT).sof $(PROJECT).svf This is what happens ***@***.***:~/src/fpga/fpga-flashrom/proj/altera/ffm-c5a4-sd-lcdif$ /tmp/openFPGALoader/build/openFPGALoader -c ft4232 --fpga-part 5CE423 -f project.rbf write to flash Jtag frequency : requested 6.00MHz -> real 6.00MHz use: /usr/local/share/openFPGALoader/spiOverJtag_5CE423.rbf Flash SRAM: [==================================================] 100.00% Done Detail: Jedec ID : ef memory type : 40 memory capacity : 17 RDSR : 00 WIP : 0 WEL : 0 BP : 0 TB : 0 SRWD : 0 flash chip unknown: use basic protection detection Erasing: [==================================================] 100.00% Done Writing: [==================================================] 100.00% Done sometimes it happens this and I must re-plug and re-power the board ***@***.***:~/src/fpga/fpga-flashrom/proj/altera/ffm-c5a4-sd-lcdif$ make flash_ofl /tmp/openFPGALoader/build/openFPGALoader -c ft4232 --fpga-part 5CE423 -f project.rbf write to flash Jtag frequency : requested 6.00MHz -> real 6.00MHz use: /usr/local/share/openFPGALoader/spiOverJtag_5CE423.rbf Flash SRAM: [==================================================] 100.00% Done Detail: Jedec ID : ff memory type : ff memory capacity : ff EDID + CFD length : ff EDID : ffff CFD : RDSR : ff WIP : 1 WEL : 1 BP : f TB : 1 SRWD : 1 flash chip unknown: use basic protection detection unlock blocks Error: block protection is set can't unlock without --unprotect memory locked Error: Failed to program FPGA: memory locked

…

On 10/22/21, Gwenhael Goavec-Merou ***@***.***> wrote: Thanks. rbf are a bit large :-/ (and it's not possible to use compression since jtag+real time uncompress is not supported by cyclone devices) Before adding this file to openFPGALoader repo could you try: 1. download this [bridge](http://kmf2.trabucayre.com/spiOverJtag_5ce423.rbf) into spiOverJtag directory. 2. add in src/part.hpp idcode for your device 3. `make install` 4. use `openFPGALoader -c ft4232 --fpga-part 5ce423 -f yourRBF.rbf` Thanks -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

spiOverjtag naming is a bit strange, i'm agree. I've assumed only size and package are required (maybe I need to do a deep check).
First dump seems good. openFPGALoader has correctly loaded bridge into RAM and you use the correct (as far I know) command to produce the rbf file.
SVF is not working here, because It will be loaded into SRAM
For the second dump it's like chip is not connected or something like this.
Need to try in my side (maybe something in spiflash update has broken that...)

[emard]

Onboard is EPCS64 which ID looks like winbond So I have added entry for W25Q64, copy pasting and setting sector number but still it doesn't work. It changes flash content but uploaded bitstream doesn't work. I use USB blaster to enter some working bitstream and then use openFPGALoader to see if flash content has changed to new bitstream /tmp/openFPGALoader/build/openFPGALoader -c ft4232 --fpga-part 5CE423 -f project.rbf write to flash Jtag frequency : requested 6.00MHz -> real 6.00MHz use: /usr/local/share/openFPGALoader/spiOverJtag_5CE423.rbf Flash SRAM: [==================================================] 100.00% Done Detected: Winbond W25Q64 128 sectors size: 64Mb 00000000 00000000 00 Erasing: [==================================================] 100.00% Done Writing: [==================================================] 100.00% Done

…

On 10/27/21, Gwenhael Goavec-Merou ***@***.***> wrote: spiOverjtag naming is a bit strange, i'm agree. I've assumed only size and package are required (maybe I need to do a deep check). First dump seems good. openFPGALoader has correctly loaded bridge into RAM and you use the correct (as far I know) command to produce the rbf file. SVF is not working here, because It will be loaded into SRAM For the second dump it's like chip is not connected or something like this. Need to try in my side (maybe something in spiflash update has broken that...) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

It's really weird. I have tried by two of my intel FPGAs (cycloneV and cyclone IV) sucessfully...
If you dump flash it's the same as rbf content? (maybe with bit reversal) ?

[emard]

Oho I didn't expect that dump flash is supported! I will check content it in a day or two

…

On 10/27/21, Gwenhael Goavec-Merou ***@***.***> wrote: It's really weird. I have tried by two of my intel FPGAs (cycloneV and cyclone IV) sucessfully... If you dump flash it's the same as rbf content? (maybe with bit reversal) ? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

Most of devices with SPI flash have dump flash support. Seems doc must be updated to highlight that :)

[emard]

hmmm am I using correctly dump flash options? /tmp/openFPGALoader/build/openFPGALoader -c ft4232 --fpga-part 5CE423 --dump-flash --file-size 65536 /tmp/flashdump.bin Jtag frequency : requested 6.00MHz -> real 6.00MHz dump flash not supported Also, I tried to modify *.rbf file and flash modified. I reversed each byte (xor 255), I reversed bit order in each byte (LSB <-> MSB mirror) and both (xor 255 and LSB <-> MSB mirror). I flashed such .rbf files, but bistream did not start in any of 3 mentioned combinations.

…

On 10/27/21, Gwenhael Goavec-Merou ***@***.***> wrote: Most of devices with SPI flash have dump flash support. Seems doc must be updated to highlight that :) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

My fault... Wrong method signature...
Fixed

[emard]

Thanx! It is working now! I can dump flash from working bitstream, erase flash and write back the dumped file and it will work again But I think we don't know how to create .rbf file Currently this file doesn't look exactly what has to be written to the flash dump of working bitstream: 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000080 f5 65 65 65 66 c2 ff ff fe c5 ff ff f6 f2 ff ff |.eeef...........| 00000090 fe c8 ff ff f6 d4 ff ff fe e0 ff ff fc d9 ff ff |................| 000000a0 f5 d1 ff ff f9 80 ff ff f5 c0 ff ff fd c6 ff ff |................| 000000b0 f5 ca ff ff f1 a1 ff ff f9 a1 ff ff f1 82 ff ff |................| 000000c0 fb d6 ff ff fb e0 ff ff f9 a2 ff ff f3 e2 ff ff |................| 000000d0 ff e2 ff ff fb c4 ff ff f7 98 ff ff f9 94 ff ff |................| 000000e0 f9 c8 ff ff f9 c2 ff ff f3 aa ff ff f9 80 ff ff |................| 000000f0 fb a0 ff ff f1 94 ff ff f3 94 ff ff f9 90 ff ff |................| 00000100 f3 a8 ff ff f1 8e ff ff f1 ae ff ff f5 0c ff ff |................| 00000110 f5 8a ff ff f1 b2 ff ff f3 42 ff ff f5 88 ff ff |.........B......| 00000120 f7 68 ff ff f0 00 0d 81 9f ff ff ff ff ff ff ff |.h..............| 00000130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000270 ff ff ff ff f0 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 86 |................| 00000480 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p...............| 00000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000680 00 00 00 00 00 00 00 00 00 00 0a 86 70 00 00 00 |............p...| 00000690 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000890 00 00 00 00 00 00 0a 86 70 00 00 00 00 00 00 00 |........p.......| 000008a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * dump of .rbf file 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000080 6a 6a 6a 6a 36 f4 ff ff 37 fa ff ff f6 f4 ff ff |jjjj6...7.......| 00000090 37 f1 ff ff b6 f2 ff ff 77 f0 ff ff b3 f9 ff ff |7.......w.......| 000000a0 ba f8 ff ff 11 f0 ff ff 3a f0 ff ff 3b f6 ff ff |........:...;...| 000000b0 3a f5 ff ff 58 f8 ff ff 59 f8 ff ff 18 f4 ff ff |:...X...Y.......| 000000c0 bd f6 ff ff 7d f0 ff ff 59 f4 ff ff 7c f4 ff ff |....}...Y...|...| 000000d0 7f f4 ff ff 39 f2 ff ff 9a f1 ff ff 99 f2 ff ff |....9...........| 000000e0 3d f1 ff ff 39 f4 ff ff 5c f5 ff ff 19 f0 ff ff |=...9...\.......| 000000f0 5d f0 ff ff 98 f2 ff ff 9c f2 ff ff 99 f0 ff ff |]...............| 00000100 5c f1 ff ff 18 f7 ff ff 58 f7 ff ff 0a f3 ff ff |\.......X.......| 00000110 1a f5 ff ff da f4 ff ff 2e f4 ff ff 1a f1 ff ff |................| 00000120 6e f1 ff ff 00 00 5a 75 ff ff ff ff ff ff ff ff |n.....Zu........| 00000130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000270 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15 e6 |................| 00000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000680 00 00 00 00 00 00 00 00 00 00 15 e6 00 00 00 00 |................| 00000690 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000890 00 00 00 00 00 00 15 e6 00 00 00 00 00 00 00 00 |................| 000008a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000aa0 00 00 15 e6 00 00 00 00 00 00 00 00 00 00 00 00 |................|

…

On 10/27/21, Gwenhael Goavec-Merou ***@***.***> wrote: My fault... Wrong method signature... Fixed -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[emard]

Please add W25Q64 support, i forgot git options how to pull request on the branch. If git wouldn't require ssh key, I'd pull req easily. the patch is this + {0xef4017, { + .manufacturer = "Winbond", + .model = "W25Q64", + .nr_sector = 128, + .sector_erase = true, + .subsector_erase = true, + .has_extended = false, + .tb_otp = false, + .tb_offset = (1 << 5), + .tb_register = STATR, + .bp_len = 3, + .bp_offset = {(1 << 2), (1 << 3), (1 << 4), 0}} + },

…

On 10/27/21, D EMARD ***@***.***> wrote: Thanx! It is working now! I can dump flash from working bitstream, erase flash and write back the dumped file and it will work again But I think we don't know how to create .rbf file Currently this file doesn't look exactly what has to be written to the flash dump of working bitstream: 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000080 f5 65 65 65 66 c2 ff ff fe c5 ff ff f6 f2 ff ff |.eeef...........| 00000090 fe c8 ff ff f6 d4 ff ff fe e0 ff ff fc d9 ff ff |................| 000000a0 f5 d1 ff ff f9 80 ff ff f5 c0 ff ff fd c6 ff ff |................| 000000b0 f5 ca ff ff f1 a1 ff ff f9 a1 ff ff f1 82 ff ff |................| 000000c0 fb d6 ff ff fb e0 ff ff f9 a2 ff ff f3 e2 ff ff |................| 000000d0 ff e2 ff ff fb c4 ff ff f7 98 ff ff f9 94 ff ff |................| 000000e0 f9 c8 ff ff f9 c2 ff ff f3 aa ff ff f9 80 ff ff |................| 000000f0 fb a0 ff ff f1 94 ff ff f3 94 ff ff f9 90 ff ff |................| 00000100 f3 a8 ff ff f1 8e ff ff f1 ae ff ff f5 0c ff ff |................| 00000110 f5 8a ff ff f1 b2 ff ff f3 42 ff ff f5 88 ff ff |.........B......| 00000120 f7 68 ff ff f0 00 0d 81 9f ff ff ff ff ff ff ff |.h..............| 00000130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000270 ff ff ff ff f0 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 86 |................| 00000480 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p...............| 00000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000680 00 00 00 00 00 00 00 00 00 00 0a 86 70 00 00 00 |............p...| 00000690 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000890 00 00 00 00 00 00 0a 86 70 00 00 00 00 00 00 00 |........p.......| 000008a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * dump of .rbf file 00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000080 6a 6a 6a 6a 36 f4 ff ff 37 fa ff ff f6 f4 ff ff |jjjj6...7.......| 00000090 37 f1 ff ff b6 f2 ff ff 77 f0 ff ff b3 f9 ff ff |7.......w.......| 000000a0 ba f8 ff ff 11 f0 ff ff 3a f0 ff ff 3b f6 ff ff |........:...;...| 000000b0 3a f5 ff ff 58 f8 ff ff 59 f8 ff ff 18 f4 ff ff |:...X...Y.......| 000000c0 bd f6 ff ff 7d f0 ff ff 59 f4 ff ff 7c f4 ff ff |....}...Y...|...| 000000d0 7f f4 ff ff 39 f2 ff ff 9a f1 ff ff 99 f2 ff ff |....9...........| 000000e0 3d f1 ff ff 39 f4 ff ff 5c f5 ff ff 19 f0 ff ff |=...9...\.......| 000000f0 5d f0 ff ff 98 f2 ff ff 9c f2 ff ff 99 f0 ff ff |]...............| 00000100 5c f1 ff ff 18 f7 ff ff 58 f7 ff ff 0a f3 ff ff |\.......X.......| 00000110 1a f5 ff ff da f4 ff ff 2e f4 ff ff 1a f1 ff ff |................| 00000120 6e f1 ff ff 00 00 5a 75 ff ff ff ff ff ff ff ff |n.....Zu........| 00000130 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000270 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000470 00 00 00 00 00 00 00 00 00 00 00 00 00 00 15 e6 |................| 00000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000680 00 00 00 00 00 00 00 00 00 00 15 e6 00 00 00 00 |................| 00000690 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000890 00 00 00 00 00 00 15 e6 00 00 00 00 00 00 00 00 |................| 000008a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000aa0 00 00 15 e6 00 00 00 00 00 00 00 00 00 00 00 00 |................| On 10/27/21, Gwenhael Goavec-Merou ***@***.***> wrote: > My fault... Wrong method signature... > Fixed > > -- > You are receiving this because you authored the thread. > Reply to this email directly or view it on GitHub: > #45 (comment)

[trabucayre]

rbf is handle as a raw data so flash's content must match rbf's content. Its may be required to add byte reversal when storage to have exactly original file content.

I've updated spiFlashdb with W25Q64 device.

[emard]

I made python script that can byte swap in all ways but still no boot of bitstream processed with this #!/usr/bin/env python3 rb=bytearray(256) # reverse bits #init_reverse_bits() def init_reverse_bits(): #p8rb=ptr8(addressof(rb)) p8rb=memoryview(rb) for i in range(256): v=i r=0 for j in range(8): r<<=1 r|=v&1 v>>=1 p8rb[i]=r init_reverse_bits() print("%02X" % rb[1]) f=open("project.rbf","rb") g=open("project_rev.rbf","wb") for x in f.read(): g.write(bytearray([rb[x]])) # reverse bit order (LSB <-> MSB mirror) #g.write(bytearray([255 ^ x])) # reverse byte (xor 255) #g.write(bytearray([255 ^ rb[x]])) # both ((LSB <-> MSB mirror and xor 255)

…

On 10/28/21, Gwenhael Goavec-Merou ***@***.***> wrote: rbf is handle as a raw data so flash's content must match rbf's content. Its may be required to add byte reversal when storage to have exactly original file content. I've updated spiFlashdb with W25Q64 device. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

byte reversal is not required before calling openFPGALoader. It is done, if required, before writing to flash. With all my intel's FPGAs rbf are working.
Byte reversal may be required after a dump to compare original rbf with the dump.

[emard]

Hmmm I must check my .rbf filez How can I control is byte reversal done or not with flashing rbf file? Suppose I want to flash FAT32 image to SPI flash, how do I know it is flashed directly or byte reversed?

…

On 10/28/21, Gwenhael Goavec-Merou ***@***.***> wrote: byte reversal is not required before calling openFPGALoader. It is done, if required, before writing to flash. With all my intel's FPGAs rbf are working. Byte reversal may be required after a dump to compare original rbf with the dump. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

A bitstream is always reversed. A raw data file is written in natural order.
Oups I have a typo in previous messages byte -> bit so LSB become MSB and MSB become LSB

[emard]

I can't get .rbf file to work. But I can cut start of .jic file and it works like this. With "dd" tool I cut first 154 bytes of beginning of .jic file with some ASCII and NULL bytes until series of 0xFF bytes starts, the rest 8MB of .jic I treat as .rbf file and such flash works. So I'd propose that you include some support for .jic files too dd if=project.jic of=/tmp/dumpjic.bin bs=1 count=8M skip=154 openFPGALoader -c ft4232 --fpga-part 5CE423 --file-type rbf -f /tmp/dumpjic.bin Second problem I have is that "spioverjtag" will not work alone - flash probe will return 0xFF as flash id. So, first I must upload any valid bitstream to SRAM (blink.svf), then "spioverjtag" detects correct flash id and can write further

[trabucayre]

Need to compare jic and rbf (maybe I've already done that but don't remember -> documentation page for file format is required). It's weird tried many time successfully (but not with your board/device)
Same for spiOverJtag with all intel based board it's okay (but again not with this device) -> have to check aliexpress for something similar to your board.
Thanks

[emard]

If there's source for spioverjtag, I can compile and
try to change something to see if I can fix it

maybe not the same chip but similar and very good board
and with good price should be "mister".

[trabucayre]

source is available, I just have to push entry for your device.
"mister" uses the de10nano? I have one of them. chip id is correctly read but further steps are not working (I suspect dual or quad access between FPGAs and chip).

[emard]

Yes de10 nano has ARM additionally, not exactly the same as I have. I got mine as gift from Emanuel for porting of some of my projects for his prototyping of modular boards. He makes gadgets like this https://retroramblings.net/?p=705 and newer of course. I will recommend your project to him for possible support. DE0-CV has similar FPGA but still not identical. https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=921 My simple procedure of .jic to .rbf conversion is to find first occurence of 0xFF byte in file as starting point for write to flash until end of flash or file EOF whichever comes first. .rbf means "raw binary file" but can be better understood as "reverse bits file"

…

On 10/29/21, Gwenhael Goavec-Merou ***@***.***> wrote: source is available, I just have to push entry for your device. "mister" uses the de10nano? I have one of them. chip id is correctly read but further steps are not working (I suspect dual or quad access between FPGAs and chip). -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[emard]

strange: prior to loading spioverjtag.rbf bridge, I have to upload some bitstream like blink.svf if I want flash ID to be detected. If I upload blink.rbf instead of blink.svf then it doesn't work for flash ID detecting by foloowing uploaded spioverjtag.rbf There's some unexplainable difference between .svf and .rbf uploading of the bitstream prior to spioverjtag.rbf to allow detecting flash ID Otherwise both blink.svf and blink.rbf seem the same and blink LED the same.

[trabucayre]

I have de10nano, de0nanoSo and de1Soc.
I have produce a jic file from sof -> it's quite similar to rbf with an header. Need to check why some small diff.
Having to load something into RAM before using spiOverJtag is really strange, currently I don't see why. Need to investigate.
Using an rbf into flash it not always possible (You can't use one in compress mode -> real time decompression isn't supported by the FPGA in JTAG mode).

[emard]

Strange, I have enable flash compression with option (example only with .svf, other formats created similar) $(quartus_env); quartus_cpf -c \ -q $(OPENOCD_SVF_CLOCK) -g 3.3 -n p \ -o bitstream_compression=on \ $(PROJECT).sof $(PROJECT).svf and the compressed bitstream is shorter (2.6MB->0.7MB) and works when programmed from .svf and .rbf to SRAM but also as flashed from .jic and my method (between 0xFF delimiters), here's python script that converts .jic to .rbf https://github.com/emard/fpga-flashrom/blob/main/proj/altera/ffm-c5a4-sd-lcdif/jic2rbf.py

…

On 10/29/21, Gwenhael Goavec-Merou ***@***.***> wrote: I have de10nano, de0nanoSo and de1Soc. I have produce a jic file from sof -> it's quite similar to rbf with an header. Need to check why some small diff. Having to load something into RAM before using spiOverJtag is really strange, currently I don't see why. Need to investigate. Using an rbf into flash it not always possible (You can't use one in compress mode -> real time decompression isn't supported by the FPGA in JTAG mode). -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

for svf the compression is, as far I know, not used.
I've started a parser for jic
But it's clear I can't reproduce your issue (and it's a situation I don't like). I need to check everything... I, definitively, have to find a board with same hardware.

[emard]

I have quick and dirty workaround to this by updating spioverjtag.rbf bridge two times in altera.cpp, then I don't need preparation with blink.svf /* first: load spi over jtag */ try { RawParser bridge(bitname, false); bridge.parse(); programMem(bridge); programMem(bridge); } catch (std::exception &e) { printError(e.what()); throw std::runtime_error(e.what()); }

…

On 10/29/21, Gwenhael Goavec-Merou ***@***.***> wrote: for svf the compression is, as far I know, not used. I've started a parser for jic But it's clear I can't reproduce your issue (and it's a situation I don't like). I need to check everything... I, definitively, have to find a board with same hardware. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[emard]

Next fix is that I made overloaded programMem(); without parameter and it has deleted code between /* write */ and /* reboot */ https://github.com/trabucayre/openFPGALoader/blob/master/src/altera.cpp#L85 https://github.com/trabucayre/openFPGALoader/blob/master/src/altera.cpp#L105 this is called like this just before bridge programMem(); programMem(bridge); You shourly have better idea how to code this cleanly, but it's just my research what is needed for flashing to work standalone.

[trabucayre]

Tried with my de10nano -> success...
flash id is read successfully...
Ok I'm unable to program chip for an unknown reason -> maybe with the clip I will be able to dump transaction with a logic analyzer.

[emard]

check also MSEL switch position, described on page 12 or other text. It has to be set to passive serial position I guess should be 10010 or 10011, but as you got flash ID correct then probably MSEL setting is OK. Flash ID should be same as of W25Q128 http://www.terasic.com.tw/cgi-bin/page/archive_download.pl?Language=Taiwan&No=1046&FID=1c19d1d50e0ee9b21678e881004f6d81 On some boards and chips (ulx3s with ISSI) when we want to reliably program in standard SPI mode, then quad lines HOLDn and WPn must be driven 1. It is not enough if lines are pulled up with resistors, because hi freq SPI traffic capacitive crosstalk will apply noise to HOLDn and WPn and in practice ISSI flash doesn't work if not driven 1. Winbond doesn't need drive 1 and in practice works with only resistors on ulx3s

…

On 10/30/21, Gwenhael Goavec-Merou ***@***.***> wrote: Tried with my de10nano -> success... flash id is read successfully... Ok I'm unable to program chip for an unknown reason -> maybe with the clip I will be able to dump transaction with a logic analyzer. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[emard]

quartus_cpf conversion of .sof to .rbf works only for SRAM but not for FLASH I have improved script to convert .jic to .rbf https://github.com/emard/fpga-flashrom/blob/main/proj/altera/ffm-c5a4-sd-lcdif/jic2rbf.py resulting .rbf file is 487 bytes shorter than .rbf from quartus_cpf and works for both SRAM and FLASH bitstream compression is used.

…

-rw-r--r-- 1 guest guest 764612 Oct 30 12:50 project.rbf -rw-r--r-- 1 guest guest 764125 Oct 30 12:49 project_flash.rbf

On 10/30/21, D EMARD ***@***.***> wrote: check also MSEL switch position, described on page 12 or other text. It has to be set to passive serial position I guess should be 10010 or 10011, but as you got flash ID correct then probably MSEL setting is OK. Flash ID should be same as of W25Q128 http://www.terasic.com.tw/cgi-bin/page/archive_download.pl?Language=Taiwan&No=1046&FID=1c19d1d50e0ee9b21678e881004f6d81 On some boards and chips (ulx3s with ISSI) when we want to reliably program in standard SPI mode, then quad lines HOLDn and WPn must be driven 1. It is not enough if lines are pulled up with resistors, because hi freq SPI traffic capacitive crosstalk will apply noise to HOLDn and WPn and in practice ISSI flash doesn't work if not driven 1. Winbond doesn't need drive 1 and in practice works with only resistors on ulx3s On 10/30/21, Gwenhael Goavec-Merou ***@***.***> wrote: > Tried with my de10nano -> success... > flash id is read successfully... > Ok I'm unable to program chip for an unknown reason -> maybe with the clip > I > will be able to dump transaction with a logic analyzer. > > -- > You are receiving this because you authored the thread. > Reply to this email directly or view it on GitHub: > #45 (comment)

[trabucayre]

it's maybe time to open an dedicated issue, this thread become very long :-)
My board is currently in AS mode (but I have tried all modes)
I can't set holdn and wpn since I use intel IP (serial flash loader).
I need to finalize my jic parser and to integrate this. But it's really weird, I have flashed many rbf this morning to verify behaviour with cylone10, cycloneIV and cycloneV (not socfpga) without any problem. Maybe something with quad/dual/single mode?

[emard]

OK! I opened new issue and there's link to my slightly improved .jic parser. I have also done some attempts for esp32 micropython to program altera and there are even more problems with spioverjtag bridge not starting

…

On 10/30/21, Gwenhael Goavec-Merou ***@***.***> wrote: it's maybe time to open an dedicated issue, this thread become very long :-) My board is currently in AS mode (but I have tried all modes) I can't set holdn and wpn since I use intel IP (serial flash loader). I need to finalize my jic parser and to integrate this. But it's really weird, I have flashed many rbf this morning to verify behaviour with cylone10, cycloneIV and cycloneV (not socfpga) without any problem. Maybe something with quad/dual/single mode? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[Mecrisp]

I am trying to write a raw binary file, too, but despite the -o option given, openFPGALoader does not accept random data. Do I need to provide additional options to enable this?

openFPGALoader --board=ulx3s -f -o 0x200000 LICENSE -v

write to flash
Jtag probe limited to 3MHz
Jtag frequency : requested 6000000Hz -> real 3000000Hz
ret 0
found 1 devices
index 0:
        idcode 0x41113043
        manufacturer lattice
        model  LFE5U-85
        family ECP5
        irlength 8
File type : LICENSE
Error: Failed to claim FPGA device: incompatible file format

openFPGALoader -V
openFPGALoader v0.5.0

[emard]

I think option "--file-type bin" is required to avoid content check and flash raw binary data

…

On 11/23/21, Matthias Koch ***@***.***> wrote: I am trying to write a raw binary file, too, but despite the -o option given, openFPGALoader does not accept random data. Do I need to provide additional options to enable this? `openFPGALoader --board=ulx3s -f -o 0x200000 LICENSE -v` ``` write to flash Jtag probe limited to 3MHz Jtag frequency : requested 6000000Hz -> real 3000000Hz ret 0 found 1 devices index 0: idcode 0x41113043 manufacturer lattice model LFE5U-85 family ECP5 irlength 8 File type : LICENSE Error: Failed to claim FPGA device: incompatible file format ``` ``` openFPGALoader -V openFPGALoader v0.5.0 ``` -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

@Mecrisp Good catch! file type are deduced from extension, but without extension, and without --file-type, openFPGALoader is unable to decide what to do. It's now fixed in master branch.
@emard true. It's a solution to avoid this error.

Thanks to all

[Mecrisp]

Thank you for the quick solution - specifying the file type did the trick. Idea: Would be great if the help text could include the possible "file-type-specifiers". I tried with --file-type raw intuitively before, but that wasn't accepted.

This did the trick with the version already installed, will update later:
openFPGALoader --board=ulx3s -f -o 0x200000 LICENSE -v --file-type bin

[emard]

Maybe file type "raw" should be treated equal as "bin" :)

…

On 11/24/21, Matthias Koch ***@***.***> wrote: Thank you for the quick solution - specifying the file type did the trick. Idea: Would be great if the help text could include the possible "file-type-specifiers". I tried with --file-type raw intuitively before, but that wasn't accepted. This did the trick with the version already installed, will update later: `openFPGALoader --board=ulx3s -f -o 0x200000 LICENSE -v --file-type bin` -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #45 (comment)

[trabucayre]

@emard exactly (and done this morning).
I have relaxed constrains about filetype:

• known format are treated using corresponding parser
• unknown format are allowed only if the file is wrtten in flash

now if you use:

openFPGALoader --board=ulx3s -f -o 0x200000 LICENSE -v --file-type bin

or

openFPGALoader --board=ulx3s -f -o 0x200000 LICENSE -v --file-type raw

or

openFPGALoader --board=ulx3s -f -o 0x200000 LICENSE -v 

Result (and behaviour) is same (or I have introduce a bug ;-) )

@Mecrisp it's true: message must be more explicit and more informative