raw FLASH option needed

[emard]

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]

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

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

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

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

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

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

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

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

[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