[question] -march de10 still runs in CPU #234
Comments
|
Are you running quartus_server on localhost:9900? If you don't provide
--quartus_server and --quartus_port the de10 backend will default to those
values when trying to connect to the server.
…On Thu, Jan 9, 2020 at 1:26 PM ***@***.*** ***@***.***> wrote:
I run
cascade --march de10 -e share/cascade/test/benchmark/bitcoin/run_25.v --enable_info --profile 3
but it runs on CPU.
In De10Compiler::compile De10Compiler::block_on_compile always returns
false because the RPC server is ok, so it never moves it to the FPGA.
What am I missing it? What is the condition that allows the program to run
on FPGA. RPC not being ok can't be such a condition.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLW6LOPTAZOFERWSQMLQ46JBFANCNFSM4KE6WXPA>
.
|
|
The problem is that |
|
Try running with --enable_info. That'll give us a bit more information
about which backend compiler is being called when.
…On Thu, Jan 9, 2020, 6:34 PM ***@***.*** ***@***.***> wrote:
--quartus_server and --quartus_port correspond to the host.
The problem is that De10Compiler::compile isn't called at all. I see that
in cascade.cc avmm::De10Compiler is created, and recorded in
runtime_.get_compiler() under the key de10, but it isn't clear who is
supposed to call its compile function.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLWBOSMNPZDFT34CMB3Q47NBRANCNFSM4KE6WXPA>
.
|
|
I run with |
|
The de10 backend uses three passes: software simulation, native compilation
using verilator, and then quartus compilation to bitstream.
The first pass looks like it's working. We know since we see the line
"finished pass 1 compilation of root with attributes ... __target="sw"".
The next thing we'd expect to see is a similar line for verilator,
something like this:
"finished pass 2 compilation of root with attributes ...
__target="verilator32"".
Depending on your machine, this can actually take a little while. How long
have you tried running for? It's only after this pass runs to completion
that we would expect to see control hit the de10 compiler.
Alternately, you could try turning off by the second pass by
editing share/cascade/march/de10.v (all the --march flag does is read the
corresponding file in share/cascade/march). On lines 6 and 7 you should see
the instantiation of the top-level root module. The __target annotation is
a semi-colon separated list of compilation passes to perform. The first
pass is required to be sw, but after that, you could use whatever you
wanted. If you want to get rid of verilator, you could change the
annotation to this:
(*__target="sw;de10"*)
If you wanted to another software pass (for no really good reason, I
suppose) you could do this:
(*__target="sw;verilator32;sw;de10"*)
…On Thu, Jan 9, 2020 at 7:21 PM ***@***.*** ***@***.***> wrote:
I run with --enable_info, and with an extra-printout in
De10Compiler::compile, but it is never printed:
$ cascade --march de10 --quartus_server 192.168.5.3 --quartus_port 9971 -e share/cascade/test/benchmark/bitcoin/run_25.v --enable_info --profile 3
>>> Started logical simulation...
>>> Installation Path: /usr/local/bin/../
>>> Fopen dirs: ./:
>>> Include dirs: /usr/local/bin/../:
>>> C++ Compiler: /usr/bin/c++
>>> Typechecker Warning:
>>> > In module declaration in share/cascade/test/benchmark/bitcoin/sha256_transform.v on line 104: HASHERS[((64 / LOOP) - 32'd1)].state[31:0]
>>> Found reference to unresolvable identifier, this may result in an error during instantiation
>>> Typechecker Warning:
>>> > In module declaration in share/cascade/test/benchmark/bitcoin/bitcoin.v on line 4: clock.val
>>> Found reference to unresolvable identifier, this may result in an error during instantiation
>>> > In module declaration in share/cascade/test/benchmark/bitcoin/bitcoin.v on line 3: clock.val
>>> Found reference to unresolvable identifier, this may result in an error during instantiation
>>> Finished pass 1 compilation of root with attributes (*__std = "logic",__loc = "local",__target = "sw"*)
>>> Finished pass 1 compilation of root.clock with attributes (*__std = "clock",__loc = "local",__target = "sw"*)
>>> Deferring pass 1 compilation of root.pad with attributes (*__std = "pad",__loc = "local",__target = "de10"*)
>>> Deferring pass 1 compilation of root.led with attributes (*__std = "led",__loc = "local",__target = "de10"*)
>>> Deferring pass 1 compilation of root.gpio with attributes (*__std = "gpio",__loc = "local",__target = "de10"*)
>>> Logical Time: 1
>>> Virtual Freq: 0 Hz
>>> Logical Time: 512
>>> Virtual Freq: 85 Hz
>>> Logical Time: 1280
>>> Virtual Freq: 76 Hz
>>> Logical Time: 1920
>>> Virtual Freq: 106 Hz
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLU2IBCXOLLVOYJLJQ3Q47ST5ANCNFSM4KE6WXPA>
.
|
|
I run and I noticed that it prints this, with errors in the messages: |
|
It's not that big a testcase. It doesn't take more than a second or two to
compile on my machine.
One thing that occurs to me ---
The documentation says to run cascade with sudo on the de10, and I notice
that you're not doing that in the command lines you sent. If you ran
cascade with sudo at some point, it would have created a tmp directory
/tmp/verilator with root permissions. If after that, you ran cascade
without sudo, the verilator backend wouldn't be able to read or write that
directory, and might be hanging or in an inconsistent state. I'd try rm
-rf'ing /tmp/verilator, /tmp/avalon, and /tmp/de10, just to be safe, and
then always running on the de10 with sudo.
If that solves the problem, we can fix this issue by being explicit about
setting permissions on any of the /tmp directories that cascade creates.
…On Thu, Jan 9, 2020 at 10:30 PM ***@***.*** ***@***.***> wrote:
Perhaps this testcase is too large? Is there a smaller testcase
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLWXUPPYMQTIENYJJR3Q5AIXTANCNFSM4KE6WXPA>
.
|
|
That's interesting. It looks like the quartus server is trying to compile
something and failing? It might *also* be in an inconsistent state. Try
shutting it down and restarting it before running cascade again?
On Fri, Jan 10, 2020 at 10:48 AM eric schkufza <[email protected]>
wrote:
… It's not that big a testcase. It doesn't take more than a second or two to
compile on my machine.
One thing that occurs to me ---
The documentation says to run cascade with sudo on the de10, and I notice
that you're not doing that in the command lines you sent. If you ran
cascade with sudo at some point, it would have created a tmp directory
/tmp/verilator with root permissions. If after that, you ran cascade
without sudo, the verilator backend wouldn't be able to read or write that
directory, and might be hanging or in an inconsistent state. I'd try rm
-rf'ing /tmp/verilator, /tmp/avalon, and /tmp/de10, just to be safe, and
then always running on the de10 with sudo.
If that solves the problem, we can fix this issue by being explicit about
setting permissions on any of the /tmp directories that cascade creates.
On Thu, Jan 9, 2020 at 10:30 PM ***@***.*** ***@***.***>
wrote:
> Perhaps this testcase is too large? Is there a smaller testcase
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#234>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAE3RLWXUPPYMQTIENYJJR3Q5AIXTANCNFSM4KE6WXPA>
> .
>
|
|
The error is reproducible, so it's not a matter of confused state. Also please note that it looks for ~/soc_system.qsys. Why does it look for this file? |
|
I think there's a bug that soc_system.qsys is assumed to be local, but it is not with the remote Quartus setup. It needs to be first copied over to the Quartus server. I'll submt a PR for this, it seems that this file is essential. |
|
The array benchmark is a little bit simpler. You could try that one instead: $ cascade -e share/test/benchmark/array/run_7.v --march de10 ...Oh. Okay. I understand what's going on. The quartus server does more than just compile the code that gets sent over the network. It creates a temp directory I didn't think about it when you submitted your PR, but invoking quartus using your tunnel command won't work unless all of those files are on the remote machine. It's more than just soc_system.qsys. It's the entire contents of the temp directory that need to be compiled by quartus. |
|
I am going to fix the problem of remote vs. local files. |
|
This not-yet-verified patch copies files to/from the remote Quartus server: #236 Quartus still printed (different) errors: |
It seems that Quartus 19.1 is just broken? They install perl, some perl module is missing and it just breaks. I tried The workaround is: |
|
Now it runs for a long time, and fails: It seems that it needs a license just to compile a design? This URL says that Quartus Lite doesn't require a license: https://www.intel.com/content/www/us/en/programmable/support/support-resources/support-centers/licensing.html |
|
It looks like you're running quartus prime. Quartus lite shouldn't require
a license.
…On Sat, Jan 11, 2020, 10:08 AM ***@***.*** ***@***.***> wrote:
Now it runs for a long time, and fails:
Warning (18236): Number of processors has not been specified which may cause overloading on shared machines. Set the global assignment NUM_PARALLEL_PROCESSORS in your QSF to an appropriate value for best performance.
Warning (292011): Can't generate programming files because you are currently using the Quartus Prime software in Evaluation Mode.
Info: Quartus Prime Assembler was successful. 0 errors, 2 warnings
Info: Peak virtual memory: 977 megabytes
Info: Processing ended: Sat Jan 11 10:01:08 2020
Info: Elapsed time: 00:00:12
Info: Total CPU time (on all processors): 00:00:08
Info: *******************************************************************
Info: Running Quartus Prime Convert_programming_file
Info: Version 19.1.0 Build 670 09/22/2019 SJ Standard Edition
Info: Copyright (C) 2019 Intel Corporation. All rights reserved.
Info: Your use of Intel Corporation's design tools, logic functions
Info: and other software and tools, and any partner logic
Info: functions, and any output files from any of the foregoing
Info: (including device programming or simulation files), and any
Info: associated documentation or information are expressly subject
Info: to the terms and conditions of the Intel Program License
Info: Subscription Agreement, the Intel Quartus Prime License Agreement,
Info: the Intel FPGA IP License Agreement, or other applicable license
Info: agreement, including, without limitation, that your use is for
Info: the sole purpose of programming logic devices manufactured by
Info: Intel and sold by Intel or its authorized distributors. Please
Info: refer to the applicable agreement for further details, at
Info: https://fpgasoftware.intel.com/eula.
Info: Processing started: Sat Jan 11 10:01:09 2020
Info: Command: quartus_cpf -c sof2rbf.cof
Error (210007): Can't locate programming file DE10_NANO_SoC_GHRD.sof (in output_files/ & ) in Conversion Setup File
Error: Quartus Prime Convert_programming_file was unsuccessful. 1 error, 0 warnings
Error: Peak virtual memory: 446 megabytes
Error: Processing ended: Sat Jan 11 10:01:10 2020
Error: Elapsed time: 00:00:01
Error: Total CPU time (on all processors): 00:00:00
It seems that it needs a license just to compile a design?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLWDUL63JECYNQE3DSTQ5IDJDANCNFSM4KE6WXPA>
.
|
|
Yes, it was Quartus Prime, now with Quartus Lite I am able to run through the compiler. Now the board crashes before Cascade attempts to configure it. It crashes right after |
|
Are you running with sudo? If you are, maybe this has to do with the mmap
issue you discovered. Maybe change length to something more than 1 byte?
…On Sat, Jan 11, 2020 at 9:25 PM ***@***.*** ***@***.***> wrote:
Yes, it was Quartus Prime, now with Quartus Lite I am able to run through
the compiler.
------------------------------
Now the board crashes before Cascade attempts to configure it. It crashes
right after fpga_off(); in De10Config::config_routine, and reboots.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLQD6EVV35ZDGW6F3V3Q5KSVZANCNFSM4KE6WXPA>
.
|
|
I was able to reproduce with this program https://github.com/nhasbun/de10nano_fpga_linux_config/blob/master/main.c In main.c change the section branching based on the argument Compile and run it. This crashes the board and it reboots. Is it possible that MSEL toggles need to be in some specific combination? Mine is 1/0/1/0/1/1. |
|
(cc'ing josh who wrote the reprogramming code)
Josh ---
Do you remember what configuration the msel toggles on the de10 need to be
in to work with the reprogramming code you found?
…On Sun, Jan 12, 2020 at 2:15 AM ***@***.*** ***@***.***> wrote:
I was able to reproduce with this program
https://github.com/nhasbun/de10nano_fpga_linux_config/blob/master/main.c
In main.c change the section branching based on the argument if(argc > 1)
{ to these lines:
report_status();
set_ctrl_en(1);
fpga_off();
Compile and run it. This crashes the board and it reboots.
Is it possible that MSEL toggles need to be in some specific combination?
Mine is 1/0/1/0/1/1.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLS434X6NOSPE3SBI53Q5LUVFANCNFSM4KE6WXPA>
.
|
|
The project where this code was taken from https://github.com/nhasbun/de10nano_fpga_linux_config has the answer: 01010 (in the section Loading rbf File). However, with the 01010 setting the board doesn't connect to the network. |
|
I think the reconfiguration code we used requires the board to be in the default configuration (which is 010100). If you're running one of the standard SD card images, the FPGA-fabric-configured LED should light up when the system boots and should get toggled when Cascade reconfigures the FPGA. The DE10 should also be able to reach the network in this configuration, as least with the SD card images we tested. |
|
It doesn't connect to the network with 01010. Also 01010 isn't a default configuration. The card comes from the factory with 10101. Their user manual also says that 10101 is their default configuration (in the Table 3-2): http://www.terasic.com.tw/cgi-bin/page/archive_download.pl?Language=English&No=1046&FID=1c19d1d50e0ee9b21678e881004f6d81 |
|
In the documentation and on MSEL switch, on is 0 and off is 1, which is quite confusing. The default mode is FPPx32, which is programmed via setting the MSEL to on off on off on, or 01010. If you have these settings correct, the FPGA should get configured during boot and a blue LED should come on. |
|
Also, can you check that the reconfiguration code is finding the bitstream file ok? If there's a transfer or pathing error, it may not catch that until the reconfiguration fails. |
|
Then I was running 01010 (ON-OFF-ON-OFF-ON) from the beginning, and the board is just crashing when this sequence is run: Specifically, fpga_off writing contol_reg=0x2c5 into |
|
The crash is reproducible using this project https://github.com/nhasbun/de10nano_fpga_linux_config. Just run and the board would crash and reboot. |
|
This seems to be a problem with my image, I use the factory image. |
|
That's very strange behavior indeed because we use the code from that project to perform the reconfiguration in Cascade. If the original code isn't working, then at least the bug isn't specific to our own code. What's concerning is that the original code doesn't really use OS-specific features, so it should be quite portable. Still, I'm curious what environment you're using on your DE10. Is it a Terasic-provided SD card image, an image based on a common distro, or something more custom? |
|
We've been using an Ubuntu-based image, but the Terasic images should work as well, which may be what your kit came with. Unfortunately, if the original code isn't working for you and you've verified your switches are correct, I'm not really sure why this is crashing your system, especially if the crash is before the bitstream is even touched. Can you verify the DE10 is getting configured at boot? Maybe send us the status of the FPGA registers via the fpga_rbf_load program? |
|
Also, it may be worth considering restarting with the Terasic image available online to make sure your current installation isn't a problem. Sometimes the SD cards get corrupted if you don't shut the DE10 down right, and things will flat out stop working. |
|
I use the image that the board came with from the factory. The initial state that the the fpga_rbf_load program reports is: The behavior is definitely not specific to the Cascade code. IMO, this might be some kernel bug that is present in my image and wasn't present earlier when fpga_rbf_load was developed and published. |
|
Those values seem correct, so the problem is probably elsewhere. Are you using any FPGA-specific features during reconfiguration? I've read the HDMI output / GUI can rely on the FPGA being configured and using them during reconfiguration can cause a crash. |
No, I access the board only through ssh. |
|
Terasic answered my e-mail. They said I think they changed something in the image and now They pointed to the example |
|
That's very strange as the code was working for us and theoretically isn't specific to any image since it accesses hardware registers directly. Maybe Eric can get you a copy of one of his images that's working or help you build you own. Alternatively, it may be worth testing with an older version of Cascade that uses JTAG for configuration in the meantime. |
|
If Eric could upload it to Google Drive I could try it. |
|
I think the image that De10-Nano ships with uses FPGA for something. This is why when control is transferred to HPS and FPGA then turned off it affects something important and the system crashes. It does load a lot of kernel modules. It loads the fft module for example. Some of them might accidentally use FPGA. I am not sure how to unload them from boot. |
|
@yurivict I'll get it uploaded asap. |
|
Sorry this is taking longer than I thought --- The image that I've been working off of is being kind of fickle and handing it off to you would probably cause more confusion than problems it solved. I got in touch with the guy who wrote the script that generates the ubuntu image that we've been using. I'm going to boot it back up, make sure it works on my end, and I'll upload it as soon as I'm done. |
|
No problem! When you are ready. I am waiting for the microSD card writer in mail too, as mine is broken. |
|
I tried a few random De10-Nano images available online to come with different other projects and they typically don't come with DHCP/Ethernet setup, which is a hassle. They expect users to connect to a terminal over USB. |
|
There's a way to share your internet connection from the host to the DE10 over the USB interface if you're having trouble getting Ethernet set up. I can't guarantee these will work with your particular OS and images, but they did work with ours (which were Ubuntu-based). To enable internet forwarding from the host to a DE10 with an IP address of 192.168.7.0: echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward > /dev/null
sudo iptables -P FORWARD ACCEPT
sudo iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24To disable forwarding: echo 0 | sudo tee /proc/sys/net/ipv4/ip_forward > /dev/null
sudo iptables -t nat -F POSTROUTING |
|
The author of the His image is free of the problem, so now I can resume testing once I have time. |
|
Oh wow, very cool.
I've been having some trouble on my end. I tried downloading the image that
ships with the de10 (
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=1046&PartNo=4)
and it wouldn't boot for me. This new image you linked to looks like it
works though, so we can use this as common ground for getting an angstrom
environment up and running. The big obstacle I can see is that opkg doesn't
have targets for verilator, google test, and google benchmark.
I've also been trying to build an ubuntu image using this tutorial (
https://bitlog.it/20170820_building_embedded_linux_for_the_terasic_de10-nano.html).
I think this is more or less the same process you're looking into. The
author says he's just expanding on the instructions posted at
rocketboards.org. So far I haven't quite gotten it to work, but if it does,
I think we should be able to use it to build cascade without issue.
I still have the ubuntu image that my co-worker generated for us a while
ago (the one that josh and I were testing against), but it's sort of a mess
and my co-worker is away on work travel, so he doesn't have a ton of cycles
to try to figure out what's wrong with it. So for the time being, let's
pursue these other two options.
…On Sun, Jan 19, 2020 at 4:53 PM ***@***.*** ***@***.***> wrote:
The author of the de10nano_fpga_linux_config project has very kindly
shared his image
https://onedrive.live.com/?authkey=%21APtymIv2zHnl8Fo&cid=0E44B54C356BA235&id=E44B54C356BA235%2124960&parId=root&action=locate
His image is free of the problem, so now I can resume testing once I have
time.
I was also building the image following the instructions from
RocketBoards.org. I may end up with too many images now. -)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLURCAUBGDDEAHG24PLQ6TYW5ANCNFSM4KE6WXPA>
.
|
|
I will submit a PR which would eliminate the need to build on an embedded system once I have it up and running and testing is done. |
|
The image from the author of I followed the instructions from here https://rocketboards.org/foswiki/Documentation/YoctoDoraBuildWithMetaAltera It is supposed to build the whole SD card image with a modern version of Linux kernel and Yocto project. The process completed but it didn't produce a usable image - it is too small, only 43MB. |
|
I eventually got back to testing. How can one tell that the application runs on the FPGA, and not on CPU? |
|
Try the --enable_info and --profile <n> flags.
You should see a message about how cascaded "finished pass 3 compilation to
... __target="de10". As long as the application is compute bound, the
profile flag will probably also show the clock frequency increasing after
the transition.
…On Fri, Jan 24, 2020 at 1:01 AM ***@***.*** ***@***.***> wrote:
I eventually got back to testing.
How can one tell that the application runs on the FPGA, and not on CPU?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLQVQZ4HMWSGJJGX34DQ7KU65ANCNFSM4KE6WXPA>
.
|
|
The image from the author of https://github.com/nhasbun/de10nano_fpga_linux_config crashes on LEDs access. The C program HPS_FPGA_LED from Terasic CDROM crashes it, but doesn't crash the Terasic's own image. I've managed to build the De10-Nano image using the Yocto Poky project with the Altera layer over Poky. This image boots but the Ethernet card "Micrel KSZ9031" doesn't work due to some bug in the Linux kernel. Still trying to figure out how to work with it. |
|
I think that this is a bug in Cascade that it even attempts to turn the FPGA off. When Quartus Platform Designer builds an image it puts some compiled Verilog in it. The same probably happens when Poky builds an image. If the system is booted with a pre-programmed FPGA you can't safely turn it off. So maybe there is nothing wrong with the Terasic image, the "off" command just can never be executed. Cascade just needs to know how to program on top of what is already there, and how to then erase the program that it wrote. I didn't see the code for the latter. |
|
Sorry about the slow reply. I've spent the past few weeks transitioning
jobs (no longer at vmware, now at amazon).
Some good news and bad news.
The good news is that I finally built an ubuntu image for the de10. You can
download it here:
https://drive.google.com/file/d/1jYNiNdQVGjDHt6YGqKA72cP8gN2CuefH/view?usp=sharing.
The image is configured with a single user; username and password are
fpga/fpga. There's a single folder in the user's home directory which
contains a checkout of cascade, which has been built and installed (via
make -C build; make -C build install). I verified that all regression tests
pass, and the example in the readme works as intended. Hopefully this works
as a better platform for debugging.
The bad news is that since I left vmware I lost my admin privileges on the
repository, so we're temporarily without an administrator. That means that
I won't be able to push any changes or accept pull requests until we get
things sorted out (hopefully in the next week or two).
…On Sun, Jan 26, 2020 at 5:40 PM ***@***.*** ***@***.***> wrote:
I think that this is a bug in Cascade that it even attempts to turn the
FPGA off.
When Quartus Platform Designer builds an image it puts some compiled
Verilog in it. The same probably happens when Poky builds an image. If the
system is booted with a pre-programmed FPGA you can't safely turn it off.
So maybe there is nothing wrong with the Terasic image, the "off" command
just can never be executed. Cascade just needs to know to to program on top
of what is there already, and how to then erase the program that it wrote.
I didn't see the code for the latter.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLR3OYO57TBNFEOFXVTQ7Y3PBANCNFSM4KE6WXPA>
.
|
|
Congrats with your new job! I'll try the image over the weekend. |
|
Can you verify that Google Drive didn't mess with your file? When I downloaded it, I only got a 22MB archive, which seems extremely small. Extracting the archive results in an extension-less file that says it's about 16GB large. That's twice the size of the microSD cards that come with the DE10 boards. It does seem to have some kind of filesystem on it, but the filesystem says there's only ~4.3GB of data. Should we write just that part of the image to the microSD card and ignore the rest of the file? |
|
That's the right one (I'm pretty sure). The microsd card I used was 16gb,
but most of the space was unused. I configured a 4gb file system.
There should be there partitions (the third is the file system --- the
other two are O(10mb) boot partitions). Depending on your os it might not
be recognizing them. Just use dd to copy the whole thing en masse.
I'll make an 8gb image when I get home tonight just in case.
…On Fri, Feb 14, 2020, 7:25 AM JoshuaLandgraf ***@***.***> wrote:
Can you verify that Google Drive didn't mess with your file? When I
downloaded it, I only got a 22MB archive, which seems extremely small.
Extracting the archive results in an extension-less file that says it's
about 16GB large. That's twice the size of the microSD cards that come with
the DE10 boards. It does seem to have some kind of filesystem on it, but
the filesystem says there's only ~4.3GB of data. Should we write just that
part of the image to the microSD card and ignore the rest of the file?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLVY56UV7TEWULLHYXTRC2ZXFANCNFSM4KE6WXPA>
.
|
|
Oh, in that case, you could just shorten the image down to the size of the filesystem. Writing zeros to the end of the disk just makes the initialization process take longer. Also, it looks like the third partition is a tiny boot partition, not the main one. Do you know if it could be relocated to before the main partition or would that break things? If the main partition is the last one on the microSD card, it's pretty easy to grow it so it can use the remaining free space. Might be handy if people want to install a few extra packages during development. |
|
Ah, great. 2GB is the size of the file system that ships with the de10s. I
was always running out of space with that one so I double it. I could have
increased the size up to the full 8GB, but I must have reflashed my sd card
about a thousand times and was getting tired of how long dd took. If you
can get away with just copying the first half of the image to your card,
then do that.
The partition order isn't particularly important, but we'd have to rebuild
the image in order to make it work. There are boot scripts that rely on
things being in one place or another. As soon we get access back to the
repository I can commit the script that I used to build the image. The
changes would go there and they'd be pretty easy to make I think.
…On Fri, Feb 14, 2020 at 8:18 AM JoshuaLandgraf ***@***.***> wrote:
Oh, in that case, you could just shorten the image down to the size of the
filesystem. Writing zeros to the end of the disk just makes the
initialization process take longer. Also, it looks like the third partition
is a tiny boot partition, not the main one. Do you know if it could be
relocated to before the main partition or would that break things? If the
main partition is the last one on the microSD card, it's pretty easy to
grow it so it can use the remaining free space. Might be handy if people
want to install a few extra packages during development.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLXR7EBLI5T4SOFMEVDRC273XANCNFSM4KE6WXPA>
.
|
|
Sounds great. Let me know when you push the scripts, so I can take a look. Also, if your transfer speed is slow in macOS, check out the /dev/rdisk* interface. It's an unbuffered (lower overhead) version of /dev/disk*. When combined with a large dd block size (e.g. 1MB), some users have claimed speedups of up to 20x. |
|
Yep. That makes a big difference. It's still O(minutes) though, which is
annoying when you want to try editing a boot script, watch it crash, and
then debug it over and over again.
…On Fri, Feb 14, 2020 at 9:37 AM JoshuaLandgraf ***@***.***> wrote:
Sounds great. Let me know when you push the scripts, so I can take a look.
Also, if your transfer speed is slow in macOS, check out the /dev/rdisk*
interface. It's an unbuffered (lower overhead) version of /dev/disk*. When
combined with a large dd block size (e.g. 1MB), some users have claimed
speedups of up to 20x.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#234>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE3RLVS5DWVKEIO7EDS4TTRC3JHLANCNFSM4KE6WXPA>
.
|
I run
but it runs on CPU.
In
De10Compiler::compileDe10Compiler::block_on_compilealways returns false because the RPC server is ok, so it never moves it to the FPGA.What am I missing? What is the condition that allows the program to run on FPGA? RPC not being ok can't be such a condition.
The text was updated successfully, but these errors were encountered: