Add launchxl and cc26x2 to the archive #2
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
2 tasks
bors bot
added a commit
to tock/tock
that referenced
this pull request
Jun 25, 2020
1933: Bind AppSlice to app instance (AppId), fixes #1914 r=bradjc a=lschuermann ### Pull Request Overview This pull request fixes #1914 by checking whether the memory an AppSlice points to still belongs to the same app instance (more precisely, the `instance` field in `AppSlice`). Thanks to @alevy for implementing the main part of this which turned out to be working perfectly. The commits on top make sure that the returned `AppSlice` length is consistent with the `AsRef` and `AsMut` implementations and document this new behavior. ### Testing Strategy This pull request was tested by developing a crude capsule which deliberately keeps an `AppSlice` out of a grant and does not accept a second `allow`. This ensures that the AppSlice is shared from the first app instance, but is used in the second app instance. The test capsule (integrated with the nRF52840) along the userspace `libtock_c` app can be found [here](lschuermann@6403b2e). The output validates that indeed the `AppSlice` returns a length of 0 and hands out a immutable / mutable slice of length `0`. ``` Initialization complete. Entering main loop NRF52 HW INFO: Variant: AAC0, Part: N52840, Package: QI, Ram: K256, Flash: K1024 --> AppSlice safety test app! Allow buffer of length 64 AppSlice shared by app! Tell capsule to print AppSlice info Shared slice reports length 64 Shared slice as_ref length 64 Shared slice as_mut length 64 <fault app by button press> --> AppSlice safety test app! Allow buffer of length 64 AppSlice already shared, refusing to replace Tell capsule to print AppSlice info Shared slice reports length 0 Shared slice as_ref length 0 Shared slice as_mut length 0 ``` ### TODO We should probably run the release test suite along with the `DebugProcessRestart` capsule to make sure this doesn't break any existing capsules. I can verify this once this gets "yes, we indeed want this" feedback. 😄 ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. I believe there not to be a section in `/docs` which needs to elaborate on this behavior. I hope the generated rustdoc is sufficient. If indeed an update in `/docs` is required, please provide pointers to the respective section. ### Formatting - [x] Ran `make prepush`. 1963: deprecate launchxl, cc26x2 r=bradjc a=ppannuto ### Pull Request Overview This pull request deprecates the LaunchXL and CC26x2, moving them to tock-archive. This is not intended as a statement one way or another on this chip or board, rather just a recognition that this board has not seem much uptake, and maintenance is lagging (e.g. #1101). See the companion PR here: tock/tock-archive#2 ### Testing Strategy Compiling. ### TODO or Help Wanted N/A ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. 1979: add --strip-sections to objcopy flags r=bradjc a=hudson-ayers ### Pull Request Overview This pull request adds `--strip-sections` to OBJCOPY_FLAGS. This fixes an issue where boards with SRAM located below flash would have huge binaries (250 MB+) after we updated to the latest nightly, which included an update to LLVM objcopy. This was first noticed by Emilio Moretti on an out of tree board he maintains, but it also affects OpenTitan. The help description for the flag follows: `--strip-sections Remove all section headers and all sections not in segments` ### Testing Strategy This pull request was tested by compiling opentitan and observing the binary size has returned to normal, and running the hello_world app in QEMU for opentitan. ### TODO or Help Wanted N/A ### Documentation Updated - [x] no updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Amit Aryeh Levy <amit@amitlevy.com> Co-authored-by: Leon Schuermann <leon@is.currently.online> Co-authored-by: Pat Pannuto <pat.pannuto@gmail.com> Co-authored-by: Brad Campbell <bradjc5@gmail.com> Co-authored-by: Hudson Ayers <hayers@stanford.edu>
alevy
approved these changes
Jul 3, 2020
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.
The captures the state of the launchxl and cc26x2 as of the 1.5 release.
This is compile-tested, but not tested on hardware (as I don't have any), but again, does match the 1.5 release, so should be tested via that, which I think is about the best we can ask for.