doc: update the memory types and startup docs

docs/en/api-reference/storage/spi_flash_concurrency.rst

@@ -37,37 +37,14 @@ IRAM-Safe Interrupt Handlers
 
 If you have an interrupt handler that you want to execute while a flash operation is in progress (for example, for low latency operations), set the ``ESP_INTR_FLAG_IRAM`` flag when the :doc:`interrupt handler is registered </api-reference/system/intr_alloc>`.
 
-You must ensure that all data and functions accessed by these interrupt handlers, including the ones that handlers call, are located in IRAM or DRAM. There are two approaches to do this:
-
-Using Attribute Macros
-""""""""""""""""""""""
-
-Use the ``IRAM_ATTR`` attribute for functions::
-
-    #include "esp_attr.h"
-
-    void IRAM_ATTR gpio_isr_handler(void* arg)
-    {
-        // ...
-    }
-
-Use the ``DRAM_ATTR`` and ``DRAM_STR`` attributes for constant data::
-
-    void IRAM_ATTR gpio_isr_handler(void* arg)
-    {
-       const static DRAM_ATTR uint8_t INDEX_DATA[] = { 45, 33, 12, 0 };
-       const static char *MSG = DRAM_STR("I am a string stored in RAM");
-    }
-
-Note that knowing which data should be marked with ``DRAM_ATTR`` can be hard, the compiler will sometimes recognize that a variable or expression is constant (even if it is not marked ``const``) and optimize it into flash, unless it is marked with ``DRAM_ATTR``.
-
-Using Linker Scripts
-""""""""""""""""""""
-
-See :doc:`/api-guides/linker-script-generation` for details.
+You must ensure that all data and functions accessed by these interrupt handlers, including the ones that handlers call, are located in IRAM or DRAM. See :ref:`how-to-place-code-in-iram`.
 
 If a function or symbol is not correctly put into IRAM/DRAM, and the interrupt handler reads from the flash cache during a flash operation, it will cause a crash due to Illegal Instruction exception (for code which should be in IRAM) or garbage data to be read (for constant data which should be in DRAM).
 
+.. note::
+
+   When working with string in ISRs, it is not advised to use ``printf`` and other output functions. For debugging purposes, use :cpp:func:`ESP_DRAM_LOGE` and similar macros when logging from ISRs. Make sure that both ``TAG`` and format string are placed into ``DRAM`` in that case.
+
 .. only:: esp32c3
 
    .. include:: auto_suspend.inc

docs/en/api-reference/system/mem_alloc.rst

@@ -92,6 +92,10 @@ DMA-Capable Memory
 
 Use the ``MALLOC_CAP_DMA`` flag to allocate memory which is suitable for use with hardware DMA engines (for example SPI and I2S). This capability flag excludes any external PSRAM.
 
+.. only SOC_SPIRAM_SUPPORTED and not esp32::
+
+    The EDMA hardware feature allows DMA buffers to be placed in external PSRAM, but there may be additional alignment constraints. Consult the {IDF_TARGET_NAME} Technical Reference Manual for details. To allocate a DMA-capable external memory buffer, use the ``MALLOC_CAP_SPIRAM`` capabilities flag together with :cpp:func:`heap_caps_aligned_alloc` with the necessary alignment specified.
+
 .. _32-bit accessible memory:
 
 32-Bit Accessible Memory

docs/en/api-reference/system/system.rst

@@ -153,6 +153,8 @@ To get the version at build time, additional version macros are provided. They c
       #endif
 
 
+.. _app-version:
+
 App version
 -----------
 Application version is stored in :cpp:class:`esp_app_desc_t` structure. It is located in DROM sector and has a fixed offset from the beginning of the binary file.