jserv / mini-arm-os Goto Github PK

We have always set LR to 0xFFFFFFFD at the end of context switch, but this is a redundant or dangerous work.

Exception entry will store EXC_RETURN to LR automatically by hardware according to previous operation mode.

ARM DUI 0533A 2-27:
The processor writes an EXC_RETURN value to the LR.
This indicates which stack pointer corresponds to the stack frame and
what operation mode the processor was in before the entry occurred

It may cause some unpredictable result as someone might intend to utilize other function of EXC_RETURN.

In the comment linked by, it indicate r7 is for sp, but sp is r13 instead. Also quoting from Arm-Cortex-M3 technical reference:

"After returning from the ISR, the processor automatically pops the eight registers from the stack. Interrupt return is passed as a data field in the LR, so ISR functions can be normal C/C++ functions, and do not require a veneer."

So I wonder if we need naked attribute at all

According to https://www.ptt.cc/bbs/ASM/M.1534260340.A.DC5.html

3d4ea33 is buggy due to reset is in privilege level and thread mode.

But the commit assume reset_handler is in Handler mode and makes undefined behavior when first calling activate except 06-Preemptive.

By some experiment, I acknowledge that it can still work well in QEMU but fail in real HW (STMF429), and that misled me during checking 3d4ea33.

I've solving it in my local by hacking activate or thread_start.
After cleanup the code, I will make a PR to solve it.

Let's take 04-Multitasking for example. I provide three doubts on exception return.

• First, Is it correctly to use assembly instruction control to replace exception return? In my opinion, control is only used when we want to change the state from privileged thread mode to unprivileged thread mode. We would change the state from handler mode to unprivileged mode when first task is created.

/*context_switch.S*/
activate:
    ...
	/* switch to process stack */
	msr psp, r0
	mov r0, #3
	msr control, r0
	isb
    ...

• Second, I can not figure it out why we need to change the state from handler mode to unprivileged thread mode before we exception return. We can just launch exception return directly.

/*context_switch.S*/
activate:
    ...
	/* switch to process stack */
	msr psp, r0
	mov r0, #3
	msr control, r0
	isb

	/* load user state */
	pop {r4, r5, r6, r7, r8, r9, r10, r11, lr}

	/* jump to user task */
	bx lr

• Third, I think it is not enough to deal with the register, "psr" by msr psr_nzcvq, ip. If the interrupt occurred when we are in IT block, It would enable the flag in "ipsr". But we could not restore the state by mrs because of the specification. However, to my best of my knowledge, It can only be restored completely by exception return.

/*context_switch.S*/
svc_handler:
     ...
	/* load kernel state */
	pop {r4, r5, r6, r7, r8, r9, r10, r11, ip, lr}
	msr psr_nzcvq, ip
    ...

By the way, I'm working on these problem. I would send the PR recently.

According to gcc onlinedocs:https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html

I found issue that why 01-HelloWorld cannot use "Press Ctrl-A and then X to exit QEMU" in my environment. After add "-cpu arm926", it works as well.

patch as bellow.

diff --git a/01-HelloWorld/Makefile b/01-HelloWorld/Makefile
index cb4d2eb..a88d386 100644
--- a/01-HelloWorld/Makefile
+++ b/01-HelloWorld/Makefile
@@ -21,7 +21,7 @@ startup.o: startup.S
 qemu: $(TARGET)
        @echo "Press Ctrl-A and then X to exit QEMU"
        @echo
-       qemu-system-arm -M versatilepb -m 128M -nographic -kernel $(TARGET)
+       qemu-system-arm -M versatilepb -cpu arm926 -m 128M -nographic -kernel $(TARGET)

 clean:
        rm -f *.o *.bin *.elf

HI,
After 08-CMSIS, is there any plan for MPU support?

MPU is common and basic to protect .text, .rodata and other custom regions.
I think nowadays memory protection is the fundamental OS concept and
should be implemented due to not only secure issue but modifying memory content accidentally.

Hi, i forked this repo thinking that this was a tutorial for beginners but it seems that it requires experience using the ARM tool chain and stm32 stuff to even get started. If this is a tutorial for beginners, do you mind creating some additional documentation so i know where to begin? It's not a tutorial without the actual documentation being there to show you how running an OS in QEMU works. I'd really like to learn how i can develop kernels for the STM32 architecture, but this doesn't give me enough information to start with. CMSIS sounds great too! The idea of porting my OS that i ran on an emulator to a bare metal dev board sounds awesome. Thanks.

According to gcc onlinedocs:https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html

Most of pendsv_handler() have the comment above it:

/* FIXME: Without naked attribute, GCC will corrupt r7 which is used for stack
 * pointer. If so, after restoring the tasks' context, we will get wrong stack
 * pointer.
 */

Issue of r7 is due to calling convention of ARM.
So why we use naked attribute to make code work should be FIXED?

I think it not a bug or something needs to be fixed, it just a kind of solution.