Closed L0g4n closed 1 year ago
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
riscv32imac
so 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
riscv32imac
so that should work in theory right?OpenTitan is
riscv32imc
orriscv32imbc
(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 :smile: 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.
Hello,
after running
make setup
on themaster
branch at 1d785a043a95d83b410f6a099a6121fc101ca3b7 and runningcargo check
I get this error:And even if specify manually for example
LIBTOCK_PLATFORM=opentitan
I get further compilation errors: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.