Add init() to the Chip trait
#4682
Conversation
This provides a standardized way for a board to run any chip-specific setup code at kernel boot.
Move the errata setup, vector table, and interrupt enable to functions, document safety, and call everything from the new init() trait function.
Since the chip knows the correct ThreadIdProvider, we can simplify board boot by putting deferred call init here.
brghena
left a comment
There was a problem hiding this comment.
Looking at this code, I feel like a chip init function should have always existed. That makes it feel like a pretty good change to me.
However, it feels a little strange to stuff deferred call initialization in there. Maybe there should be a kernel init function in addition to the chip init function?
Yeah, on one hand DeferredCall is a core-kernel-provided resource, on the other it is a chip-specific initialization. If we added a kernel init to kernel.rs it would be virtually a direct copy of what is in deferred_call, complete with the safe and unsafe versions and the ThreadIdProvider parameter. We can't add deferred call init to kernel::new or kernel::loop because the init must happen essentially first. By lumping it in with a chip init 1) users don't have to remember to do it, and 2) it will come first in main. |
| /// - Any architecture-specific setup | ||
| /// - Any errata fixes | ||
| /// - Any configuration needed for the chip to continue booting the kernel | ||
| fn init(); |
There was a problem hiding this comment.
Is there any way to write a check that would panic if this function was not called by the board?
There was a problem hiding this comment.
I'm not entirely sure, be we could probably enforce a return type that is required to call the kernel loop if we wanted.
Pull Request Overview
Tock has a very ad-hoc initialization convention. Every arch/chip/board has roughly created its own procedure, with any commonalities a byproduct of convention and copying rather than anything expressed in types. This tries to add some structure by adding an
init()function to theChiptrait. Boards can then all callChipHw::init()at the beginning of their main() to run all the necessary chip-level initialization.This came up in the deferred call initialization discussions. Since initializing single thread value requires knowing the ThreadIdProvider, moving the deferred call init to chips is both doable and avoids a potentially very annoying mistake in boards.
Testing Strategy
todo
TODO or Help Wanted
Thoughts?
Obviously this would need to be added to all chips.
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.