Vystem 0.2

docs/shelter/kernel/efifb.md

@@ -0,0 +1,18 @@
+# EFI framebuffer
+
+## Introduction
+
+This subsystem aims to provide a simple way to indicate the boot process state using a progress bar displayed on the EFI GOP framebuffer. For the moment, only framebuffers using 32 bits pixel format are supported. It's defined in `shelter/lib/include/kernel/efifb.h` and implemented in `shelter/lib/src/kernel/efifb.c`.
+
+## Overview
+
+To avoid any complex colors encoding, pixel values for the colors white and gray must be provided through the framebuffer configuration.
+
+The framebuffer parameters are loaded using the `sh_efifb_init_fb(sh_conf_FB_CONFIG *fb_conf,sh_page_PAGE_TABLE_POOL *ptp)` function. This function will:
+1) Load framebuffers dimensions
+2) Identity map the whole framebuffers
+3) Erase the previous texts on the framebuffer, based on the information provided in the framebuffer configuration
+
+The progress bar is initialized using `sh_efifb_init_bar()`. It will draw an empty progress bar.
+
+Finally, to update the progress bar, the `sh_efifb_set_bar(sh_uint8 percent)` function is used.

docs/shelter/kernel/kernel.md

@@ -9,3 +9,4 @@ The Shelter kernel define his own specific APIs like logging and configuration p
 1) [Log API](log.md)
 2) [Config parsing](config.md)
 3) [Tests utilities](testutils.md)
+4) [EFI framebuffer](efifb.md)

docs/shelter/kernel/log.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-The logging API is one of the most important of the entire kernel: it allow it to output informations with various level of importance and various sources.
+The logging API is one of the most important of the entire kernel: it allow it to output informations with various level of importance and various sources, during the early boot period. After the APs bootstrap, the log API is replaced by the print implementation provided by the standard library, because it is thread safe.
 
 ## Output methods
 
@@ -35,7 +35,7 @@ There are two mores functions:
 
 ## Output channels and log level
 
-The Shelter logging API provide higher level functions to output on specific log channels. Here are all the log channels:
+The Shelter logging API provides higher level functions to output on specific log channels. Here are all the log channels:
 - `SH_LOG_DEBUG`: log level 0
 - `SH_LOG_LOG`: log level 1
 - `SH_LOG_WARNING`: log level 2
@@ -43,6 +43,7 @@ The Shelter logging API provide higher level functions to output on specific log
 - `SH_LOG_CRITICAL`: log level 4
 - `SH_LOG_FATAL`: log level 5
 - `SH_LOG_TEST`: log level 6
+- `SH_LOG_FAULT`: log level 7
 
 Each log channel has a log level. The log level is set by the `log_level` boot configuration key. The log API will only output log messages with log level equal or higher to current log level. This restriction doesn't apply to log channel `SH_LOG_TEST`.
 
@@ -69,7 +70,7 @@ The `sh_log_OUTPUT_SOURCE` type is used to store log source. It's a wrapper of `
 
 ## Output payloads
 
-In order to compile all of those informations into one payload, the logging API provide this structure :
+In order to compile all of those informations into one payload, the logging API provides this structure :
 ``` C
 typedef struct {
   sh_log_OUTPUT_TYPE output_type;
@@ -115,7 +116,7 @@ They all need two arguments in the following order (except `sh_log_ltest` which
 
 ### Logging with formating
 
-In order to allow for formatting log messages, the log API provide functions named like this:
+In order to allow for formatting log messages, the log API provides functions named like this:
 ```
 sh_log_f[test/debug/log/warning/error/critical/fatal]
 ```