Forum Discussion
Occasional ContributorA topic explaining a problem with Cyclone V SoC - u-booting .rbf file failure - got rejected.
Hello Yoshiaki,
Thank you so much for taking the effort to test the .rbf files I built and shared on your own DE10-Nano system, and confirming them that they actually work. :)
On my side, on my own QMTECH board, I did the check (performed the register read from U-Boot shell) of the 'stat' register of the FPGA Manager Module, and I think I found my answer/reason for my troubles. So I had set MSEL SW to '01010' (ON-OFF-ON-OFF-ON) on my board, stopped at U-Boot, issued the command and got the below:
=> md ff706000 1 ff706000: 00000058 X... =>So, I do NOT get the expected: 'ff706000: 00000050 P...' , but actually 'ff706000: 00000058 X...' . And then I checked my board physically , toggling one pin at a time , and then reading back the 'stat' register after each pin change. And it was found out that one of the pad pins (the PIN.5) of the DIP SW was broken. And toggling the one switch adjacent to that pin, made no change in the 'stat' register readout.
So, I think the cause had been found for why Uboot can't load compressed .rbf succesfully - my board has a broken MSEL DIP SW pin and it just physically cannot apply/provide the MSEL = '01010'. So, I have to fix my board in this case.
Anyway, at this point, I think the issue is to be considered SOLVED. You can close this ticket.
Much gratitutes Yoshiaki, you've been of great help!
Best Regards,
- Monk M.
Occasional ContributorGreetings Yoshiaki,
So, first, I actually tried something first yesterday after writing my original message and I have good results. In the Quartus project settings - I disabled the compression for the bitstream and also set the Configuration scheme to Passive Parallel x16.
Also, in the same project settings, I enabled the generation of the Raw Binary File (.rbf).
So, now when the Quartus project is rebuild (as normal) it will also create the .rbf file I need for U-boot. Then I recompiled the project, and just used to .sof file to program directly the FPGA part of the device:
And it was all successful. Actually, the FPGA portion of the design contains a Qsys, that features several different JTAG masters and JTAG Uart. And after the design (.sof) was programmed - those became visible when polling the jtagconfig with the USB-Blaster still attached:
Thus, the configuration files (.sof) and (.rbf) - match and work with the SoC FPGA on the board correctly. Note: At this point the produced .sof and .rbf files are 'uncompressed' and configured for 'FPP x16'.
