Proximity driver to Tock 2.0 system-call interface #2284
Conversation
Port the proximity driver to the Tock 2.0 system-call Driver interface. I simplified `enqueue_command` a bit by moving the logic into the enter closure. I think it could be improved with different logic that virtualizes the commands a bit more thoroughly, but that's for another day.
feafd42 to
265b13b
Compare
There was a problem hiding this comment.
These changes look good.
I did notice while reviewing that run_next_command() calls find_thresholds() internally which triggers unsoundness per #2135 , but that has nothing to do with the changes here.
There was a problem hiding this comment.
This looks pretty good.
It appears I'm unable to comment on unchanged regions, but the comments regarding subscribe in the top of the file seem partially outdated. I don't think such a description is required any more, given that encoding of allow and subscribe is now centrally done in the kernel.
|
@hudson-ayers @lschuermann Did one of you get a chance to test this with the aforementioned hardware (nano33ble or clue_nrf52840)? |
I did not |
|
@arjundeopujari Unfortunately not, those boards are still on my wishlist. |
|
@hudson-ayers @lschuermann Okay. I will test them quickly after the call today on one of my nano33ble's |
@alevy Ok. I tested with the original driver and the 2.0 driver and the 2.0 driver consistently generates a data access fault. See below serial output from tockloader.---| No debug queue found. You can set it with the DebugQueue component. ---| Fault Status |--- ---| App Status |--- ======== Steps to recreate: Comments: It consistently seems to consistently fault at the same address. Not sure if this could be caused by @hudson-ayers 's claim on the Grant API unsoundness? Original one still works perfectly well. Not sure what is going on here. |
|
@bradjc Maybe you can double-check this since it seems it should work and you have the board with you. |
|
I have seen a data access fault as well. I tracked mine down to |
|
I saw a data access fault on the UDP example as well once I rebased libtock-c and updated to the new system calls. Haven't had time to dig into it yet |
|
I think I found it. crt0.c has inline assembly for invoking |
|
Pulling in that change fixed my bug as well, thanks! |
|
bors r+ |
2284: Proximity driver to Tock 2.0 system-call interface r=phil-levis a=alevy ### Pull Request Overview This pull request Port the proximity driver to the Tock 2.0 system-call Driver interface. I simplified `enqueue_command` a bit by moving the logic into the enter closure. ### Testing Strategy So far, only compiled-tested. I don't have a board with the right peripheral (the nanoble-sense or the clue_nrf52840). ### TODO or Help Wanted Can @arjundeopujari (original author of the driver) maybe test this quickly? Or else someone with one of the two boards that have this driver? ### Documentation Updated - [] ~~Updated the relevant files in `/docs`, or no updates are required.~~ ### Formatting - [X] Ran `make prepush`. Co-authored-by: Amit Aryeh Levy <[email protected]>
Pull Request Overview
This pull request Port the proximity driver to the Tock 2.0 system-call Driver interface.
I simplified
enqueue_commanda bit by moving the logic into the enter closure.Testing Strategy
So far, only compiled-tested. I don't have a board with the right peripheral (the nanoble-sense or the clue_nrf52840).
TODO or Help Wanted
Can @arjundeopujari (original author of the driver) maybe test this quickly? Or else someone with one of the two boards that have this driver?
Documentation Updated
Updated the relevant files in/docs, or no updates are required.Formatting
make prepush.