- Devel - lists.tockos.org

Re: Porting Tock OS to STM32 (L476 / F756)
by Kamil Duljas Nov. 3, 2025

Nov. 3, 2025

Hi, while porting stm32L476 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. niedz., 26 paź 2025 o 18:56 Kamil Duljas <dudo1990(a)gmail.com> napisał(a): > Thank's! I guess STM32L4 series are widely available :) It's newer than > F4. It would be a pleasure to maintain the board :). I will be back with > basic support :) > > niedz., 26 paź 2025 o 17:43 Amit Levy <amit(a)amitlevy.com> napisał(a): > >> That's great! >> >> It's unfortunately a bit buried, but there the porting guide suggests >> what a minimal upstream board should support: < >> https://book.tockos.org/development/porting#adding-a-platform-to-tock-repos… >> > >> >> >> 1. The hardware must be widely available. Generally that means the >> hardware platform can be purchased online. >> 2. The port of Tock to the platform must include at least: >> - Console support so that debug!() and printf() work. >> - Timer support. >> - GPIO support with interrupt functionality. >> 3. The contributor must be willing to maintain the platform, at least >> initially, and help test the platform for future releases. >> >> >> In other words, the blink and hello world apps should work. >> >> GPIO, RCC and UART should be sufficient for this. >> >> Having said that, there is no harm to initiating a draft pull request >> _or_ sharing an external repo with the port at whatever stage you have if >> it would be useful to get a gut check that the style and/or implementation >> details are on the right path. >> >> >> On October 26, 2025 8:46:05 AM PDT, Kamil Duljas <dudo1990(a)gmail.com> >> wrote: >> >>> Thank you for all replies. I ran Tock os on L476 :D but only minimal >>> stuff to blinking Led. I'm wondering what should be done before first >>> official pull request? Full gpio, RCC, UART? >>> >>> Greetings >>> Kamil Duljas >>> >>> pon., 20 paź 2025, 19:30 użytkownik Patrick Pannuto <ppannuto(a)ucsd.edu> >>> napisał: >>> >>>> +Tyler Potyondy <tpotyondy(a)ucsd.edu> and a few other folks are most of >>>> the way through a port to the STM32WLE5xx family, which may share some more >>>> with the STM32L than the existing STM32F upstream as well >>>> >>>> On Sat, Oct 18, 2025 at 5:51 AM Amit Levy via Devel < >>>> devel(a)lists.tockos.org> wrote: >>>> >>>>> Hi and welcome! >>>>> >>>>> I don't see any obstacles. The STM32L476 is a Cortex-M4, of which there >>>>> are many examples upstream, and the STM32F756 is a Cortex-M7 for which >>>>> there is support (albeit only one example upstream, so there is of >>>>> course a slightly higher likelihood of kinds to iron out). >>>>> >>>>> Since both are STM chips, I'd expect much of their peripherals to be >>>>> shared with or at least very similar to some of the STM32 chips for >>>>> which there are upstream ports. >>>>> >>>>> Keep posted and please feel free to ask questions or for help or if you >>>>> run into issues! >>>>> >>>>> -Amit >>>>> >>>>> Kamil Duljas via Devel <devel(a)lists.tockos.org> writes: >>>>> >>>>> > Hi, >>>>> > >>>>> > I'd like to port Tock OS to an STM32 microcontroller - either the >>>>> STM32L476 >>>>> > or STM32F756. >>>>> > >>>>> > Are there any known technical obstacles or limitations that would >>>>> make this >>>>> > difficult? >>>>> > >>>>> > Best regards, >>>>> > Pozdrawiam, >>>>> > Kamil Duljas >>>>> > _______________________________________________ >>>>> > Devel mailing list -- devel(a)lists.tockos.org >>>>> > To unsubscribe send an email to devel-leave(a)lists.tockos.org >>>>> _______________________________________________ >>>>> Devel mailing list -- devel(a)lists.tockos.org >>>>> To unsubscribe send an email to devel-leave(a)lists.tockos.org >>>>> >>>> > > -- > Pozdrawiam, > Kamil Duljas > -- Pozdrawiam, Kamil Duljas

2 1

Porting Tock OS to STM32 (L476 / F756)
by Kamil Duljas Oct. 26, 2025

Oct. 26, 2025

Hi, I'd like to port Tock OS to an STM32 microcontroller - either the STM32L476 or STM32F756. Are there any known technical obstacles or limitations that would make this difficult? Best regards, Pozdrawiam, Kamil Duljas

3 4

TockWorld will be at Microsoft after RustConf
by Amit Levy July 14, 2025

July 14, 2025

It's official! TockWorld will be hosted at Microsoft in Redmond, WA, just a stone's throw from RustConf in downtown Seattle on September 5th. The specific schedule is still TBD, but most of the speakers and their talks are listed: https://world.tockos.org/tockworld8/ Registeration will open soon, so sign up to be notified: https://world.tockos.org/tockworld8/register

1 0

Call for interest in MMU and/or paging
by Amit Levy June 20, 2025

June 20, 2025

Please respond if you are currently working on, or otherwise have an interest or stake in support for MMU-based platforms in Tock and paging support in particular. There are a couple parallel efforts underway, all of which would require careful consideration to achieve successfully alongside MPU-based protection. You can respond only to me (amit(a)amitlevy.com) but better to the list. For example, why you're interested (e.g. you have or are planning support for a platform that has an MMU, or there are specific features you'd hope to get from paging) and whether and what efforts you have underway. I will use this to ensure people are kept in the loop and included in discussions. Thanks! Amit

3 2

Tock Open Office Hours, Thurs 12pm Pacific
by Amit Levy June 17, 2025

June 17, 2025

Hi all, I (and perhaps @lschuermann) will be hosting the first attempt at an office hours open to developers, users, and other contributors this Thursday at noon pacific time. If you attended a weekly meeting before it became a Core WG meeting, this should be similar: a summary of what's happining in the ecosystem including a report from the Core WG meeting, as well as an open forum for questions, discussions, or comments from anyone joining. Since this is the first one, we'll keep it simple and only add in more involved moderation if it becomes necessary. Please see details and RSVP here: https://calendar.app.google/qRdfGQmZEdgjovN56 See you there! Amit

1 0

TockWorld Europe, August 11th-12th
by Amit Levy June 12, 2025

June 12, 2025

Hello all! The IP Workshop Association, in partnership with the Tock Foundation, OxidOS and Wyliodrin are hosting the first European edition at Sapientia University in Târgu Mureș, Romania. This will be a two-day event, with the first day dedicated to Tock related presentations. If you have worked with or contributed to Tock or a related project, we are very eager to hear about it! The second day is dedicated to Tock workshops and a Tock Developers Meeting. Among the subjects proposed are: Networking support, MMU and OTA Updates. While focused on the European Tock community, all are welcome! More details, and registration information available at https://world.tockos.org/europe See you there! Amit

1 0

VB: Kerneldebug with uart
by Patrik Svensson May 5, 2025

May 5, 2025

________________________________ Från: Patrik Svensson <patsv(a)outlook.com> Skickat: den 5 maj 2025 19:09 Till: Branden Ghena <branden(a)northwestern.edu> Ämne: Sv: [Tock Devel] Kerneldebug with uart Thanks, I was not aware of the #4416 so I have my own 2350 port from 2040. I will look into that and perhaps contribute some code if needed. Being new to tock I am not 100% familiar with the muxes, I try to use a hard UART1 to my openocd debugger. // Patrik ________________________________ Från: Branden Ghena <branden(a)northwestern.edu> Skickat: den 5 maj 2025 16:57 Till: Patrik Svensson <patsv(a)outlook.com> Kopia: devel(a)lists.tockos.org <devel(a)lists.tockos.org> Ämne: Re: [Tock Devel] Kerneldebug with uart Hi Patrik, Welcome to Tock! Kind of a silly question, but did you see the recent PR with code for the RPi Pico 2? https://github.com/tock/tock/pull/4416 (apologies if you were involved with this PR and I misunderstood) If not, that might solve some of your problems. Assuming that the code in #4416 does not just solve your problem, my hypothesis for you would be an issue with flushing or configuring the UART. When a panic occurs, the code in your board src/io.rs<http://io.rs/> gets called, which configures the UART and writes to it. If debug prints are appearing then, that implies to me that something about the panic writer actions is letting the UART finally work. A second idea though. Based on the code you wrote above, are you using serial-over-USB instead of a UART? (You called it a `cdc`, and USB CDC is serial-over-USB) If that's the case, you should double-check your configuration code compared to another board with a USB serial stack. The Nano33BLE would probably be a good example: https://github.com/tock/tock/blob/master/boards/nano33ble_rev2/src/main.rs Thanks, Branden Ghena Northwestern University On Mon, May 5, 2025 at 1:47 AM Patrik Svensson via Devel <devel(a)lists.tockos.org<mailto:devel@lists.tockos.org>> wrote: Hi, new developer here. Trying to get a Raspberry Pico2 (2350) card running, almost there. Need to check things by printing to UART from kernel. However cannot get the debug!,debug_verbose to come out unless I do a panic! then it will come out. I suspect that there is some flush needed or is there something to enable in the kernel? Snip from my main.rs<http://main.rs/> code for enabling uart: // UART // Create a shared UART channel for kernel debug. let uart_mux = components::console::UartMuxComponent::new(cdc, 115200) .finalize(components::uart_mux_component_static!()); // Uncomment this to use UART as an output let uart_mux2 = components::console::UartMuxComponent::new( &peripherals.uart0, 115200, ) .finalize(components::uart_mux_component_static!()); // Setup the console. let console = components::console::ConsoleComponent::new( board_kernel, capsules_core::console::DRIVER_NUM, uart_mux2, ) .finalize(components::console_component_static!()); // Create the debugger object that handles calls to `debug!()`. components::debug_writer::DebugWriterComponent::new(uart_mux2) .finalize(components::debug_writer_component_static!());

1 0

Re: Kerneldebug with uart
by Branden Ghena May 5, 2025

May 5, 2025

Hi Patrik, Welcome to Tock! Kind of a silly question, but did you see the recent PR with code for the RPi Pico 2? https://github.com/tock/tock/pull/4416 (apologies if you were involved with this PR and I misunderstood) If not, that might solve some of your problems. Assuming that the code in #4416 does not just solve your problem, my hypothesis for you would be an issue with flushing or configuring the UART. When a panic occurs, the code in your board src/io.rs gets called, which configures the UART and writes to it. If debug prints are appearing then, that implies to me that something about the panic writer actions is letting the UART finally work. A second idea though. Based on the code you wrote above, are you using serial-over-USB instead of a UART? (You called it a `cdc`, and USB CDC is serial-over-USB) If that's the case, you should double-check your configuration code compared to another board with a USB serial stack. The Nano33BLE would probably be a good example: https://github.com/tock/tock/blob/master/boards/nano33ble_rev2/src/main.rs Thanks, Branden Ghena Northwestern University On Mon, May 5, 2025 at 1:47 AM Patrik Svensson via Devel < devel(a)lists.tockos.org> wrote: > Hi, new developer here. > Trying to get a Raspberry Pico2 (2350) card running, almost there. > Need to check things by printing to UART from kernel. > However cannot get the debug!,debug_verbose to come out unless I do a > panic! then it will come out. > I suspect that there is some flush needed or is there something to enable > in the kernel? > > Snip from my main.rs code for enabling uart: > // UART > // Create a shared UART channel for kernel debug. > let uart_mux = components::console::UartMuxComponent::new(cdc, 115200) > .finalize(components::uart_mux_component_static!()); > > // Uncomment this to use UART as an output > let uart_mux2 = components::console::UartMuxComponent::new( > &peripherals.uart0, > 115200, > ) > .finalize(components::uart_mux_component_static!()); > > // Setup the console. > let console = components::console::ConsoleComponent::new( > board_kernel, > capsules_core::console::DRIVER_NUM, > uart_mux2, > ) > .finalize(components::console_component_static!()); > // Create the debugger object that handles calls to `debug!()`. > components::debug_writer::DebugWriterComponent::new(uart_mux2) > .finalize(components::debug_writer_component_static!()); >

1 0

Kerneldebug with uart
by Patrik Svensson May 4, 2025

May 4, 2025

Hi, new developer here. Trying to get a Raspberry Pico2 (2350) card running, almost there. Need to check things by printing to UART from kernel. However cannot get the debug!,debug_verbose to come out unless I do a panic! then it will come out. I suspect that there is some flush needed or is there something to enable in the kernel? Snip from my main.rs code for enabling uart: // UART // Create a shared UART channel for kernel debug. let uart_mux = components::console::UartMuxComponent::new(cdc, 115200) .finalize(components::uart_mux_component_static!()); // Uncomment this to use UART as an output let uart_mux2 = components::console::UartMuxComponent::new( &peripherals.uart0, 115200, ) .finalize(components::uart_mux_component_static!()); // Setup the console. let console = components::console::ConsoleComponent::new( board_kernel, capsules_core::console::DRIVER_NUM, uart_mux2, ) .finalize(components::console_component_static!()); // Create the debugger object that handles calls to `debug!()`. components::debug_writer::DebugWriterComponent::new(uart_mux2) .finalize(components::debug_writer_component_static!());

1 0

Attn: GH #4418: RFC: Policy on creation of capabilities in components
by Patrick Pannuto April 30, 2025

April 30, 2025

There is a newly opened RFC on GitHub, https://github.com/tock/tock/issues/4418, based on a discussion that came up during the core team call today. This RFC may be relevant to a wider audience than is able to regularly track GitHub issues, so I'm sending a pointer to it here. If you have comments or feedback, please leave them on the GitHub issue. -Pat

1 0