[GitHub] [incubator-nuttx] a-lunev commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA
a-lunev commented on pull request #3958: URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-1046220216 This PR is still actual. I am going to return to it later. -- 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. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org 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
a-lunev commented on pull request #3958: URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-875203449 Hi David, I've checked User Manuals for stm32h7 boards. STM32H745I-DISCO, STM32H750B-DK and STM32H7B3I-DK have eMMC memory chip connected to SDMMC1, however I have neither of them. One more possible option could be to solder wires to SD or MMC connector, insert MMC card and connect the wires to some stm32h7 board (e.g. NUCLEO-H743ZI) to its SDMMC1 interface. -- 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. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org 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
a-lunev commented on pull request #3958: URL: https://github.com/apache/incubator-nuttx/pull/3958#issuecomment-864997606 -- 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
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
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 commented on pull request #3958: stm32h7:sdmmc: prevent SRAM123 and SRAM4 from using by SDMMC1 IDMA
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
