more cleanup for cram dev target #597
Merged
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
NTO can interpret the nearly full-width ASID (lower 8 bits) as the lock target for key material, so no need to compress it down to 1 bits anymore.
the `cramium-soc` target is now the simulation target (just the bare bones chip in a simulation harness, using the `dabao` board configuration which is basically just a breakout board). baosec continues to be the prototype for the first USB dongle coming out.
verilator doesn't implement the TRNG, so the TRNG is bodged. A warning is left in to help remind us/alert us if the bodge is accidentally put into production. the 'dabao' board type is introduced, which is the breakout board codename. camera and display are feature-gated behind their respective board definitions.
a field doesn't exist that is accesed by a debug-print resource in the case of swap being inactivated
RAM clearing takes a lot of time in simulation and is not necessary, hence the feature gate option.
cramium-soc is moving closer to the platonic SoC specifier, and the board-* features are for the specific boards that use cramium-soc This division of feature flags feels a lot nicer and cleaner - if it holds up to further development, I think this style might become the new standard for Xous (as opposed to a single level of feature flag where both SoC and board target are conflated in terms of meaning - which kind of made sense when the CPU was an FPGA and could actually have different features for different boards, but for ASICs this wouldn't happen).
this is not used under certain combinations of e.g. printing and swap
this re-oragnizes the feature matrix of the loader to reflect the chip/board division of feature flags better.
- updates enables or disables updates in the loader - verilator-only will turn off routines that access hardware not present in verilator (e.g. leads to a bus lockup) - simulation-only turns of features that take a long amount of time and aren't necessary in simulation, such as bulk clearing of all RAM - in simulation, we can configure the simulator to do this for us prior to boot; but in HW, of course, RAM is just random, or worse, has the previous session's secrets in it.
we don't have pio block on nto; let's avoid maintaining two versions of the code base for a non-essential feature (the downside of not having this is that the system could end up locking up if no processes call yield_slice(), but in practice this happens often enough that we can get away with it -- at least at this stage).
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.
merge to avoid branch divergence