f9micro / f9-kernel Goto Github PK

At present, there is only one userspace task, which creates two threads for pingpong test. We expect to have the following:

• libL4: userspace library with POSIX-like APIs
• apps: example applications
• server: sigma0-like implementation

Reference: pistachio/user

At present, STM32F4-Discovery is the only board that F9 Microkernel support, and the source tree lacks of the following information:

• build configurations: CONFIG_{BITMAP_BITBAND,PANIC_DUMP_STACK}
• global constants and target hardware definitions
• hardware configuration and usage, such as USART

LK embedded kernel supports a new initialization system, which allows code anywhere in the system to define an init hook which is
called at the run level specified.

Hooks are guaranteed to be called in order of init level. Within an init level the order of the hooks is not guaranteed. It is quite convenient for low-level handling of F9 Microkernel.

Reference:

• init: new init hook system
• lib: move a few libs to the new init hook system

I have implemented a non-recursive thread_select, will it be helpful?
commit: 6802d69

At present, thread destroy function is absent in F9 Microkernel implementation, that means syscall THREAD_CONTROL can not really real with the cases of destroy and destruction.

We expect the kernel can avoid most context-switching overhead costs by eliminating periodic ticks. In most embedded RTOS, there is a trade off between high time-resolution (by increasing tick frequency) and overhead. F9 Microkernel would not use ticks and achieves high-time resolution with very low overhead.

The tickless infrastructure allows individual ARM Cortex-M to spend longer periods of time in the idle state between events when nothing is scheduled. This is hopefully accomplished by adding new ktimer / kevent API to update the tasks to use more sensible event notification mechanisms.

To be more practical, we can introduce tickless idle mode, which stops the periodic tick interrupt during idle periods (periods when there are no application tasks that are able to execute), then makes a correcting adjustment to the RTOS tick count value when the tick interrupt is restarted.

Stopping the tick interrupt allows ARM Cortex-M to remain in a deep power saving state until either an interrupt occurs, or it is time for the kernel to transition a task into the ready state.

Reference:

• Low Power Support: Tickless Idle Mode
• Low Power RTOS For Cortex-M MCUs

Hi All,

While I used gdb to trace F9-kernel on STM32F4 Discovery, it panic at platform/debug_device.c:43

Git HEAD: 7ae6e15

I desire using gdb with f9 but I have no idea how to fix it.

Would someone can give me a hint?

best regards,

• ben6

Kprobe is a very simple method to probe the running kernel. At a fundamental level, it requires the address of a kernel function that needs to be debugged. Then, you create pre- and post-handlers that will print a debugging message when the target kernel function is called. (Actually, a handler performs any action specified in its code; in this case, it happens to be printing.) Thus, every time that function is called, you can track it.

It is really useful if we can introduce this idea into F9 Microkernel.

We would like to have a classical feature, top, for listing threads when executing KDB.

After commit 6dfdd3f, it is straightforward to switch KDB function during build time. However, we would encounter kernel panic if KDB is not enabled as the following messages:

---------------------------------------
F9 microkernel is ready!
Kernel panic: Hard fault. Restarting


Stack dump:
20000384 00000000 08003621 00000040 00000000 2000334c 080033db 08004cf4 
2000334c 200003c0 00000000 00000000 fffffff9 00000040 2000334c 200003c0 
00000000 000000f0 080038e7 080037a4 61000000 0800282d 08004b24 08004d8c 
00000000 00000000 08003621 00000040 00000000 00000000 080038e7 00000000 
00000000 00000000 08003fb7 e000ed24 0800406f 40023c00 ffffffff 00000000 

F9 Microkernel is known to crash if being built with gcc -O1 (or higher order):

--------------------------------------
F9 microkernel is ready!
Press '?' to print KDB menu
Memory fault
-------KTABLES------

KT: fpage_table
bitmap:10000000, data:200013e4, num: 256 size: 16
    0: XXXXXXXXXXXXXXX--X---XX-X---XX-X--X--------X-XX---XX---------XX-
   64: --XXX-XXX--X---X--X-X-------XXXXX-------XXXX----XX-XXXXXX---X-XX
  128: --------X---XXXX--X-------------X-------X---XXXX--X-----X-------
  192: -X---X-XX---XXXXX--------X------X---XXXXXXX--XXX---------XXXXX-X

commit 551b9f0 disables optimization as workaround.

F9 outputs unexpected result when using sleep function.

Sleep function:

void msec_sleep(L4_Word_t msec) {
  L4_Sleep(L4_TimePeriod(msec * 1000));
}

Output:

MEM:   fpage MEM0  [b:2000fb00, sz:2**8]
MEM:   fpage MEM0  [b:2000fc00, sz:2**8]
MEM:   fpage MEM0  [b:2000fd00, sz:2**8]
MEM:   fpage MEM0  [b:2000fe00, sz:2**9]
Address Space 00400002
MEM:   fpage KIP   [b:20000400, sz:2**8]
MEM:   fpage KIP   [b:20000500, sz:2**8]
MEM:   fpage UTEXT [b:2000ee00, sz:2**9]
MEM:   fpage UTEXT [b:2000f000, sz:2**8]
MEM: o fpage UTEXT [b:2000f100, sz:2**8]
MEM: o fpage UTEXT [b:2000f200, sz:2**9]
MEM: o fpage UTEXT [b:2000f400, sz:2**8]
MEM: o fpage UTEXT [b:2000f500, sz:2**8]
MEM: o fpage UTEXT [b:2000f600, sz:2**8]
MEM:   fpage UDATA [b:2000f700, sz:2**8]
MEM: o fpage UDATA [b:2000f800, sz:2**9]
MEM:   fpage MEM0  [b:2000fa00, sz:2**8]
MEM:   fpage MEM0  [b:2000fa00, sz:2**8]
MEM:   fpage MEM0  [b:2000fb00, sz:2**8]
MEM:   fpage MEM0  [b:2000fc00, sz:2**8]
MEM:   fpage MEM0  [b:2000fc00, sz:2**8]
MEM: o fpage MEM0  [b:2000fd00, sz:2**8]
MEM:   fpage MEM0  [b:2000fe00, sz:2**9]
-------TOP------
Init sampling...


Stack dump:
20000388 00000001 2000e380 e000ed34 08004a70 00000000 080016df 08004b6c 
00000001 e000ed34 00404002 2000fd98 08004a70 080043cd 00000002 0800551c 
2000fd5c 00000000 080016fb fffffffd 00000001 080051b4 00000000 08003f41 
2000e27c 08003b43 08003f48 61000000 08003f41 08003ec9 00000000 08003eb5 
00000300 08003f11 e000ed24 08003cf1 00000000 ffffffff 00000000

After commit 3af7f02, the build system is now flexible enough to support concrete board implementation. At present, STM32F4-Discovery board is the only target, and we expect to have a dedicated board directory to decouple from platform specific implementation.

While designing next generation of F9 microkernel, we introduce generic FIFO concept for manipulating shared resources. However, there is already one fifo implementation in the form of kernel library. It would be better that we can move it to explicit queue for implementation consistency.

In ipc test, two threads, simple_ipc_t1_l, simple_ipc_t2_l should be released finally by sending L4_Niltag to their parent thread. However, these two threads are still alive after all. Use 't' command in KDB could observe this issue.

How to reproduce:

• modify mk/toolchain.mk, change from CFLAGS_OPT = -O1 to CFLAGS_OPT = -O0.
• under KDB, use 't' to list all threads.
• There is no USR threads.

Reference output:

-------THREADS------
type  global   local    state  parent
IDLE  00000000 00000000 RUN    00000000
ROOT  00008000 00000000 SEND   00000000
KERN  00004000 00000000 RUN    00000000
----------------

I'm trying to modify the PR #86 move the gpio driver (gpio.c with __USER_TEXT)

Unfortunately, Memory fault occurred at 40023830
this address is accessed by gpio_config()

  *RCC_AHB1ENR |= (1 << port);

after gcc -E expended

*(volatile uint32_t *) ((((uint32_t) (0x40000000) + 0x00020000) + 0x3800) + 0x30)
        |= (1 << port);

even though I have grant memory.c memmap table from

         DECLARE_MEMPOOL("AHB1_1DEV", 0x40020000, 0x40022400,

to

         DECLARE_MEMPOOL("AHB1_1DEV", 0x40020000, 0x4002383f,

kernel dump show that user can read/write

----- part from dump begin ----- `
AHB1_1DEV       14399 [40020000:4002383f] --- rw- D
----- part from dump end ----- 

Are there any idea?

===================================================
      Copyright(C) 2013 The F9 Microkernel Project
====================================================
Git head: 972471e29447f150a9504dcc0d5c815e750c6ec2
Host: i686
Build: 2014-04-21T02:21:44+0800

Press '?' to print KDB menu
test gpioer to on off

-------MPU------
b:2000ff00, sz:2**8, attr:1300
b:2000f800, sz:2**8, attr:0300
b:2000fa00, sz:2**9, attr:1300
b:2000f400, sz:2**10, attr:0300
b:20000400, sz:2**8, attr:1300
b:20000500, sz:2**8, attr:1300
b:2000ee00, sz:2**9, attr:0300
b:2000f000, sz:2**8, attr:0300
Memory fault mmsr:00000082, mmar:40023830,
             current:00404002, psp:2000ffb8, pc:2000eefc

-------KTABLES------

KT: fpage_table
bitmap:10000000, data:2000c4e4, num: 256 size: 24
    0: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX--------------------------------
   64: ----------------------------------------------------------------
  128: ----------------------------------------------------------------
  192: ----------------------------------------------------------------

KT: as_table
bitmap:10000028, data:2000e0e4, num: 16 size: 20
    0: XX--------------
KT: ktimer_event_table
bitmap:10000020, data:2000dce4, num: 64 size: 16
    0: X---------------------------------------------------------------

KT: thread_table
bitmap:1000002c, data:2000e224, num: 32 size: 88
    0: XXXXX----------------------------------KTIMER------

ktimer events:
EVENT    DELTA
2000dce4           64
-------NOW------
Now is 0
Ktimer T=3 D=0
-------SOFTIRQ------
Kernel timer events              not scheduled
Asynchronous events              not scheduled
System calls                     not scheduled
KDB enters                       not scheduled
-------THREADS------
type  global   local    state  parent
IDLE  00000000 00000000 RUN    00000000
ROOT  00008000 00000000 RECV   00000000
KERN  00004000 00000000 FREE   00000000
[USR] 00400002 00000040 RECV   00008000
[USR] 00404002 00000040 RUN    00400002
-------MEMPOOLS------
NAME       SIZE       [START   :END     ] FLAGS
KTEXT           20544 [08001000:08006040] r-x --- N
UTEXT            2816 [2000ee00:2000f900] --- r-x M
KIP               512 [20000400:20000600] rw- r-- S
KDATA             888 [20000600:20000978] rw- --- N
KBSS            58148 [20000a00:2000ed24] rw- --- N
UDATA             768 [2000f900:2000fc00] --- rw- M
UBSS                0 [2000fc00:2000fc00] --- rw- M
MEM0            50176 [2000fc00:2001c000] --- rw- S
KBITMAP            48 [10000000:10000030] rw- --- N
MEM1            65488 [10000030:10010000] --- rw- A
APB1DEV         30720 [40000000:40007800] --- rw- D
APB2_1DEV       13312 [40010000:40013400] --- rw- D
APB2_2DEV        3072 [40014000:40014c00] --- rw- D
AHB1_1DEV       14399 [40020000:4002383f] --- rw- D
AHB1_2DEV      115712 [40023c00:40040000] --- rw- D
AHB2DEV        397312 [50000000:50061000] --- rw- D
AHB3DEV    1073745920 [60000000:a0001000] --- rw- D
-------AS------
Address Space 00008000
MEM:   fpage KIP   [b:20000400, sz:2**8]
MEM: o fpage KIP   [b:20000500, sz:2**8]
MEM: o fpage UTEXT [b:2000ee00, sz:2**9]
MEM: o fpage UTEXT [b:2000f000, sz:2**8]
MEM: o fpage UTEXT [b:2000f100, sz:2**8]
MEM: o fpage UTEXT [b:2000f200, sz:2**9]
MEM: o fpage UTEXT [b:2000f400, sz:2**10]
MEM:   fpage UTEXT [b:2000f800, sz:2**8]
MEM: o fpage UDATA [b:2000f900, sz:2**8]
MEM: o fpage UDATA [b:2000fa00, sz:2**9]
MEM:   fpage MEM0  [b:2000fc00, sz:2**8]
MEM:   fpage MEM0  [b:2000fd00, sz:2**8]
MEM:   fpage MEM0  [b:2000fe00, sz:2**8]
MEM:   fpage MEM0  [b:2000ff00, sz:2**8]
Address Space 00400002
MEM: o fpage KIP   [b:20000400, sz:2**8]
MEM: o fpage KIP   [b:20000500, sz:2**8]
MEM: o fpage UTEXT [b:2000ee00, sz:2**9]
MEM: o fpage UTEXT [b:2000f000, sz:2**8]
MEM:   fpage UTEXT [b:2000f100, sz:2**8]
MEM:   fpage UTEXT [b:2000f200, sz:2**9]
MEM: o fpage UTEXT [b:2000f400, sz:2**10]
MEM: o fpage UTEXT [b:2000f800, sz:2**8]
MEM:   fpage UDATA [b:2000f900, sz:2**8]
MEM: o fpage UDATA [b:2000fa00, sz:2**9]
MEM:   fpage MEM0  [b:2000fc00, sz:2**8]
MEM:   fpage MEM0  [b:2000fc00, sz:2**8]
MEM:   fpage MEM0  [b:2000fd00, sz:2**8]
MEM:   fpage MEM0  [b:2000fe00, sz:2**8]
MEM:   fpage MEM0  [b:2000fe00, sz:2**8]
MEM: o fpage MEM0  [b:2000ff00, sz:2**8]
-------TOP------
Init sampling...

Stack dump:
20000388 00000082 08005fb4 2000e384 40023830 00000000 080017ef 08005594
00000082 40023830 00404002 2000ffb8 2000eefc 08004ca3 00000002 08005fb4
2000ff8c 00000000 08001803 fffffffd 00000001 08005bf4 200003b0 08004769
000000f0 08004303 08004770 61000000 08004769 080046dd 00000000 080046bb
00000000 0800472d e000ed24 08004519 40023c00 08003869 00000000

mung, another L4.X2 compatible microkernel, has a nice testbench, which deploys at least the following test items:

• forkserv: service that takes over the root task's memory, letting it fork subprocesses
  (and subprocesses of those). this is useful for test cases involving map operations
  in IPC, or the Unmap system call.
• interrupt: tests about interrupt handling per the L4.X2 spec. heavily tied to PC-style
  x86 due to serial port use.
• ipc: tests concerning the Ipc system call, with the exception of anything related to
  string transfers.
• scheduler: kernel preemption
• thread: unit tests concerning the ThreadControl and ExchangeRegister system
  calls, and TCR access.
• type: tests wrt the types defined by <l4/types.h>

We can port parts of the test suite and evaluate on F9 Microkernel.

After commit 672e292 done by @arcbbb , as_setup_mpu appears to be the most frequent function so far:

-------TOP------
 3725 [ as_setup_mpu             ]
 1124 [ syscall_handler          ]
 1118 [ __svc_handler            ]
  798 [ softirq_execute          ]
  770 [ mempool_getbyid          ]
  662 [ softirq_schedule         ]

We have to clarify the distribution of the sampling results. However, both as_setup_mpu and mempool_getbyid implies the room for improvements.

According to @georgekang 's experiments, the ranking is getting back to match our expectation exactly after GCC optimization order is set to -O0.

For historical reasons, F9 Microkernel uses two similar definitions DEBUG and CONFIG_DEBUG for picking up the configuration. However, this option is not really functioned because it breaks the build while the option is disabled,

If either DEBUG or CONFIG_DEBUG is disabled, no serial I/O is configured in kernel, but we can still utilize some facilities, such as st-term in stlink package, to verify system.

We should at least decouple DEBUG / CONFIG_DEBUG from build process first and then provide the mechanism for non-serial I/O.

If a thread runs L4_Call before the receiving thread run L4_Wait, this ipc connection
between sender and receiver would not be created.
Sender uses L4_Call first and it would suspends if receiver is in running state at this
moment. Then receiver runs L4_Wait which uses "L4_anythread" as "ipc_from" to
wait "any" thread. However, "L4_anythread" would be skipped by kernel in ipc_deliver(). Therefore, this ipc connection would not be created and both sender
and receiver suspend.

At present, there is a dummy message when F9 Microkernel is started:

---------------------------------------
F9 microkernel is ready!

It looks unprofessional and is not so informative. We expect that the better welcome messages might consist of the following:

• ASCII art
• build information: date, git HEAD, host

In preparation of new boards support other than STM32F4 Discovery, it is necessary to make the USART pin assignment configurable. Also, it might be a good idea to introduce the idea of "resources".

When tickless scheduling is enabled, kernel timer varies once SysTick gets reload value from wakeup state.

The proper kernel timer compensation is required to fix up the timing though.

In the original design of F9 Microkernel, there are various terminologies to describe the layer of various systems including board, architecture, platform, hardware, chip, etc. However, it has been simplified before the public release for the sake of the major focus on bringing modern microkernel characteristics to 32-bit ARM microcontrollers.

We should provide the consistent naming, especially for "chip" and "platform", and then unify the build system along with source tree.

I don't know why this doesn't hit the STM32F4 but when bringing up the K10 I was hitting busfaults during L4_Map, the code in root_thread.c calls L4_Map before a stack has been set for given thread. So, do_ipc should not try to dereference a non-existing stack pointer. My guess with the STM is that the busfault is being treated as a memfault and being handled by the memmanage_handler (incorrectly).

At present, mk/generic.mk includes mk/rules/symmap.mk directly, that is regarded as unexpected usage for build system since its name implies the generic operations.

We should include some make rule definitions only when the feature is matching. To make it better, it is straightforward to scan the configurations in directory mk/rules first and then specify the inclusion.

Sometimes, the stack[REG_PC](in kernel/kprobes.c) was nvic_handler52, rather than not the next instruction of breakpoint. The is because the priority of UART is higher than ktimer_handler, the location of breakpoint.

If F9 + STM32F4-Discovery board is powered on within longer idle time (typically, 5 min) without any UART input sequence, its thread behavior would be wrong as following KDB output indicates:

-------THREADS------
type  global   local    state  parent
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 RUN    00000000
ROOT  00008000 00000000 SVC    00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
KERN  00004000 00000000 RUN    00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
[USR] 00400000 00000040 RUN    00008000
[USR] 00404000 00000080 RUN    00008000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
IDLE  00000000 00000000 FREE   00000000
----------------

The unexpected IDLE threads cause the incorrect reaction of reset handler as well.

Memory fault would happen when the alignment of fpage is larger than data section.
In default setting, the fpage is 2^8-byte aligned and data section is at 0x20000400. Data section is not only 2^7-byte aligned but also 2^8-byte aligned. However, data section is only set as 2^7-byte aligned in link file. If data section is only 2^7-byte aligned(e.g. 0x2000480) and fpage is 2^8-byte aligned, memory fault would happen when accessing first 128 bytes of data section.

The current implementation of IRQ handling is highly ineffective because:

• It is does not support Nested Interrupts. At present, interrupt nesting will rewrite irq_stack_pointer which is global.
• We always save all registers even if we do not perform context switching.

ChibiOS/RT provides an efficient interrupt nesting design, and it would be great design material for improving F9 Microkernel.

Reference:

• ChibiOS/RT kernel features matrix

After Issue #11 is done, it means F9 Microkernel could have a separate userspace environment, which might be initialized by certain system loader. Upon the ideas of @georgekang, here are the expected features of system loader:

• F9 microkernel itself should be minimized, and the 1st stage image only includes low level parts + system loader
• system loader locates the address which points the image of userspace environment
• system loader, included in 1st stage image, attempts to load F9 Microkernel to memory (RamLoc, 0x20000000) and then userspace environment to other area according to its descriptor.
• loader switches the mapping configuration and jump to __l4_start, which is the entry of F9 Microkernel.
• all userspace environment is initialized by F9 microkernel.

After commit 27b9fb2, F9 microkernel has FPU support now. However, it brings a side effect of abnormal statistics as the following:

-------TOP------
 4209 [ schedule_select          ]
 1548 [ softirq_execute          ]
 1544 [ svc_handler              ]
 1113 [ thread_current           ]
  867 [ thread_isrunnable        ]
  440 [ kernel_thread            ]
  436 [ __svc_handler            ]
   72 [ L4_Ipc                   ]

It is evident that symbol L4_Ipc should not run out the ranking.

Vagrant is a tool for building complete development environments. With an easy-to-use workflow and focus on automation.

wukong-vagrant is a nice example to speed up M2M development.

To make build system more consistent, we should move file mk/loader.mk to directory mk/rules/ as file mk/rules/symmap.mk does. Therefore, we can avoid the misleading mk/target.mk at all.

ELF loader is an experimental feature for F9, and its build process should be regarded as the special condition instead of the generic build rules inside the first level of directory mk.

After new init hook system is introduced by @DreamLinuxer, it is a bit flexible to initialize sub-systems by means of init hooks especially for the configured parts.

In addition, it would be easier to track the usage in each stage during initialization.

Function test_and_set_word and test_and_set_bit in file platform/bitops.c implements the basic locking mechanism utilizing ldrex and strexeq instruction. However, other similar routines are not taken into consideration carefully, and we have to ensure that all explicit memory accesses that appear in program order before the DMB instruction are observed before any explicit memory accesses.

Here is the conceptual implementation:

int test_and_set(int *lock)
{
    int old_value;
    /* Ensure that all explicit memory accesses that appear in program order
     * before the DMB instruction are observed before any explicit memory
     * accesses. */
    __asm__ volatile ("dmb");
    old_value = *lock;
    *lock = 1;
    return old_value;
}

The linker scripts are very chip specific, move to platform.

F9 Microkernel is designed to be highly configurable and customized for flexible embedded applications, such as IoT (Internet of Things) and medical devices.

olibc, another C Library implementation optimized for Embedded Linux, utilizes Kconfig, which handles the dependency issue of several combinations for specific configuration options. It is ideal to improve the build system for better customization by means of Kconfig.

Regarding STM32F4DISCOVERY hardware, we can setup Eclipse in order to use an ST-Link probe for debugging. By usingstlink, which is a GDB server compatible with the ST-Link, we can debug F9 Microkernel with Eclipse CDT as the following documentation:

• GNU MCU Eclipse OpenOCD
• Using an Eclipse-based IDE

While @georgekang 's working on #51 , it is important to introduce an efficient realtime compressor. lz4 claims to be a very fast lossless compression algorithm, providing compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems.

We should evaluate it on ARM Cortex-M in advance.

While @southernbear is implementing tickless scheduler #19 , the mechanism depends on thread_sleep and time related APIs. mung microkernel is a good reference about the implementation. According to file include/ukernel/thread.h, thread_sleep is described as following:

/* sets a thread's wakeup timer and updates its scheduling. if "period" is
 * L4_ZeroTime, the thread wakes up immediately.
 *
 * (see thread_wake() for the period = L4_Never case.)
 *
 * requires that status \in {RECV_WAIT, SEND_WAIT, XFER}.
 */
extern void thread_sleep(struct thread *t, L4_Time_t period);

Also, thread_wake is implemented as following:

/* interrupts an IPC wait (incl. R_RECV state) and sets state to STOPPED or
 * READY, depending on TF_HALT as you'd expect; or retains it as XFER if it
 * was already XFER. this is a low-level function: it doesn't set error codes
 * or invoke exception IPC callbacks. it's exactly equivalent to
 * thread_sleep(t, L4_ZeroTime), but this is better documentation.
 *
 * requires that status \in {RECV_WAIT, SEND_WAIT}.
 */
#define thread_wake(t) thread_sleep((t), L4_ZeroTime)

We need a working implementation for thread_sleep and time related APIs in order to verify tickless scheduler.

At present, include/config.h is used for selecting feature configurations of F9 Microkernel. However, the current pattern can not handle the following definition:

#define CONFIG_KTIMER_HEARTBEAT         65536

It will be set to "y" forcely, which is incorrect.

We should improve mk/config.mk.

When floating point support is enabled, lr value would be strange (0xffffffe9) in IRQ_HANDLER, and we need to save ctx's lr in irq_save routine in order to correct it.

We might have to implement proper FPU initialization and corresponding support for ARM Cortex-M4F.

When loader configuration is enabled, GNU ld always complains as the following:

  LD      loader.elf
arm-none-eabi-ld: error: build/discoveryf4/kernel.loader.o: Conflicting CPU architectures 13/0

To ensure the re-usability, we need appropriate in-source documentation which Doxygen can parse and generate from.

Both source file include/platform/stm32f4/nvic.h and include/platform/stm32f4/nvic.h provide the duplicated entries for NVIC, that makes it more difficult to maintain and sync with each other.

Simplify first and avoid the duplicated.

Directory kernel/lib contains the implementation of memcpy and memset, but it is too generic. We can utilize several ARM Cortex-M3/M4 specific features to optimize:

• Thumb-2
  • apply 32-bit aligned data copy in inner loop, which is not necessary to Cortex-M3/M4, but it could be better for the external memory access depending on memory controller.
• unaligned memory access
• PLD instruction to preload cache with memory source

Not all Cortex-M MCUs use the ARM MPU, Kinetis MCU from FSL is an example.