OpenTitan patches on 10.2.0 #322
Draft
Conversation
This file contains hidden or 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
These changes are specific to our fork and are either being dropped by open pull requests or will not be needed upstream. Co-authored-by: Emmanuel Blot <[email protected]> Co-authored-by: Loïc Lefort <[email protected]> Signed-off-by: James Wainwright <[email protected]>
The option is disabled by default. Signed-off-by: Emmanuel Blot <[email protected]>
Demangler code taken from GNU libiberty. Signed-off-by: Emmanuel Blot <[email protected]>
Signed-off-by: Emmanuel Blot <[email protected]>
This changes enables providing custom address translation engine. OpenTitan does not have an MMU, but support a custom virtual remapper. Signed-off-by: Emmanuel Blot <[email protected]>
Signed-off-by: Emmanuel Blot <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
Add the capability to maintain CPU in reset. The Resettable API has added a new way to manage reset, where resetting a device not only trigger a transient reset, but enable devices to be held in reset and manage a reset tree. This commit adds this resettable feature to CPUs, so they can be held in reset and released once other devices in the machine are released. The CPU reset is no longer a transient state but a stable state. The CPU reset state can be tracked with a new attribute: held_in_reset. This feature is useful to better emulate SoC like OpenTitan where the CPU is actively held in Reset while other devices complete their own initialization, such as the power manager and ROM controller. It also enables to update the CPU configuration and attributes while the CPUs are held in reset. On RISC-V CPUs, reset vector and mtvec registers for example can be updated before releasing the harts from reset. Signed-off-by: Emmanuel Blot <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
This machine emulates the Ibex Demo System [0] and includes GPIO, SPI device, a timer, UART, and a debug module. There is an st7735 LCD display connected to the SPI device. [0]: https://github.com/lowRISC/ibex-demo-system
The emulator is written in Rust and based on Greg Chadwick's RRS RISC-V simulator. Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
These machines come with many new blocks, scripts, and documentation. Co-authored-by: Loïc Lefort <[email protected]> Signed-off-by: James Wainwright <[email protected]>
These scripts are needed for generating the OTP and flash images and can be used to interact with IO peripherals and generate data. Signed-off-by: James Wainwright <[email protected]>
Includes GitLab flows, though these are not tested in the open source repository.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
These commits are squashed versions of all the changes in our fork on top of upstream 10.2.0. The final repository matches our fork exactly (at time of writing).
I've tested that each commit compiles but haven't run the machines on every commit.
The commits are split to make them easier to rebase and resolve conflicts. Almost all OpenTitan changes are in a single commit because they introduce new files and will not conflict with anything already in the repository.