- Devel - lists.tockos.org

Re: Need Help regarding libtock-rs on STM32 Nucleo F429zi

by Brad Campbell

Hi Jahn, It sounds like you did all of the steps correctly, and it's promising that the libtock-c app works. Do you see the "Initialization complete. Entering main loop" message with `tockloader listen` or similar serial terminal? https://github.com/tock/tock/blob/740a3897a00ed4fa3020a554abeb51fb5869ade2/… The process console is enabled, so you should be able to interact with the board via the serial terminal. Specifically, entering the "list" command should list the currently enabled processes. One challenge with using libtock-rs is that we do not have the same PIC support that we do on libtock-c. So, it's possible that the libtock-rs app is being compiled for a fixed address which does not line up with where the app is actually located on the board (either in flash or in RAM, or both). In that case, `tockloader list` would should the app as being installed, but the process console would not show the process as active because it cannot be loaded. It is also possible to enable the `debug_load_processes` config flag ( https://github.com/tock/tock/blob/master/kernel/src/config.rs#L92) to see more information when processes are loaded. If an address mismatch is the issue, the fix is to modify the addresses here ( https://github.com/tock/libtock-rs/blob/master/build_scripts/src/lib.rs#L19) to where the app is actually running (PR would be welcome!). If that isn't the issue, we can keep debugging. - Brad On Thu, Aug 22, 2024 at 10:04 AM Jahn Jantos via Devel < devel(a)lists.tockos.org> wrote: > Hello, > > I have been trying to use Tock OS on my STM32 Nucleo F429zi > Microcontroller, but so far I've only been able to flash the example > code from libtock-c and not the code from libtock-rs. > I tried it in Rust with compiling the blink example (I ran the command > "make nucleo_f429zi EXAMPLE=blink" in libtock-rs) and then compiled the > Board (under tock/boards/nucleo_f429zi I ran make, make install and then > make program) but the Rust example did not turn the LEDs on. > And I also found the following Issue on GitHub: > https://github.com/tock/tock/issues/2811 > Which is not about my Board, but made me realise that libtock-rs might > not be ready for use yet. > Furthermore in the Makefile under tock/boards/nucleo_f429zi within the > command make program that was listed in the ReadMe.md was also the path > to the c-hello example from libtock-c. > So what I am getting at is, is it possible to use the examples in > libtock-rs or do I need to write my examples in C to use Tock OS for my > board? > thanks in advance for your work. > > kind regards, > Jahn Jantos > > _______________________________________________ > Devel mailing list -- devel(a)lists.tockos.org > To unsubscribe send an email to devel-leave(a)lists.tockos.org >

Aug. 22, 2024

Need Help regarding libtock-rs on STM32 Nucleo F429zi

by Jahn Jantos

Hello, I have been trying to use Tock OS on my STM32 Nucleo F429zi Microcontroller, but so far I've only been able to flash the example code from libtock-c and not the code from libtock-rs. I tried it in Rust with compiling the blink example (I ran the command "make nucleo_f429zi EXAMPLE=blink" in libtock-rs) and then compiled the Board (under tock/boards/nucleo_f429zi I ran make, make install and then make program) but the Rust example did not turn the LEDs on. And I also found the following Issue on GitHub: https://github.com/tock/tock/issues/2811 Which is not about my Board, but made me realise that libtock-rs might not be ready for use yet. Furthermore in the Makefile under tock/boards/nucleo_f429zi within the command make program that was listed in the ReadMe.md was also the path to the c-hello example from libtock-c. So what I am getting at is, is it possible to use the examples in libtock-rs or do I need to write my examples in C to use Tock OS for my board? thanks in advance for your work. kind regards, Jahn Jantos

Aug. 22, 2024

Tock meeting agenda 2024-08-09

by Amit Levy

Meeting Link: https://meetings.dialpad.com/room/tock/1vnk9r3e1b Agenda - Updates - Outstanding, assigned, PRs - CHERI upstreaming preview - https://github.com/tock/tock/issues/4134 - https://github.com/tock/tock-cheri - https://github.com/tock/libtock-c-cheri - https://github.com/tock/libtock-rs-cheri - DMA'able grant preview

Aug. 9, 2024

Re: Call for meeting agenda items

by Ludovic Vanasse

+1

Aug. 9, 2024

Call for meeting agenda items

by Amit Levy

Please respond with agenda items and +1s for tomorrow's core call

Aug. 9, 2024

Tock meeting agenda 2024-08-02

by Amit Levy

Meeting Link: https://meetings.dialpad.com/room/tock/1vnk9r3e1b Agenda - Updates - Outstanding, assigned, PRs - OpenTitan working group status and trajectory

Aug. 2, 2024

Call for Tock meeting agenda items 08/02

by Amit Levy

Please respond with agenda items and +1s for tomorrow's core call - OpenTitan working group trajectory and plan

Aug. 1, 2024

Tock meeting agenda 2024-07-26

by Amit Levy

Meeting Link: https://meetings.dialpad.com/room/tock/1vnk9r3e1b Agenda - Updates - Outstanding, assigned, PRs - OpenTitan working group status and trajectory - Dynamic allocation in libtock-rs - https://lists.tockos.org/hyperkitty/list/devel@lists.tockos.org/message/QYQ…

July 26, 2024

Re: Call for Tock meeting agenda items 07/26

by Hudson Ayers

I would like to discuss options for dynamic allocation in libtock-rs. There are two basic approaches: 1. The approach used in the old libtock-rs: Allow apps to specify a heap size at compile time, reserve that much space for the heap using brk() while initializing the runtime, and then use an allocator that assumes a backing store of a fixed size (such as linked_list_allocator <https://crates.io/crates/linked_list_allocator>). 2. An approach similar to that originally suggested <https://github.com/tock/libtock-rs/pull/205#pullrequestreview-436914914> by Johnathan when the old libtock-rs allocator was first implemented: a heap that only takes memory from the kernel as needed, and return memory to the kernel when no longer needed. The idea is generally an allocator that works on a backing store it was given, but will grow the size of this contiguous backing store as needed. One advantage of this approach is that if an app wants to allocate a bunch of memory, then return it before calling any syscalls that lead to grant allocation, that app can use more memory than would otherwise be possible given the size of a grant allocation. This approach can also just be useful toward maximizing the memory available to the app -- rather than having to specify a constant heap size that is known to be smaller than (app memory - allocated grant size), the app can just use everything that is not taken by grants, and then allocations will start to fail once that point is reached. The second approach is more challenging to integrate with existing open source embedded Rust allocators, because in practice I have not found any that provide APIs for returning memory given to the allocator back to the kernel, without having to add an OS port to the allocator itself. IMO this approach seems more likely to require us to write our own allocator, or to modify an existing open source allocator with a port to Tock specifically. Interested to hear what others think. On Thu, Jul 25, 2024 at 5:15 PM Amit Levy via Devel <devel(a)lists.tockos.org> wrote: > Please respond with agenda items and +1s for tomorrow's core call > _______________________________________________ > Devel mailing list -- devel(a)lists.tockos.org > To unsubscribe send an email to devel-leave(a)lists.tockos.org >

July 26, 2024

Call for Tock meeting agenda items 07/26

by Amit Levy

Please respond with agenda items and +1s for tomorrow's core call

July 26, 2024