WIP: Documentation: replace first person perspectives

Documentation containing first person perspective phrasing may be
understood as belonging to a single person project (instead of a
community project).

Documentation/applications/examples/nximage/index.rst

@@ -24,9 +24,9 @@ the display. This only works for ``RGB23`` (``888``), ``RGB16`` (``656``), ``RGB
 
 How was that run-length encoded image produced?
 
-1. I used GIMP output the image as a ``.c`` file.
+1. Use GIMP to output the image as a ``.c`` file.
-2. I added some C logic to palette-ize the RGB image in the GIMP ``.c`` file.
+2. Add some C logic to palette-ize the RGB image in the GIMP ``.c`` file.
-3. Then I add some simple run-length encoding to palette-ized image.
+3. Then add some simple run-length encoding to palette-ized image.
 
 But now there is a tool that can be found in the NxWidgets package at
 ``NxWidgets/tools/bitmap_converter.py`` that can be used to convert any graphics

Documentation/applications/graphics/nxwidgets/index.rst

@@ -260,7 +260,7 @@ Work-Arounds
 Build Issues
 ............
 
-1. I have seen this error on Cygwin building C++ code::
+1. This error was reported on Cygwin building C++ code::
 
      LD:  nuttx.rel
      ld: skipping incompatible /home/patacongo/projects/nuttx/nuttx/trunk/nuttx/libxx//liblibxx.a when searching for -llibxx

Documentation/applications/graphics/twm4nx/index.rst

@@ -22,7 +22,7 @@ minimal resources. For example, no assumption is made about the availability of
 a file system; no ``.twmrc`` file is used. Bitmaps are not used (other than for
 fonts).
 
-The TWM license is, I believe compatible with the BSD license used by NuttX. The
+The TWM license is probably compatible with the BSD license used by NuttX. The
 origin TWM license required notice of copyrights within each file and a full
 copy of the original license which you can find in the ``COPYING`` file. within
 this directory.
@@ -34,8 +34,8 @@ Progress
 ~~~~~~~~
 
 - ``2019-04-28`` This port was brutal. Much TWM logic was removed because it
-  depended on X11 features (or just because I could not understand how to use
+  depended on X11 features (or just because it was not obvious how it should be
-  it). The replacement logic is only mostly in place but more needs to be done
+  used). The replacement logic is only mostly in place but more needs to be done
   to have a complete system (hence, it is marked ``EXPERIMENTAL``). The kinds of
   things that need to done are:
 
@@ -49,12 +49,12 @@ Progress
   connection. The server is no longer connected so Twm4Nx constipates and and
   eventually hangs.
 
-- ``2019-05-08`` I abandoned the VNC interface and found that things are much
+- ``2019-05-08`` After abandoning the VNC interface, things are much
   better using a direct, hardware framebuffer. The background comes up properly
   and the Icon Manager appears properly in the upper right hand corner. The Icon
   Manager Window can be iconified or de-iconified. The Icon Manager window can
   be grabbed by the toolbar title and moved about on the window (the movement is
-  not very smooth on the particular hardware that I am working with).
+  not very smooth on the particular hardware used for testing).
 
 - ``2019-05-10`` A left click on the background brings up the main menu. At
   present there are only two options: _Desktop_ which will iconify all windows
@@ -166,9 +166,8 @@ Issues
 ~~~~~~
 
 ``2019-05-16`` Twm4Nx is in a very complete state but only at perhaps _alpha_ in
-its maturity. You should expect to see some undocumented problems. If you see
+its maturity. You should expect to see some undocumented problems.
-such problems and can describe a sequence to actions to reproduce the problem,
+Please report any problems you may encounter.
-let me know and I will try to resolve the problems.
 
 Here are all known issues and features that are missing:
 
@@ -182,7 +181,7 @@ TWM Compatibilities Issues:
 
 There are no near-term plans to address these compatibility issues.
 
-Other issues/bugs. All-in-all, I would say that Twm4Nx is maturing well and is
+Other issues/bugs. Twm4Nx is maturing well and is
 attaining stability. That being said, there are some issues and untested
 functionality that should be addressed:
 
@@ -194,22 +193,22 @@ functionality that should be addressed:
    though the are configured to be borderless).
 3. Most Twm4Nx configuration settings are hard-coded in ``*_config.hxx`` header
    files. These all need to be brought out and made accessible via Kconfig files
-4. I have seen some odd behavior when many NxTerm windows have been opened
+4. There is some odd behavior when many NxTerm windows have been opened
-   (around 15). Specifically, I see failures to start NSH in the windows so they
+   (around 15). Specifically, failures to start NSH in the windows so they
    come up blank. All other behaviors seem normal. Most likely, some NxTerm
    resource allocation is failing silently and leaving things in an unusable
-   state. The board I am using has 128Mb of SDRAM so I can't believe that memory
+   state. The board used for testing has 128Mb of SDRAM so memory is probably
-   is the limiting factor. These are, however, RAM-backed windows and will use
+   not the limiting factor. These are, however, RAM-backed windows and will use
    significant amounts of memory. The primary issue is that the number of
    windows should probably be managed in some way to assure that the end-user
    does not experience odd behaviors when resource usage is high.
-5. Menus with sub-menus have not been verified. There is no use of sub- menus in
+5. Menus with sub-menus have not been verified. There is no use of sub-menus in
-   the current code base so I expect that there are issues when, for example,
+   the current code base so issues may be expected when, for example,
    and item from a sub-menu item: That menu and all of its antecedent menus
    should be closed.
 6. There is an optional MENU button that may appear at the far left on the
    toolbar. It is not used by any window in the current code base and, hence, is
-   unverified. I would expect some issues with generating and routing the MENU
+   unverified. Some issues may be expected with generating and routing the MENU
    button events to applications. There are likely other unverified features.
 7. X/Y input may be either via a touchscreen or a mouse. Only touchscreen input
    has been verified. There is, however, very little difference. The primary

Documentation/applications/interpreters/minibasic/index.rst

@@ -4,8 +4,8 @@
 
 The Mini Basic implementation at ``apps/interpreters`` derives from version ``1.0``
 by Malcolm McLean, Leeds University, and was released under the Creative Commons
-Attibution license. I am not legal expert, but this license appears to be
+Attibution license. This license appears to be
 compatible with the NuttX BSD license see:
-https://creativecommons.org/licenses/. I, however, cannot take responsibility
+https://creativecommons.org/licenses/. However, no responsibility can be taken
-for any actions that you might take based on my understanding. Please use your
+for any actions that you might take based on this understanding. Please use your
 own legal judgement.

Documentation/applications/nsh/login.rst

@@ -174,9 +174,9 @@ start-up script. We can then piggyback the passwd file into the ``/etc``
 file system already mounted for the NSH start up file as described above
 `above <#custinit>`__.
 
-I use the sim/nsh configuration to create a new password file, but other
+The sim/nsh configuration can be used to create a new password file, but other
 configurations could also be used. That configuration already supports a
-ROMFS file system, passwords, and login prompts. First, I make these
+ROMFS file system, passwords, and login prompts. First make these
 changes to that configuration.
 
   #. Disable logins:

Documentation/applications/nsh/running_apps.rst

@@ -175,6 +175,6 @@ There are currently be three ways to execute applications from NSH:
 
    **Next Steps**
 
-   In the longer term, I would like to see an option to move most of the larger
+   In the longer term, it would be good to optionally move most of the larger
    NSH commands out of RAM and built them as standalone programs that can reside,
    for example, on an SD card (**NOT implemented**).

Documentation/applications/system/i2c/index.rst

@@ -58,7 +58,7 @@ or::
 
   nsh> i2c ?
 
-Here is an example of the help output. I shows the general form of the command
+Here is an example of the help output. It shows the general form of the command
 line, the various I2C commands supported with their unique command line options,
 and a more detailed summary of the command I2C command options::
 

Documentation/applications/system/ymodem/index.rst

@@ -18,10 +18,10 @@ Advanced Usage
 ~~~~~~~~~~~~~~
 
 In order to achieve a faster transmission speed,
-I added a specific HEADER ``STC`` to the YMODEM protocol to represent the custom length.
+a specific HEADER ``STC`` was added to the YMODEM protocol to represent the custom length.
 Using the ``sb`` and ``rb`` commands on the board, you can use the ``-k`` option to set the length
 of the custom packet, and the unit is KB. Therefore, you need to use ``sbrb.py`` for file transfer,
-and you need ``sbrb.py`` -k to set the same length as the board. According to my test,
+and you need ``sbrb.py`` -k to set the same length as the board. According to tests,
 when using -k 32, it can reach 93% of the baud rate,
 and is fully compatible with the original ymodem protocol.
 First, you need to add a soft link to sbrb.py, for example ``sudo ln -s /home/<name>/.../<nuttxwork>/apps/system/ymodem/sbrb.py /usr/bin``

Documentation/applications/system/zmodem/index.rst

@@ -27,11 +27,11 @@ Hardware Flow Control
 ~~~~~~~~~~~~~~~~~~~~~
 
 Hardware flow control must be enabled in serial drivers in order to prevent data
-overrun. However, in the most NuttX serial drivers, hardware flow control only
+overrun. However, in most NuttX serial drivers, hardware flow control only
 protects the hardware RX FIFO: Data will not be lost in the hardware FIFO but
 can still be lost when it is taken from the FIFO. We can still overflow the
 serial driver's RX buffer even with hardware flow control enabled! That is
-probably a bug. But the workaround solution that I have used is to use lower
+probably a bug. But the currently implemented workaround solution is to use lower
 data rates and a large serial driver RX buffer.
 
 Those measures should be unnecessary if buffering and hardware flow control are
@@ -70,7 +70,7 @@ Buffer Recommendations
 ~~~~~~~~~~~~~~~~~~~~~~
 
 Based on the limitations of NuttX hardware flow control and of the Linux sz
-behavior, I have been testing with the following configuration (assuming ``UART1``
+behavior, testing was conducted with the following configuration (assuming ``UART1``
 is the ZModem device):
 
 1) This setting determines that maximum size of a data packet frame::
@@ -215,9 +215,9 @@ Status
 
 - ``2013-7-15``: Testing against the Linux ``rz``/``sz`` commands.
 
-  I have tested with the ``boards/arm/lpc17xx_40xx/olimex-lpc1766stk``
+  Performed tests with the ``boards/arm/lpc17xx_40xx/olimex-lpc1766stk``
-  configuration. I have been able to send large and small files with the target
+  configuration. Large and small files were transferred with the target
-  ``sz`` command. I have been able to receive small files, but there are problems
+  ``sz`` command. It was possible to receive small files, but there are problems
   receiving large files using the Linux ``sz`` command: The Linux ``sz`` does not
   obey the buffering limits and continues to send data while ``rz`` is writing the
   previously received data to the file and the serial driver's RX buffer is
@@ -235,9 +235,9 @@ Status
 
 - ``2013-7-16``. More Testing against the Linux ``rz``/``sz`` commands.
 
-  I have verified that with debug off and at lower serial BAUD (``2400``), the
+  Verified that with debug off and at lower serial BAUD (``2400``), the
-  transfers of large files succeed without errors. I do not consider this a
+  transfers of large files succeed without errors. This is considered a
-  _solution_ to the problem. I also found that the LPC17xx hardware flow control
+  _solution_ to the problem. In addition the LPC17xx hardware flow control
   caused strange hangs; ZModem works better with hardware flow control disabled
   on the LPC17xx.
 
@@ -267,7 +267,7 @@ Status
 
   Verified correct operation with hardware flow control using the
   ``olimex-stm32-p407/zmodem`` configuration with target-to-host transfers was
-  verified. Again, there are issues remaining if I tried the NuttX ``rz`` utility
+  verified. Again, there are issues remaining when using the NuttX ``rz`` utility
   running on Linux.
 
 - ``2018-6-26``

Documentation/applications/tools/index.rst

@@ -22,8 +22,7 @@ supports resizing via pixel replication instead of interpolation).
 When a simple graphics image does not encode well, the symptom is that the
 resulting RLE data structures are quite large. The palette structure, in
 particular, may have hundreds of colors in it. There is a way to fix the graphic
-image in this case. Here is what I do (in fact, I do this on all images prior to
+image in this case. Here is what can be done:
-conversion just to be certain):
 
 - Open the original image in GIMP.
 - Select the option to select the number of colors in the image.

Documentation/applications/wireless/i8sak/index.rst

@@ -36,9 +36,9 @@ How To Use
 The i8sak app has a series of CLI functions that can be invoked. The default
 i8sak command is ``i8`` to make things quick and easy to type.
 
-In my test setup I have 2 Clicker2-STM32 boards from MikroElektronika, with the
+A test setup contained 2 Clicker2-STM32 boards from MikroElektronika, with the
-BEE-click (MRF24J40) radios. Choose one device to be the PAN Coordinator. We'll
+BEE-click (MRF24J40) radios. Choose one device to be the PAN Coordinator.
-refer to that as device A.
+This device is referred to as device A.
 
 On that device, run::
 
@@ -165,7 +165,7 @@ the ``-d`` option.
 
 **Note**: Currently, the indirect transaction timeout is disabled. This means
 frames must be extracted or space may run out. This is only for the testing
-phase as it is easier to debug when I am not fighting a timeout. Re-enabling the
+phase as it is easier to debug when not fighting a timeout. Re-enabling the
 timeout may effect the behavior of the indirect transaction features in the
 ``i8sak`` app.
 

Documentation/contributing/coding_style.rst

@@ -1481,7 +1481,7 @@ the naming of `enumeration values <#enumerations>`__.
 -  **Uppercase**. Macro names are always in upper case.
 -  **Lowercase Exceptions**. There are a few lower case values in NuttX
    macro names. Such as a lower-case ``p`` for a period or decimal point
-   (such as ``VOLTAGE_3p3V``). I have also used lower-case ``v`` for a
+   (such as ``VOLTAGE_3p3V``). The lower-case ``v`` is also used for a
    version number (such as ``CONFIG_NET_IPv6``). However, these are
    exceptions to the rule rather than illustrating a rule.
 -  **Macros that could be functions**. Lower-case macro names are also

Documentation/contributing/making-changes.rst

@@ -8,8 +8,7 @@ Making Changes Using Git
 The Apache NuttX project uses the `Git version control system <https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control>`_
 to track changes, and the source code is hosted on `GitHub <https://www.github.com>`_.
 
-If you want to make changes to NuttX, for your own personal use, or to submit them back to project to improve NuttX,
+If you want to make changes to NuttX, for your own personal use, or to submit them back to the project to improve NuttX, that's easy. For the purposes of this guide, you will need a `GitHub <https://www.github.com>`_ account, since
-that's easy. For the purposes of this guide, you'll need a `GitHub <https://www.github.com>`_ account, since
 the Apache NuttX team uses GitHub. (You could also use git locally, or save your changes to other sites like
 `GitLab <https://about.gitlab.com/>`_ or `BitBucket <https://bitbucket.org>`_, but that's beyond the scope of this
 guide).
@@ -71,10 +70,10 @@ Git Workflow With an Upstream Repository
 The main NuttX git repository is called an "upstream" repository - this is because it's the main source of truth, and
 its changes flow downstream to people who've forked that repository, like us.
 
-Working with an upstream repo is a bit more complex, but it's worth it since you can submit fixes and features
+Working with an upstream repo is a bit more complex, but it is worth the effort since you can submit fixes and features
 to the main NuttX repos. One of the things you need to do regularly is keep your local repo in sync
-with the upstream. I work with a local branch, make changes, pull new software from the upstream and merge it in,
+with the upstream. While working with a local branch you can make changes, pull new software from the upstream and merge it in,
-maybe doing that several times. Then when everything works, I get my branch ready to do a Pull Request. Here's how:
+maybe doing that several times. Then when everything works, the branch is ready to be proposed as a Pull Request. That is how it works:
 
 #. Fetch upstream changes and merge into my local master:
 
@@ -171,10 +170,10 @@ Submitting Your Changes to NuttX
 
 Before you do a Pull Request, the NuttX team will usually want all the changes you made in your branch "squashed" into
 a single commit, so that when they review your changes, there's a clean view of the history. If there are changes
-after Pull Request review feedback, they can be separate commits. Here's the easiest way I found to do that initial
+after Pull Request review feedback, they can be separate commits. Here is the easiest way to do this initial
 squash before submitting the Pull Request:
 
-#. Check out my branch
+#. Check out ``my-branch``
 
     .. code-block:: bash
 
@@ -268,7 +267,7 @@ So, someone will ask you some enigmatic thing: "Please rebase and squash these c
 Basically what they are saying is that you need to update your repository
 and fuse your commits in a single commit.
 
-Let walk through the steps to do it!
+Let us walk through the steps to do it!
 
 Move to upstream branch and pull the new commits from there:
 

Documentation/implementation/simulation.rst

@@ -60,7 +60,8 @@ If you want to access a host device driver, then the code that does that has to
 Toward a General Design
 =======================
 
-There is no design in place for accessing Host devices from the simulation.  Here are some directions that I would investigate, however.
+There is no design in place for accessing Host devices from the simulation.
+Here are some directions that could be worth investigating, however.
 
 Perhaps you could create a NuttX FIFO in the NuttX blob.  It would reside at, say, ``/dev/mydevice`` in the NuttX VFS.  Perhaps this FIFO could be used in the NuttX world as your character device?  Perhaps it could read and write from FIFOs to intermediate the interaction with the host PC device?
 
@@ -96,13 +97,13 @@ The current NuttX host simulation has no interrupts and, hence, is non-preemptib
 
 Currently, all timing and serial input is simulated in the IDLE loop: When nothing is going on in the simulation, the IDLE loop runs and fakes timer and UART events.
 
-I have been thinking about how to implement simulated interrupts in the simulation.  I think a solution would work like this.
+The simulation of interrupts needs some thought. A possible solution could look like this:
 
   * In the earliest initialization, simulator could start a host simulation interrupt thread and setup a signal handler to catch signals on the main thread.  One signal, say ``SIGUSER`` could indicate a context switch.  This would be a type ``SA_SIGINFO`` and the context switch information would be provided in the ``sival_t`` field of the ``siginfo``.
 
   * Interrupt logic could be implemented on a host pthread.  The host pthread, like a hardware interrupt, executes asynchronously outside of the operating system.  The interrupt thread could wait for a host signal or a host message and, upon receipt, perform simulated interrupt logic.
 
-  * ``up_interrupt_context()`` would need to be implemented; it is only a stub now.  I think this could be done with a simple global boolean like:
+  * ``up_interrupt_context()`` would need to be implemented; it is only a stub now.  This could probably be done with a simple global boolean like:
 
     .. code-block:: console
 
@@ -132,7 +133,7 @@ The threading is a little mind-bending.  The signal handler needs to run in the
 
 When ``up_longjmp()`` is executing, operation will continue under the main thread, but the context including the stack are different for the new NuttX thread.  When the context finally switches back to this thread, it will appear as an appear return from ``up_setjmp()`` with a non-zero return value.  In that case, the signal handler will just return and the normal execution of the preempted NuttX task will resume.
 
-**Issues**.  My only real technical questions involve signal masking.  When the ``SIGUSER`` signal handler executes, the ``SIGUSER`` interrupt will be masked.  That would prevent any further context switches until the signal handler returns.  Can we simply *unmask* ``SIGUSER`` signal to get more context switches?  I would need to experiment to know for sure.
+**Issues**.  My only real technical questions involve signal masking.  When the ``SIGUSER`` signal handler executes, the ``SIGUSER`` interrupt will be masked.  That would prevent any further context switches until the signal handler returns.  Can we simply *unmask* ``SIGUSER`` signal to get more context switches?  This detail needs to be clarified by experiments.
 
 Supported Devices
 =================
@@ -167,7 +168,7 @@ SMP
 
 There is a simulator configuration has basic support for SMP testing.  The simulation supports the emulation of multiple CPUs by creating multiple pthreads, each run a copy of the simulation in the same process address space.
 
-At present, the SMP simulation is not fully functional:  It does operate on the simulated CPU threads for a few context switches then fails during a setjmp() operation.  I suspect that this is not an issue with the NuttX SMP logic but more likely some chaos in the pthread controls.  I have seen similar such strange behavior other times that I have tried to use setjmp/longmp from a signal handler! Like when I tried to implement simulated interrupts using signals.
+At present, the SMP simulation is not fully functional:  It does operate on the simulated CPU threads for a few context switches then fails during a setjmp() operation.  It is suspected that this is not an issue with the NuttX SMP logic but more likely some chaos in the pthread controls.  Similar strange behavior was seen in other times where setjmp/longmp was used from a signal handler. For example when implementing simulated interrupts using signals.
 
 Apparently, if longjmp is invoked from the context of a signal handler, the result is undefined: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm
 
@@ -213,4 +214,4 @@ But for example, this command:
 
     nsh> sleep 1 &
 
-will execute the sleep command on CPU1 which has worked every time that I have tried it (which is not too many times).
+will execute the sleep command on CPU1 which has worked every time it was tested.

Documentation/introduction/about.rst

@@ -239,7 +239,7 @@ OS with all of that?
     you actually use.
 
     Using a variety of technologies, NuttX can scale from the very tiny to the moderate-size system.
-    I have executed NuttX with some simple applications in as little as 32K *total* memory (code and
+    NuttX was seen operating with some simple applications in as little as 32K *total* memory (code and
     data). On the other hand, typical, richly featured NuttX builds require more like 64K (and
     if all of the features are used, this can push 100K).
 

Documentation/introduction/development_environments.rst

@@ -39,7 +39,7 @@ referenced above may be build in the Cygwin environment as well.
 Windows with Cygwin + GNU ``make`` + SDCC (custom built under Cygwin)
 =====================================================================
 
-I have never tried this combination, but it would probably work just
+This combination was not reported to have ever been tested, but it would probably work just
 fine.
 
 Windows with Cygwin + GNU ``make`` + Windows Native Toolchain
@@ -95,11 +95,11 @@ At present, this build environment also requires:
 
 **Windows Console**. The build must be performed in a Windows console
 window. This may be using the standard ``CMD.exe`` terminal that comes
-with Windows. I prefer the ConEmu terminal which can be downloaded from:
+with Windows. The ConEmu terminal may be preferable. It can be downloaded from:
 http://code.google.com/p/conemu-maximus5/
 
-**GNUWin32**. The build still relies on some Unix-like commands. I
+**GNUWin32**. The build still relies on some Unix-like commands.
-usethe GNUWin32 tools that can be downloaded from
+The GNUWin32 tools may be of use here. They can be downloaded from
 http://gnuwin32.sourceforge.net/. See the top-level ``nuttx/README.txt``
 file for some download, build, and installation notes.
 
@@ -112,7 +112,7 @@ there may be conflicts.
 Wine + GNU ``make`` + Windows Native Toolchain
 ==============================================
 
-I've never tried this one, but I off the following reported by an ez80
+The following was reported by an ez80
 user using the ZiLOG ZDS-II Windows-native toolchain:
 
    "I've installed ZDS-II 5.1.1 (IDE for ez80-based boards) on wine
@@ -141,8 +141,8 @@ very likely that NuttX would work in that environment as well (with some
 porting effort). If GNU make is not supported, then some significant
 modification of the Make system would be required.
 
-**MSYS**. I have not used MSYS but what I gather from talking with NuttX
+**MSYS**. MSYS was not specifically tested, but some users consider it
-users is that MSYS can be used as an alternative to Cygwin in any of the
+as an alternative to Cygwin in any of the
 above Cygwin environments. This is not surprising since MSYS is based on
 an older version of Cygwin (cygwin-1.3). MSYS has been modified,
 however, to interoperate in the Windows environment better than Cygwin

Documentation/platforms/arm64/fvp-v8r/boards/fvp-armv8r/README.txt

@@ -53,7 +53,7 @@ Note:
       terminal_2: Listening for serial connection on port 5002
       terminal_3: Listening for serial connection on port 5003
 
-     FVP has four UART port and I choice UART1 as tty, so just telnet to port 5001
+     FVP has four UART port and UART1 was choosen as tty, so just telnet to port 5001
      will enter nsh:
      telnet localhost 5001
 

Documentation/platforms/arm64/qemu/boards/qemu-armv8a/README.txt

@@ -316,17 +316,17 @@ Status
 
 2022-07-01:
 
-1. It's very stranger to see that signal testing of ostest is PASSED at Physical Ubuntu PC
+1. It's very strange to see that signal testing of ostest is PASSED at Physical Ubuntu PC
-   rather than an Ubuntu at VMWare. For Physical Ubuntu PC, I have run the ostest
+   rather than an Ubuntu at VMWare. For Physical Ubuntu PC, the ostest was run
-   for 10 times at least but never see the crash again, but it's almost crashed every time
+   for 10 times at least but the crash was never seen again, but it's almost crashed every time
    running the ostest at Virtual Ubuntu in VMWare
-   I check the fail point. It's seem at signal routine to access another CPU's task context reg
+   Checking for the the fail point. It's seem at signal routine to access another CPU's task context reg
-   will get a NULL pointer, but I watch the task context with GDB, everything is OK.
+   will get a NULL pointer, but watch the task context with GDB, shows everything as OK.
-   So maybe this is a SMP cache synchronize issue? But I have done cache synchronize
+   So maybe this is a SMP cache synchronize issue? But synchronize operations have
-   operation at thread switch and how to explain why the crash not happening at
+   been done at thread switch. It is hard to explain why the crash is not happening with a
-   Physical Ubuntu PC?
+   Physical Ubuntu PC.
-   So maybe this is a qemu issue at VMWare. I am planning to run
+   So maybe this is a qemu issue at VMWare.
-   the arm64 to real hardware platform like IMX8 and will check the issue again
+   ``arm64`` should be tested on a real hardware platform like IMX8 for the above issue.
 
 2022-06-12:
 
@@ -426,7 +426,7 @@ The nuttx ELF image can be debugged with QEMU.
 
 FPU Support and Performance
 ===========================
-  I was using FPU trap to handle FPU context switch. For threads accessing
+  The FPU trap was used to handle FPU context switch. For threads accessing
 the FPU (FPU instructions or registers), a trap will happen at this thread,
 the FPU context will be saved/restore for the thread at the trap handler.
   It will improve performance for thread switch since it's not to save/restore
@@ -450,7 +450,7 @@ index c58fb45512..acac6febaa
  DEPPATH += --dep-path syslog
  VPATH += :syslog
 +syslog/lib_syslog.c_CFLAGS += -mgeneral-regs-only
-   I cannot commit the patch for NuttX mainline because it's very special case
+   This patch cannot be merged into NuttX mainline because it is a very special case
 since ostest is using syslog for lots of information printing. but this is
 a clue for FPU performance analysis. va_list object is using for many C code to
 handle argument passing, but if it's not passing floating point argument indeed.

Documentation/platforms/avr/at32uc3/boards/avr32dev1/README.txt

@@ -79,9 +79,9 @@ Serial Connection
 USART1 is the default USART1 used in the configuration files to
 provide a serial console (of course, that can be easily changed
 by editing the configuration file).  The AVR32DEV1 board has no
-RS-232 drivers or connectors on board.  I use an off-board MAX232
+RS-232 drivers or connectors on board.  An off-board MAX232 module
-module that I got on eBay (search for MAX232 if you want to find
+was used (search for MAX232 if you want to find
-one).  I connect the MAX232 board as follows:
+one).  The MAX232 board was conneted as follows:
 
 In boards/avr/at32uc3/avr32dev/include/board.h:
 
@@ -106,7 +106,7 @@ PA17 and PA23 are available from the AVR32DEV1:
   PA11-PA12, PA18-PA19, PA28-PA31............................-0.3 to 3.6V
   Other Pins ............................................... -0.3 to 5.5V
 
-  I get the 5V from another USB port (using the 5V power cable that normally
+  The 5V are taken from another USB port (using the 5V power cable that normally
   provides the extra current needed by my USB IDE drive).
 
 Development Environment
@@ -307,7 +307,7 @@ AVR32 Bootloader
 Reset
 ^^^^^
 
-   I don't trust the reset button -- if you reset and something weird happens,
+   The reset button may not be really reliable -- if you reset and something weird happens,
    try a full power cycle.
 
 Make Tip