diff --git a/building/README.md b/building/README.md index a11c09eb..3dbb99f6 100644 --- a/building/README.md +++ b/building/README.md @@ -206,13 +206,13 @@ Firstly, you need to have the docker installed. export PATH="/Applications/Docker.app/Contents/Resources/bin:$PATH" ``` - It's recommended to place it in `.zshrc` startup script to export in every time during startup: + It's recommended to place it in `.zshrc` startup script to export it every time during startup: ```bash echo "export PATH=\"/Applications/Docker.app/Contents/Resources/bin:\$PATH\"" >> $HOME/.zshrc ``` -- Check if Docker is properly installed by checking version: +- Check if Docker is properly installed by checking its version: ``` bash docker --version @@ -251,7 +251,7 @@ This is the method preferred when you plan to develop Phoenix-RTOS. Firstly, you need to install some tools required for compiling the toolchain and finally create a Phoenix-RTOS system image. -There is a list of commands you can use to get them: on both Ubuntu and MacOS host operating systems. +There is a list of commands you can use to get them: on both Ubuntu and macOS host operating systems.
Intalling required tools for native build on Ubuntu (click to expand) @@ -310,7 +310,7 @@ There is a list of commands you can use to get them: on both Ubuntu and MacOS ho *Note that you have to place the `gnubin` path that provides `make` before the `/usr/bin` in the `PATH` environment variable to use the `gnu` version (as it is done above). - Phoenix-RTOS requires the `endian.h` header, which may exist, but not be visible. If during the buildig you discover + Phoenix-RTOS requires the `endian.h` header, which may exist, but not be visible. If during the building you discover the following error: `fatal error: 'endian.h' file not found` please create the symlink to this header by the given command: diff --git a/building/script.md b/building/script.md index 541c4c67..c26793d9 100644 --- a/building/script.md +++ b/building/script.md @@ -9,7 +9,7 @@ TARGET=ia32-generic-qemu phoenix-rtos-build/build.sh all As you can see there can be other arguments like `all`. -You can also use the `clean` argument to clean last build artifacts. +You can also use the `clean` argument to clean the last build artifacts. ```bash TARGET=ia32-generic-qemu phoenix-rtos-build/build.sh clean all @@ -33,8 +33,8 @@ The available components are listed below: - `image` - system image to be loaded to the target, For example, in ia32-generic-qemu target `all` means `core fs image project ports`.
-For the other targets `all` can be different components configurations.
-You can also choose what components do you want to build, for example the following command will build a system image +For the other targets, `all` can be different components configurations.
+You can also choose what components you want to build, for example, the following command will build a system image without test and ports components. The `ports` component compiling process can take a while. If you need to build the system image quickly, you can use the command above. diff --git a/building/toolchain.md b/building/toolchain.md index f9d3ce58..a4b1db60 100644 --- a/building/toolchain.md +++ b/building/toolchain.md @@ -7,7 +7,7 @@ Phoenix-RTOS provides its toolchain, based on GNU CC. It's divided into the foll - riscv64-phoenix - sparc-phoenix -Each part delivers the tools required to compile for the given architecture simply. +Each part delivers the tools required to compile the given architecture simply. There are a few reasons why that is helpful - You can easily compile source code for a given Phoenix-RTOS platform, for example, ia32-generic-qemu: diff --git a/corelibs/README.md b/corelibs/README.md index 57e08dec..32b357cf 100644 --- a/corelibs/README.md +++ b/corelibs/README.md @@ -7,7 +7,7 @@ GitHub repository. The example of usage can be found in the `_user` directory, placed in [phoenix-rtos-project](https://github.com/phoenix-rtos/phoenix-rtos-project). -Read more about reference project repository [here](../project.md). +Read more about the reference project repository [here](../project.md). There are following Phoenix-RTOS libraries: diff --git a/corelibs/libcache.md b/corelibs/libcache.md index 89d63728..ab09573f 100644 --- a/corelibs/libcache.md +++ b/corelibs/libcache.md @@ -227,11 +227,11 @@ into the buffer. The address of the first whole line is computed as follows: ```(address of the first byte to be read - offset of the first byte) + size of a cache line``` The addresses of following lines are computed by adding the size of a whole cache line to the address of a previous - line. Each of these addresses is mapped on to a specific cache set. Lookup in a set is performed according to the + line. Each of these addresses is mapped onto a specific cache set. Lookup in a set is performed according to the algorithm below: -1. The tag computed from the memory address becomes a part of a key used to perform binary search in a table of pointers -to cache lines sorted by the tag (dark gray table in the image above). +1. The tag computed from the memory address becomes a part of a key used to perform a binary search in a table of +pointers to cache lines sorted by the tag (dark gray table in the image above). 2. If a line marked by the tag is found, it becomes the MRU line. The pointers in the circular doubly linked list are rearranged so that this line is stored in the tail of the list. 3. The pointer to the found line is returned. @@ -244,10 +244,10 @@ Writing via the cache is implemented similarly to reading: data is written in th buffer. The user might want to update just a few bytes in a specific cache line, hence the line needs to be -found in the cache first. On success the bytes starting from the offset are updated and a chosen to write policy is +found in the cache first. On success, the bytes starting from the offset are updated and a chosen to write policy is executed. -If it happens that a line mapped from a specific address does not exist in the cache, it is +If it happens, that a line mapped from a specific address does not exist in the cache, it is created and written to the cache according to the algorithm below: 1. The pointer to the LRU line is removed from the circular doubly linked list and dereferenced to find a pointer (a @@ -277,7 +277,7 @@ cache clean instead. ### Cleaning the cache -The clean operation combines both cache flush and cache invalidate operations in atomic way while also providing a +The clean operation combines both cache flush and cache invalidate operations in an atomic way while also providing better efficiency than if the user were to perform cache flush followed by cache invalidate. ## Running tests diff --git a/corelibs/libgraph.md b/corelibs/libgraph.md index e411a44a..0d16b408 100644 --- a/corelibs/libgraph.md +++ b/corelibs/libgraph.md @@ -81,7 +81,7 @@ Examples of applications, which use graphics library (`ia32-generic-qemu` target Initializes the `graph_t` structure and opens a context for the specified graphics adapter. The uninitialized `graph_t` structure should be passed in the _`graph`_ argument and the graphics _`adapter`_ should be chosen from the following list: - - `GRAPH_NONE` - the graphics adapter isn't specified, in this case the function returns `-ENODEV` + - `GRAPH_NONE` - the graphics adapter isn't specified, in this case, the function returns `-ENODEV` - `GRAPH_VIRTIOGPU` - generic VirtIO GPU graphics adapter - `GRAPH_VGA` - generic VGA graphics adapter - `GRAPH_CIRRUS` - Cirrus Logic graphics adapter @@ -98,8 +98,8 @@ Examples of applications, which use graphics library (`ia32-generic-qemu` target - `int graph_mode(graph_t *graph, graph_mode_t mode, graph_freq_t freq)` Sets graphics mode with specified screen refresh rate frequency. The initialized _`graph`_ structure should be passed, - and _`mode`_ should be chosen from the `graph_mode_t` enum, placed in the `graph.h` header. The common graphics modes - are presented below: + and _`mode`_ should be chosen from the `graph_mode_t` enum, and placed in the `graph.h` header. The common graphics + modes are presented below: - `GRAPH_DEFMODE` - default graphics mode - `GRAPH_ON` - display enabled mode - `GRAPH_OFF` - display disabled mode @@ -157,20 +157,20 @@ color, graph_queue_t queue)` - `int graph_fill(graph_t *graph, unsigned int x, unsigned int y, unsigned int color, graph_fill_t type, graph_queue_t queue)` - Fills a closed figure with color specified in the _`color`_ argument ((_`x`_, _`y`_) should be any point inside the + Fills a closed figure with the color specified in the _`color`_ argument ((_`x`_, _`y`_) should be any point inside the figure to fill). The following `graph_fill_t` color fill methods are supported: - `GRAPH_FILL_FLOOD` - works like Windows paint bucket tool (floods homogeneous area, all pixels inside the polygon with color values same as the one at (_`x`_, _`y`_) flood origin point) - `GRAPH_FILL_BOUND` - fills the polygon until an edge of the same color as the fill color is found. It can't fill the - figure with color different from the figure boundary + figure with a color different from the figure boundary - `int graph_print(graph_t *graph, const graph_font_t *font, const char *text, unsigned int x, unsigned int y, unsigned char dx, unsigned char dy, unsigned int color, graph_queue_t queue)` Prints text pointed by the _`text`_ argument. Font data should be passed to `graph_font_t` structure. The example is stored in `gfx` directory in [phoenix-rtos-tests](https://github.com/phoenix-rtos/phoenix-rtos-tests.git) - repository (`font.h` file). The remaining arguments are similar to those from functions above. + repository (`font.h` file). The remaining arguments are similar to those from the functions above. - `int graph_move(graph_t *graph, unsigned int x, unsigned int y, unsigned int dx, unsigned int dy, int mx, int my, graph_queue_t queue)` @@ -182,7 +182,7 @@ graph_queue_t queue)` unsigned int dstspan, graph_queue_t queue)` Copies a bitmap pointed by the _`src`_ argument into bitmap pointed by the _`dst`_ argument. The area which is copied - is limited by a rectangle with _`dx`_ and _`dy`_ dimensions. There should also be specified span arguments, which is + is limited by a rectangle with _`dx`_ and _`dy`_ dimensions. There should also be specified span arguments, which are the total width of a source/destination bitmap multiplied by its color depth. When copying some part of a bitmap, _`src`_ should point to the proper element, same with destination buffer. @@ -190,7 +190,7 @@ unsigned int dstspan, graph_queue_t queue)` Sets a color palette used for 8-bit indexed color mode. A color map should be passed in _`cmap`_ argument. The range of changing colors is set by passing _`first`_ and _`last`_ arguments. If a set color palette's size is lower than a - default one, remaining colors are the same. + default one, the remaining colors are the same. - `graph_colorget(graph_t *graph, unsigned char *colors, unsigned char first, unsigned char last)` @@ -202,9 +202,10 @@ int fg)` Sets cursor icon, _`amask`_ (`AND` mask) and _`xmask`_ (`XOR` mask) arguments determine the shape of the cursor. Default cursor shape is defined in `cursor.h` header file placed in `gfx` directory in `phoenix-rtos-tests` - repository. There is possibility to pass cursor colors - outline color (`bg` argument) and main color (`fg` argument). - The following color format should be applied: `0xAARRGGBB`, where `A` represents alpha, so when it's set to `0xff` - 100% opacity is provided. Opacity isn't supported for cirrus graphics adapter (default for `ia32-generic-qemu` target) + repository. There is a possibility to pass cursor colors - outline color (`bg` argument) and main color + (`fg` argument). The following color format should be applied: `0xAARRGGBB`, where `A` represents alpha, so when it's + set to `0xff` 100% opacity is provided. Opacity isn't supported for cirrus graphics adapter + (default for `ia32-generic-qemu` target) - `int graph_cursorpos(graph_t *graph, unsigned int x, unsigned int y)` @@ -253,7 +254,8 @@ int fg)` ## How to use the graphics library Few simple examples of `libgraph` functions usage. Default graphics adapter (`cirrus`) for `ia32-generic-qemu` running -script is used, default color depth is 4 bytes. Before calling mentioned functions following initialization was applied: +script is used, the default color depth is 4 bytes. Before calling mentioned functions the following initialization +was applied: ```c #include @@ -305,7 +307,7 @@ int main(void) - Printing text using libgraph - Header file with a font data in `graph_font_t` structure has to be included. The example of `font.h` is placed in + Header file with font data in `graph_font_t` structure has to be included. The example of `font.h` is placed in `gfx` directory in [phoenix-rtos-tests](https://github.com/phoenix-rtos/phoenix-rtos-tests) repository. ```C @@ -444,12 +446,12 @@ There are few steps to follow: - for other color depths - export the file to C source/header format (a dialog window pops up with additional options for color conversion) -- At this point image binary data should be available (either as array in `.c` or `.h` file or raw hex dump) +- At this point image binary data should be available (either as an array in `.c` or `.h` file or raw hex dump) - Custom image data formatting might be required -If the image bitmap is ready, there is possibility to display it using `graph_copy()`. Please see the proper example in -[How to use libgraph](#how-to-use-the-graphics-library) chapter. +If the image bitmap is ready, there is a possibility to display it using `graph_copy()`. Please see the proper example +in [How to use libgraph](#how-to-use-the-graphics-library) chapter. ## See also diff --git a/corelibs/libswdg.md b/corelibs/libswdg.md index afaa0d85..05cd2819 100644 --- a/corelibs/libswdg.md +++ b/corelibs/libswdg.md @@ -58,7 +58,7 @@ other operation. `chanCount` has to be greater than zero, `priority` has to be g ### Notes - All channels start disabled, -- Channel configuration does not change it's state, channel needs to be enabled if it was not prior, +- Channel configuration does not change its state, channel needs to be enabled if it was not prior, - Callback function **must not** call any libswdg functions! Deadlock will occur. ## Using libswdg @@ -86,4 +86,4 @@ int main() } ``` -Should `doAppStuff()` function hang/crash for more than 30 seconds, system will reset. +Should `doAppStuff()` function hang/crash for more than 30 seconds, the system will reset. diff --git a/corelibs/libuuid.md b/corelibs/libuuid.md index fff7bdb5..2fafe1a9 100644 --- a/corelibs/libuuid.md +++ b/corelibs/libuuid.md @@ -2,7 +2,7 @@ =================== -Linux libuuid compliant library used to generate unique identifiers for objects that may be accessible +Linux libuuid compliant library is used to generate unique identifiers for objects that may be accessible beyond the system. According to `RFC 4122` and `DCE 1.1` (Distributed Computing Environment) currently supported UUID format is variant 1, version 4 (randomly/pseudo-randomly generated). @@ -15,7 +15,7 @@ version 4 (randomly/pseudo-randomly generated). ## General information -Linux libuuid compliant library used to generate unique identifiers for objects that may be accessible beyond the +Linux libuuid compliant library is used to generate unique identifiers for objects that may be accessible beyond the system. According to `RFC 4122` and `DCE 1.1` (Distributed Computing Environment) currently supported UUID format is variant 1, version 4 (randomly/pseudo-randomly generated). diff --git a/devices/hwaccess.md b/devices/hwaccess.md index 06c5f40c..9c1ff13c 100644 --- a/devices/hwaccess.md +++ b/devices/hwaccess.md @@ -61,7 +61,7 @@ does not contain the `MAP_FAILED` value, which would indicate that `mmap` failed ### ISA without MMU -On architectures without `MMU` access to the hardware registers does not require prior memory mapping. Registers can be +On architectures without `MMU`, access to the hardware registers does not require prior memory mapping. Registers can be accessed by directly setting a volatile pointer to the desired physical base address. ## See also diff --git a/devices/interface.md b/devices/interface.md index efbc9d00..bdf94fc6 100644 --- a/devices/interface.md +++ b/devices/interface.md @@ -18,7 +18,7 @@ not have to create separate ports for them. The driver needs to assign each "fil Assume we want to create an SPI server that manages 2 instances of the device - spi0 and spi1. We can manage both using only one port by registering the same port as `/dev/spi0` with id = 1 and `/dev/spi1` with id = 2. Every message driver receives contains information to which `oid` (object ID) it has been sent. This enables the driver to recognize to -which special file message has been addressed to. +which special file message has been addressed. If the system does not have a root filesystem, a port can be registered within Phoenix native filesystem by using syscall @@ -67,8 +67,8 @@ Then we can create a new special file and register: ## Message types -There are several standard types of messages, although device driver servers need to implement an only subset of them. -With every message type there are 3 common fields: +There are several standard types of messages, although device driver servers need to implement only a subset of them. +With every message type, there are 3 common fields: - _`type`_ - type of message, - _`pid`_ - process ID of sender, diff --git a/hostutils/psdisk.md b/hostutils/psdisk.md index 180d1fa0..06a314dc 100644 --- a/hostutils/psdisk.md +++ b/hostutils/psdisk.md @@ -20,7 +20,7 @@ To generate an image with a flash memory size, the user should use `-o` option. ## Examples -The following example generates a partition table for MICRON MT25QL01GBBB. The size of the memory and sector bases on +The following example generates a partition table for MICRON MT25QL01GBBB. The size of the memory and sector based on data from ### Creating partition table diff --git a/kernel/proc/scheduler.md b/kernel/proc/scheduler.md index c465db42..b72062b3 100644 --- a/kernel/proc/scheduler.md +++ b/kernel/proc/scheduler.md @@ -18,7 +18,7 @@ the same priority. A scheduling algorithm is defined as follows: 2. The current thread's context for the interrupted core is saved and added to the end of its priority list. 3. The next available thread with the highest priority is selected to be run and is removed from the ready thread list. If a selected thread is a ghost (a thread whose process has ended execution) and has not been executed in a supervisor -mode, it is added to the ghosts list and the reaper thread is woken up. +mode, it is added to the ghosts list and the reaper thread woke up. 4. For the selected thread, the following actions are performed: * A global pointer to the current thread is changed to the selected one, * A pointer to the kernel stack is updated to the stack of a new thread,