wake-0 / fhvOS

This repository contains an os for the arm cortex a8 in combination with beaglebone.
GNU General Public License v2.0
7 stars 1 forks source link

[ProcessManagement] Implement process scheduler #28

Closed wake-0 closed 9 years ago

wake-0 commented 9 years ago

Implement a default process scheduler without mmu.

wake-0 commented 9 years ago

Sample code for starting a timer for the scheduler:

DriverManagerInit();

SchedulerInit();
SchedulerStartProcess(&led1);
SchedulerStartProcess(&led2);

timer2 = DeviceManagerGetDevice("TIMER2", 6);
DeviceManagerInitDevice(timer2);

device_t cpu = DeviceManagerGetDevice("CPU", 3);
DeviceManagerIoctl(cpu, DRIVER_CPU_COMMAND_INTERRUPT_MASTER_IRQ_ENABLE, 0, NULL, 0);
DeviceManagerIoctl(cpu, DRIVER_CPU_COMMAND_INTERRUPT_RESET_AINTC, 0, NULL, 0);

uint16_t timeInMilis = 1;
uint16_t interruptMode = 0x02; // overflow
uint16_t priority = 0x1;

DeviceManagerIoctl(timer2, timeInMilis, interruptMode, (char*) timerISR, priority);
DeviceManagerOpen(timer2);
trylimits commented 9 years ago

It seems like the last commit fixes all the problems we had.

I'm not sure if we should close this ticket and open a new one if we face some issues with the context switch. @Blackjack92 Pls decide this

trylimits commented 9 years ago

I did some refactoring in the scheduler, i.e. I moved the timer initialization and timer isr to the scheduler code.

Furthermore, I have implemented a third process which ends after one iteration and improved the scheduler to handle this case.

The scheduler runs perfectly fine for at least 10 minutes thus fulfilling the requirements :)

ghost commented 9 years ago

do you know why the scheduler crashes after 10mins? is it still the stack overwriting problem?

trylimits commented 9 years ago

It does not crash after 10 mins. I just tested it until it crashes and it was approx. after one hour. And yes, imo it is caused by not restoring the stack pointer properly if the scheduler performs a context switch. I suggest to open a new ticket for that issue.

ghost commented 9 years ago

Take a look at the last line in the restore registers function:

RestoreRegisters: ADD SP, SP, #40 LDMFD SP!, {CPSR}

LDMFD    SP, {R13}^
NOP
ADD      SP, SP, #4
;LDMFD   SP!, {SP}
LDMFD    SP, {R0-R12, PC}^
;ADD         SP, SP, #56

We are restoring the registers without correcting the stack pointer. Then the relative slow crash after about an hour would make sense. What do you think? I'm sorry that I can't test it, I'm currently not st home.

trylimits commented 9 years ago

Further discussion in Bug #44