You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2021/04/07 19:23:09 UTC

[GitHub] [incubator-nuttx] Ouss4 commented on a change in pull request #3470: Documentation: migrate ESP32 README to docs

Ouss4 commented on a change in pull request #3470:
URL: https://github.com/apache/incubator-nuttx/pull/3470#discussion_r608969405



##########
File path: Documentation/platforms/xtensa/esp32/boards/esp32-devkitc/index.rst
##########
@@ -83,3 +176,128 @@ outputted::
 
 From the host the message :code:`test` should be outputted.
 
+smp
+---
+
+Another NSH configuration, similar to nsh, but also enables
+SMP operation.  It differs from the nsh configuration only in these
+additional settings:
+
+SMP is enabled::
+
+  CONFIG_SMP=y
+  CONFIG_SMP_IDLETHREAD_STACKSIZE=3072
+  CONFIG_SMP_NCPUS=2
+  CONFIG_SPINLOCK=y
+
+The apps/testing/smp test is included::
+
+  CONFIG_TESTING_SMP=y
+  CONFIG_TESTING_SMP_NBARRIER_THREADS=8
+  CONFIG_TESTING_SMP_PRIORITY=100
+  CONFIG_TESTING_SMP_STACKSIZE=2048
+
+ostest
+------
+
+This is the NuttX test at apps/examples/ostest that is run against all new
+architecture ports to assure a correct implementation of the OS.  The default
+version is for a single CPU but can be modified for an SMP test by adding::
+
+  CONFIG_SMP=y
+  CONFIG_SMP_IDLETHREAD_STACKSIZE=2048
+  CONFIG_SMP_NCPUS=2
+  CONFIG_SPINLOCK=y
+
+NOTES:
+
+  1. See NOTES for the nsh configuration.
+  2. 2016-12-23: Test appears to be fully functional in the single CPU mode.
+  3. 2016-12-24: But when SMP is enabled, there is a consistent, repeatable
+     crash in the waitpid() test.  At the time of the crash, there is
+     extensive memory corruption and a user exception occurs (cause=28).

Review comment:
       ostest runs fine on SMP now.

##########
File path: Documentation/platforms/xtensa/esp32/boards/esp32-devkitc/index.rst
##########
@@ -44,7 +113,31 @@ Configurations
 nsh
 ---
 
-Basic NuttShell configuration (console enabled in UART0, exposed via USB connection, at 115200 bps).
+Basic NuttShell configuration (console enabled in UART0, exposed via
+USB connection, at 115200 bps). Note the following:
+
+1. Uses the CP2102 USB/Serial converter for the serial console.
+
+2. I have only tested this in IRAM with UART reconfiguration disabled.
+   See "Sample Debug Steps".  In that case, NuttX is started via GDB.
+   It has, however, been reported to me that this configuration also
+   runs when written to address 0x1000 of FLASH with the esptool.py
+   (as described above).  Then NuttX is started via the second level
+   bootloader.  I cannot vouch for that since I have never tried it.
+
+3. There are open clocking issues.  Currently clock configuration
+   logic is disabled because I don't have the technical information
+   to provide that logic -- hopefully that is coming.  As a
+   consequence, whatever clock setup was left when NuttX started is
+   used.  For the case of execution out of IRAM with GDB, the
+   settings in boards/xtensa/esp32/esp32-devkitc/include/board.h work.
+   To check the timing, I use a stop watch and::
+
+     nsh> sleep 60
+
+   If the timing is correct in the board.h header file, the value
+   timed with the stop watch should be about 60 seconds.  If not,
+   change the frequency in the board.h header file.

Review comment:
       We can remove this one, IMO. This information is outdated.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org