Incorporate atsama5d27 target into CI
Opened this issue · 2 comments
atsama5d27 target is bit-rotting because it's not in CI. There's a fair bit of cleanup that needs to be done, especially on the ticktimer interface, to make sure this works.
An open question is: We can build the code, but we can't test it (don't have the corresponding hardware). So how do we know if our patches are working?
So how do we know if our patches are working?
I'm not really aware of a way to properly emulate atsama5d2 in software which means the only way to know if patches are working apart from being able to compile them is to run them on a dev board. Since we're actively using xous and ticktimer, I'm willing spend some time back-porting these changes to the atsama5d2 while making sure it's still working.
Cool. I took a quick look and I think the back-port isn't too onerous on the ticktimer implementation.rs module. Most of the changes are in how the sleep heap is recalculated, and not interacting with the hardware itself.
I'd say we're still at the stage of testing the ticktimer changes -- I'd let the current changes soak in for a couple weeks unless you are encountering an urgent issue in stability.
On that front, if you use condvars (or MPSC channels) heavily, there are some problems with waking up the variables after their time-out which I think we traced to the sleep_heap() getting duplicate entries that overwrite a wake event causing a thread to never wake up again. But if you don't use these and/or your system isn't running at heavy loads, you probably won't notice the problem.
Our recent changes to the Net stack (where we use MPSC channels to efficiently implement the smoltcp poll primitive) really exercised the sleep_heap() and thus we were seeing failures after running intense workloads on the order of 15 minutes continuously, but this seems to now be fixed.
We still think there might still be dragons in thread local storage (which is used in thread parking by the std library), but currently we have only seen failures in synthetic tests and not in real code.
All that being said, I probably should still make a atsama5d2 target just so we're aware of how far that target is drifting. I just realized today that it's a total blind spot while doing a search-and-replace of an idiom in the ticktimer, so I opened the issue to prod myself into eventually addressing that.