diff options
| -rw-r--r-- | Various-random-things-explained-I-dont-feel-like-creating-a-separate-txt-for-each-or-ordering-them-in-any-way.txt | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/Various-random-things-explained-I-dont-feel-like-creating-a-separate-txt-for-each-or-ordering-them-in-any-way.txt b/Various-random-things-explained-I-dont-feel-like-creating-a-separate-txt-for-each-or-ordering-them-in-any-way.txt new file mode 100644 index 0000000..cd69b45 --- /dev/null +++ b/Various-random-things-explained-I-dont-feel-like-creating-a-separate-txt-for-each-or-ordering-them-in-any-way.txt @@ -0,0 +1,16 @@ +Supervisor call happens, when the svc (previously called swi) instruction get executed. Exception is then entered. Supervisor call is the standard way for user process to ask the kernel for something. As user code might request many different things, the kernel must somehow know which one was requested. The svc instruction takes one immediate operand. The supervisor call exception handler can check at what address the execution was, read svc instruction from there and inspect it's bytes. This way, by executing svc with different immediate values, the used mode code can request different things from the kernel - the value in svc shall encode the request's type. +To save time and for the sake of simplicity, we don't make use of immediades in svc and instead we encode call's type in r0. In our implementation we decided, that supervisor call will preserve and clobber the same registers as function call and it will return values through r0, just as function call. This enables us to use actually perform the supervisor call as call to function defined in src/arm/PL0/svc.S. Calls from C are performed in src/arm/PL0/PL0_utils.c and request type encodings are defined in src/arm/common/svc_interface.h (they must be known to both user mode code and handler code). + +We've compiled useful utilities (i.e. memcpy(), strlen(), etc.) in src/arm/common/strings.c. Those Do not depend on the environment and can be used by both user mode code, kernel code, even bootloader code. +Functions used for io (like puts()) are also defined in common way for privileged and unprivileged code. They do, however, rely on the existence of putchar() and getchar(). In PL0 code (src/arm/PL0/PL0_utils.c), putchar() and getchar() are defined to perform a supervisor call, that does that operation. In the PL1 code, they are defined as operations on UART. + +src/arm/PL1/PL1_common/uart.c implements putchar() and getchar() in terms of UART. Those implementations are blocking - they poll UART peripheral registers in a loop, checking, if the device is ready to perform the operation. They are, however, accompanied by functions getchar_non_blocking() and putchar_non_blocking(), that check **once** if the device is ready and only perform the operation if it is. Otherwise, they return an error value, Their purpose is to use them with interrupts. In interrupt-driven UART we avoid waiting in a loop - instead, an IRQ comes when desired UART's operation completes. The code that wants to write/read from UART, does, however, need to tie it's operation with IRQ handler and scheduler. Blocking versions should not be used once UART interrupts are enabled or in exception handlers, that should always run quickly. However, doing this does not break UART and might be justified for debugging purposes (like error() function defined in src/arm/common/io.c and used throughout the kernel code). + +There are 2 UARTs in RapsberryPi. One mini UART (also called UART 1) and one PL011 UART (also called UART 0). The PL011 UART is used exclusively in this project. The hardware allows some degree of configuration of which pins which UART is routed to (via so-called alternative functions). In our project it is assumed, that UART 0's TX and RX are routed to GPIO pins 14 & 15 by the firmware, which is true for rpi-open-firmware. With stock Broadcom firmware, either changing the default configuration (config.txt) or selection of alternative fuctions as part of uart initialization (present in TODOs list) might be required. +Before UART can be used, GPIO pins 14 and 15 should have pull up/down disabled. This is done as part of UART initialization in uart_init() in src/arm/PL1/PL1_common/uart.c. There is a requirement that UART is disabled when being configured, which is also fulfilled by uart_init(). The PL011 is toroughly described in BCM2837 ARM Peripherals <link to pdf on github (raspberrypi.org is naughty and throws recaptcha on me)> as well as PrimeCell UART (PL011) Techincal Reference Manual <link>. + +<add to catalogs/files' descriptions... Btw, the sentence b4 those descriptions suggests only catalogs are listed there, which is not true> +TODOs +Contains what the name suggests, in plain text. It lists things that can be implemented or improvemed, as well as tasks, that were once listed and have since been completed (in which case they're marked as done). + +<mention us as authors somewhere in documentation, give contact information> |