Altera Cyclone-V prog and flash

[emard]

I have board with FT4232 and Cyclone-V part 5CEBA4F23C7 JTAG ID: 0x02b050dd and flash EPCS64, which has ID same as Winbond W25Q64.

spioverjtag bridge doesn't work standalone. FLASH ID is reported as 0xFF If another .svf bitstream is uploaded before the spioverjtag bridge, then it works.

The minimal workaround is to make parameterless programMem() which doesn't upload bitstream (code deleted between comments "write" and "reboot") and call it before bridge, then the bridge works standalone

            programMem();
            programMem(bridge);

.rbf file generated by quartus_cpf converter doesn't work. What works is extracted .rbf from .jic file, from first occurence of 0xFF byte to last series 0xFF as empty flash padding. Here is simple script that converts .jic to .rbf https://github.com/emard/fpga-flashrom/blob/main/proj/altera/ffm-c5a4-sd-lcdif/jic2rbf.py

[trabucayre]

Thanks! I have updated spiOverJtag with an entry for your device. Could you rebuild the rbf (not available in rbf format) (needs to have edalize) with:

make spiOverJtag_5ce423.rbf

Definition for this version is a not exactly one used for rbf I have sent to you (speed grade match your device instead of slowest).

[emard]

I compiled this bridge 223 but it doesn't work (always returns 0xFF flash ID) bridge 423 still works with workaround by previously loading a .svf file

On 10/30/21, Gwenhael Goavec-Merou @.***> wrote:

Thanks! I have updated spiOverJtag with an entry for your device. Could you rebuild the rbf (not available in rbf format) (needs to have edalize) with:

make spiOverJtag_5ce423.rbf

Definition for this version is a not exactly one used for rbf I have sent to you (speed grade match your device instead of slowest).

-- 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/128#issuecomment-955575787

[emard]

223 bridge doesn't work, after upload, the bridge somehow "exits" and reloads old bitstream from flash. I compiled the bridge using quartus lite 20.1

On 10/30/21, D EMARD @.***> wrote:

I compiled this bridge 223 but it doesn't work (always returns 0xFF flash ID) bridge 423 still works with workaround by previously loading a .svf file

On 10/30/21, Gwenhael Goavec-Merou @.***> wrote:

Thanks! I have updated spiOverJtag with an entry for your device. Could you rebuild the rbf (not available in rbf format) (needs to have edalize) with:

make spiOverJtag_5ce423.rbf

Definition for this version is a not exactly one used for rbf I have sent to you (speed grade match your device instead of slowest).

-- 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/128#issuecomment-955575787

[trabucayre]

223 is not targeted for your device: I'm agree the name is a bit error prone but:

• 2 is for A2 (25K)
• 4 is for A4 (49K) So for you device you need to rebuild and use 423 bridge.

I have searched for a board with exactly the same device to reproduce your issue but unfortunately not found anythiing.

[emard]

Ahaaaa, I was confused by naming, then I will rebuild the 423 bridge

On 10/31/21, Gwenhael Goavec-Merou @.***> wrote:

223 is not targeted for your device: I'm agree the name is a bit error prone but:

• 2 is for A2 (25K)
• 4 is for A4 (49K) So for you device you need to rebuild and use 423 bridge.

I have searched for a board with exactly the same device to reproduce your issue but unfortunately not found anythiing.

-- 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/128#issuecomment-955649607

[emard]

I have 2 similar cyclone-5 modules and 2 similar motherboards they can plug in, but modules work correctly only on one motherboard. Those are only prototypes, so other things also don't work, even one LED is always off (probably reverse polarity :)

I mailed the author of boards about issues we have and I suggested sending a free prototype to you :)

On 10/31/21, D EMARD @.***> wrote:

Ahaaaa, I was confused by naming, then I will rebuild the 423 bridge

On 10/31/21, Gwenhael Goavec-Merou @.***> wrote:

223 is not targeted for your device: I'm agree the name is a bit error prone but:

• 2 is for A2 (25K)
• 4 is for A4 (49K) So for you device you need to rebuild and use 423 bridge.

I have searched for a board with exactly the same device to reproduce your issue but unfortunately not found anythiing.

-- 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/128#issuecomment-955649607

[trabucayre]

Thanks. It's a solution. But at least if you have schematics too. I have tried with my 5CEFA2F23I7 to change operation temperature, embedded hard IP and speed grade. In all case it's works....

[emard]

I'd like if there's a simple short demo.svf for your spioverjtag.rbf that just reads flash ID and checks for expected values, so I can use it with openocd to check is the bridge working

On 10/31/21, Gwenhael Goavec-Merou @.***> wrote:

Thanks. It's a solution. But at least if you have schematics too. I have tried with my 5CEFA2F23I7 to change operation temperature, embedded hard IP and speed grade. In all case it's works....

-- 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/128#issuecomment-955662500

[trabucayre]

In fact this design do quite nothing. It is just used to adapt JTAG signals to produce a SPI compatible flow see https://github.com/trabucayre/openFPGALoader/blob/master/src/altera.cpp#L276 for example

[emard]

I have isolated SPI part and finally made the board having FT4232 port B to FPGA to connect to vendor specific SPI module and use "flashrom" utility to read and write EPCS64 flash.

https://github.com/emard/fpga-flashrom

Core reliably works every time, after re-plugging etc

What is slightly suspicious in spioverjtag.v is usage of rising and falling edge of TCK which itself is not true clock line but normal data line.

Data line can be used for clocking but it can lead to unreliable behavior, similar with triggering on both edges.

"correct" usage would be to sample JTAG with much higher clock and then use registers for edge detection for rising and falling.

We could try to rewrite the core using onboard clock and if it is more reliable, then find if altera has some on-chip RC internal clock generator so core would be independent from board clock

On 11/1/21, Gwenhael Goavec-Merou @.***> wrote:

In fact this design do quite nothing. It is just used to adapt JTAG signals to produce a SPI compatible flow see https://github.com/trabucayre/openFPGALoader/blob/master/src/altera.cpp#L276 for example

-- 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/128#issuecomment-956038757

[trabucayre]

I'm not sure if tck is a data line or clock line, a datasheet check has to be done. I don't remember if an internal oscillator is available for cyclone devices, but if present it make sense to use it to improve design implementation/behaviour.

[trabucayre]

I have pushed the compressed rbf for your FPGA. Now it's required to find why flashrom is able to deal with this flash using spiOverJtag and openFPGALoader's code, but openFPGALoader itself fails...

[emard]

HI

I compiled new spioverjtag bridge (spiflash_rework branch) and gzipped it Small note it compiles as lowercase name spiOverJtag_5ce423.rbf but at programming asks for uppercase name spiOverJtag_5CE423.rbf I think filename must be either uppercased or lowercased to be found properly

small suggestion on options usage report: -o, --offset arg start offset in EEPROM should probably be written as -o, --offset arg start offset in FLASH

sometimes when I'm connected over USB hub, those errors appear at programming stage: (while previous erase stage passes without errors)

write error: -1 instead of 512 mpsse_store: Fails to first flush write error: -1 instead of 512 write_data error in mpsse_store write error: -1 instead of 512 mpsse_read: fails to write Error: ftdi_read_data in mpsse_readLoopback failed, expect problems on later runs -1

I plug out from USB hub, plug in directly into PC and then it works better

[emard]

Wait, actually I can reproduce the problem:

if correct bistream is already flashed, flashing new bitstream works :)

if bistream is erased, then flashing from spioverjtag bridge doesn't work

If I use flashrom to upload bitstream first, then spioverjtag will also work

Here is I first upload bitstream to wrong offset 0x10000 to make it not work and trying to upload again to correct offset 0 will fail: @.:~/src/fpga/fpga-flashrom/proj/altera/ffm-c5a4-sd-lcdif$ /tmp/openFPGALoader/build/openFPGALoader -c ft4232 --fpga-part 5ce423 -f -o 0x10000 project_flash.rbf write to flash Jtag frequency : requested 6.00MHz -> real 6.00MHz use: /usr/local/share/openFPGALoader/spiOverJtag_5ce423.rbf.gz Flash SRAM: [==================================================] 100.00% Done Detected: Winbond W25Q64 128 sectors size: 64Mb reset RDSR : 00 WIP : 0 WEL : 0 BP : 0 TB : 0 SRWD : 0 00010000 00000000 00 Erasing: [==================================================] 100.00% Done Writing: [==================================================] 100.00% Done @.:~/src/fpga/fpga-flashrom/proj/altera/ffm-c5a4-sd-lcdif$ /tmp/openFPGALoader/build/openFPGALoader -c ft4232 --fpga-part 5ce423 -f -o 0 project_flash.rbf write to flash Jtag frequency : requested 6.00MHz -> real 6.00MHz use: /usr/local/share/openFPGALoader/spiOverJtag_5ce423.rbf.gz Flash SRAM: [==================================================] 100.00% Done Detail: Jedec ID : ff memory type : ff memory capacity : ff EDID + CFD length : ff EDID : ffff CFD : reset 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-flash Error: Failed to program FPGA: Fail to write data

Now I will use flashrom to make it work again: guest@brix7:~/src/fpga/fpga-flashrom/proj/altera/ffm-c5a4-sd-lcdif$ make flash_rom /tmp/openFPGALoader/build/openFPGALoader -c ft4232 project.svf write to ram Jtag frequency : requested 6.00MHz -> real 6.00MHz
Jtag probe limited to 30MHz Jtag frequency : requested 33.00MHz -> real 30.00MHz end of flash /usr/sbin/flashrom -p ft2232_spi:type=4232H,port=B,divisor=8 -w project_flash.bit flashrom v1.2 on Linux 5.15.0-1-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ft2232_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED.

check that it works again:

guest@brix7:~/src/fpga/fpga-flashrom/proj/altera/ffm-c5a4-sd-lcdif$ /tmp/openFPGALoader/build/openFPGALoader -c ft4232 --fpga-part 5ce423 -f project_flash.rbf write to flash Jtag frequency : requested 6.00MHz -> real 6.00MHz
use: /usr/local/share/openFPGALoader/spiOverJtag_5ce423.rbf.gz Flash SRAM: [==================================================] 100.00% Done Detected: Winbond W25Q64 128 sectors size: 64Mb reset RDSR : 00 WIP : 0 WEL : 0 BP : 0 TB : 0 SRWD : 0 00000000 00000000 00 Erasing: [==================================================] 100.00% Done Writing: [==================================================] 100.00% Done

Board was powered constantly during this tests. When it stops working because of wrong flash I tried to power off the board but it doesn't help

It seems that already flashed bitstream for "flashrom" bridge contains some setup important for spioverjtag bridge to work, or in other words either spioverjtag bitstream or JTAG flashing sequence needs some additional setup commands to get it working with empty flash

On 11/29/21, D EMARD @.***> wrote:

HI

I compiled new spioverjtag bridge (spiflash_rework branch) and gzipped it Small note it compiles as lowercase name spiOverJtag_5ce423.rbf but at programming asks for uppercase name spiOverJtag_5CE423.rbf I think filename must be either uppercased or lowercased to be found properly

small suggestion on options usage report: -o, --offset arg start offset in EEPROM should probably be written as -o, --offset arg start offset in FLASH

flashing altera cyclone5

Now it works all the time - I can't reproduce bug now.

But sometimes when I'm connected over USB hub, those errors appear at programming stage: (while previous erase stage passes without errors)

write error: -1 instead of 512 mpsse_store: Fails to first flush write error: -1 instead of 512 write_data error in mpsse_store write error: -1 instead of 512 mpsse_read: fails to write Error: ftdi_read_data in mpsse_readLoopback failed, expect problems on later runs -1

I plug out from USB hub, plug in directly into PC and then it works

On 11/28/21, Gwenhael Goavec-Merou @.***> wrote:

I have pushed the compressed rbf for your FPGA. Now it's required to find why flashrom is able to deal with this flash using spiOverJtag and openFPGALoader's code, but openFPGALoader itself 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/128#issuecomment-981123861

[trabucayre]

For connection through hub I suspect this is not software relative... But for the rest it's really stange. When you said "if correct bistream is already flashed, flashing new bitstream works :)" I suppose this mean "is present in SPI flash"? Is it the same flashed bitstream again?

The weird thing it seems a delay is required to have spiOverJtag ready on your board. Again: have you schematics?

I have no idea on how to reproduce your issue: spiOverJtag works on cyclone10 (cyc1000), on my cycloneV board (qmtech) and on cyclone IV (de0nano & qmtech) (when it's work in local but not elsewhere, it's the worst case. Usually, when it's possible my only option is to order same board to locally fix the issue).

[emard]

Yes "flashrom" bitstream was present in SPI flash from address 0

flashrom bitstream is similar, but not the same as spioverjtag. it doesn't have JTAG module. It directly routes flash SPI to outside FT4232. Its source is here

https://github.com/emard/fpga-flashrom/blob/main/proj/altera/ffm-c5a4-sd-lcdif/top/altera_flashrom.vhd

FPGA has loaded this bitstream from SPI flash and running (I see on the LEDs).

I have schematics, I have to ask permission to send you but I expect author will let me. Only few boards are produced, they are kinda prototypes

its a bit complicated.

FPGA submodule is plugged to motherboard, so one should track schematics from FPGA submodule over connector to motherboard's connector, some DIP switches for JTAG routing and finally FT4232

I was experimenting with DIP switches but it doesn't fix it

On 11/30/21, Gwenhael Goavec-Merou @.***> wrote:

For connection through hub I suspect this is not software relative... But for the rest it's really stange. When you said "if correct bistream is already flashed, flashing new bitstream works :)" I suppose this mean "is present in SPI flash"? Is it the same flashed bitstream again?

The weird thing it seems a delay is required to have spiOverJtag ready on your board. Again: have you schematics?

I have no idea on how to reproduce your issue: spiOverJtag works on cyclone10 (cyc1000), on my cycloneV board (qmtech) and on cyclone IV (de0nano & qmtech) (when it's work in local but not elsewhere, it's the worst case. Usually, when it's possible my only option is to order same board to locally fix the issue).

-- 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/128#issuecomment-982365364

[trabucayre]

i have done a similar bitstream for cyc1000 at the beginning. It's clearly the simpliest way but unfortunately it's not a common use case :( For schematics: okay no problem. I can understood the situation :)

[trabucayre]

I have updated altera code (in rework_spiflash branch ) to use new implementation. It no more use ecpq class since all my altera based boards have classic flash (or said it's EPCQ but finally been something like spansion devices). I'm not sure this update will fix your issue...

[emard]

Thanks I will try that! My "EPC" flash detects as Winbond w25q64

On 12/5/21, Gwenhael Goavec-Merou @.***> wrote:

I have updated altera code (in rework_spiflash branch ) to use new implementation. It no more use ecpq class since all my altera based boards have classic flash (or said it's EPCQ but finally been something like spansion devices). I'm not sure this update will fix your issue...

-- 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/128#issuecomment-986241748

[emard]

HI

pulled spiflash rework branch and researched further this issue. It definitely depends what is uploaded to FPGA before flashing.

If in the FLASH is already flashrom bitstream and FPGA has loaded it, next flashing will work.

If in the SRAM is loaded flashrom.svf (no matter what in FLASH is) also flashing will work.

if in the SRAM is loaded flashrom.rbf and in FLASH is already flashrom bitstream flashing will work

If in the sram is loaded flashrom.rbf and FLASH is no bistream, flashing will NOT work.

so success of flashing somehow depends what is in FPGA prior to flashing and how it is uploaded. File uploaded as .svf makes it work, but same bitstream uploaded as .rbf doesn't make next flashing work.

On 12/5/21, D EMARD @.***> wrote:

Thanks I will try that! My "EPC" flash detects as Winbond w25q64

On 12/5/21, Gwenhael Goavec-Merou @.***> wrote:

I have updated altera code (in rework_spiflash branch ) to use new implementation. It no more use ecpq class since all my altera based boards have classic flash (or said it's EPCQ but finally been something like spansion devices). I'm not sure this update will fix your issue...

-- 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/128#issuecomment-986241748