- Devel - lists.tockos.org

New tock-registers design
by Johnathan Ryan Van Why May 20, 2026

May 20, 2026

Hi all, As previously mentioned, I'm working on a redesign of tock-registers which focuses on soundness and unit-testability. My implementation is at PR 11 <https://github.com/tock/tock-registers/pull/11>. At this point, I believe that the design is the correct path forward for tock-registers. I am looking for additional feedback on the design, so if you have not taken a look at it yet please do so. I'm hoping that at next week's core WG call, we can finalize the macro's name <https://github.com/tock/tock-registers/pull/11#discussion_r3275870143> and make the decision to move forward with the design (at which point I will break it up into smaller non-draft PRs). -Johnathan Van Why

1 0

Adding procedural macro dependencies to tock-registers
by Johnathan Ryan Van Why May 10, 2026

May 10, 2026

Hi all, I am currently working on a tock-registers redesign which: 1. Resolves the soundness issue <https://github.com/tock/tock-registers/issues/4> with register_structs. 2. Makes it relatively easy to unit-test driver implementations. Meeting these requirements without using procedural macros is not really feasible (the complexity of the required macro vastly exceeds the amount of complexity manageable in a macro_rules! macro). As a result, I plan to use procedural macros in tock-registers, and furthermore, those procedural macros will need to depend on the syn, quote, and proc-macro2 crates. I've opened PR 4814 <https://github.com/tock/tock/pull/4814> to extend Tock's external dependencies policy to allow for these macros. Please take a look at it and provide your input. Feedback has already resulted in one change: my tock-registers prototype now supports a build mode where macro expansion is performed up-front, allowing the procedural macros to be omitted from the final build. For reference, my current prototype for the new tock-registers is at tock-registers PR 11 <https://github.com/tock/tock-registers/pull/11>. Feel free to take a look at that and provide feedback on it as well! Thank you, Johnathan Van Why

1 0

Request for Guidance on Userland Startup Issue in Custom OS
by Mohammad Muzamil April 21, 2026

April 21, 2026

Dear Tock OS Team, I hope you are doing well. My name is Mohammad Muzamil, and I am currently working on a small operating system project called Qunix. GitHub repository: https://github.com/MohammadMuzamil23/Qunix-Operating-System/ I am currently facing an issue where the system boots successfully, but the userland does not start. I have been trying to debug the kernel-to-userland transition, but I am currently stuck and unable to identify the root cause. Since I am studying embedded and systems-level OS design, I have been learning from the architecture and security model of Tock OS, and it has been very helpful for understanding safe isolation and user-space execution. If possible, I would greatly appreciate any guidance on: Common causes of userland failing to start in embedded OS designs Debugging approaches for kernel → user space transition Or any design patterns that help ensure reliable userland execution Even a small pointer would be extremely helpful and would guide me in the right direction. Thank you very much for your time and for your work on secure embedded operating systems. Best regards, Mohammad Muzamil

2 1

Re: Request for Guidance on Userland Startup Issue in Custom OS
by Branden Ghena April 13, 2026

April 13, 2026

Hi Mohammad, Unfortunately, this is still a pretty big, vague question. It's not clear what "userspace does not start" means in the context of your OS. If you want to look at Tock, which I'm not clear is long-term useful for a Unix-like OS, you could take a look at our code for 32-bit x86 that switches to userspace: https://github.com/tock/tock/blob/master/arch/x86/src/boundary/switch_to_us… The hard part is not normally switching to userspace once, it's reliably switching back and forth between kernel and userspace, while making progress on both that's challenging. You'll note that most of our assembly there is 1) saving the kernel state and 2) restoring the userspace state. The userspace state is defined here: https://github.com/tock/tock/blob/master/arch/x86/src/boundary/context.rs#L… To start with, I'd recommend focusing on a one-way transition, from kernel to userspace. If you can get your code to run at all, that's a victory. Then you can work on returning from userspace. As for debugging, honestly using GDB to step through assembly is quite valuable. It might have a hard time following the transition, but being able to see how memory and registers are set up and manipulated is pretty useful. Good luck! Branden Ghena TockOS On Sun, Apr 12, 2026 at 1:28 PM Mohammad Muzamil via Devel < devel(a)lists.tockos.org> wrote: > Dear Tock OS Team, > I hope you are doing well. My name is Mohammad Muzamil, and I am currently > working on a small operating system project called Qunix. > GitHub repository: > > https://github.com/MohammadMuzamil23/Qunix-Operating-System/ > <https://urldefense.com/v3/__https://github.com/MohammadMuzamil23/Qunix-Oper…> > > I am currently facing an issue where the system boots successfully, but > the userland does not start. I have been trying to debug the > kernel-to-userland transition, but I am currently stuck and unable to > identify the root cause. > Since I am studying embedded and systems-level OS design, I have been > learning from the architecture and security model of Tock OS, and it has > been very helpful for understanding safe isolation and user-space execution. > If possible, I would greatly appreciate any guidance on: > Common causes of userland failing to start in embedded OS designs > Debugging approaches for kernel → user space transition > Or any design patterns that help ensure reliable userland execution > Even a small pointer would be extremely helpful and would guide me in the > right direction. > Thank you very much for your time and for your work on secure embedded > operating systems. > Best regards, > Mohammad Muzamil >

1 0

Threat model appendix: use case description
by Johnathan Ryan Van Why Feb. 17, 2026

Feb. 17, 2026

Hi all, I want to call attention to a threat model PR I opened last month: Threat model appendix: use case description <https://github.com/tock/book/pull/81>. It documents a few different use cases for Tock with varying security requirements and describes how Tock can be configured to satisfy each use case. To my knowledge, this is the first concrete description of how application identifiers and short IDs should be generated in practice. If you are interested or involved in Tock's application ID infrastructure (or any subsystem that may need to use application IDs), please take a look. -Johnathan

1 0

Re: Support tockloader for STM32L4
by Branden Ghena Jan. 14, 2026

Jan. 14, 2026

If you want to install applications over UART, you'll need some kind of system for receiving those bytes and writing them to memory. That's usually the tock-bootloader. Rarely, some systems have a hardware bootloader system capable of that. The tock-bootloader repo is not obsolete. It's just been quite stable for a while now, so it hasn't needed updates. Alternatively, many platforms Tock supports have USB->JTAG support. This doesn't require any software like a bootloader, but it does require hardware to support it, usually in the form of an additional chip on a board. That separate chip can be an entirely separate Microcontroller running software like DAPLink, which is how the Microbit v2 works, or some other hardware JTAG converter. JTAG support is preferred over bootloaders when available, since it doesn't require any additional software running on the actual microcontroller. Thanks, Branden Ghena Northwestern University On Tue, Jan 13, 2026 at 6:26 AM Kamil Duljas via Devel < devel(a)lists.tockos.org> wrote: > Thanks a lot! Could you please explain something to me? I think I’m > missing an important piece. > As far as I understand, tockloader allows installing apps and > communicating over UART, etc. > But to install applications, do I also need to implement a bootloader? > Is the tock-bootloader repository obsolete? If so, what is the current > recommended approach? > > best, > Kamil Duljas > > pon., 12 sty 2026, 17:27 użytkownik Tyler Potyondy <potyondyt(a)gmail.com> > napisał: > >> I recently added tockloader support for the WL5xx board family. It is >> still a work in progress and has a few hacky fixes I need to cleanup, but >> here's my branch in case it helps you for adding L4 tockloader support: >> https://github.com/tyler-potyondy/tockloader/commits/ents-board-config/ >> <https://urldefense.com/v3/__https://github.com/tyler-potyondy/tockloader/co…> >> >> -Tyler Potyondy >> >> On Mon, Jan 12, 2026 at 7:31 AM Branden Ghena via Devel < >> devel(a)lists.tockos.org> wrote: >> >>> Sure! Go ahead and make a PR to Tockloader whenever. >>> >>> And thanks for the contributions! We will get to reviewing them as soon >>> as we can. >>> >>> Thanks, >>> Branden Ghena >>> Northwestern University >>> >>> >>> On Mon, Jan 12, 2026 at 1:52 AM Kamil Duljas via Devel < >>> devel(a)lists.tockos.org> wrote: >>> >>>> Hi, >>>> My PR is waiting for review https://github.com/tock/tock/pull/4672 >>>> <https://urldefense.com/v3/__https://github.com/tock/tock/pull/4672__;!!Dq0X…> >>>> >>>> but I'm wondering if I can add support in tockloader parallelly. A code >>>> should be similar to F4 boards but it should be separated because OpenOCD >>>> defines his own cfg file for L4 boards. >>>> >>>> -- >>>> Best, >>>> Kamil Duljas >>>> >>> _______________________________________________ >>> Devel mailing list -- devel(a)lists.tockos.org >>> To unsubscribe send an email to devel-leave(a)lists.tockos.org >>> >>

1 0

Re: Support tockloader for STM32L4
by Branden Ghena Jan. 13, 2026

Jan. 13, 2026

Sure! Go ahead and make a PR to Tockloader whenever. And thanks for the contributions! We will get to reviewing them as soon as we can. Thanks, Branden Ghena Northwestern University On Mon, Jan 12, 2026 at 1:52 AM Kamil Duljas via Devel < devel(a)lists.tockos.org> wrote: > Hi, > My PR is waiting for review https://github.com/tock/tock/pull/4672 > <https://urldefense.com/v3/__https://github.com/tock/tock/pull/4672__;!!Dq0X…> > > but I'm wondering if I can add support in tockloader parallelly. A code > should be similar to F4 boards but it should be separated because OpenOCD > defines his own cfg file for L4 boards. > > -- > Best, > Kamil Duljas >

3 2

The main direction of development STM32
by Kamil Duljas Jan. 12, 2026

Jan. 12, 2026

Hi, As a Rust enthusiast, I wanted to gain more experience by adding support for an STM32L4 board. It’s quite a popular board in Poland, with many tutorials on electronics blogs. At the same time, I’m wondering about the next steps for STM32 support in general. It’s a very popular vendor, and the wide range of boards definitely makes it easier to get started with Tock OS. Do you have any roadmap for STM32 boards or plans for supporting other platforms? Best regards, Kamil Duljas

2 1

Support tockloader for STM32L4
by Kamil Duljas Jan. 12, 2026

Jan. 12, 2026

Hi, My PR is waiting for review https://github.com/tock/tock/pull/4672 but I'm wondering if I can add support in tockloader parallelly. A code should be similar to F4 boards but it should be separated because OpenOCD defines his own cfg file for L4 boards. -- Best, Kamil Duljas

1 0

Re: Porting Tock OS to STM32 (L476 / F756)
by Branden Ghena Nov. 24, 2025

Nov. 24, 2025

HI Kamil, While you're welcome to use DMA, it's not required for an initial port of a board. Often DMA is a later addition once the proof of concept works and a more-performant system is desired. Using interrupts for the UART would be totally fine. Thanks, Branden Ghena Northwestern University On Mon, Nov 10, 2025 at 6:06 AM Kamil Duljas via Devel < devel(a)lists.tockos.org> wrote: > Hi, regarding the port to the STM32L476RG — work in progress :) > I’m wondering about UART transmission. I noticed that some boards (e.g. > Nucleo, Discovery) use interrupts, > while others use DMA as well. Should I use UART with DMA, or is DMA > optional at this stage? > > Kamil > > pon., 3 lis 2025 o 16:10 Leon Schuermann <leon(a)is.currently.online> > napisał(a): > >> I'm excited seeing the progress made on this port! >> >> Kamil Duljas via Devel <devel(a)lists.tockos.org> writes: >> > I noticed that GPIO code for F3 F4 and L4 is 80-90% the same. maybe we >> > could extract it as a common part like stm32x ? I guess it could be >> > done for many pheripherials. >> >> Yes! In general, avoiding such code duplication is desirable, and there >> should be plenty of existing examples in the `chips/` folder, like >> `nrf5x` or `stmf4xx`. >> >> However, Tock has some particular (and somewhat implicit) conventions >> when it comes to code-sharing for multiple targets. For instance, we >> generally discourage conditional compilation by means of Cargo features >> (`#[cfg(...)]`) in our code, as that makes code harder to test. >> >> For a new target, I think it could be good to first get a chip and board >> crate merged (which perhaps duplicates some code that is not completely >> identical and thus trivially sharable between chips), and then split out >> that common infrastructure in a follow-up PR. This way you won't risk >> de-railing the PR to add the board over discussions on how to organize >> that shared infrastructure. >> >> -Leon >> > > > -- > Pozdrawiam, > Kamil Duljas >

2 1