docs/os: fix typos

This fixes a few typos in conventions.rst and libc/index.rst.

Signed-off-by: Yanfeng Liu <yfliu2008@qq.com>

Documentation/components/libs/libc/index.rst

@@ -7,16 +7,16 @@ what you would expect to find in a standard C library.  The sub-directories
 in this directory contain standard interface that can be executed by user-
 mode programs.
 
-Normally, NuttX is built with no protection and all threads running in kerne-
-mode.  In that model, there is no real architectural distinction between
+Normally, NuttX is built with no protection and all threads running in kernel-
+mode.  In that mode, there is no real architectural distinction between
 what is a kernel-mode program and what is a user-mode program; the system is
-more like on multi-threaded program that all runs in kernel-mode.
+more like an multi-threaded program that all runs in kernel-mode.
 
 But if the ``CONFIG_BUILD_PROTECTED`` option is selected, NuttX will be built
 into distinct user-mode and kernel-mode sections.  In that case, most of the
 code in the ``nuttx/`` directory will run in kernel-mode with exceptions
 of (1) the user-mode "proxies" found in syscall/proxies, and (2) the
-standard C library functions found in this directory.  In this build model,
+standard C library functions found in this directory.  In this build mode,
 it is critical to separate the user-mode OS interfaces in this way.
 
 If ``CONFIG_BUILD_KERNEL`` is selected, then only a NuttX kernel will be built
@@ -25,9 +25,9 @@ with no applications.
 Sub-Directories
 ===============
 
-The files in the ``libs/libc/`` directory are organized (mostly) according which file
-in the include/ directory provides the prototype for library functions.  So
-we have::
+The files in the ``libs/libc/`` directory are organized (mostly) according
+which file in the ``include/`` directory provides the prototype for library
+functions.  So we have::
 
   audio     - This part of the audio system: nuttx/audio/audio.h
   builtin   - Support for builtin applications.  Used by nuttx/binfmt and NSH.
@@ -128,7 +128,8 @@ Symbol tables have differing usefulness in different NuttX build modes:
    interact with the OS).
 
 #. But in the kernel build mode (``CONFIG_BUILD_LOADABLE``), only fully linked
-   executables loadable via ``execl()``, ``execv()``, or ``posix_spawan()`` can used.
+   executables loadable via ``execl()``, ``execv()``, or ``posix_spawan()``
+   can be used.
    There is no use for a symbol table with the kernel build since all
    memory resources are separate; nothing is share-able with the newly
    started process.

Documentation/reference/os/conventions.rst

@@ -9,7 +9,7 @@ Naming and Header File Conventions
    the architecture-specific implementation in ``arch/``.
 
       ``up_`` is supposed to stand for microprocessor; the ``u``
-      is like the Greek letter micron: ľ. So it would be ``ľP``
+      is like the Greek letter micron: μ. So it would be ``μP``
       which is a common shortening of the word microprocessor. I
       don't like that name very much. I wish I would have used a
       more obvious prefix like ``arch_`` instead -- then I would
@@ -51,8 +51,8 @@ Naming and Header File Conventions
    case I am referring to the OS as layered into application
    interface, common internal OS logic, and lower level
    platform-specific layers. The platform-specific layers all
-   reside in the either ``arch/`` sub-directories on the
-   ``config/`` subdirectories: The former sub-directories are
+   reside in the either ``arch/`` sub-directories or the
+   ``boards/`` subdirectories: The former sub-directories are
    reserved for microcontroller-specific logic and the latter for
    board-specific logic.
 
@@ -66,7 +66,7 @@ Naming and Header File Conventions
 
    This strict layering is enforced in the NuttX build system by
    controlling the compiler include paths: Higher level code can
-   never include header files from either; of the
+   never include header files from either of the
    platform-specific source directories; microcontroller-specific
    code can never include header files from the board-specific
    source directories. The board-specific directories are, then,