Multiprocessing #86
Multiprocessing #86
Conversation
nasko25
commented
Apr 26, 2021
nasko25
commented
- Implemented a context switcher and a dispatcher.
- Rewrote the software and irq handlers (they seems to work, but further testing would be beneficial)
…used by the processes (when we implement them). For now it does not do anything (I am trying to make it work with the already implemented software interrupt handlers by calling SWI from assembly, because it looks like this was intended by the other developers).
Also for some reason calling code from syscall.c causes kernel panic, but running the same code directly does not (not entering the switch statement in syscall() does not cause the kernel panic, so it should be a problem with the inline assembly).
There was a problem in the way inline assembly was executed, so I changed how the variables are taken from the registers. I am not really sure if it is a great way, because I read the syntax might be compiler-dependent, but using registers is already pretty system-dependent, so it shouldn't matter. Also tested more the syscalls code, and it still behaves weirdly, so I made the comment regarding the issue more descriptive.
… in the switch statement fixes the kernel panic. This needs to be investigated further. Probably some registers are incorrectly set before the software interrupt because of the inline assembly?
For some reason the software interrupt handler changed lr, so after returnting from the SWI call, the syscall() function returned to where lr was pointing to (somewhere in software_interrupt_handler()), which caused a kernel panic at some point, probably because of dereferencing an invalid pointer.
Now the software interrupt handler can return the pid of the newly created process.
(I think they were generated by vscode)
|
The day has finally come for the merging storm! I will take a look it at a bit later today after my meetings |
Updates the kernel readme to include the current state of the project, giving people starting on the project a better overview of what already is available to them.
Pi Zero Compatibility; DTB parser
Testing framework rewrite
|
@fayalalebrun Changed something with the early startup and the linker file which broke the build system. I haven't been able to figure it up until now, it should generate the DTB file correctly now but it just doesn't boot anymore. Typically this happens whenever the linker can't find the file. To fix the build just generate the DTB file or add it as a dependency for the two elf files. |
|
@ValentijnvdBeek Indeed, I believe the error must be in the linking. Something must be happening differently in the new Meson build file. However, I'm not able to run the kernel with the Meson build system, not even get qemu to start. Could you update the README? It still refers to Make as the build system. |
Yeah, I suppose it is with the DTB file. Which one needs to be linked in? The one generated by the build file or in src/common?
Qemu not starting is typical for a bad linker script, but I cannot tell what is wrong what is wrong with it now. |
The file in src/common is a binary file, so you can't link it directly. Hence an object file is generated from it by the build script, which is the one you have to link. |
|
When I run it, I get Perhaps kernel_elf is not set to depend on the dtb generation? |
ValentijnvdBeek
force-pushed
the
multiprocessing
branch
from
9018879
to
5b8d841
Compare
