Add simple Pinmux driver & check application. #212
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AlexJones0
force-pushed
the
pinmux_driver
branch
from
0b0de1c
to
5cf1682
Compare
This commit adds a simple Pinmux driver for Sonata. This is the version that will hopefuly be upstreamed to `cheriot-rtos` in the future, but with some minor changes so that it can run in a baremetal environment (it has a constructor that takes a bounded capability, rather than using the `MMIO_CAPABILITY` macro recommended to be used in the RTOS drivers). This driver is being added here for usage in checks, and so that it can live somewhere while there are potential software-breaking changes to the pinmux RTL that can be tested and fixed before the driver is upstreamed. Sonata's pinmux only allows certain block inputs/outputs to be muxed with certain pin inputs/outputs. For now, these combinations are only explicit in the documentation. Instead, the driver provides a way to check the valid range of indexes of selections for a given output pin or block input, but users of the driver must check the documentation to see which multiplexing options are available.
This commit adds a very basic pinmux sanity check for a CHERI execution environment. Note that this is just a check and not a test. The check simply logs to the UART, disables the UART0 pinmux to Serial 0 TX, logs again, and then re-enables the UART0 pinmux to Serial 0 TX, and logs one more time. If pinmux is working as expected, then when running the check application you can see the first and third messages but not the second. This is only intended to be a simple check, and not a test, and as such does not test any other blocks or any more complex muxing functionality.
AlexJones0
force-pushed
the
pinmux_driver
branch
from
5cf1682
to
535b6dc
Compare
I assumed that e.g. rph_g17 would map to the Raspberry Pi HAT header pin 17. This is not actually the case, there is no linear mapping. Instead was necessary to consult the pin description and schematic. This commit changes the enum output pin names to better reflect the actual pin labelling on the chip, and also directly labels each pin with its location on the board (e.g. P3.37, in the form header.number), so that users of the driver can easily identify which pin it describes. The existing hardware pin names are retained in the comment also, in case they might be useful.
AlexJones0
force-pushed
the
pinmux_driver
branch
from
535b6dc
to
05340b2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a simple Pinmux driver, and a check application to go along with it.
More detailed information can be found in commit messages.
The Pinmux driver is a slightly modified version of one that I've already been using to develop applications running on CHERIoT RTOS, with small modifications such that it takes a bounded capability as input rather than using the RTOS
MMIO_CAPABILITYmacro recommended to be used in the RTOS drivers. For now this driver requires users to read the documentation to see what is muxed where; it might be nice to extend this to enforce compile-time checks in the future but this was proving sufficiently complicated for now, and more emphasis is placed on testing the hardware.The intent is that the driver exists in
sonata-systemfor usage in check and CI test applications (similar to the USB driver), and so that it can live somewhere while there are potential software-breaking changes to the pinmux RTL that should be tested and fixed before the driver is upstreamed.The PR also adds a
pinmux_checkcheck application, which simply logs some messages to the console UART (UART0), whilst enabling and disabling the output of UART0 to ser0_tx via pinmux, such that some log messages are lost and not seen. A user can then read the messages to confirm that the pinmux appears to be working at some basic level. Testing with this basic check was sufficient to notice the RTL error in #209, for example.This can be tested by running the
pinmux_checkapplication directly and confirming that you get the expected result.Note that this currently is only confirmed to work on FPGA and not on Verilator, as pinmux is not working in the Verilator simulation environment at the time of writing.