From ef63811e6d603c1a9cffb20b3ef9bc72ff51ddf8 Mon Sep 17 00:00:00 2001 From: Ivan Grokhotkov Date: Wed, 5 Jul 2017 11:29:53 +0800 Subject: [PATCH 1/5] phy_init: fix log level for "PHY data partition validated" message --- components/esp32/phy_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/esp32/phy_init.c b/components/esp32/phy_init.c index ab62aad2ca..43e9c97ce5 100644 --- a/components/esp32/phy_init.c +++ b/components/esp32/phy_init.c @@ -119,7 +119,7 @@ const esp_phy_init_data_t* esp_phy_get_init_data() ESP_LOGE(TAG, "failed to validate PHY data partition"); return NULL; } - ESP_LOGE(TAG, "PHY data partition validated"); + ESP_LOGD(TAG, "PHY data partition validated"); return (const esp_phy_init_data_t*) (init_data_store + sizeof(phy_init_magic_pre)); } From cd1b6abc8c122596d6cd05e47092897fc768cac5 Mon Sep 17 00:00:00 2001 From: Ivan Grokhotkov Date: Wed, 5 Jul 2017 11:35:01 +0800 Subject: [PATCH 2/5] docs: fix flash encryption key storage block, use same names as in TRM --- docs/security/flash-encryption.rst | 2 +- docs/security/secure-boot.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/security/flash-encryption.rst b/docs/security/flash-encryption.rst index fd9b620e18..866cff498f 100644 --- a/docs/security/flash-encryption.rst +++ b/docs/security/flash-encryption.rst @@ -373,7 +373,7 @@ Flash Encryption Algorithm - AES algorithm is used inverted in flash encryption, so the flash encryption "encrypt" operation is AES decrypt and the "decrypt" operation is AES encrypt. This is for performance reasons and does not alter the effectiveness of the algorithm. -- The main flash encryption key is stored in efuse (BLK2) and by default is protected from further writes or software readout. +- The main flash encryption key is stored in efuse (BLOCK1) and by default is protected from further writes or software readout. - Each 32 byte block (two adjacent 16 byte AES blocks) is encrypted with a unique key. The key is derived from the main flash encryption key in efuse, XORed with the offset of this block in the flash (a "key tweak"). diff --git a/docs/security/secure-boot.rst b/docs/security/secure-boot.rst index 126b8c9d6e..0493ee3612 100644 --- a/docs/security/secure-boot.rst +++ b/docs/security/secure-boot.rst @@ -14,7 +14,7 @@ Background - Most data is stored in flash. Flash access does not need to be protected from physical access in order for secure boot to function, because critical data is stored (non-software-accessible) in Efuses internal to the chip. -- Efuses are used to store the secure bootloader key (in efuse block 2), and also a single Efuse bit (ABS_DONE_0) is burned (written to 1) to permanently enable secure boot on the chip. For more details about efuse, see the (forthcoming) chapter in the Technical Reference Manual. +- Efuses are used to store the secure bootloader key (in efuse BLOCK2), and also a single Efuse bit (ABS_DONE_0) is burned (written to 1) to permanently enable secure boot on the chip. For more details about efuse, see Chapter 11 "eFuse Controller" in the Technical Referecnce Manual. - To understand the secure boot process, first familiarise yourself with the standard :doc:`ESP-IDF boot process <../api-guides/general-notes>`. From 0087b887ae57d9214444d3f4c7ddf3de7fea5e02 Mon Sep 17 00:00:00 2001 From: Ivan Grokhotkov Date: Wed, 5 Jul 2017 11:47:02 +0800 Subject: [PATCH 3/5] docs: update general notes section on IRAM/ISRs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Remove outdated note that all ISRs should be in IRAM - Replace “ISR handler” with “ISR” or “interrupt handler” --- docs/api-guides/general-notes.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/api-guides/general-notes.rst b/docs/api-guides/general-notes.rst index 8f3c030451..7bbe616f91 100644 --- a/docs/api-guides/general-notes.rst +++ b/docs/api-guides/general-notes.rst @@ -82,7 +82,7 @@ If some application code needs to be placed into IRAM, it can be done using ``IR Here are the cases when parts of application may or should be placed into IRAM. -- ISR handlers must always be placed into IRAM. Furthermore, ISR handlers may only call functions placed into IRAM or functions present in ROM. *Note 1:* all FreeRTOS APIs are currently placed into IRAM, so are safe to call from ISR handlers. *Note 1:* all constant data used by ISR handlers and functions called from ISR handlers (including, but not limited to, ``const char`` arrays), must be placed into DRAM using ``DRAM_ATTR``. +- Interrupt handlers must be placed into IRAM if ``ESP_INTR_FLAG_IRAM`` is used when registering the interrupt handler. In this case, ISR may only call functions placed into IRAM or functions present in ROM. *Note 1:* all FreeRTOS APIs are currently placed into IRAM, so are safe to call from interrupt handlers. If the ISR is placed into IRAM, all constant data used by the ISR and functions called from ISR (including, but not limited to, ``const char`` arrays), must be placed into DRAM using ``DRAM_ATTR``. - Some timing critical code may be placed into IRAM to reduce the penalty associated with loading the code from flash. ESP32 reads code and data from flash via a 32 kB cache. In some cases, placing a function into IRAM may reduce delays caused by a cache miss. @@ -103,13 +103,13 @@ DRAM (data RAM) Non-constant static data and zero-initialized data is placed by the linker into the 256 kB ``0x3FFB0000 — 0x3FFF0000`` region. Note that this region is reduced by 64kB (by shifting start address to ``0x3FFC0000``) if Bluetooth stack is used. Length of this region is also reduced by 16 kB or 32kB if trace memory is used. All space which is left in this region after placing static data there is used for the runtime heap. -Constant data may also be placed into DRAM, for example if it is used in an ISR handler (see notes in IRAM section above). To do that, ``DRAM_ATTR`` define can be used:: +Constant data may also be placed into DRAM, for example if it is used in an ISR (see notes in IRAM section above). To do that, ``DRAM_ATTR`` define can be used:: DRAM_ATTR const char[] format_string = "%p %x"; char buffer[64]; sprintf(buffer, format_string, ptr, val); -Needless to say, it is not advised to use ``printf`` and other output functions in ISR handlers. For debugging purposes, use ``ESP_EARLY_LOGx`` macros when logging from ISR handlers. Make sure that both ``TAG`` and format string are placed into ``DRAM`` in that case. +Needless to say, it is not advised to use ``printf`` and other output functions in ISRs. For debugging purposes, use ``ESP_EARLY_LOGx`` macros when logging from ISRs. Make sure that both ``TAG`` and format string are placed into ``DRAM`` in that case. DROM (data stored in Flash) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ From a054ced7402b017d9457ae328750370b0175cfbd Mon Sep 17 00:00:00 2001 From: Ivan Grokhotkov Date: Thu, 6 Jul 2017 11:01:40 +0800 Subject: [PATCH 4/5] =?UTF-8?q?esp=5Fchip=5Finfo:=20populate=20=E2=80=98mo?= =?UTF-8?q?del=E2=80=99=20field?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- components/esp32/system_api.c | 1 + 1 file changed, 1 insertion(+) diff --git a/components/esp32/system_api.c b/components/esp32/system_api.c index c797f30bdc..c79761fd7d 100644 --- a/components/esp32/system_api.c +++ b/components/esp32/system_api.c @@ -349,6 +349,7 @@ const char* esp_get_idf_version(void) static void get_chip_info_esp32(esp_chip_info_t* out_info) { + out_info->model = CHIP_ESP32; uint32_t reg = REG_READ(EFUSE_BLK0_RDATA3_REG); memset(out_info, 0, sizeof(*out_info)); if ((reg & EFUSE_RD_CHIP_VER_REV1_M) != 0) { From 6b2e16e51b16c6bcf5823f0dfba44220acea9d61 Mon Sep 17 00:00:00 2001 From: Ivan Grokhotkov Date: Thu, 6 Jul 2017 12:36:06 +0800 Subject: [PATCH 5/5] soc: fix typo in register name --- components/soc/esp32/rtc_init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/components/soc/esp32/rtc_init.c b/components/soc/esp32/rtc_init.c index 8aabd5c261..ff7b6b73cc 100644 --- a/components/soc/esp32/rtc_init.c +++ b/components/soc/esp32/rtc_init.c @@ -45,8 +45,8 @@ void rtc_init(rtc_config_t cfg) DPORT_CLEAR_PERI_REG_MASK(DPORT_ROM_FO_CTRL_REG, DPORT_APP_ROM_FO); DPORT_CLEAR_PERI_REG_MASK(DPORT_ROM_FO_CTRL_REG, DPORT_PRO_ROM_FO); //clear sram clock force on - DPORT_SET_PERI_REG_BITS(DPORT_SRAM_FO_CTRL_0_REG, DPORT_SRAM_FO_0, 0, DPORT_SRAM_FO_0_S); - DPORT_CLEAR_PERI_REG_MASK(DPORT_SRAM_FO_CTRL_0_REG, DPORT_SRAM_FO_1); + DPORT_CLEAR_PERI_REG_MASK(DPORT_SRAM_FO_CTRL_0_REG, DPORT_SRAM_FO_0); + DPORT_CLEAR_PERI_REG_MASK(DPORT_SRAM_FO_CTRL_1_REG, DPORT_SRAM_FO_1); //clear tag clock force on DPORT_CLEAR_PERI_REG_MASK(DPORT_TAG_FO_CTRL_REG, DPORT_APP_CACHE_TAG_FORCE_ON); DPORT_CLEAR_PERI_REG_MASK(DPORT_TAG_FO_CTRL_REG, DPORT_PRO_CACHE_TAG_FORCE_ON);