2021-02-18 08:09:27 -05:00
|
|
|
menu "Hardware Settings"
|
2022-03-17 09:58:15 -04:00
|
|
|
|
|
|
|
menu "Chip revision"
|
|
|
|
# Insert chip-specific HW config
|
|
|
|
orsource "./port/$IDF_TARGET/Kconfig.hw_support"
|
2023-05-03 23:46:21 -04:00
|
|
|
|
|
|
|
config ESP_REV_NEW_CHIP_TEST
|
|
|
|
bool "Internal test mode"
|
|
|
|
depends on IDF_CI_BUILD
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
For internal chip testing, a small number of new versions chips didn't
|
|
|
|
update the version field in eFuse, you can enable this option to force the
|
|
|
|
software recognize the chip version based on the rev selected in menuconfig.
|
2022-03-17 09:58:15 -04:00
|
|
|
endmenu
|
|
|
|
|
2021-02-18 08:09:27 -05:00
|
|
|
menu "MAC Config"
|
|
|
|
config ESP_MAC_ADDR_UNIVERSE_WIFI_STA
|
|
|
|
bool
|
|
|
|
|
|
|
|
config ESP_MAC_ADDR_UNIVERSE_WIFI_AP
|
|
|
|
bool
|
|
|
|
|
|
|
|
config ESP_MAC_ADDR_UNIVERSE_BT
|
|
|
|
bool
|
|
|
|
|
|
|
|
config ESP_MAC_ADDR_UNIVERSE_ETH
|
|
|
|
bool
|
2021-03-17 08:42:10 -04:00
|
|
|
|
2022-11-10 09:21:06 -05:00
|
|
|
config ESP_MAC_ADDR_UNIVERSE_IEEE802154
|
|
|
|
bool
|
|
|
|
|
|
|
|
config ESP_MAC_UNIVERSAL_MAC_ADDRESSES_ONE
|
|
|
|
bool
|
|
|
|
|
|
|
|
config ESP_MAC_UNIVERSAL_MAC_ADDRESSES_TWO
|
|
|
|
bool
|
|
|
|
|
|
|
|
config ESP_MAC_UNIVERSAL_MAC_ADDRESSES_FOUR
|
|
|
|
bool
|
|
|
|
|
2024-01-24 05:59:43 -05:00
|
|
|
config ESP_MAC_UNIVERSAL_MAC_ADDRESSES
|
|
|
|
int
|
|
|
|
default 1 if ESP_MAC_UNIVERSAL_MAC_ADDRESSES_ONE
|
|
|
|
default 2 if ESP_MAC_UNIVERSAL_MAC_ADDRESSES_TWO
|
|
|
|
default 4 if ESP_MAC_UNIVERSAL_MAC_ADDRESSES_FOUR
|
|
|
|
|
2021-03-17 08:42:10 -04:00
|
|
|
# Insert chip-specific MAC config
|
2022-12-02 01:54:27 -05:00
|
|
|
orsource "./port/$IDF_TARGET/Kconfig.mac"
|
2022-12-23 08:31:39 -05:00
|
|
|
|
|
|
|
config ESP_MAC_IGNORE_MAC_CRC_ERROR
|
|
|
|
bool "Ignore MAC CRC error (not recommended)"
|
|
|
|
depends on IDF_TARGET_ESP32
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
If you have an invalid MAC CRC (ESP_ERR_INVALID_CRC) problem
|
|
|
|
and you still want to use this chip, you can enable this option to bypass such an error.
|
|
|
|
This applies to both MAC_FACTORY and CUSTOM_MAC efuses.
|
2023-11-01 03:05:55 -04:00
|
|
|
|
|
|
|
config ESP_MAC_USE_CUSTOM_MAC_AS_BASE_MAC
|
|
|
|
bool "Enable using custom mac as base mac"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
When this configuration is enabled, the user can invoke `esp_read_mac` to obtain the desired type of
|
|
|
|
MAC using a custom MAC as the base MAC.
|
2021-02-18 08:09:27 -05:00
|
|
|
endmenu
|
2021-03-10 08:55:49 -05:00
|
|
|
|
|
|
|
menu "Sleep Config"
|
|
|
|
# This is here since this option affect behavior of esp_light_sleep_start
|
|
|
|
# regardless of power management configuration.
|
|
|
|
config ESP_SLEEP_POWER_DOWN_FLASH
|
|
|
|
bool "Power down flash in light sleep when there is no SPIRAM"
|
|
|
|
depends on !SPIRAM
|
2022-07-21 07:14:26 -04:00
|
|
|
default n
|
2021-03-10 08:55:49 -05:00
|
|
|
help
|
|
|
|
If enabled, chip will try to power down flash as part of esp_light_sleep_start(), which costs
|
|
|
|
more time when chip wakes up. Can only be enabled if there is no SPIRAM configured.
|
2022-07-21 07:14:26 -04:00
|
|
|
|
|
|
|
This option will power down flash under a strict but relatively safe condition. Also, it is possible to
|
|
|
|
power down flash under a relaxed condition by using esp_sleep_pd_config() to set ESP_PD_DOMAIN_VDDSDIO
|
|
|
|
to ESP_PD_OPTION_OFF. It should be noted that there is a risk in powering down flash, you can refer
|
|
|
|
`ESP-IDF Programming Guide/API Reference/System API/Sleep Modes/Power-down of Flash` for more details.
|
2021-07-16 05:44:03 -04:00
|
|
|
|
2023-06-19 07:06:44 -04:00
|
|
|
config ESP_SLEEP_FLASH_LEAKAGE_WORKAROUND
|
|
|
|
bool "Pull-up Flash CS pin in light sleep"
|
2023-06-25 05:12:43 -04:00
|
|
|
depends on !APP_BUILD_TYPE_PURE_RAM_APP && !ESP_SLEEP_POWER_DOWN_FLASH
|
2023-06-19 07:06:44 -04:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
All IOs will be set to isolate(floating) state by default during sleep.
|
|
|
|
Since the power supply of SPI Flash is not lost during lightsleep, if its CS pin is recognized as
|
|
|
|
low level(selected state) in the floating state, there will be a large current leakage, and the
|
|
|
|
data in Flash may be corrupted by random signals on other SPI pins.
|
|
|
|
Select this option will set the CS pin of Flash to PULL-UP state during sleep, but this will
|
|
|
|
increase the sleep current about 10 uA.
|
|
|
|
If you are developing with esp32xx modules, you must select this option, but if you are developing
|
|
|
|
with chips, you can also pull up the CS pin of SPI Flash in the external circuit to save power
|
|
|
|
consumption caused by internal pull-up during sleep.
|
|
|
|
(!!! Don't deselect this option if you don't have external SPI Flash CS pin pullups.)
|
|
|
|
|
|
|
|
config ESP_SLEEP_PSRAM_LEAKAGE_WORKAROUND
|
|
|
|
bool "Pull-up PSRAM CS pin in light sleep"
|
2023-06-25 05:12:43 -04:00
|
|
|
depends on SPIRAM
|
2023-06-19 07:06:44 -04:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
All IOs will be set to isolate(floating) state by default during sleep.
|
|
|
|
Since the power supply of PSRAM is not lost during lightsleep, if its CS pin is recognized as
|
|
|
|
low level(selected state) in the floating state, there will be a large current leakage, and the
|
|
|
|
data in PSRAM may be corrupted by random signals on other SPI pins.
|
|
|
|
Select this option will set the CS pin of PSRAM to PULL-UP state during sleep, but this will
|
|
|
|
increase the sleep current about 10 uA.
|
|
|
|
If you are developing with esp32xx modules, you must select this option, but if you are developing
|
|
|
|
with chips, you can also pull up the CS pin of PSRAM in the external circuit to save power
|
|
|
|
consumption caused by internal pull-up during sleep.
|
|
|
|
(!!! Don't deselect this option if you don't have external PSRAM CS pin pullups.)
|
|
|
|
|
|
|
|
config ESP_SLEEP_MSPI_NEED_ALL_IO_PU
|
|
|
|
bool "Pull-up all SPI pins in light sleep"
|
2023-06-25 05:12:43 -04:00
|
|
|
depends on !ESP_SLEEP_POWER_DOWN_FLASH \
|
2023-06-19 07:06:44 -04:00
|
|
|
&& (ESP_SLEEP_PSRAM_LEAKAGE_WORKAROUND || ESP_SLEEP_FLASH_LEAKAGE_WORKAROUND)
|
|
|
|
default y if IDF_TARGET_ESP32C2 || IDF_TARGET_ESP32S3
|
|
|
|
help
|
|
|
|
To reduce leakage current, some types of SPI Flash/RAM only need to pull up the CS pin
|
|
|
|
during light sleep. But there are also some kinds of SPI Flash/RAM that need to pull up
|
|
|
|
all pins. It depends on the SPI Flash/RAM chip used.
|
|
|
|
|
2021-07-16 05:44:03 -04:00
|
|
|
config ESP_SLEEP_RTC_BUS_ISO_WORKAROUND
|
|
|
|
bool
|
|
|
|
default y if IDF_TARGET_ESP32 || IDF_TARGET_ESP32S2 || IDF_TARGET_ESP32S3
|
2021-07-02 22:57:49 -04:00
|
|
|
|
2021-10-10 23:33:36 -04:00
|
|
|
config ESP_SLEEP_GPIO_RESET_WORKAROUND
|
|
|
|
bool "light sleep GPIO reset workaround"
|
2023-05-19 04:26:58 -04:00
|
|
|
default y if IDF_TARGET_ESP32C2 || IDF_TARGET_ESP32C3 || IDF_TARGET_ESP32S3 || \
|
|
|
|
IDF_TARGET_ESP32C6 || IDF_TARGET_ESP32H2
|
2021-10-10 23:33:36 -04:00
|
|
|
select PM_SLP_DISABLE_GPIO if FREERTOS_USE_TICKLESS_IDLE
|
|
|
|
help
|
2023-05-19 04:26:58 -04:00
|
|
|
esp32c2, esp32c3, esp32s3, esp32c6 and esp32h2 will reset at wake-up if GPIO is received
|
|
|
|
a small electrostatic pulse during light sleep, with specific condition
|
2021-10-10 23:33:36 -04:00
|
|
|
|
|
|
|
- GPIO needs to be configured as input-mode only
|
|
|
|
- The pin receives a small electrostatic pulse, and reset occurs when the pulse
|
|
|
|
voltage is higher than 6 V
|
|
|
|
|
|
|
|
For GPIO set to input mode only, it is not a good practice to leave it open/floating,
|
|
|
|
The hardware design needs to controlled it with determined supply or ground voltage
|
|
|
|
is necessary.
|
|
|
|
|
|
|
|
This option provides a software workaround for this issue. Configure to isolate all
|
|
|
|
GPIO pins in sleep state.
|
|
|
|
|
2023-12-06 07:37:28 -05:00
|
|
|
config ESP_SLEEP_WAIT_FLASH_READY_EXTRA_DELAY
|
|
|
|
int "Extra delay (in us) after flash powerdown sleep wakeup to wait flash ready"
|
|
|
|
default 2000 if IDF_TARGET_ESP32 || IDF_TARGET_ESP32S3
|
|
|
|
default 0
|
2022-05-10 00:27:36 -04:00
|
|
|
range 0 5000
|
|
|
|
help
|
2023-12-06 07:37:28 -05:00
|
|
|
When the chip exits sleep, the CPU and the flash chip are powered on at the same time.
|
|
|
|
CPU will run rom code (deepsleep) or ram code (lightsleep) first, and then load or execute
|
|
|
|
code from flash.
|
|
|
|
|
|
|
|
Some flash chips need sufficient time to pass between power on and first read operation.
|
|
|
|
By default, without any extra delay, this time is approximately 900us, although
|
2022-05-10 00:27:36 -04:00
|
|
|
some flash chip types need more than that.
|
|
|
|
|
2023-12-06 07:37:28 -05:00
|
|
|
(!!! Please adjust this value according to the Data Sheet of SPI Flash used in your project.)
|
|
|
|
In Flash Data Sheet, the parameters that define the Flash ready timing after power-up (minimum
|
|
|
|
time from Vcc(min) to CS activeare) usually named tVSL in ELECTRICAL CHARACTERISTICS chapter,
|
|
|
|
and the configuration value here should be:
|
|
|
|
ESP_SLEEP_WAIT_FLASH_READY_EXTRA_DELAY = tVSL - 900
|
|
|
|
|
|
|
|
For esp32 and esp32s3, the default extra delay is set to 2000us. When optimizing startup time
|
2022-05-10 00:27:36 -04:00
|
|
|
for applications which require it, this value may be reduced.
|
|
|
|
|
2023-12-06 07:37:28 -05:00
|
|
|
If you are seeing "flash read err, 1000" message printed to the console after deep sleep reset
|
|
|
|
on esp32, or triggered RTC_WDT/LP_WDT after lightsleep wakeup, try increasing this value.
|
|
|
|
(For esp32, the delay will be executed in both deep sleep and light sleep wake up flow.
|
|
|
|
For chips after esp32, the delay will be executed only in light sleep flow, the delay
|
|
|
|
controlled by the EFUSE_FLASH_TPUW in ROM will be executed in deepsleep wake up flow.)
|
2023-06-28 01:34:52 -04:00
|
|
|
|
|
|
|
config ESP_SLEEP_CACHE_SAFE_ASSERTION
|
|
|
|
bool "Check the cache safety of the sleep wakeup code in sleep process"
|
|
|
|
default n
|
2024-02-26 02:20:14 -05:00
|
|
|
select ESP_PANIC_HANDLER_IRAM
|
2023-06-28 01:34:52 -04:00
|
|
|
help
|
|
|
|
Enabling it will check the cache safety of the code before the flash power is ready after
|
|
|
|
light sleep wakeup, and check PM_SLP_IRAM_OPT related code cache safety. This option is
|
|
|
|
only for code quality inspection. Enabling it will increase the time overhead of entering
|
|
|
|
and exiting sleep. It is not recommended to enable it in the release version.
|
|
|
|
|
2023-07-21 02:49:50 -04:00
|
|
|
config ESP_SLEEP_DEBUG
|
|
|
|
bool "esp sleep debug"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
Enable esp sleep debug.
|
|
|
|
|
2023-09-14 03:42:35 -04:00
|
|
|
config ESP_SLEEP_GPIO_ENABLE_INTERNAL_RESISTORS
|
|
|
|
bool "Allow to enable internal pull-up/downs for the Deep-Sleep wakeup IOs"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
When using rtc gpio wakeup source during deepsleep without external pull-up/downs, you may want to
|
|
|
|
make use of the internal ones.
|
2023-07-06 03:52:21 -04:00
|
|
|
|
|
|
|
config ESP_SLEEP_EVENT_CALLBACKS
|
|
|
|
bool "Enable registration of sleep event callbacks"
|
|
|
|
depends on FREERTOS_USE_TICKLESS_IDLE
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
If enabled, it allows user to register sleep event callbacks. It is primarily designed for internal
|
|
|
|
developers and customers can use PM_LIGHT_SLEEP_CALLBACKS as an alternative.
|
|
|
|
|
|
|
|
NOTE: These callbacks are executed from the IDLE task context hence you cannot have any blocking calls
|
|
|
|
in your callbacks.
|
|
|
|
|
|
|
|
NOTE: Enabling these callbacks may change sleep duration calculations based on time spent in
|
|
|
|
callback and hence it is highly recommended to keep them as short as possible.
|
2021-03-10 08:55:49 -05:00
|
|
|
endmenu
|
2021-11-23 00:07:43 -05:00
|
|
|
|
|
|
|
menu "RTC Clock Config"
|
2022-03-02 02:49:31 -05:00
|
|
|
orsource "./port/$IDF_TARGET/Kconfig.rtc"
|
2021-11-23 00:07:43 -05:00
|
|
|
endmenu
|
2022-03-24 09:33:36 -04:00
|
|
|
|
|
|
|
menu "Peripheral Control"
|
|
|
|
config PERIPH_CTRL_FUNC_IN_IRAM
|
|
|
|
bool "Place peripheral control functions into IRAM"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
Place peripheral control functions (e.g. periph_module_reset) into IRAM,
|
|
|
|
so that these functions can be IRAM-safe and able to be called in the other IRAM interrupt context.
|
|
|
|
endmenu
|
2022-03-02 02:49:31 -05:00
|
|
|
|
2022-07-12 02:44:10 -04:00
|
|
|
menu "ETM Configuration"
|
|
|
|
depends on SOC_ETM_SUPPORTED
|
|
|
|
config ETM_ENABLE_DEBUG_LOG
|
|
|
|
bool "Enable debug log"
|
|
|
|
default n
|
|
|
|
help
|
2024-03-25 02:11:33 -04:00
|
|
|
whether to enable the debug log message for ETM core driver.
|
2022-07-12 02:44:10 -04:00
|
|
|
Note that, this option only controls the ETM related driver log, won't affect other drivers.
|
|
|
|
endmenu # ETM Configuration
|
|
|
|
|
2023-11-29 22:15:34 -05:00
|
|
|
rsource "./dma/Kconfig.dma"
|
2022-06-27 23:06:27 -04:00
|
|
|
|
2022-07-12 22:54:41 -04:00
|
|
|
menu "Main XTAL Config"
|
2023-12-18 07:43:06 -05:00
|
|
|
# TODO: IDF-8943
|
2022-07-12 22:54:41 -04:00
|
|
|
choice XTAL_FREQ_SEL
|
|
|
|
prompt "Main XTAL frequency"
|
2024-01-01 22:16:55 -05:00
|
|
|
default XTAL_FREQ_48 if SOC_XTAL_SUPPORT_48M
|
|
|
|
default XTAL_FREQ_40 if (SOC_XTAL_SUPPORT_40M && !SOC_XTAL_SUPPORT_48M)
|
2022-07-12 22:54:41 -04:00
|
|
|
help
|
|
|
|
This option selects the operating frequency of the XTAL (crystal) clock used to drive the ESP target.
|
|
|
|
The selected value MUST reflect the frequency of the given hardware.
|
|
|
|
|
|
|
|
Note: The XTAL_FREQ_AUTO option allows the ESP target to automatically estimating XTAL clock's
|
|
|
|
operating frequency. However, this feature is only supported on the ESP32. The ESP32 uses the
|
|
|
|
internal 8MHZ as a reference when estimating. Due to the internal oscillator's frequency being
|
|
|
|
temperature dependent, usage of the XTAL_FREQ_AUTO is not recommended in applications that operate
|
|
|
|
in high ambient temperatures or use high-temperature qualified chips and modules.
|
|
|
|
|
|
|
|
config XTAL_FREQ_24
|
|
|
|
depends on SOC_XTAL_SUPPORT_24M
|
|
|
|
bool "24 MHz"
|
|
|
|
config XTAL_FREQ_26
|
|
|
|
depends on SOC_XTAL_SUPPORT_26M
|
|
|
|
bool "26 MHz"
|
|
|
|
config XTAL_FREQ_32
|
|
|
|
depends on SOC_XTAL_SUPPORT_32M
|
|
|
|
bool "32 MHz"
|
|
|
|
config XTAL_FREQ_40
|
|
|
|
depends on SOC_XTAL_SUPPORT_40M
|
|
|
|
bool "40 MHz"
|
2024-01-01 22:16:55 -05:00
|
|
|
config XTAL_FREQ_48
|
|
|
|
depends on SOC_XTAL_SUPPORT_48M
|
|
|
|
bool "48 MHz"
|
2022-07-12 22:54:41 -04:00
|
|
|
config XTAL_FREQ_AUTO
|
|
|
|
depends on SOC_XTAL_SUPPORT_AUTO_DETECT
|
|
|
|
bool "Autodetect"
|
|
|
|
endchoice
|
|
|
|
|
2024-01-03 02:28:29 -05:00
|
|
|
# soc_xtal_freq_t enum in soc/clk_tree_defs.h lists the XTAL frequencies can be supported
|
2022-07-12 22:54:41 -04:00
|
|
|
# SOC_XTAL_SUPPORT_XXX in soc_caps.h lists the XTAL frequencies already supported
|
|
|
|
config XTAL_FREQ
|
|
|
|
int
|
|
|
|
default 24 if XTAL_FREQ_24
|
|
|
|
default 26 if XTAL_FREQ_26
|
|
|
|
default 32 if XTAL_FREQ_32
|
|
|
|
default 40 if XTAL_FREQ_40
|
2024-01-01 22:16:55 -05:00
|
|
|
default 48 if XTAL_FREQ_48
|
2022-07-12 22:54:41 -04:00
|
|
|
default 0 if XTAL_FREQ_AUTO
|
|
|
|
endmenu
|
2023-05-24 07:31:41 -04:00
|
|
|
|
|
|
|
menu "Crypto DPA Protection"
|
|
|
|
depends on SOC_CRYPTO_DPA_PROTECTION_SUPPORTED
|
|
|
|
config ESP_CRYPTO_DPA_PROTECTION_AT_STARTUP
|
|
|
|
bool "Enable crypto DPA protection at startup"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This config controls the DPA (Differential Power Analysis) protection
|
|
|
|
knob for the crypto peripherals. DPA protection dynamically adjusts the
|
|
|
|
clock frequency of the crypto peripheral. DPA protection helps to make it
|
|
|
|
difficult to perform SCA attacks on the crypto peripherals. However,
|
|
|
|
there is also associated performance impact based on the security level
|
|
|
|
set. Please refer to the TRM for more details.
|
|
|
|
|
|
|
|
choice ESP_CRYPTO_DPA_PROTECTION_LEVEL
|
|
|
|
prompt "DPA protection level"
|
|
|
|
depends on ESP_CRYPTO_DPA_PROTECTION_AT_STARTUP
|
|
|
|
default ESP_CRYPTO_DPA_PROTECTION_LEVEL_LOW
|
|
|
|
help
|
|
|
|
Configure the DPA protection security level
|
|
|
|
|
|
|
|
config ESP_CRYPTO_DPA_PROTECTION_LEVEL_LOW
|
|
|
|
bool "Security level low"
|
|
|
|
|
|
|
|
config ESP_CRYPTO_DPA_PROTECTION_LEVEL_MEDIUM
|
|
|
|
bool "Security level medium"
|
|
|
|
|
|
|
|
config ESP_CRYPTO_DPA_PROTECTION_LEVEL_HIGH
|
|
|
|
bool "Security level high"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config ESP_CRYPTO_DPA_PROTECTION_LEVEL
|
|
|
|
int
|
|
|
|
default 1 if ESP_CRYPTO_DPA_PROTECTION_LEVEL_LOW
|
|
|
|
default 2 if ESP_CRYPTO_DPA_PROTECTION_LEVEL_MEDIUM
|
|
|
|
default 3 if ESP_CRYPTO_DPA_PROTECTION_LEVEL_HIGH
|
|
|
|
|
|
|
|
endmenu
|
2023-06-20 04:04:41 -04:00
|
|
|
|
2024-04-19 01:38:22 -04:00
|
|
|
orsource "./port/$IDF_TARGET/Kconfig.dcdc"
|
|
|
|
|
2024-03-17 09:40:57 -04:00
|
|
|
orsource "./port/$IDF_TARGET/Kconfig.ldo"
|
2023-12-22 05:44:51 -05:00
|
|
|
|
2023-06-20 04:04:41 -04:00
|
|
|
# Invisible bringup bypass options for esp_hw_support component
|
|
|
|
config ESP_BRINGUP_BYPASS_CPU_CLK_SETTING
|
|
|
|
bool
|
2024-01-01 22:16:55 -05:00
|
|
|
# TODO: [ESP32C5] IDF-8642 IDF_TARGET_ESP32C5 is added because clock
|
|
|
|
# is required when bringup on C5 beta3, remove it when clock tree is
|
|
|
|
# supported
|
|
|
|
default y if !SOC_CLK_TREE_SUPPORTED && !IDF_TARGET_ESP32C5
|
2023-06-20 04:04:41 -04:00
|
|
|
default n
|
|
|
|
help
|
|
|
|
This option is only used for new chip bringup, when
|
|
|
|
clock support isn't done yet. So with this option,
|
|
|
|
we use xtal on FPGA as the clock source.
|
|
|
|
|
2023-12-04 21:42:19 -05:00
|
|
|
config ESP_BRINGUP_BYPASS_RANDOM_SETTING
|
|
|
|
bool
|
|
|
|
default y if !SOC_RNG_SUPPORTED
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This option is only used for new chip bringup, when
|
|
|
|
RNG isn't done yet. So with this option, we use 0x5A
|
|
|
|
to fill the random buffers
|
|
|
|
|
2023-11-13 22:14:34 -05:00
|
|
|
config ESP_SPI_BUS_LOCK_ISR_FUNCS_IN_IRAM
|
|
|
|
bool
|
|
|
|
default n
|
|
|
|
|
|
|
|
config ESP_SPI_BUS_LOCK_FUNCS_IN_IRAM
|
|
|
|
bool
|
|
|
|
default n
|
2021-02-18 08:09:27 -05:00
|
|
|
endmenu
|