- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We recently obtained a Terasic DE10-nano development board and installed their Linux Console (kernel 4.5) image on its SD Card, the board booted up as expected. We noticed we could put our old DE0 raw binary file (.rbf) file onto the new DE10-nano SD card and the system booted up without complaint. Furthermore the C applications we wrote for the DE0 run correctly on the DE10 as does the HDL code. Why does this work? The parts are different; DE0 (5CSEMA4U23C6N) and DE10 (5CSEBA6U23I7NDK) , I would have expected it *not* to work.
Any insight would be appreciated!Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- We recently obtained a Terasic DE10-nano development board and installed their Linux Console (kernel 4.5) image on its SD Card, the board booted up as expected. We noticed we could put our old DE0 raw binary file (.rbf) file onto the new DE10-nano SD card and the system booted up without complaint. Furthermore the C applications we wrote for the DE0 run correctly on the DE10 as does the HDL code. Why does this work? The parts are different; DE0 (5CSEMA4U23C6N) and DE10 (5CSEBA6U23I7NDK) , I would have expected it *not* to work. Any insight would be appreciated! --- Quote End --- No, the rbf should not be able to configure successfully. Kindly check if the msel is set as 00000 or 01010 and please check if the CONF_D led turns on after booting. May I know if the code you used is in the FPGA side or HPS side? If you only use the HPS side, as the ARM is the same, it can indeed work properly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- No, the rbf should not be able to configure successfully. Kindly check if the msel is set as 00000 or 01010 and please check if the CONF_D led turns on after booting. May I know if the code you used is in the FPGA side or HPS side? If you only use the HPS side, as the ARM is the same, it can indeed work properly. --- Quote End --- The msel switches are set 01010. The .rbf code is loaded from the SD card during Linux boot by the ARM. It makes sense that the ARM would still work but not the HDL functionality our C code is using, at least not in my experience.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- We recently obtained a Terasic DE10-nano development board and installed their Linux Console (kernel 4.5) image on its SD Card, the board booted up as expected. We noticed we could put our old DE0 raw binary file (.rbf) file onto the new DE10-nano SD card and the system booted up without complaint. Furthermore the C applications we wrote for the DE0 run correctly on the DE10 as does the HDL code. Why does this work? The parts are different; DE0 (5CSEMA4U23C6N) and DE10 (5CSEBA6U23I7NDK) , I would have expected it *not* to work. Any insight would be appreciated! --- Quote End --- We know that you've put the DE0 rbf file into the DE10-Nano SD card, but could you let us know which board you put the DE10-Nano SD card for testing? Did you put the SD card into DE0-Nano-SoC or DE10-Nano? If you put the DE10-Nano SD card which is with the DE0 reb file into the DE0-Nano-SoC, then since the HPS structure is the same for both boards, it's positive that you may run the DE0-Nano-SoC with the DE10 SD card without any problem. On the other hand, if you put the SD card into DE10-Nano, since the FPGA structure of the boards are different, it will not be able to run successfully as the DE0 rbf file will not be able to be download by the DE10-Nano. The CONF_D led will not turn on and you will also notice a failed message in PuTTY while you are booting the board up. Hope this will be useful for you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- We know that you've put the DE0 rbf file into the DE10-Nano SD card, but could you let us know which board you put the DE10-Nano SD card for testing? Did you put the SD card into DE0-Nano-SoC or DE10-Nano? If you put the DE10-Nano SD card which is with the DE0 reb file into the DE0-Nano-SoC, then since the HPS structure is the same for both boards, it's positive that you may run the DE0-Nano-SoC with the DE10 SD card without any problem. On the other hand, if you put the SD card into DE10-Nano, since the FPGA structure of the boards are different, it will not be able to run successfully as the DE0 rbf file will not be able to be download by the DE10-Nano. The CONF_D led will not turn on and you will also notice a failed message in PuTTY while you are booting the board up. Hope this will be useful for you. --- Quote End --- We put the DE10-Nano SD card back into the DE10-nano board. Exactly, we did this: - Replaced the DE10 SD cards Linux BSP image with the Linux Console (kernel 4.5) located here: http://www.terasic.com.tw/cgi-bin/page/archive.pl?language=english&categoryno=205&no=1046&partno=4 - Copied our DE0 .rbf file onto the FAT partition of the updated DE10 SD card - Copied our DE0 embedded C executable (developed under SoC EDS) into /home/root on the DE10 SD Card - Ran the embedded executable via the console program (using PuTTY) Watching Linux boot on the PuTTY console, we saw the .rbf load successfully. Also CONF_D did turn on. Importantly, our DE0 embedded C executable communicates with two verilog cores we wrote and configured in Qsys to produce a successful result (it did). So can I conclude that an embedded executable and .rbf developed for the DE0 will run properly on a DE10? The ARM/Linux compatibility I understand since the micro-controller cores on the DE0's SoC and DE10 SoC are the same. What doesn't make sense to me is how the FPGA fabric configuration can also be compatible. If the fabric supports this type of compatibility could you please elaborate or provide a pointer to an explanation? Thank you very much for your attention
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We put the DE10 SD back into the DE10 board and powered up - the .rbf file loads, CONF_D turns on and the embedded executable runs properly under the Linux system. This embedded executable needs two verilog cores we wrote and configured under Qsys to run properly. I understand the HPS systems are similar but the FPGA configuration also? Maybe it has something to do with Qsys compatibility?
Thanks you for your attention.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- We put the DE10 SD back into the DE10 board and powered up - the .rbf file loads, CONF_D turns on and the embedded executable runs properly under the Linux system. This embedded executable needs two verilog cores we wrote and configured under Qsys to run properly. I understand the HPS systems are similar but the FPGA configuration also? Maybe it has something to do with Qsys compatibility? Thanks you for your attention. --- Quote End --- That's quite weird as it should not be loaded successfully. We've also tried to put the rbf file into the DE10-nano in our side, but it turned out failed. Is it possible to provide us with the rbf for our testing?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
We worked with this some more and found the problem, a mix up with some images. The DE10 looks fine now.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page