-
Notifications
You must be signed in to change notification settings - Fork 83
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
Compile apps for RISC-V with make flag #88
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't test this yet as I was hoping to skip brew debugging.
From just reading it, it looks like this will force a recompile every time make
is run? (Because the binary depends on the *.custum.ld
and the rule that makes that file runs unconditionally). I wouldn't expect to recompile if nothing has changed though.
Ok it seems like the main issue is how to install toolchains, and make sure they work on both mac and linux. There was no pushback on #44, so I'm assuming there is no reservations about supporting both, we just need reasonable install steps. If anyone knows of a trick for installing on Linux, please let me know. |
I don't even know where to post an issue (or comment on one) asking the toolchain maintainers to make this easier. But, I'm kind of thinking we just host our own build for ubuntu. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you checking in some binary files as well?
We pre-compile binaries (nrf serialization for example) to make it easier for users. |
How do you handle different RISC-V ISA strings in the pre-compiled binaries? For example supporting both OT and the HiFive1? |
It's no different than cortex-m3 vs m4 (at least it shouldn't be). |
Good point. Just watch out as there are a lot of different combinations that will have to be built and maintained as RISC-V support grows. |
$ sudo apt install gcc-riscv64-unknown-elf | ||
``` | ||
|
||
Unfortunately, Ubuntu does not currently (June 2020) provide a package for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's probably best to specify the version as earlier then 20.10
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if this isn't fixed in 20.10?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we will have to update it, but a date has the same problem. What if 20.10 works? It's then not clear to people that it should work for them.
Either way though we will need to update the steps.
I don't this
If riscv isn't in the targets list, then its toolchain shouldn't be being invoked at all. Verbose output[-bash] Sun 14 Jun 16:10 [[riscv-for-all] ~/code/helena-project/libtock-c/examples/tests/hail] $ make V=1 ************************************************** TOCK USERLAND BUILD SYSTEM -- VERBOSE BUILD ************************************************** Config: CC=-gcc LAYOUT=../../../userland_generic.ld MAKEFLAGS= -r -R PACKAGE_NAME=hail TOCK_ARCHS=cortex-m0 cortex-m3 cortex-m4 rv32imac rv32imc TOCK_TARGETS=cortex-m4 TOCK_USERLAND_BASE_DIR=../../.. TOOLCHAIN= ************************************************** |
TARGETS works together with the |
I guess I don't understand why these should be different things? |
Filed riscvarchive/riscv-gcc#190 for ICE |
We don't have PIC support currently, so we need to hardcode the address for the app. Also don't bother building the cortex binaries.
Got it. I pushed a commit so that |
So I think the only issue left is installing a toolchain?
|
I think I'm concluding that the thing to do at the moment is retain the I think it would be better to get these changes merged, while giving us more time to work on the toolchain problems. |
I agree that these changes are good and shouldn't sit needlessly out-of-tree while we wait on toolchain stuff. We could even be a bit smarter and just have TOCK_TARGETS conditionally include riscv targets based on the presence of the toolchain (roughly ifeq ($(shell command -v riscv64-unknown-elf-gcc),)
TOCK_TARGETS ?= ...arm-only
else
TOCK_TARGETS ?= ...all
endif should work). |
I agree that making risc-v compilation optional in the master branch is better than having it in a second branch that will have to be kept up to date with master somehow. But having the toolchain installed is not sufficient for it to actually work, and I don't think we should force users to uninstall their risc-v toolchain just to be able to build arm apps, all because their toolchain does not include newlib. |
I think it's important the out-of-master change is very small (and never grows). After this PR it would just be changing one make variable (which people will need to do anyway to support new risc-v boards with different flash and ram addresses). But I think that is preferable to having a dynamic system where supporting users is first establishing what toolchains they have just to understand what our build system should be doing. |
Why not just require users to pass |
Oy. Didn't realize there was a newlib wildcard. Yeah, the single TARGETS patch feels good. Or a guard on an environment variable, like |
A single line Make change works for me, same with a command line argument of environment variable. It kind of looks like Ubuntu is the only recent distro that doesn't support RV32 embedded libc, so this is really useful and simple for lots of people. Hopefully Ubuntu 20.10 fixes this and then we at least has a working version (although non-LTS versions don't make it to Travis). |
Use `make RISCV=1` to build them.
I added |
For CI, the options I see:
|
The riscv toolchain isn't the problem, the problem is the build all script doesn't include |
Make picks up variables from the environment, i.e. For CI, probably a separate thing, but should we kick this repo over to github actions as well? That makes mac way less painful as a target. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors r+
🎉
Build succeeded: |
88: Compile apps for RISC-V with make flag r=ppannuto a=bradjc This adds `rv32imac` binaries to TABs from libtock-c. These are compiled for specific flash and RAM addresses. The main change for doing this is automatically generating the linker script when building for each architecture. This copies the default linker script and sets the addresses if needed. Different compilation versions are set in the Configuration.mk makefile. This also compiles libraries for rv32imac, and updates some apps that use assembly. TODO ------ - [x] fix crt0 header for riscv, need to take the stack size into account - [x] make got just a copy - [x] fix lst build for cortex-m Co-authored-by: Brad Campbell <bradjc5@gmail.com> Co-authored-by: Adam H. Leventhal <ahl@oxide.computer>
This adds
rv32imac
binaries to TABs from libtock-c. These are compiled for specific flash and RAM addresses.The main change for doing this is automatically generating the linker script when building for each architecture. This copies the default linker script and sets the addresses if needed. Different compilation versions are set in the Configuration.mk makefile.
This also compiles libraries for rv32imac, and updates some apps that use assembly.
TODO