-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segmentation fault when flashing bitstream into sipeed FPGA #345
Comments
could you add |
Hi, see this log, I change to use tang primer 20k. lee@ubuntu:~/Desktop/openFPGALoader$ sudo openFPGALoader -b tangprimer20k -f WS2812.fs --verbose
write to flash
Jtag frequency : requested 6.00MHz -> real 6.00MHz
found 1 devices
index 0:
idcode 0x81b
manufacturer Gowin
family GW2A
model GW2A(R)-18(C)
irlength 8
File type : fs
Parse file Parse WS2812.fs:
checksum 0x941a
Done
DONE
bitstream header infos
CRCCheck: ON
Compress: OFF
ConfDataLength: 1342
ProgramDoneBypass: OFF
SPIAddr: 00000000
SecurityBit: ON
idcode: 0000081b
loading_rate: 212
Jtag frequency : requested 2.50MHz -> real 2.00MHz
Jtag frequency : requested 10.00MHz -> real 6.00MHz
pollFlag: a0
erase SRAM pollFlag: 80
pollFlag: 80
pollFlag: 80
pollFlag: 80
pollFlag: a0
Done
pollFlag: 20
b 40 16 b read b40160b
Segmentation fault And this log is flashing SRAM. lee@ubuntu:~/Desktop/openFPGALoader$ sudo openFPGALoader -b tangprimer20k WS2812.fs --verbose
Jtag frequency : requested 6.00MHz -> real 6.00MHz
found 1 devices
index 0:
idcode 0x81b
manufacturer Gowin
family GW2A
model GW2A(R)-18(C)
irlength 8
File type : fs
Parse file Parse WS2812.fs:
checksum 0x941a
Done
DONE
bitstream header infos
CRCCheck: ON
Compress: OFF
ConfDataLength: 1342
ProgramDoneBypass: OFF
SPIAddr: 00000000
SecurityBit: ON
idcode: 0000081b
loading_rate: 0
Jtag frequency : requested 2.50MHz -> real 2.00MHz
displayReadReg 00000020
Memory Erase
pollFlag: a0
erase SRAM pollFlag: 80
pollFlag: 80
pollFlag: 80
pollFlag: 80
pollFlag: a0
Done
pollFlag: 20
pollFlag: a0
Flash SRAM: [========================================= ] 80.24%pollFlag: 60e0
Flash SRAM: [==================================================] 100.00%
Done
pollFlag: 6020
displayReadReg 00006020
Memory Erase
Done Final
Security Final |
Ok: seems to have a problem somewhere between gowin class and spiFlash. |
This https://github.com/sipeed/TangPrimer-20K-example/blob/main/WS2812/WS2812.fs , and projuct is also here: https://github.com/sipeed/TangPrimer-20K-example/tree/main/WS2812 |
I have tried this project with my tang primer 20k. I'm unable to reproduce your segfault. It's not the first time an issue appear with this board and I'm unable to reproduce it (I dislike this situation because I can't fix it). could you try with:
and with |
@trabucayre I also have the same problem on the Tang Nano 20K (Ubuntu 20.04 LTS running under a VMWare Workstation VM). Loading to SRAM works just fine. Selecting Flash however, causes a Segmentation Fault as per the OP.
EDIT: recompiled with Debug symbols and dumped again (might help a little more?):
Second run:
Finally, might be relevant, might not, but I had to run openFPGALoader as root (Sudo) since no amount of faffing around on my Ubuntu would let openFPGALoader open the /dev/ttyUSB without it. Not dailup group, not tty group, nothing. Again, Flashing SRAM works just fine using sudo. |
Hmm, some extra context that might help narrow down the issue: If I upload to SRAM first (successfully), then immediately change the destination to the Flash, openFPGALoader gives me a Stack Smashing error* instead of a SegFault (dump below). Further attempts to upload to Flash revert to the original SegFault error as previous comment.
Seems like it is the same stack trace from call number 5 down but interesting that this is different after a successful upload to SRAM. |
Is it possible to test without vmware ? Sometime a VM may (or not) introduces issues with USB? |
your suspicions seem to be correct; it works when tested on my bare-metal Linux box. Whilst I have successfully loaded to the Flash without issue now, I can't say for sure that this is the problem since I didn't have a Ubuntu 20.04 LTS bare-metal box lying around. Instead I had to use a Fedora FC36 Workstation I had on an old dev machine. I did however, recompile from source (same source as the Ubuntu) rather than use the loader that is in the Fedora repos so that at least levels some of the test parameters. It could still be an Ubuntu 20.04 problem and the VM being anywhere from irrelevant or partially involved. UPDATE ---- Installed a fresh Fedora Workstation 38 in a VMWare Workstation and built from source. Loader successfully flashes the SRAM and the Flash chip. Looking like this is a stock Ubuntu 20.04 LTS issue.... @trabucayre what distro/platform are you running/developing on? |
tldr; I've solved my problem (and maybe 'the' problem): make sure the build instructions are followed to-the-letter. I think this is the UDEV rules. Remember my needing to use sudo to get the app to run because of a failure to open the ttyUSBx device? I upgraded my Ubuntu to 22.04 but that exhibited the same problem (segmentation fault). However, issue #245 caught my eye since this is the error I used to get if I ran the app without sudo. Following that issue's comments, I noticed my udev rules folder didn't have the 99-openfpgaloader.rules file (as per the build instructions). Not sure why this was the case as i'm sure i followed, step by step! However, Following the udev section from the Ubuntu build instructions:
and now running the system without sudo, resulted in a working app that flashes both to SRAM and Flash. Seems like the issue was related to udev, device permissions and the subsequent use of sudo when running openFPGALoader. Usually always a sign of an issue if userland stuff needs to be run with sudo.... @wonderfullook would you be interested in verifying any of my findings above and perhaps we can close this off for Gwenhael? |
It's really interesting and may make sense to update FAQ by adding a section. Thanks for this information! |
Hi All
and all good :
|
The segmentation fault is really weird again.
followed by |
When i comment out _spi->spi_put(0x9F, NULL, rx, len); in spiFlash.cpp around line 550 I do not get seg_faults any more
|
Thanks for your feadback: I have disabled this code section. |
This is the log when I use the latest openFPGAloader, hope this can be fixed soon.
The text was updated successfully, but these errors were encountered: