emard commented 4 years ago

HI

I'd like if there is some option to flash given file unmodified, directly to flash chip, starting from some offset.

To make code simpler, It's acceptable if offset has to be multiple of 4K or 64K what I think is erase block size.

trabucayre commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 (@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.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-686380213

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 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.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-687015259

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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, 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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-687122971

emard commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-687631385

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com wrote:

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.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-687634114

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-696710808

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-697490805

trabucayre commented 4 years ago

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 commented 4 years ago

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

On 9/24/20, Gwenhael Goavec-Merou notifications@github.com wrote:

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)

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-698544027

emard commented 4 years ago

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 vordah@gmail.com wrote:

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

On 9/24/20, Gwenhael Goavec-Merou notifications@github.com wrote:

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)

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-698544027

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-698717806

emard commented 4 years ago

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 vordah@gmail.com 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 notifications@github.com 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 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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-698717806

emard commented 4 years ago

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 commented 4 years ago

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

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-698854920

trabucayre commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-699049991

trabucayre commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-948534544

trabucayre commented 3 years ago

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:

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

Thanks

emard commented 3 years ago

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:

download this bridge into spiOverJtag directory.

add in src/part.hpp idcode for your device

make install

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-949289330

trabucayre commented 3 years ago

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 commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-952521373

trabucayre commented 3 years ago

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 commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-952720341

trabucayre commented 3 years ago

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

emard commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-952859285

trabucayre commented 3 years ago

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

emard commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-953157886

emard commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-953157886

trabucayre commented 3 years ago

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 commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-953522212

trabucayre commented 3 years ago

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 commented 3 years ago

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: https://github.com/trabucayre/openFPGALoader/issues/45#issuecomment-953578227

trabucayre / openFPGALoader

raw FLASH option needed #45

!/usr/bin/env python3

init_reverse_bits()

p8rb=ptr8(addressof(rb))

g.write(bytearray([255 ^ x])) # reverse byte (xor 255)

g.write(bytearray([255 ^ rb[x]])) # both ((LSB <-> MSB mirror and xor 255)