Support ECC RAM on 11xx MCUs - #31
Merged
Merged
Conversation
No change in behavior. Follows the approach shown by ITCM in a prior commit. Unit tests still pass, and existing ELF tests show that we still generate valid linker script.
As of this commit, the RuntimeBuilder only limits the available OCRAM if either ECC controller is enabled. It's misleading; however, it gives users a chance to evaluate their firmware builds with the restricted RAM regions. I'll add and test the controller setups in a later commit. Existing tests still pass. New unit tests demonstrate the restricted RAM behavior.
Testing shows that we must blow fuses in order to activate either ECC engine. Once the fuse is blown, NXP's boot ROM will enable the ECC engine. So by the time the reset handler is running, ECC may already be enabled. The 32-bit copy loops won't work for initializing ITCM and OCRAM. Since these bus widths are 64-bit and the ECC is computed over 64 bits, these 32 bit accesses result in a read-modify-write (RMW) on the underlying interface. If these RAM regions aren't already initialized, we'll fail an ECC check; the read in RMW compares bogus RAM contents against a bogus ECC. This seems to dramatically slow down initialization, or stall it (I've seen the CPU spinning in the boot ROM). If we listen to NXP and use 64-bit writes to preload ECC-protected RAM regions, the 32-bit copy loops will work as expected. Note that we can still issue 64-bit accesses towards DTCM; they're scattered across the two 32-bit interfaces. There's an NXP whitepaper [1] describing that. Once TCM ECC is enabled, we need to tell the TCM interfaces to RMW smaller accesses. Otherwise, we won't generate correct ciphers. We also might need to retry operations if there was a correction by the RAM controller. We can perform these with predicated instructions. Tested on an 1010EVK, where I used the debugger to show the control registers weren't touched; and tested on the 1170EVK, with the same approach showing the expected set bits. [1]: https://www.nxp.com/docs/en/white-paper/CORTEXM7WP.pdf [2]: https://www.nxp.com/docs/en/application-note/AN13204.pdf
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
RuntimeBuildersupports additional configurations for MECC64 and FlexRAM ECC on 11xx MCUs (1160, 1170). The feature is backwards compatible, although the instruction count in__pre_initincreases no matter your chip and usage.If enabled,
__pre_initconfigures TCM interfaces & performs RAM preloading.Something else is expected to turn on the MECCC64 peripherals and FlexRAM ECC. That's typically NXP's boot ROM. You'll need to configure your FlexRAM ECC RAM bank to support your FlexRAM allocation.
See commit messages for more info.