[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #3961: net: Add if_nameindex and if_freenameindex API

[GitBox]

xiaoxiang781216 opened a new pull request #3961:
URL: https://github.com/apache/incubator-nuttx/pull/3961


   ## Summary
   Specified here:
   https://man7.org/linux/man-pages/man3/if_nameindex.3.html
   
   ## Impact
   New API
   
   ## Testing
   Internal test case.
   


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a change in pull request #3960: xtensa/esp32: Refactor the text heap and add RTC memory to it

[GitBox]

xiaoxiang781216 commented on a change in pull request #3960:
URL: https://github.com/apache/incubator-nuttx/pull/3960#discussion_r655829504



##
File path: arch/xtensa/src/esp32/esp32_textheap.c
##
@@ -57,16 +51,11 @@ struct mm_heap_s g_textheap;
 
 void up_textheap_init()
 {
-  mm_initialize(_textheap, &_stextheap, &_etextheap - &_stextheap);
-
-#if defined(CONFIG_FS_PROCFS) && !defined(CONFIG_FS_PROCFS_EXCLUDE_MEMINFO)
-  static struct procfs_meminfo_entry_s g_textheap_procfs;
-
-  g_textheap_procfs.name = "textheap";
-  g_textheap_procfs.mallinfo = (void *)mm_mallinfo;
-  g_textheap_procfs.user_data = _textheap;
-  procfs_register_meminfo(_textheap_procfs);
+#ifdef CONFIG_ESP32_RTC_HEAP
+  esp32_rtc_heap_initialize();

Review comment:
   One question should we unify the prefix? 
esp32_rtc[_]heap<->esp32_iramheap?




-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev edited a comment on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev edited a comment on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-865420356


   > @a-lunev what are you trying to achieve? Is this similar to the BDMA/SRAM4 
heap clobbering issue fixed in 
[4716fc929d7](https://github.com/apache/incubator-nuttx/commit/4716fc929d74850283120507e84913838e722904)
 / [PR-3198](https://github.com/apache/incubator-nuttx/pull/3198)?
   
   Hi @hartmannathan,
   Your [PR-3198](https://github.com/apache/incubator-nuttx/pull/3198) is 
different to my PR.
   In your PR SRAM4 should be used by BDMA because BDMA allows access only to 
SRAM4 that was clobbered by the heap and vice versa.
   In my PR SRAM123 and SRAM4 should not be used by SDMMC1 IDMA because SDMMC1 
IDMA does not provide access to SRAM123 and SRAM4 (stm32h7 hardware 
limitation). SDMMC1 IDMA can access only AXI-SRAM memory region, that is the 
main part of the heap, and there is not a clobbering issue.


-- 
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:
us...@infra.apache.org

[incubator-nuttx-website] branch asf-site updated: Publishing web: 934a4647f20f1ab1148ce00d3b05b97fb19ad702 docs: a4289c4f84fc7d55d174b0aa4e77d77c19e9ae07

[github-bot]

This is an automated email from the ASF dual-hosted git repository.

github-bot pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx-website.git


The following commit(s) were added to refs/heads/asf-site by this push:
 new 43ebc97  Publishing web: 934a4647f20f1ab1148ce00d3b05b97fb19ad702 
docs: a4289c4f84fc7d55d174b0aa4e77d77c19e9ae07
43ebc97 is described below

commit 43ebc9774215cdc8e529973a096527d8ed2359e7
Author: Nathan <59230071+hartmannat...@users.noreply.github.com>
AuthorDate: Tue Jun 22 00:08:31 2021 +

Publishing web: 934a4647f20f1ab1148ce00d3b05b97fb19ad702 docs: 
a4289c4f84fc7d55d174b0aa4e77d77c19e9ae07
---
 content/docs/10.0.0/index.html | 2 +-
 content/docs/10.0.1/index.html | 2 +-
 content/docs/10.1.0/index.html | 2 +-
 content/docs/latest/index.html | 2 +-
 content/feed.xml   | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/content/docs/10.0.0/index.html b/content/docs/10.0.0/index.html
index 95ddc2d..2eda2a2 100644
--- a/content/docs/10.0.0/index.html
+++ b/content/docs/10.0.0/index.html
@@ -207,7 +207,7 @@ by following these 
 NuttX Documentation¶
 NuttX is a real-time operating system (RTOS) with an emphasis on standards 
compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller 
environments, the primary governing standards in NuttX are Posix and ANSI 
standards. Additional standard APIs from Unix and other common RTOS’s (such as 
VxWorks) are adopted for functionality not available under these standards, or 
for functionality that is not appropriate for deeply-embedded environments 
(such as fork()).
-Last Updated: 21 June 21 at 00:05
+Last Updated: 22 June 21 at 00:05
 
 Table of Contents
 
diff --git a/content/docs/10.0.1/index.html b/content/docs/10.0.1/index.html
index f96b188..c89f551 100644
--- a/content/docs/10.0.1/index.html
+++ b/content/docs/10.0.1/index.html
@@ -213,7 +213,7 @@ by following these 
 NuttX Documentation¶
 NuttX is a real-time operating system (RTOS) with an emphasis on standards 
compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller 
environments, the primary governing standards in NuttX are Posix and ANSI 
standards. Additional standard APIs from Unix and other common RTOS’s (such as 
VxWorks) are adopted for functionality not available under these standards, or 
for functionality that is not appropriate for deeply-embedded environments 
(such as fork()).
-Last Updated: 21 June 21 at 00:06
+Last Updated: 22 June 21 at 00:05
 
 Table of Contents
 
diff --git a/content/docs/10.1.0/index.html b/content/docs/10.1.0/index.html
index 68bc2c4..a2a37c2 100644
--- a/content/docs/10.1.0/index.html
+++ b/content/docs/10.1.0/index.html
@@ -213,7 +213,7 @@ by following these 
 NuttX Documentation¶
 NuttX is a real-time operating system (RTOS) with an emphasis on standards 
compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller 
environments, the primary governing standards in NuttX are POSIX and ANSI 
standards. Additional standard APIs from Unix and other common RTOS’s (such as 
VxWorks) are adopted for functionality not available under these standards, or 
for functionality that is not appropriate for deeply-embedded environments 
(such as fork()).
-Last Updated: 21 June 21 at 00:06
+Last Updated: 22 June 21 at 00:06
 
 Table of Contents
 
diff --git a/content/docs/latest/index.html b/content/docs/latest/index.html
index cc854ed..1604ff3 100644
--- a/content/docs/latest/index.html
+++ b/content/docs/latest/index.html
@@ -214,7 +214,7 @@ by following these 
 NuttX Documentation¶
 NuttX is a real-time operating system (RTOS) with an emphasis on standards 
compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller 
environments, the primary governing standards in NuttX are POSIX and ANSI 
standards. Additional standard APIs from Unix and other common RTOS’s (such as 
VxWorks) are adopted for functionality not available under these standards, or 
for functionality that is not appropriate for deeply-embedded environments 
(such as fork()).
-Last Updated: 21 June 21 at 00:06
+Last Updated: 22 June 21 at 00:06
 
 Table of Contents
 
diff --git a/content/feed.xml b/content/feed.xml
index b2ef4a9..1f2d101 100644
--- a/content/feed.xml
+++ b/content/feed.xml
@@ -5,8 +5,8 @@
 
 /
 
-Mon, 21 Jun 2021 00:08:08 +
-Mon, 21 Jun 2021 00:08:08 +
+Tue, 22 Jun 2021 00:08:29 +
+Tue, 22 Jun 2021 00:08:29 +
 Jekyll v3.8.5
 
   

[GitHub] [incubator-nuttx] a-lunev edited a comment on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev edited a comment on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-865413409


   > @a-lunev stm32_dmapreflight is used by the high level SDMMC driver 
https://github.com/apache/incubator-nuttx/blob/master/drivers/mmcsd/mmcsd_sdio.c#L1392
 . The debug assert is in addition to that just for debugging.
   
   @davids5 concerning the high level SDMMC driver (drivers/mmcsd/mmcsd_sdio.c) 
there is e.g. mmcsd_read_csd() function that has a local buffer (`uint8_t 
buffer[512] aligned_data(16);`) that is placed on the stack. The stack is 
allocated within the heap. If SRAM123 or SRAM4 is included into the total heap, 
and the local buffer is allocated somewhere in SRAM123 or SRAM4 areas, then the 
buffer address will be passed to SDIO_DMAPREFLIGHT(), the validation will 
trigger error and the target sdio operation will fail.
   There are multiple similar places in NuttX where a not allowed buffer 
address may be passed to dmapreflight() or directly to stm32h7 sdmmc driver 
that will result in a failure.
   It's still not clear what is the strategy to fix those situations?


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev commented on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-865420356


   > @a-lunev what are you trying to achieve? Is this similar to the BDMA/SRAM4 
heap clobbering issue fixed in 
[4716fc929d7](https://github.com/apache/incubator-nuttx/commit/4716fc929d74850283120507e84913838e722904)
 / [PR-3198](https://github.com/apache/incubator-nuttx/pull/3198)?
   
   Hi @hartmannathan,
   Your [PR-3198](https://github.com/apache/incubator-nuttx/pull/3198) is 
different to my PR.
   In your PR SRAM4 should be used by BDMA because BDMA allows access only to 
SRAM4.
   In my PR SRAM123 and SRAM4 should not be used by SDMMC1 IDMA because SDMMC1 
IDMA does not provide access to SRAM123 and SRAM4 (stm32h7 hardware 
limitation). SDMMC1 IDMA can access only AXI-SRAM memory region.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev commented on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-865413409


   > @a-lunev stm32_dmapreflight is used by the high level SDMMC driver 
https://github.com/apache/incubator-nuttx/blob/master/drivers/mmcsd/mmcsd_sdio.c#L1392
 . The debug assert is in addition to that just for debugging.
   
   @davids5 concerning drivers/mmcsd/mmcsd_sdio.c there is e.g. 
mmcsd_read_csd() function that has a local buffer (`uint8_t buffer[512] 
aligned_data(16);`) that is placed on the stack. The stack is allocated within 
the heap. If SRAM123 or SRAM4 is included into the total heap, and the local 
buffer is allocated somewhere in SRAM123 or SRAM4 areas, then the buffer 
address will be passed to SDIO_DMAPREFLIGHT(), the validation will trigger 
error and the target sdio operation will fail.
   There are multiple similar places in NuttX where a not allowed buffer 
address may be passed to dmapreflight() or directly to stm32h7 sdmmc driver 
that will result in a failure.
   It's still not clear what is the strategy to fix those situations?


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev edited a comment on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev edited a comment on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606


   > @a-lunev - Why is this needed when stm32_dmapreflight already excludes it?
   
   Hi David,
   ~~stm32_dmapreflight() depends on the CONFIG_STM32H7_SDMMC_IDMA option that 
as I understand should not do, because IDMA is still in use not depending on 
the option.~~
   Also stm32_dmapreflight() is invoked only if CONFIG_DEBUG_ASSERTIONS option 
is enabled.
   If my understanding is correct, concerning namely SDMMC1 IDMA, 
stm32_dmapreflight() is useful for debug purposes to check if IDMA is trying to 
access not allowed memory regions like SRAM123 and SRAM4. This can be caught 
only if CONFIG_DEBUG_ASSERTIONS option is enabled.
   In a normal build CONFIG_DEBUG_ASSERTIONS option is not enabled. How then 
the system should be prevented from the IDMA access failure?
   On another hand, if CONFIG_DEBUG_ASSERTIONS option is enabled and the assert 
has been triggered, what the further developer's actions should be in this 
particular case with SDMMC1 IDMA? As I understand, normally there are two 
possible options:
   - either to exclude SRAM123 and SRAM4 from the heap allocation;
   - or to use SDMMC2 instead of SDMMC1 as SDMMC2 does not have the access 
limitation.
   
   Please let me know what do you think.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] Ouss4 opened a new pull request #3960: xtensa/esp32: Refactor the text heap and add RTC memory to it

[GitBox]

Ouss4 opened a new pull request #3960:
URL: https://github.com/apache/incubator-nuttx/pull/3960


   ## Summary
   1. Use the slow RTC memory (8KB) as a separate heap.  This is used to 
allocate text for dynamic code loading.
   2. Refactor the text heap section to use both IRAM and RTC memories.
   ## Impact
   ESP32 only.  The RTC option is disabled by default.
   ## Testing
   esp32-devkitc:elf esp32-devkitc:module esp32-devkitc:sotest
   


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #3959: libc/time: Implement timegm function

[GitBox]

xiaoxiang781216 opened a new pull request #3959:
URL: https://github.com/apache/incubator-nuttx/pull/3959


   ## Summary
   and replace mktime to timegm for more security
   
   ## Impact
   
   ## Testing
   ostest


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] hartmannathan commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

hartmannathan commented on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-865214101


   @a-lunev what are you trying to achieve? Is this similar to the BDMA/SRAM4 
heap clobbering issue fixed in 
[4716fc929d7](https://github.com/apache/incubator-nuttx/commit/4716fc929d74850283120507e84913838e722904)
 / [PR-3198](https://github.com/apache/incubator-nuttx/pull/3198)?


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] davids5 commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

davids5 commented on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-865024395


   
   @a-lunev - the stm32_dmapreflight does the right thing.  The lame FIFO 
requires IDMA. But to a buffer that is not from the heap.
   
   > Please let me know what do you think.
   
   I think the exclusion from the heap for this drive is not the correct 
solution. The solution is in place. Did not work or is this just a 
misunderstanding or configuration issue on your part?
   
   You may want to add the Exclusion as an option in a separate PR but it can 
not come in here


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] acassis commented on issue #3765: GSoC: NuttX support for pysimCoder (info thread)

[GitBox]

acassis commented on issue #3765:
URL: 
https://github.com/apache/incubator-nuttx/issues/3765#issuecomment-865022893


   Hmm, understood to point. In fact it is sad they didn't included the DAC 
support in the board!


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev edited a comment on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev edited a comment on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606


   > @a-lunev - Why is this needed when stm32_dmapreflight already excludes it?
   
   Hi David,
   stm32_dmapreflight() depends on the CONFIG_STM32H7_SDMMC_IDMA option that as 
I understand should not do, because IDMA is still in use not depending on the 
option.
   Also stm32_dmapreflight() is invoked olny if CONFIG_DEBUG_ASSERTIONS option 
is enabled.
   If my understanding is correct, concerning namely SDMMC1 IDMA, 
stm32_dmapreflight() is useful for debug purposes to check if IDMA is trying to 
access not allowed memory regions like SRAM123 and SRAM4. This can be caught 
only if CONFIG_DEBUG_ASSERTIONS option is enabled.
   In a normal build CONFIG_DEBUG_ASSERTIONS option is not enabled. How then 
the system should be prevented from the IDMA access failure?
   On another hand, if CONFIG_DEBUG_ASSERTIONS option is enabled and the assert 
has been triggered, what the further developer's actions should be in this 
particular case with SDMMC1 IDMA? As I understand, normally there are two 
possible options:
   - either to exclude SRAM123 and SRAM4 from the heap allocation;
   - or to use SDMMC2 instead of SDMMC1 as SDMMC2 does not have the access 
limitation.
   
   Please let me know what do you think.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev edited a comment on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev edited a comment on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606


   > @a-lunev - Why is this needed when stm32_dmapreflight already excludes it?
   
   Hi David,
   stm32_dmapreflight() depends on the CONFIG_STM32H7_SDMMC_IDMA option that as 
I understand should not do, because IDMA is still in use not depending on the 
option.
   Also stm32_dmapreflight() is invoked olny if CONFIG_DEBUG_ASSERTIONS option 
is enabled.
   If my understanding is correct, concerning namely SDMMC1 IDMA, 
stm32_dmapreflight() is useful for debug purposes to check if IDMA is trying to 
access not allowed memory regions like SRAM123 and SRAM4. This can be caught 
only if CONFIG_DEBUG_ASSERTIONS option is enabled.
   In a normal build CONFIG_DEBUG_ASSERTIONS option is not enabled. How then 
the system should be prevented from the IDMA access failure?
   On another hand, if CONFIG_DEBUG_ASSERTIONS option is enabled and the assert 
has been triggered, what the further developer actions should be in this 
particular case with SDMMC1 IDMA? As I understand, normally there are two 
possible options:
   - either to exclude SRAM123 and SRAM4 from the heap allocation;
   - or to use SDMMC2 instead of SDMMC1 as SDMMC2 does not have the access 
limitation.
   
   Please let me know what do you think.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev edited a comment on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev edited a comment on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606


   > @a-lunev - Why is this needed when stm32_dmapreflight already excludes it?
   
   Hi David,
   stm32_dmapreflight() depends on the CONFIG_STM32H7_SDMMC_IDMA option that as 
I understand should not do, because IDMA is still in use not depending on the 
option.
   Also stm32_dmapreflight() is invoked olny if CONFIG_DEBUG_ASSERTIONS option 
is enabled.
   If my understanding is correct, concerning namely SDMMC1 IDMA, 
stm32_dmapreflight() is useful for debug purposes to check if IDMA is trying to 
access not allowed memory regions like SRAM123 and SRAM4. This can be caught 
only if CONFIG_DEBUG_ASSERTIONS option is enabled.
   In a normal build CONFIG_DEBUG_ASSERTIONS option is not enabled. How then 
the system should be prevented from the IDMA access failure?
   On another hand, if CONFIG_DEBUG_ASSERTIONS option is enabled and the assert 
has been triggered, what the further developer actions should be in this 
particular case with SDMMC1 IDMA? As I understand, normally there are two 
possible options:
   - either to exclude SRAM123 and/or SRAM4 from the heap allocation;
   - or to use SDMMC2 instead of SDMMC1 as SDMMC2 does not have the access 
limitation.
   
   Please let me know what do you think.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev edited a comment on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev edited a comment on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606


   > @a-lunev - Why is this needed when stm32_dmapreflight already excludes it?
   
   Hi David,
   stm32_dmapreflight() depends on the CONFIG_STM32H7_SDMMC_IDMA option that as 
I understand should not do, because IDMA is still in use not depending on the 
option.
   Also stm32_dmapreflight() is invoked olny if CONFIG_DEBUG_ASSERTIONS option 
is enabled.
   If my understanding is correct, concerning namely SDMMC1 IDMA, 
stm32_dmapreflight() is useful for debug purposes to check if IDMA is trying to 
access not allowed memory regions like SRAM123 and SRAM4. This can be caught 
only if CONFIG_DEBUG_ASSERTIONS option is enabled.
   In a normal build CONFIG_DEBUG_ASSERTIONS option is not enabled. How then 
the system should be prevented from the IDMA access failure?
   On another hand, if CONFIG_DEBUG_ASSERTIONS option is enabled and the assert 
triggered, what the further developer actions should be in this particular case 
with SDMMC1 IDMA? As I understand, normally there are two possible options:
   - either to exclude SRAM123 and/or SRAM4 from the heap allocation;
   - or to use SDMMC2 instead of SDMMC1 as SDMMC2 does not have the access 
limitation.
   
   Please let me know what do you think.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev commented on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606


   > @a-lunev - Why is this needed when stm32_dmapreflight already excludes it?
   Hi David,
   stm32_dmapreflight() depends on the CONFIG_STM32H7_SDMMC_IDMA option that as 
I understand should not do, because IDMA is still in use not depending on the 
option.
   Also stm32_dmapreflight() is invoked olny if CONFIG_DEBUG_ASSERTIONS option 
is enabled.
   If my understanding is correct, concerning namely SDMMC1 IDMA, 
stm32_dmapreflight() is useful for debug purposes to check if IDMA is trying to 
access not allowed memory regions like SRAM123 and SRAM4. This can be caught 
only if CONFIG_DEBUG_ASSERTIONS option is enabled.
   In a normal build CONFIG_DEBUG_ASSERTIONS option is not enabled. How then 
the system should be prevented from the IDMA access failure?
   On another hand, if CONFIG_DEBUG_ASSERTIONS option is enabled and the assert 
triggered, what the further developer actions should be in this particular case 
with SDMMC1 IDMA? As I understand, normally there are two possible options:
   - either to exclude SRAM123 and/or SRAM4 from the heap allocation;
   - or to use SDMMC2 instead of SDMMC1 as SDMMC2 does not have the access 
limitation.
   
   Please let me know what do you think.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] davids5 commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

davids5 commented on pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864966538


   @a-lunev - Why is this needed when stm32_dmapreflight already excludes it?


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] xiewenxiang edited a comment on pull request #3543: feat(esp32c3): Support esp32c3 ble function

[GitBox]

xiewenxiang edited a comment on pull request #3543:
URL: https://github.com/apache/incubator-nuttx/pull/3543#issuecomment-864961579


   Hi @protobits 
   
   I have refactored the tty driver, could you please help re-reivew this MR, 
thanks!


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] xiewenxiang commented on pull request #3543: feat(esp32c3): Support esp32c3 ble function

[GitBox]

xiewenxiang commented on pull request #3543:
URL: https://github.com/apache/incubator-nuttx/pull/3543#issuecomment-864961579


   Hi @protobits 
   
   I have refactored the tty driver, could you please help re-reivew this MR.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] a-lunev opened a new pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA

[GitBox]

a-lunev opened a new pull request #3958:
URL: https://github.com/apache/incubator-nuttx/pull/3958


   ## Summary
   Preventing SRAM123 and SRAM4 from using by SDMMC1 IDMA.
   
   ## Impact
   STM32H7 SDMMC


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request #3956: xtensa/esp32_aes.c: Use the same output as SHA and RSA when testing the AES driver.

[GitBox]

xiaoxiang781216 merged pull request #3956:
URL: https://github.com/apache/incubator-nuttx/pull/3956


   


-- 
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:
us...@infra.apache.org

[incubator-nuttx] branch master updated (841fb02 -> a4289c4)

[xiaoxiang]

This is an automated email from the ASF dual-hosted git repository.

xiaoxiang pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git.


from 841fb02  arch: esp32: Replace getcoreid with the latest esp-idf's
 add a4289c4  xtensa/esp32_aes.c: Use the same output when testing the AES 
driver.

No new revisions were added by this update.

Summary of changes:
 arch/xtensa/src/esp32/esp32_aes.c | 176 --
 1 file changed, 132 insertions(+), 44 deletions(-)

[GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request #3955: arch: esp32: Replace getcoreid with the latest esp-idf's

[GitBox]

xiaoxiang781216 merged pull request #3955:
URL: https://github.com/apache/incubator-nuttx/pull/3955


   


-- 
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:
us...@infra.apache.org

[incubator-nuttx] branch master updated (f7c8875 -> 841fb02)

[xiaoxiang]

This is an automated email from the ASF dual-hosted git repository.

xiaoxiang pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git.


from f7c8875  sdio,stm32h7: fixed an issue with not starting IDMA data 
transfer in case of IO_RW_EXTENDED command (CMD53); corrected setting 
SDMMC_DCTRL.DTMODE field for block data transfers ending on block count and for 
block data transfers ending with STOP_TRANSMISSION command; stm32_sdio: added 
more debug messages
 add 841fb02  arch: esp32: Replace getcoreid with the latest esp-idf's

No new revisions were added by this update.

Summary of changes:
 arch/xtensa/src/esp32/chip_macros.h | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request #3957: sched/wdog: Remove flags field from wdog_s to save memory

[GitBox]

xiaoxiang781216 opened a new pull request #3957:
URL: https://github.com/apache/incubator-nuttx/pull/3957


   ## Summary
   since WDOG_ISACTIVE can check next field instead
   
   ## Impact
   Save four bytes for each wdog_s
   
   ## Testing
   Pass ostest
   


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] michallenc edited a comment on issue #3765: GSoC: NuttX support for pysimCoder (info thread)

[GitBox]

michallenc edited a comment on issue #3765:
URL: 
https://github.com/apache/incubator-nuttx/issues/3765#issuecomment-864926968


   Hi @acassis. Unfortunately there is no digital/analog converter output on 
the iMXRT 1060 chip at all. There is just a 6 bit DAC for on chip internal 
signals only, but it´s not routed to the external pins (chapter 65 in the 
reference manual). So DAC can be tested just on Nucleo board.
   
   DAC support should be in newer iMXRT 11xx chips though, but those are not 
supported by NuttX yet.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] michallenc commented on issue #3765: GSoC: NuttX support for pysimCoder (info thread)

[GitBox]

michallenc commented on issue #3765:
URL: 
https://github.com/apache/incubator-nuttx/issues/3765#issuecomment-864926968


   Hi @acassis. Unfortunately there is no digital/analog converter output on 
the iMXRT 1060 chip at all. There is just a 6 bit DAC for on chip internal 
signals only, but it´s not routed to the external pins (chapter 65 in the 
reference manual). So DAC can be tested just on Nucleo board.
   
   DAC support should be in newer series iMXRT11xx chips though, but those are 
not supported by NuttX yet.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] ocramlhark edited a comment on pull request #3954: stm32f103-minimum/sensors: Remove DS28E17 that is not used and add SENSORTEST

[GitBox]

ocramlhark edited a comment on pull request #3954:
URL: https://github.com/apache/incubator-nuttx/pull/3954#issuecomment-864596501


   Hi Alan,
   
   yes I will do that tomorrow.
   
   On Sun, Jun 20, 2021, 19:26 Alan Carvalho de Assis ***@***.***>
   wrote:
   
   > Please @ocramlhark  review it.
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   >
   
   Oh, I'm too late, but your patch is fine. This was an obsolete artifact that 
comes from the old configuration based on 1-wire implementation from Juha.


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] Ouss4 opened a new pull request #3956: xtensa/esp32_aes.c: Use the same output as SHA and RSA when testing the AES driver.

[GitBox]

Ouss4 opened a new pull request #3956:
URL: https://github.com/apache/incubator-nuttx/pull/3956


   ## Summary
   Use the same output as SHA, RSA and DMA when testing the AES driver.  This 
is used for internal testing and will allow using the same script to test all 
of these drivers.
   ## Impact
   ESP32 AES test example only.
   ## Testing
   esp32-devkitc:aes.
   


-- 
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:
us...@infra.apache.org

[incubator-nuttx] branch master updated: sdio,stm32h7: fixed an issue with not starting IDMA data transfer in case of IO_RW_EXTENDED command (CMD53); corrected setting SDMMC_DCTRL.DTMODE field for blo

[xiaoxiang]

This is an automated email from the ASF dual-hosted git repository.

xiaoxiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git


The following commit(s) were added to refs/heads/master by this push:
 new f7c8875  sdio,stm32h7: fixed an issue with not starting IDMA data 
transfer in case of IO_RW_EXTENDED command (CMD53); corrected setting 
SDMMC_DCTRL.DTMODE field for block data transfers ending on block count and for 
block data transfers ending with STOP_TRANSMISSION command; stm32_sdio: added 
more debug messages
f7c8875 is described below

commit f7c8875fd71899a1a253c983186ea71a55cae884
Author: Alexander Lunev 
AuthorDate: Sun Jun 20 18:10:41 2021 +0300

sdio,stm32h7: fixed an issue with not starting IDMA data transfer in case 
of IO_RW_EXTENDED command (CMD53);
corrected setting SDMMC_DCTRL.DTMODE field for block data transfers ending 
on block count
and for block data transfers ending with STOP_TRANSMISSION command;
stm32_sdio: added more debug messages
---
 arch/arm/src/stm32/stm32_sdio.c   |  9 +++--
 arch/arm/src/stm32h7/hardware/stm32h7x3xx_sdmmc.h |  4 ++--
 arch/arm/src/stm32h7/stm32_sdmmc.c| 21 ++---
 boards/arm/stm32/emw3162/README.txt   |  2 +-
 drivers/wireless/ieee80211/bcm43xxx/mmc_sdio.c| 12 ++--
 include/nuttx/sdio.h  |  7 ---
 6 files changed, 38 insertions(+), 17 deletions(-)

diff --git a/arch/arm/src/stm32/stm32_sdio.c b/arch/arm/src/stm32/stm32_sdio.c
index 5c78d79..0ca47da 100644
--- a/arch/arm/src/stm32/stm32_sdio.c
+++ b/arch/arm/src/stm32/stm32_sdio.c
@@ -1232,6 +1232,10 @@ static void stm32_eventtimeout(wdparm_t arg)
   DEBUGASSERT((priv->waitevents & SDIOWAIT_TIMEOUT) != 0 ||
   priv->wkupevent != 0);
 
+  mcinfo("sta: %08" PRIx32 " enabled irq: %08" PRIx32 "\n",
+ getreg32(STM32_SDIO_STA),
+ getreg32(STM32_SDIO_MASK));
+
   /* Is a data transfer complete event expected? */
 
   if ((priv->waitevents & SDIOWAIT_TIMEOUT) != 0)
@@ -1917,8 +1921,9 @@ static int stm32_sendcmd(FAR struct sdio_dev_s *dev, 
uint32_t cmd,
   cmdidx  = (cmd & MMCSD_CMDIDX_MASK) >> MMCSD_CMDIDX_SHIFT;
   regval |= cmdidx | SDIO_CMD_CPSMEN;
 
-  mcinfo("cmd: %08" PRIx32 " arg: %08" PRIx32 " regval: %08" PRIx32 "\n",
- cmd, arg, regval);
+  mcinfo("cmd: %08" PRIx32 " arg: %08" PRIx32 " regval: %08" PRIx32
+ " enabled irq: %08" PRIx32 "\n",
+ cmd, arg, regval, getreg32(STM32_SDIO_MASK));
 
   /* Write the SDIO CMD */
 
diff --git a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_sdmmc.h 
b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_sdmmc.h
index 41ea213..71a96ac 100644
--- a/arch/arm/src/stm32h7/hardware/stm32h7x3xx_sdmmc.h
+++ b/arch/arm/src/stm32h7/hardware/stm32h7x3xx_sdmmc.h
@@ -119,10 +119,10 @@
 #define STM32_SDMMC_DCTRL_DTDIR   (1 << 1)  /* Bit 1: Data 
transfer direction */
 #define STM32_SDMMC_DCTRL_DTMODE_SHIFT(2)   /* Bits 2-3: Data 
transfer mode */
 #define STM32_SDMMC_DCTRL_DTMODE_MASK (3 << 
STM32_SDMMC_DCTRL_DTMODE_SHIFT)
-#  define STM32_SDMMC_DCTRL_DTMODE_END(0 << 
STM32_SDMMC_DCTRL_DTMODE_SHIFT)
+#  define STM32_SDMMC_DCTRL_DTMODE_BLOCK  (0 << 
STM32_SDMMC_DCTRL_DTMODE_SHIFT)
 #  define STM32_SDMMC_DCTRL_DTMODE_SDIO   (1 << 
STM32_SDMMC_DCTRL_DTMODE_SHIFT)
 #  define STM32_SDMMC_DCTRL_DTMODE_EMMC   (2 << 
STM32_SDMMC_DCTRL_DTMODE_SHIFT)
-#  define STM32_SDMMC_DCTRL_DTMODE_BLOCK  (3 << 
STM32_SDMMC_DCTRL_DTMODE_SHIFT)
+#  define STM32_SDMMC_DCTRL_DTMODE_BLKSTOP(3 << 
STM32_SDMMC_DCTRL_DTMODE_SHIFT)
 
 #define STM32_SDMMC_DCTRL_DBLOCKSIZE_SHIFT(4)   /* Bits 7-4: Data 
block size */
 #define STM32_SDMMC_DCTRL_DBLOCKSIZE_MASK (0xf << 
STM32_SDMMC_DCTRL_DBLOCKSIZE_SHIFT)
diff --git a/arch/arm/src/stm32h7/stm32_sdmmc.c 
b/arch/arm/src/stm32h7/stm32_sdmmc.c
index c813eb8..5ba9fa1 100644
--- a/arch/arm/src/stm32h7/stm32_sdmmc.c
+++ b/arch/arm/src/stm32h7/stm32_sdmmc.c
@@ -1128,10 +1128,12 @@ static void stm32_dataconfig(struct stm32_dev_s *priv, 
uint32_t timeout,
 #if defined(HAVE_SDMMC_SDIO_MODE)
   if (priv->sdiomode == true)
 {
-  dctrl |= STM32_SDMMC_DCTRL_SDIOEN | STM32_SDMMC_DCTRL_DTMODE_SDIO;
+  dctrl |= STM32_SDMMC_DCTRL_SDIOEN;
 }
 #endif
 
+  dctrl |= STM32_SDMMC_DCTRL_DTMODE_BLOCK;
+
   /* if dlen > priv->blocksize we assume that this is a multi-block transfer
* and that the len is multiple of priv->blocksize.
*/
@@ -2250,9 +2252,22 @@ static int stm32_sendcmd(FAR struct sdio_dev_s *dev, 
uint32_t cmd,
   cmdidx  = (cmd & MMCSD_CMDIDX_MASK) >> MMCSD_CMDIDX_SHIFT;
   regval |= cmdidx | STM32_SDMMC_CMD_CPSMEN;
 
-  if (cmd & MMCSD_DATAXFR_MASK)
+  switch (cmd & MMCSD_DATAXFR_MASK)
 {
-  regval |= STM32_SDMMC_CMD_CMDTRANS;
+case MMCSD_RDDATAXFR: /* Read block transfer */
+case MMCSD_WRDATAXFR: /* Write block transfer */
+case MMCSD_RDSTREAM:  /* 

[GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request #3952: SDIO IO_RW_EXTENDED command (CMD53) related fixes

[GitBox]

xiaoxiang781216 merged pull request #3952:
URL: https://github.com/apache/incubator-nuttx/pull/3952


   


-- 
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:
us...@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 merged pull request #3882: risc-v/esp32c3: Support ESP32-C3 SHA accelerator

[GitBox]

xiaoxiang781216 merged pull request #3882:
URL: https://github.com/apache/incubator-nuttx/pull/3882


   


-- 
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:
us...@infra.apache.org

[incubator-nuttx] branch master updated: risc-v/esp32c3: Support ESP32-C3 SHA accelerator

[xiaoxiang]

This is an automated email from the ASF dual-hosted git repository.

xiaoxiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git


The following commit(s) were added to refs/heads/master by this push:
 new 2dd081e  risc-v/esp32c3: Support ESP32-C3 SHA accelerator
2dd081e is described below

commit 2dd081ed7ddabc2bb7a5bd9e0974018aedc4399d
Author: Liu Han 
AuthorDate: Wed Jun 9 20:10:31 2021 +0800

risc-v/esp32c3: Support ESP32-C3 SHA accelerator
---
 arch/risc-v/src/esp32c3/Kconfig|   13 +
 arch/risc-v/src/esp32c3/Make.defs  |4 +
 arch/risc-v/src/esp32c3/esp32c3_sha.c  | 1715 
 arch/risc-v/src/esp32c3/esp32c3_sha.h  |  121 ++
 arch/risc-v/src/esp32c3/hardware/esp32c3_sha.h |  938 +++
 .../esp32c3/esp32c3-devkit/configs/sha/defconfig   |   48 +
 .../esp32c3/esp32c3-devkit/src/esp32c3_bringup.c   |   13 +
 7 files changed, 2852 insertions(+)

diff --git a/arch/risc-v/src/esp32c3/Kconfig b/arch/risc-v/src/esp32c3/Kconfig
index 30e92dd..e12fdcd 100644
--- a/arch/risc-v/src/esp32c3/Kconfig
+++ b/arch/risc-v/src/esp32c3/Kconfig
@@ -309,6 +309,11 @@ config ESP32C3_WIRELESS
 config ESP32C3_AES_ACCELERATOR
bool "AES Accelerator"
default n
+config ESP32C3_SHA_ACCELERATOR
+   bool "SHA Accelerator"
+   default n
+   ---help---
+   Enable ESP32-C3 SHA accelerator support.
 
 config ESP32C3_BIGNUM_ACCELERATOR
bool "BIGNUM Accelerator"
@@ -840,6 +845,14 @@ config ESP32C3_AES_ACCELERATOR_TEST
default n
 
 endmenu # AES accelerator
+menu "SHA accelerator"
+   depends on ESP32C3_SHA_ACCELERATOR
+
+config ESP32C3_SHA_ACCELERATOR_TEST
+   bool "SHA accelerator test"
+   default n
+
+endmenu # ESP32C3_SHA_ACCELERATOR
 
 menu "RSA Accelerate Configuration"
depends on ESP32C3_RSA_ACCELERATOR
diff --git a/arch/risc-v/src/esp32c3/Make.defs 
b/arch/risc-v/src/esp32c3/Make.defs
index 7a47f31..3de2375 100644
--- a/arch/risc-v/src/esp32c3/Make.defs
+++ b/arch/risc-v/src/esp32c3/Make.defs
@@ -117,6 +117,10 @@ ifeq ($(CONFIG_ESP32C3_RSA_ACCELERATOR),y)
 CHIP_CSRCS += esp32c3_rsa.c
 endif
 
+ifeq ($(CONFIG_ESP32C3_SHA_ACCELERATOR),y)
+CHIP_CSRCS += esp32c3_sha.c
+endif
+
 ifeq ($(CONFIG_ESP32C3_FREERUN),y)
 CHIP_CSRCS += esp32c3_freerun.c
 endif
diff --git a/arch/risc-v/src/esp32c3/esp32c3_sha.c 
b/arch/risc-v/src/esp32c3/esp32c3_sha.c
new file mode 100644
index 000..773ad23
--- /dev/null
+++ b/arch/risc-v/src/esp32c3/esp32c3_sha.c
@@ -0,0 +1,1715 @@
+/
+ * arch/risc-v/src/esp32c3/esp32c3_sha.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.  The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ /
+
+/
+ * Included Files
+ /
+
+#include 
+
+#ifdef CONFIG_ESP32C3_SHA_ACCELERATOR
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "riscv_arch.h"
+#include "hardware/esp32c3_sha.h"
+#include "hardware/esp32c3_system.h"
+
+#include "esp32c3_sha.h"
+
+/
+ * Pre-processor Definitions
+ /
+
+#define PUT_UINT32_BE(n,b,i)  \
+{ \
+  (b)[(i)] = (unsigned char) ((n) >> 24); \
+  (b)[(i) + 1] = (unsigned char) ((n) >> 16); \
+  (b)[(i) + 2] = (unsigned char) ((n) >>  8); \
+  (b)[(i) + 3] = (unsigned char) ((n));   \
+}
+
+#define GET_UINT64_BE(n,b,i)\
+{   \
+  (n) = ((uint64_t) (b)[(i)] << 56) \
+| ((uint64_t) (b)[(i) + 1] << 48)   \
+| ((uint64_t) (b)[(i) + 2] << 40)   \
+| ((uint64_t) (b)[(i) + 3] << 32)   \
+| ((uint64_t) (b)[(i) + 4] << 24)   \
+| ((uint64_t) (b)[(i) + 5] << 16)   \
+| 

[GitHub] [incubator-nuttx-apps] xiaoxiang781216 commented on a change in pull request #770: system/ping[6]: correct the ping return value

[GitBox]

xiaoxiang781216 commented on a change in pull request #770:
URL: 
https://github.com/apache/incubator-nuttx-apps/pull/770#discussion_r655094692



##
File path: system/ping/ping.c
##
@@ -224,6 +241,8 @@ int main(int argc, FAR char *argv[])
   info.delay = ICMP_POLL_DELAY;
   info.timeout   = ICMP_POLL_DELAY;
   info.callback  = ping_result;
+  info.priv  = 
+  priv.code  = ICMP_I_BEGIN;

Review comment:
   Fix




-- 
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:
us...@infra.apache.org