Overview: Add tock v2 support #580

L0g4n · 2023-01-17T17:37:19Z

Fixes #579

This is the starting point for the maintainers to get an overview of all changes (and can be split up, after further discussion) and hence this PR has not been opened with the intention to merge in this state.

Important things to note

This has still some very rough edges, hence, this is considered a WIP
commit. Next to the missing firmware_protect driver for TockOs (for disabling JTAG support and preventing dumping of the firmware), this includes non-working examples.

Additionally, it is important to note that OpenSK can not be built anymore on x86 host machines, since libtock_runtime (part of libtock-rs 2.0 WIP) is only running on ARM and riscv hosts.
Hence a normal invocation of cargo build or cargo check on your average dev machine will fail, but you can still cross-compile for ARM or RISCV and/or run cargo check --features std to see if the code compiles fine, but you need to apply the alloc_init patch for the libtock-rs submodule before running the build commands.

These circumstances probably mean that with the current CI config the pipeline will for sure fail and needs further modifications. Let me know what you think, where problematic areas are, and how we can continue from here.

Tests pass
Appropriate changes to README are included in PR

ia0 · 2023-01-18T11:34:12Z

Thanks @L0g4n for the work you put in this PR!

@kaczmarczyck is currently on vacation and I'm a currently a bit busy, but I'll take a look next week and provide some comments. Some early comment though that might simplify your workflow: You can use the ./maintainers/patches script to deal with the tock and libtock-rs patches. Running the command without argument explains how to use it, but the main idea is to use apply to get one commit per patch and a clean state, then use save once the commits have been modified (including adding new commits) to update the patches.

L0g4n · 2023-01-18T17:35:29Z

You can use the ./maintainers/patches script to deal with the tock and libtock-rs patches. Running the command without argument explains how to use it, but the main idea is to use apply to get one commit per patch and a clean state, then use save once the commits have been modified (including adding new commits) to update the patches.

Thanks, will try do that. I originally had multiple patches but then just merged it one big file since some of the stuff commits in there revert some earlier changes since this has been a bit of an exploratory journey.

L0g4n · 2023-01-18T21:06:07Z

Quick question regarding the ./maintainers/patches script: After reading the help text it seems I can add new patches by submitting changes to the previous patches, and then adding commits which reference the previous patch files. What about potentially new patches in this case since this does not seem to be mentioned in the help text?

ia0 · 2023-01-19T09:58:38Z

After reading the help text it seems I can add new patches by submitting changes to the previous patches, and then adding commits which reference the previous patch files. What about potentially new patches in this case since this does not seem to be mentioned in the help text?

I'm not sure I understand the question, but I'll try another explanation which might help.

The logic of the script is to provide you a way to sync between the patches and the chain of commits of the submodule. The apply method synchronizes assuming the patches are the source of truth (i.e. it copies the patches to the commits). The save method does the opposite (i.e. it copies the commits to the patches). The order of the chain of commits is the alphabetical order of the patches. In particular, this means that if the commits are not ordered alphabetically, then save followed by apply is not a no-op but we reorder the commits.

Here are a few examples.

Patches are: 01-foo, 02-bar, 03-baz.
You apply the patches and get the following commits: 01-foo, 02-bar, 03-baz.
Let's say you add a commit 04-new.
You save the commits and get the following patches: 01-foo, 02-bar, 03-baz, 04-new.

Same initial patches as above and already applied.
You `git rebase -i` to modify 02-bar to 02-modified-bar.
You save and get: 01-foo, 02-modified-bar, 03-baz.

Same initial patches as above and already applied.
You `git rebase -i` to delete 02-bar.
You save and get: 01-foo, 03-baz.

Same initial patches as above and already applied.
You `git rebase -i` to insert 02-new before 02-bar and rename 02-bar and 03-baz to increase their number.
You save and get: 01-foo, 02-new, 03-bar, 04-baz.

Note that you can combine any such operations. You just want the chain of commits to be alphabetically ordered and represent the set of patches you want. You can use any git operations you want to modify the chain of commits (including inserting, deleting, modifying, splitting, merging, reordering, renaming commits).

L0g4n · 2023-01-19T12:57:40Z

@ia0

The logic of the script is to provide you a way to sync between the patches and the chain of commits of the submodule. The apply method synchronizes assuming the patches are the source of truth (i.e. it copies the patches to the commits). The save method does the opposite (i.e. it copies the commits to the patches). The order of the chain of commits is the alphabetical order of the patches. In particular, this means that if the commits are not ordered alphabetically, then save followed by apply is not a no-op but we reorder the commits

Alright, however, I did not start with the patches as the source of truth, but rather with the tock submodule and then added my commits into the submodule. Can I simply edit the files, add the commits, rebase, and then call save? Or do I have to start with the patches as a source-of-truth? This is problematic since the patches wont properly apply with the tock submodule updated to 2.1.

P.S: I changed this PR into a draft to avoid getting a load of emails because of failed CI.

ia0 · 2023-01-19T13:12:28Z

Or do I have to start with the patches as a source-of-truth?

No you don't need to start with the patches as source-of-truth. You can just save at any time and it will overwrite the patches with whatever chain of commits you have in the submodules. However, it's important that the submodule commit is up-to-date (which is the case in this PR) because that's what defines the beginning of the chain of commits.
It's also better if your chain of commits is linear (no merge) and in alphabetical order (only the short description, i.e. first line).

Can I simply edit the files, add the commits, rebase, and then call save?

Why do you need to rebase? I'm assuming you start from commit 55c73f1c9f3c0966d975458a9564ae430a5919af in tock, edit files until it works, commit changes as you go, and call save once all changes are committed.

P.S: I changed this PR into a draft to avoid getting a load of emails because of failed CI.

Sounds good.

coveralls · 2023-01-21T21:47:24Z

Coverage: 87.814% (-0.2%) from 88.057% when pulling f7494a2 on L0g4n:add_tock_v2_support into 0db393b on google:develop.

ia0

I didn't have time to review everything, but went over most of it (at least quickly). I think overall it looks to go in the right direction. I'm wondering though if we need the code to be generic over those libtock_platform traits or if we can define the actual types somewhere (gated by appropriate cfg) and then use those types directly. Because it doesn't look like we need to instantiate differently in the same binary. This would remove a bit of boilerplate.

ia0 · 2023-01-27T12:42:46Z

.gitignore

@@ -14,3 +14,6 @@ target/
 /reproducible/elf2tab.txt
 /reproducible/reproduced.tar
 __pycache__
+
+# ctags
+**/tags*


Where do those come from? You're not using rust-analyzer? Or do we have some C files?

Ah, these come from my neovim tooling, more specifically gutentags. I do use rust-analyzer, this artefacts are automatically generated when I open sth. nvim. Can probably be removed if annoying.

There should be a way to not generate them. I'm not a partisan of having non-common tooling configuration in the repo, but if others believe that's fine, then fine by me.

Regardless I would just use tags*, the **/ prefix is redundant. Could you provide example filenames to get an idea of the sort of suffixes that gutentags create?

ia0 · 2023-01-27T12:50:25Z

Cargo.toml


 [profile.release]
 panic = "abort"
-lto = true # Link Time Optimization usually reduces size of binaries and static libraries
+lto = true        # Link Time Optimization usually reduces size of binaries and static libraries


Out of curiosity, what editor do you use? We currently don't enforce any formatting on TOML files, but maybe we should if there are easy solutions. (I just checked and looks like taplo would be an LSP server.)

For rust I typically use vscode with rust analyzer. Sometimes though for quick editing I also use neovim.

Do you know which one (VSCode or neovim) formats TOML files by trying to "align" line-suffix comments?

I think this one is caused by the VSCode Plugin "better-toml": https://github.com/bungcip/better-toml
Although I see that is archived now ^^

boards/nordic/nrf52840_dongle_opensk/src/main.rs

examples/erase_storage.rs

examples/store_latency.rs

libraries/persistent_store/src/storage.rs

libraries/rng256/src/lib.rs

ia0 · 2023-01-27T14:21:19Z

patches/tock/0004-vendor-hid.patch

@@ -155,163 +153,3 @@ index f7899d8c5..6956523c6 100644
                     } else {
                         hil::usb::CtrlSetupResult::ErrGeneric
                     }
-diff --git a/capsules/src/usb/usbc_ctap_hid.rs b/capsules/src/usb/usbc_ctap_hid.rs


I guess this is removed because work in progress.

L0g4n · 2023-01-30T12:35:11Z

Thanks, I added some comments to your remarks, in particular about the platform impl stuff.

Edit: BTW, ignore the "ready for review" thing for now, I just changed it from draft to normal PR again as it still informed about failing CI ;)

kaczmarczyck

Thanks @ia0 for the first review.

Do you have a general opinion on USB? Does Tock v2 have better support and we should follow more closely, rather than maintaining our own stack? Did you already get something to work?

Next steps for you are probably to finish the missing drivers?

I haven't looked into the submodules. But first of all thanks for this big contribution!

boards/nordic/nrf52840dk_opensk/src/main.rs

kaczmarczyck · 2023-02-07T04:53:55Z

boards/nordic/nrf52840dk_opensk/src/main.rs


 /// Dummy buffer that causes the linker to reserve enough space for the stack.
 #[no_mangle]
 #[link_section = ".stack_buffer"]
-pub static mut STACK_MEMORY: [u8; 0x1000] = [0; 0x1000];
+pub static mut STACK_MEMORY: [u8; 0x2000] = [0; 0x2000];


FYI: We had to do this sometimes in v1 already. Out of curiosity, did you observe memory problems often before you made this change? I noticed you made comments about stack sizes elsewhere, so I was wondering if you can share some of your gained wisdom :)

Nope, this is simply here because it was done in v1. I did no fine tuning with the memory limits, priority was first to get it to work :)

kaczmarczyck · 2023-02-07T04:59:51Z

deploy.py

 }

 # The following value must match the one used in the file
 # `src/entry_point.rs`
-APP_HEAP_SIZE = 90000
+APP_HEAP_SIZE = 90_000


FYI: Not sure if this value is still accurately reflecting how much we should use.

I see. I wondered how you came up with this specific heap limit, do you have some measurements with the certified versions that give a rough estimate how much heap is needed for allocation? Because this seems to be a rather large value.

examples/console_test.rs

patches/libtock-rs/0001-alloc-init-feature.patch

kaczmarczyck · 2023-02-07T05:26:20Z

src/ctap/main_hid.rs

@@ -30,6 +30,12 @@ pub struct MainHid {
    wink_permission: TimedPermission,
 }

+impl Default for MainHid {


Where is this used?

In here, nowhere. This was added (as countless other times) to satisfy the clippy lints.

We can move the implementation of new to default then. And call ::default() instead of ::new().

kaczmarczyck · 2023-02-07T05:33:35Z

third_party/lang-items/src/panic_handler.rs

    }
-
-    util::flash_all_leds();
+    #[cfg(not(feature = "panic_console"))]


Can we always flash the LEDs?

Problem is, when we have the panic_console active, both the TockSyscalls::exit_terminate and the flash_all_leds both never return, as they have a return type of !. This will spit out warnings by the rust compiler.

Ah right, if the above never returns, no point in having code after.

L0g4n · 2023-02-07T11:28:12Z

Do you have a general opinion on USB? Does Tock v2 have better support and we should follow more closely, rather than maintaining our own stack? Did you already get something to work?

Eh, I don't really have an opinion on this. TBH, I did not ready anything newsworthy in the Tock v2 release notes that mention something in regard to USB. Do you mean with better support the upstream USB_CTAP capsule? The code is a lot shorter, and seems a bit more elegant (as they seem not to have handle as much conditionals), fewer limitations (more than one client for example, althought this is not really relevant), but I don't know for certain how it compares in detail.

Next steps for you are probably to finish the missing drivers?

I planned to work in first all the relevant review comments, and check for review after that. As you are talking about drivers in plural, what else is still missing besides crp?

kaczmarczyck · 2023-02-08T13:22:50Z

Yours seems to work, so we don't have to bother with USB for now it seems. The question is orthogonal then, but I was curious.

I played around with the firmware a bit, and it seems to work. For RTT (as expected), I had to flip the bool in third_party/tock/boards/nordic/nrf52840dk_opensk/src/main.rs to see output. So no plural, only crp is missing :)

More comments:

I looked at binary sizes, and both kernel and app are a few kB smaller with your changes. The decrease for the app can be explained by the new compiler.
Rust compiler version nightly-2023-02-01 also works. We don't need it, but good to know nothing broke in between.

Which means I am happy. Also I didn't see any substantial or blocking comment. We can go ahead and think about how to submit.

This includes new patches for the TockOS 2.1-dev base and the libtock-rs 2.0 (WIP) submodules, with the addition of the new pinned commits for both submodules.

This has still some very rough edges, hence, this is considered a WIP commit. Next to the missing `firmware_protect` driver for TockOs (for disabling JTAG support and preventing dumping of the firmware), this includes non-working examples. Additionally, it is important to note that OpenSK can not be built anymore on x86 host machines, since `libtock_runtime` (part of libtock-rs 2.0 WIP) is only running on ARM and riscv hosts. Hence a normal invocation of `cargo build` or `cargo check` on your average dev machine will fail, but you can still cross-compile for ARM or RISCV and/or run `cargo check --features std` to see if the code compiles fine, but you **need** to apply the *alloc_init* patch for the libtock-rs submodule before running the build commands. Change submodules back to upstream

L0g4n · 2023-02-26T21:15:09Z

Rust compiler version nightly-2023-02-01 also works. We don't need it, but good to know nothing broke in between.

In the last commits I did some work and rebased the tock patches on top of the stable tock 2.1.1 release (despite released later than previous state on master, we're not actually now on an earlier state of the tock repo); I also updated the nightly in this session to the aforementioned one.

I did not have the chance to test it on real hardware though yet, so if you got time you can do that to see if there were hopefully no regressions in Tock 😀. As you might have noticed (or not), I am currently not so active working on this PR, as my thesis deadline in Mid-April approaches, I'm currently kinda focusing on getting the OpenTitan port to work (mostly NVMC driver in the flash_ctrl for persistent storage, and a slight variation of the button driver for using the user DIP switches as buttons for the user presence).

kaczmarczyck · 2023-02-27T13:21:40Z

Tested on the development kit, and still works. Thanks for the update on your available time.

kaczmarczyck · 2023-03-09T11:36:02Z

We merged #602 to move all CTAP logic into its own library. You mostly shouldn't need to touch this part of the code anymore. #603 fixes most of the lints in src/ctap/, though some of your changes there are missing as clippy hasn't been complaining for me. Otherwise, all you do in ctap/ is add UserPresenceError::ButtonListenerFailed, which you could just call Error to make it generally useful, and that should be it!

So when you rebase, all other changes should be in third_party/, src/env/tock/ or boards/, respectively. I hope this helps!

kaczmarczyck · 2023-04-20T14:18:45Z

Hi, I hope your thesis is going well? Please let me know if you want to continue to land this PR afterwards.

On CRP: I realized that there are different variants of the nrf52840 with different versions of CRP. We consider removing CRP support until we have a working implementation for the latest chip. I wanted to share since that was the last piece you were missing, and we can agree to ignore it.

L0g4n · 2023-04-20T15:51:02Z

Hey there,

thanks for asking: Yes, I submitted my thesis this week. I did not reach all goals I originally set for myself considering the time available (mostly having to do with OpenTitan blocking things), but overall I'm still positive about it 😀

On CRP: I realized that there are different variants of the nrf52840 with different versions of CRP. We consider removing CRP support until we have a working implementation for the latest chip. I wanted to share since that was the last piece you were missing, and we can agree to ignore it.

About the question: Yes, I still want to land this PR, since CRP is not anymore required, what is still missing in this PR besides the rebase work with the CTAP library?

Introduced in google#580 The conversion to libtock's ErrorCode has to happen outside of the library.

kaczmarczyck · 2023-04-20T16:21:00Z

I doubled checked, and this should be it. I expect that your rebase does not touch libraries/opensk (which corresponds to src/ctap, src/api and src/env/test here), and you can discard all your changes in these directories when you rebase. The only difference in API you need is addressed in #616 . If you feel like our new API and Env are not good enough, please let me know! The new library (without Tock) is tested on nightly.

Concerning the TockEnv function:
pub fn lock_firmware_protection(&mut self) -> bool;
Just let it return false, and I'll deal with the command that calls it.

Thanks for your help!

Introduced in #580 The conversion to libtock's ErrorCode has to happen outside of the library.

L0g4n · 2023-04-21T12:01:48Z

You know, I think it might be better if you finish this PR off. That's quite a lot of steps for rebasing (n = 44 and quite some merge conflicts), and I'm not really familiar with all the code changes in the background that you did (removed rng256, crypto changes, ...) and don't want to mess things up, plus it has been a while since I actively worked on this code.

And to be honest, fixing all the merge conflicts is not something I like to do for fun :)

zhalvorsen · 2023-04-21T15:31:35Z

src/env/tock/storage.rs

-fn get_info(nr: usize, arg: usize) -> StorageResult<usize> {
-    let code = syscalls::command(DRIVER_NUMBER, command_nr::GET_INFO, nr, arg);
-    code.map_err(|_| StorageError::CustomError)
+fn get_info<S: Syscalls>(nr: u32, arg: u32) -> StorageResult<u32> {


Should we put these syscall functions in a struct similar to those in third_party/libtock-drivers/src/?

pub trait Config: platform::allow_ro::Config + platform::subscribe::Config { } impl<T: platform::allow_ro::Config + platform::subscribe::Config> Config for T { } pub struct Storage<S: Syscalls + RawSyscalls, C: Config = DefaultConfig>(S, C); impl<S: Syscalls + RawSyscalls, C: Config> Storage<S, C> { pub fn get_info(nr: u32, arg: u32) -> StorageResult<u32> { let info = S::command(DRIVER_NUMBER, command_nr::GET_INFO, nr, arg) .to_result::<u32, ErrorCode>() .map_err(|_| StorageError::CustomError)?; Ok(info) } pub fn memop(nr: u32, arg: u32) -> StorageResult<u32> { let registers = unsafe { S::syscall2::<{ syscall_class::MEMOP }>([nr.into(), arg.into()]) }; let r0 = registers[0].as_u32(); let r1 = registers[1].as_u32(); // make sure r0 is the `success with u32` (129) return variant and then return the value in r1 as u32 // see: https://github.com/tock/tock/blob/master/doc/reference/trd104-syscalls.md#32-return-values match (r0, r1) { (129, r1) => Ok(r1), (_, _) => Err(StorageError::CustomError), } } pub fn write_slice( ptr: usize, value: &[u8], ) -> StorageResult<()> { share::scope(|allow_ro| { S::allow_ro::<C, DRIVER_NUMBER, { ro_allow_nr::WRITE_SLICE }>(allow_ro, value) .map_err(|_| StorageError::CustomError)?; block_command::<S, C>( DRIVER_NUMBER, command_nr::WRITE_SLICE, ptr as u32, value.len() as u32, ) }) } pub fn erase_page( ptr: usize, page_length: usize, ) -> StorageResult<()> { block_command::<S, C>( DRIVER_NUMBER, command_nr::ERASE_PAGE, ptr as u32, page_length as u32, ) } fn block_command( driver: u32, cmd: u32, arg1: u32, arg2: u32, ) -> StorageResult<()> { let called: Cell<Option<(u32,)>> = Cell::new(None); share::scope(|subscribe| { S::subscribe::<_, _, C, DRIVER_NUMBER, { subscribe_nr::DONE }>(subscribe, &called) .map_err(|_| StorageError::CustomError)?; S::command(driver, cmd, arg1, arg2) .to_result::<(), ErrorCode>() .map_err(|_| StorageError::CustomError)?; libtock_drivers::util::Util::<S>::yieldk_for(|| called.get().is_some()); if called.get().unwrap().0 == 0 { Ok(()) } else { Err(StorageError::CustomError) } }) } } unsafe fn read_slice(address: usize, length: usize) -> &'static [u8] { core::slice::from_raw_parts(address as *const u8, length) }

What's the benefit? The calls to these functions are not getting shorter, and the functions are private, so it's not really an API design advantage?

I was picturing we would end up putting this in third_party/libtock-drivers/src. Is there a reason it is kept here?

kaczmarczyck · 2023-04-24T20:05:40Z

You know, I think it might be better if you finish this PR off. That's quite a lot of steps for rebasing (n = 44 and quite some merge conflicts), and I'm not really familiar with all the code changes in the background that you did (removed rng256, crypto changes, ...) and don't want to mess things up, plus it has been a while since I actively worked on this code.

And to be honest, fixing all the merge conflicts is not something I like to do for fun :)

Understood. Thanks for all your work so far! I'm almost done with the rebased PR, just needs more testing now. It sits here until then, for the curious:
https://github.com/kaczmarczyck/OpenSK/tree/tock-v2

* Changes from #580 * fixes USB cancel panic * style fixes * Update src/env/tock/storage.rs Co-authored-by: Zach Halvorsen <[email protected]> --------- Co-authored-by: Zach Halvorsen <[email protected]>

kaczmarczyck · 2023-05-06T07:18:42Z

Merged in #620

L0g4n marked this pull request as draft January 19, 2023 11:48

ia0 reviewed Jan 27, 2023

View reviewed changes

L0g4n marked this pull request as ready for review January 30, 2023 19:34

kaczmarczyck reviewed Feb 7, 2023

View reviewed changes

L0g4n force-pushed the add_tock_v2_support branch from 9ffba32 to 70df9bb Compare February 10, 2023 18:19

L0g4n added 15 commits February 10, 2023 19:24

Replace patches for tock v2 support

4755f24

This includes new patches for the TockOS 2.1-dev base and the libtock-rs 2.0 (WIP) submodules, with the addition of the new pinned commits for both submodules.

Change nrf52 board definitions to tock 2.1 API

22bc36a

Add tock 2.1 patches w/ maintainer script

2349d48

Remove debug comments

2e453e5

Specify link script in cargo bloat to fix "debug symbols missing"

06a7460

Fix unused imports warning in allocator

c013bb8

Remove no_main attribute

b78a3de

Fix examples again libtock-rs 2.0 except nfc

7f040c2

Remove unused code

8a12196

Fix missing "start item" in main application

0b68b54

Add no_main attribute to examples

93d4b48

Fix warnings in examples

2dfa28a

Bump tock_registers to 0.7.0 to fix bootloader

0465c33

Fix clippy warnings

ae858e2

L0g4n added 2 commits February 24, 2023 23:10

Bump tock submodule to 2.1.1

0498afa

Adjust opensk boards for tock 2.1 changes

a9b6bbf

kaczmarczyck mentioned this pull request Mar 9, 2023

Fixes new clippy lints on the latest nightly #603

Merged

Increase stack size in crypto bench to fix panic

0c1d8e1

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 20, 2023

Adds a hardware failure state for user presence

bbf7b53

Introduced in google#580 The conversion to libtock's ErrorCode has to happen outside of the library.

kaczmarczyck mentioned this pull request Apr 20, 2023

Hardware failure state for user presence API #616

Merged

kaczmarczyck mentioned this pull request Apr 20, 2023

Improved pure-Rust cryptographic implementations #1

Open

kaczmarczyck added a commit that referenced this pull request Apr 21, 2023

Adds a hardware failure state for user presence (#616)

a88a1b2

Introduced in #580 The conversion to libtock's ErrorCode has to happen outside of the library.

zhalvorsen reviewed Apr 21, 2023

View reviewed changes

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 22, 2023

Changes from google#580

eb0d96b

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 22, 2023

Changes from google#580

7043fa8

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 22, 2023

Changes from google#580

ff98dec

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 24, 2023

Changes from google#580

dccabea

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 24, 2023

Changes from google#580

eac6b58

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 24, 2023

Changes from google#580

204652b

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 26, 2023

Changes from google#580

b8d78db

kaczmarczyck added a commit to kaczmarczyck/OpenSK that referenced this pull request Apr 26, 2023

Changes from google#580

6b1daf8

kaczmarczyck mentioned this pull request Apr 26, 2023

Tock V2 port - rebased and updated #620

Merged

kaczmarczyck closed this May 6, 2023

kaczmarczyck mentioned this pull request May 6, 2023

Interest in Tock 2.x Port? #579

Closed

Overview: Add tock v2 support #580

Overview: Add tock v2 support #580

Conversation

L0g4n commented Jan 17, 2023 • edited Loading

Important things to note

ia0 commented Jan 18, 2023

L0g4n commented Jan 18, 2023

L0g4n commented Jan 18, 2023 • edited Loading

ia0 commented Jan 19, 2023

L0g4n commented Jan 19, 2023 • edited Loading

ia0 commented Jan 19, 2023

coveralls commented Jan 21, 2023 • edited Loading

ia0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

L0g4n Jan 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

L0g4n Feb 3, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

L0g4n commented Jan 30, 2023 • edited Loading

kaczmarczyck left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

L0g4n commented Feb 7, 2023

kaczmarczyck commented Feb 8, 2023

L0g4n commented Feb 26, 2023 • edited Loading

kaczmarczyck commented Feb 27, 2023

kaczmarczyck commented Mar 9, 2023

kaczmarczyck commented Apr 20, 2023

L0g4n commented Apr 20, 2023 • edited Loading

kaczmarczyck commented Apr 20, 2023

L0g4n commented Apr 21, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaczmarczyck commented Apr 24, 2023

kaczmarczyck commented May 6, 2023

L0g4n commented Jan 17, 2023 •

edited

Loading

L0g4n commented Jan 18, 2023 •

edited

Loading

L0g4n commented Jan 19, 2023 •

edited

Loading

coveralls commented Jan 21, 2023 •

edited

Loading

L0g4n Jan 29, 2023 •

edited

Loading

L0g4n Feb 3, 2023 •

edited

Loading

L0g4n commented Jan 30, 2023 •

edited

Loading

L0g4n commented Feb 26, 2023 •

edited

Loading

L0g4n commented Apr 20, 2023 •

edited

Loading

L0g4n commented Apr 21, 2023 •

edited

Loading