Compilation fails with 'Please specify LIBTOCK_PLATFORM: NotPresent' error
L0g4n opened this issue · comments
Hello,
after running make setup on the master branch at 1d785a0 and running cargo check I get this error:
Caused by:
process didn't exit successfully: `/home/yk/rust-artifacts/debug/build/libtock_runtime-3b6f81c3384645c2/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=LIBTOCK_PLATFORM
--- stderr
thread 'main' panicked at 'Please specify LIBTOCK_PLATFORM: NotPresent', runtime/build.rs:31:52
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
And even if specify manually for example LIBTOCK_PLATFORM=opentitan I get further compilation errors:
error[E0277]: the trait bound `TockSyscalls: RawSyscalls` is not satisfied
--> runtime/src/startup/mod.rs:62:5
|
62 | Termination::complete::<TockSyscalls>(result)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `RawSyscalls` is not implemented for `TockSyscalls`
|
= note: required because of the requirements on the impl of `Syscalls` for `TockSyscalls`
note: required by a bound in `complete`
--> /home/yk/Dokumente/Coding/opensk_fork/third_party/libtock-rs/platform/src/termination.rs:7:20
|
7 | fn complete<S: Syscalls>(self) -> !;
| ^^^^^^^^ required by this bound in `complete`
error[E0599]: no function or associated item named `syscall2` found for struct `TockSyscalls` in the current scope
--> runtime/src/startup/mod.rs:95:23
|
95 | TockSyscalls::syscall2::<{ syscall_class::MEMOP }>([
| ^^^^^^^^ function or associated item not found in `TockSyscalls`
|
::: runtime/src/lib.rs:27:1
|
27 | pub struct TockSyscalls;
| ------------------------ function or associated item `syscall2` not found for this
|
= help: items from traits can only be used if the trait is implemented and in scope
= note: the following trait defines an item `syscall2`, perhaps you need to implement it:
candidate #1: `RawSyscalls`
error[E0599]: no function or associated item named `syscall2` found for struct `TockSyscalls` in the current scope
--> runtime/src/startup/mod.rs:99:23
|
99 | TockSyscalls::syscall2::<{ syscall_class::MEMOP }>([
| ^^^^^^^^ function or associated item not found in `TockSyscalls`
|
::: runtime/src/lib.rs:27:1
|
27 | pub struct TockSyscalls;
| ------------------------ function or associated item `syscall2` not found for this
|
= help: items from traits can only be used if the trait is implemented and in scope
= note: the following trait defines an item `syscall2`, perhaps you need to implement it:
candidate #1: `RawSyscalls`
warning: unused import: `RawSyscalls`
--> runtime/src/startup/mod.rs:4:39
|
4 | use libtock_platform::{syscall_class, RawSyscalls, Termination};
| ^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
Some errors have detailed explanations: E0277, E0599.
For more information about an error, try `rustc --explain E0277`.
warning: `libtock_runtime` (lib) generated 1 warning
error: could not compile `libtock_runtime` due to 3 previous errors; 1 warning emitted
Is the current master branch supposed to be broken or I am doing something wrong? Since the documentation seems to be outdated, I did not know what do instead.
The README being outdated is definitely a known issue -- I was waiting for Tock 2.1 to release to update it. Tock 2.1 is out but I haven't had the time to update it.
That error is expected if you try to build libtock_runtime (or something that depends on it, like libtock) for an unsupported architecture. The only supported architectures at the moment are arm and riscv32. We definitely could generate a better error message here.
You will not be able to make a single cargo check invocation pass for the entire workspace, because some of the crates are meant to run on Tock and some are meant to run on a host platform (e.g. desktop Linux).
I suggest looking at doc/Overview.md to understand which crates should build on which architecture. The warning at the top of that file (about not all of the crates existing yet) is outdated, and the Tock 1.0 crates have been removed. You can also look at the recipe for make test, which builds libtock-rs crates for several enviroments (Tock on RISC-V, Tock on ARM, Miri, and the host system).
Thanks for your response, I will definitely try that later and see if it'll work.
Just for clarity (since you said only ARM and RISCV32 are supported), OpenTitan is basically riscv32imac so that should work in theory right?
I am currently in the process of backporting the whole OpenSk stuff to Tock 2.1 due to better support for OpenTitan. I already managed to backport the kernel patches and now I am facing this task of migrating the whole userspace libtock-rs based stuff.
Just for clarity (since you said only ARM and RISCV32 are supported), OpenTitan is basically
riscv32imacso that should work in theory right?
OpenTitan is riscv32imc or riscv32imbc (no atomics are present, I don't recall the details on its bitmanip support), and yes that should work.
What libtock-rs drivers does OpenSK rely on? @L0g4n
Just for clarity (since you said only ARM and RISCV32 are supported), OpenTitan is basically
riscv32imacso that should work in theory right?OpenTitan is
riscv32imcorriscv32imbc(no atomics are present, I don't recall the details on its bitmanip support), and yes that should work.
You're right, the a was actually a typo, I know about the missing atomics.
What libtock-rs drivers does OpenSK rely on? @L0g4n
@hudson-ayers A custom USB-CTAP(-HID) driver, a custom firmware protection driver (not strictly necessary), a custom non-volatile memory controller (for more the details checkout the repo). And of course the whole userspace driver interface stuff around the userspace program.
So OpenSK does not use, for example, the libtock-rs alarm driver? Or is that covered under the umbrella of your last sentence?
In the current Tock 1.x version no, it's a custom driver interface 1
From a quick glance I thought I can just use a wrapper type around the current libtock-rs alarm driver to add the additional methods. However, I did not check yet if multiple alarms at the same time are required (which are impossible to do in libtock-rs as you said) but I hope at least not 😄 And it would not make much sense in single-threaded environment, I guess.
It's been a couple years since I've looked at OpenSK's code, but IIRC they never need multiple alarms at the same time.