[En-Nut-Discussion] arm port (RFC: Changing ARM mode)

[Rocendo Bracamontes del Toro]

Hi,

While previously debugging our system, I found the following:

.- "user mode stack" was not initialized on the cstartup, therefore any 
attempt to change to user mode failed and produced undefined behavior. 
This was very simple to fix, just modify the stack initialization.

.- When entering an ISR, the processor switches to IRQ mode, and there 
also a IRQ_ENTRY, IRQ_EXIT, these macros do not change the processor 
mode. In my case I wanted to process the ISR in "user" mode, so I 
enhanced the macros to change to "user" mode, also the potentially 
support nested interrupts as long as the ISR is carefully written to be 
re-entrant.

wold be great if we could run the kernel in supervisor mode and 
everything else on user/system mode.  To achieve that we will need to 
differentiate the calls to the OS that yield CPU to others threads.

Using "SWI" is very handy while running a preemptive OS, since SWI takes 
the processor to a privileged mode "IRQ".

I  think having an "enter kernel routine" makes easy decide when to 
change to "supervisor", or  having a list of  calls  that eventually 
will yield  cpu would do the job too.

 Let me know how could I help.

Thanks
rocendo
/
/Harald Kipp escribió:
> Ole Reinhardt wrote:
>   
>> In which cases would we need 'enter kernel routine'? In some interrupt
>> driven functions? All other driver code shold just run fine in user
>> mode, does it?
>>     
>
> At least NutEnter/ExitCritical() won't work in user mode, if I correctly
> understood the ARM documents.
>
>   
>> For me it sounds much cleaner to run as most code as possible in user
>> mode and implement such context switch functions???
>>     
>
> Do you have any idea, what else is disabled in user mode?
>
> Protected OSes use an exception like SWI to switch the mode. No idea how
> to implement this in Nut/OS, where the kernel is a bunch of libs only.
>
> Harald
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>