Remove use of internal RTX types #4776

c1728p9 · 2017-07-18T17:06:32Z

Make calls to cmsis-os to get thread state, stack size, and max stack usage rather than accessing internal RTX data directly. Wrap the code which has no public RTX function in TARGET_CORTEX_M since this needs to be defined for RTX to be included.

c1728p9 · 2017-07-18T20:58:34Z

/morph test

mbed-bot · 2017-07-19T04:22:33Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 848

Test failed!

bulislaw · 2017-07-19T08:08:13Z

rtos/Thread.cpp

@@ -238,10 +237,12 @@ uint32_t Thread::free_stack() {
    uint32_t size = 0;
    _mutex.lock();

+#if defined(TARGET_CORTEX_M)


Why are we adding that? I would hope the new Cortex A support in RTX is not that different

I'll add Cortex A to this as well.

bulislaw · 2017-07-19T08:11:00Z

rtos/Thread.cpp

@@ -168,7 +168,7 @@ Thread::State Thread::get_state() {
    _mutex.lock();

    if (_tid != NULL) {
-        state = _obj_mem.state;
+        state = osThreadGetState(_tid);


That's possibly incorrect, if we want to preserve compatibility with pre CMSIS5 code, the osThreadGetState compresses statuses to short list, RTOS C++ API have quite extensive list. I personally agree we don't need all this detailed states like ('waiting for semaphore' as opposed to 'Waiting') but that's what we used to return.

I can revert this back to what it was. Just let me know what you prefer.

To be backward compatible if there is no strong reason to break this. In this case it is not?

bulislaw · 2017-07-19T08:13:14Z

rtos/Thread.cpp

-        while (((uint32_t *)(thread->stack_mem))[high_mark] == 0xE25A2EA5)
-            high_mark++;
-        size = thread->stack_size - (high_mark * sizeof(uint32_t));
+        size = osThreadGetStackSize(_tid) - osThreadGetStackSpace(_tid);


to use osGetStackSpace we need to enable OS_STACK_WATERMARK, right now we only do it conditionally.

I didn't realize that, thanks for pointing it out. I think this code will be ok since osThreadGetStackSpace isn't compiled out when OS_STACK_WATERMARK isn't set, it just returns 0. Regardless, if stack watermarking isn't turned out then this code won't work as expected, since the stack won't be filled with 0xE25A2EA5.

I would say we should either leave it the way it was or define OS_STACK_WATERMARK and change the code to fit it (eg not fill the stack with our pattern and let the RTX to use their 0xCCCCCCCCU).

Ah, I forgot there were two watermarking schemes. So the existing code would actually work when OS_STACK_WATERMARK isn't set. Either way works for me. Defining OS_STACK_WATERMARK seems like it might unify the code more, so that would be my preference.

c1728p9 · 2017-07-19T16:41:41Z

/morph test

mbed-bot · 2017-07-19T18:35:12Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 851

Test failed!

c1728p9 · 2017-07-19T19:55:03Z

/morph test

mbed-bot · 2017-07-19T21:59:02Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 853

All builds and test passed!

bulislaw · 2017-07-20T08:14:17Z

rtos/rtx5/mbed_rtx_conf.h

@@ -24,6 +24,11 @@

 #include "mbed_rtx.h"

+/** Any access to RTX5 specific data structures used in common code should be wrapped in ifdef OS_BACKEND_RTX5 */


I don't get why we have it this way. I would say it's fair enough to try to be 'generic' and let people replace RTX with other RTOSs as long as they implement CMSIS-RTOS2 API. But why do you enable it for CORTEX A and M? In any case that's the only HW we support. We could just define this flag in mbed_rtx_conf.h without checking the cores as it's RTX config and I would expect it should be provided per implementation (together with the storage and handlers files). Also I'm a big fan of mbed flags starting with mbed, so maybe something like MBED_OS_BACKEND_RTX5 for clarity.

c1728p9 · 2017-07-20T21:21:48Z

This will be updated once #4786 has been merged.

theotherjimmy · 2017-07-27T14:15:46Z

@c1728p9 Does this really need #4786 to go in first?

c1728p9 · 2017-07-27T14:24:55Z

The only dependency is the TARGET_CORTEX change.

c1728p9 · 2017-07-27T16:27:53Z

Updated this PR to include the TARGET_CORTEX directory addition. Also, expanded the scope of this PR to remove the use of internal RTX structures everywhere in the codebase.

c1728p9 · 2017-07-27T16:27:58Z

/morph test

theotherjimmy · 2017-07-27T16:41:35Z

@c1728p9 that change does make more sense here.

c1728p9 · 2017-07-27T17:03:24Z

retest uvisor

c1728p9 · 2017-07-27T19:25:32Z

/morph test

c1728p9 · 2017-08-31T23:53:42Z

@bulislaw has already worked with the cmsis-rtos team to try and get the new types added, but this enhancement was rejected.

c1728p9 · 2017-09-01T00:51:35Z

I created a PR #5003 for the directory restructuring and rebased this to master.

c1728p9 · 2017-09-01T00:59:37Z

/morph test

mbed-bot · 2017-09-01T02:20:04Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1149

Test failed!

bulislaw · 2017-09-01T08:23:58Z

features/FEATURE_UVISOR/source/rtx/box_init.c

@@ -29,7 +29,7 @@
 extern void SVC_Handler(void);
 extern void PendSV_Handler(void);
 extern void SysTick_Handler(void);
-extern uint32_t svcRtxKernelLock(void);


That's going to be overwritten by next uvisor drop.

It was merged by uvisor, the new update contains this, its ready for merge: https://github.com/ARMmbed/mbed-os/pull/4907/files . This will be rebased once it gets in

This PR shouldn't do the update, but should use the uVisor v0.30.0 changes.

Does this PR need to raise the priority of PR #4907? We thought the v0.30.0 PR was optional for 5.6, but maybe because this PR depends on it, the uVisor PR must go into 5.6.

Thanks @Patater. If both gets in, it would be nice. This is nice to have.
We will wait for uvisor to get in with the change, and rebase this one afterwards.

bulislaw

LGTM

c1728p9 · 2017-09-01T14:47:46Z

/morph test

mbed-bot · 2017-09-01T16:34:37Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1156

All builds and test passed!

0xc0170 · 2017-09-04T08:22:49Z

As marked above (#4776 (comment)), waiting for uvisor update.

0xc0170 · 2017-09-04T15:53:51Z

@c1728p9 Please rebase, uvisor PR update was merged to master

Make calls to cmsis-os to get thread state, stack size, and max stack usage rather than accessing internal RTX data directly. Wrap RTX5 specific code in OS_BACKEND_RTX5. Also refactor the code to use mbed types rather than RTX types: os_timer_t -> mbed_rtos_storage_timer_t os_event_flags_t -> mbed_rtos_storage_event_flags_t osRtxMutex_t -> mbed_rtos_storage_thread_t

c1728p9 · 2017-09-04T16:30:36Z

Rebased and removed uvisor changes to rtx_box_index.h.

c1728p9 · 2017-09-04T16:30:41Z

/morph test

mbed-bot · 2017-09-05T15:50:58Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1215

All builds and test passed!

0xc0170 · 2017-09-06T08:24:16Z

Ready for intergration.

c1728p9 requested a review from bulislaw July 18, 2017 17:06

bulislaw reviewed Jul 19, 2017

View reviewed changes

0xc0170 added the needs: review label Jul 19, 2017

c1728p9 force-pushed the rtx_usage branch from 7240643 to ac95b6c Compare July 19, 2017 16:37

c1728p9 force-pushed the rtx_usage branch from ac95b6c to 637c6b2 Compare July 19, 2017 19:53

bulislaw reviewed Jul 20, 2017

View reviewed changes

c1728p9 added needs: work and removed needs: review labels Jul 20, 2017

theotherjimmy added the needs: preceding PR label Jul 24, 2017

c1728p9 force-pushed the rtx_usage branch from 637c6b2 to c213b71 Compare July 27, 2017 16:25

c1728p9 removed needs: preceding PR needs: work labels Jul 27, 2017

c1728p9 mentioned this pull request Jul 27, 2017

RTOS: Rework directory structure #4786

Closed

c1728p9 force-pushed the rtx_usage branch from c213b71 to 52cd426 Compare July 27, 2017 19:25

c1728p9 force-pushed the rtx_usage branch from 24bb5c3 to 87af9a8 Compare September 1, 2017 00:50

bulislaw reviewed Sep 1, 2017

View reviewed changes

bulislaw approved these changes Sep 1, 2017

View reviewed changes

0xc0170 approved these changes Sep 1, 2017

View reviewed changes

0xc0170 added needs: preceding PR and removed needs: review labels Sep 4, 2017

0xc0170 added needs: work and removed needs: preceding PR labels Sep 4, 2017

c1728p9 force-pushed the rtx_usage branch from 87af9a8 to b2384b1 Compare September 4, 2017 16:27

Patater added ready for merge and removed ready for merge labels Sep 5, 2017

0xc0170 added ready for merge and removed needs: work labels Sep 6, 2017

theotherjimmy merged commit 1244802 into ARMmbed:master Sep 6, 2017

theotherjimmy added release-version: 5.5.7 and removed ready for merge labels Sep 6, 2017

c1728p9 mentioned this pull request Nov 21, 2017

thread max_stack() returns always aligned stacksize-4 in rtos5 #5522

Closed

		@@ -24,6 +24,11 @@

		#include "mbed_rtx.h"

		/** Any access to RTX5 specific data structures used in common code should be wrapped in ifdef OS_BACKEND_RTX5 */

Remove use of internal RTX types #4776

Remove use of internal RTX types #4776

Conversation

c1728p9 commented Jul 18, 2017

c1728p9 commented Jul 18, 2017

mbed-bot commented Jul 19, 2017

Output

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

c1728p9 commented Jul 19, 2017

mbed-bot commented Jul 19, 2017

Output

c1728p9 commented Jul 19, 2017

mbed-bot commented Jul 19, 2017

Output

Choose a reason for hiding this comment

c1728p9 commented Jul 20, 2017

theotherjimmy commented Jul 27, 2017

c1728p9 commented Jul 27, 2017

c1728p9 commented Jul 27, 2017

c1728p9 commented Jul 27, 2017

theotherjimmy commented Jul 27, 2017

c1728p9 commented Jul 27, 2017

c1728p9 commented Jul 27, 2017

c1728p9 commented Aug 31, 2017

c1728p9 commented Sep 1, 2017 • edited Loading

c1728p9 commented Sep 1, 2017

mbed-bot commented Sep 1, 2017

Output

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bulislaw left a comment

Choose a reason for hiding this comment

c1728p9 commented Sep 1, 2017

mbed-bot commented Sep 1, 2017

Output

0xc0170 commented Sep 4, 2017

0xc0170 commented Sep 4, 2017

c1728p9 commented Sep 4, 2017

c1728p9 commented Sep 4, 2017

mbed-bot commented Sep 5, 2017

Output

0xc0170 commented Sep 6, 2017

c1728p9 commented Sep 1, 2017 •

edited

Loading