-
Notifications
You must be signed in to change notification settings - Fork 7k
/
Kconfig
341 lines (268 loc) · 13.9 KB
/
Kconfig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
#
# For a description of the syntax of this configuration file,
# see kconfig/kconfig-language.txt.
#
mainmenu "Espressif IoT Development Framework Configuration"
# Hidden option to support checking for this specific target in C code and Kconfig files
config IDF_TARGET_ESP32
bool
default "y" if IDF_TARGET="esp32"
default "n"
config IDF_CMAKE
bool
option env="IDF_CMAKE"
config IDF_TARGET
# This option records the IDF target when sdkconfig is generated the first time.
# It is not updated if environment variable $IDF_TARGET changes later, and
# the build system is responsible for detecting the mismatch between
# CONFIG_IDF_TARGET and $IDF_TARGET.
string
default "$(IDF_TARGET)"
config IDF_TARGET_ESP32
bool
default "y" if IDF_TARGET="esp32"
default "n"
config IDF_TARGET_ESP32S2BETA
bool
default "y" if IDF_TARGET="esp32s2beta"
default "n"
select FREERTOS_UNICORE
config IDF_FIRMWARE_CHIP_ID
hex
default 0x0000 if IDF_TARGET_ESP32
# note: S2 beta uses Chip ID 0 still, S2 will use 0x0002
default 0x0000 if IDF_TARGET_ESP32S2BETA
default 0xFFFF
menu "SDK tool configuration"
config SDK_TOOLPREFIX
string "Compiler toolchain path/prefix"
default "xtensa-esp32-elf-" if IDF_TARGET_ESP32
default "xtensa-esp32s2-elf-" if IDF_TARGET_ESP32S2BETA
help
The prefix/path that is used to call the toolchain. The default setting assumes
a crosstool-ng gcc setup that is in your PATH.
config SDK_PYTHON
string "Python 2 interpreter"
depends on !IDF_CMAKE
default "python"
help
The executable name/path that is used to run python. On some systems Python 2.x
may need to be invoked as python2.
(Note: This option is used with the legacy GNU Make build system only.)
config SDK_MAKE_WARN_UNDEFINED_VARIABLES
bool "'make' warns on undefined variables"
depends on !IDF_CMAKE
default "y"
help
Adds --warn-undefined-variables to MAKEFLAGS. This causes make to
print a warning any time an undefined variable is referenced.
This option helps find places where a variable reference is misspelled
or otherwise missing, but it can be unwanted if you have Makefiles which
depend on undefined variables expanding to an empty string.
(Note: this option is used with the legacy GNU Make build system only.)
endmenu # SDK tool configuration
menu "Build type"
choice APP_BUILD_TYPE
prompt "Application build type"
default APP_BUILD_TYPE_APP_2NDBOOT
help
Select the way the application is built.
By default, the application is built as a binary file in a format compatible with
the ESP32 bootloader. In addition to this application, 2nd stage bootloader is
also built. Application and bootloader binaries can be written into flash and
loaded/executed from there.
Another option, useful for only very small and limited applications, is to only link
the .elf file of the application, such that it can be loaded directly into RAM over
JTAG. Note that since IRAM and DRAM sizes are very limited, it is not possible to
build any complex application this way. However for kinds of testing and debugging,
this option may provide faster iterations, since the application does not need to be
written into flash.
Note that at the moment, ESP-IDF does not contain all the startup code required to
initialize the CPUs and ROM memory (data/bss). Therefore it is necessary to execute
a bit of ROM code prior to executing the application. A gdbinit file may look as follows:
# Connect to a running instance of OpenOCD
target remote :3333
# Reset and halt the target
mon reset halt
# Run to a specific point in ROM code,
# where most of initialization is complete.
thb *0x40007901
c
# Load the application into RAM
load
# Run till app_main
tb app_main
c
Execute this gdbinit file as follows:
xtensa-esp32-elf-gdb build/app-name.elf -x gdbinit
Recommended sdkconfig.defaults for building loadable ELF files is as follows.
CONFIG_APP_BUILD_TYPE_ELF_RAM is required, other options help reduce application
memory footprint.
CONFIG_APP_BUILD_TYPE_ELF_RAM=y
CONFIG_VFS_SUPPORT_TERMIOS=
CONFIG_NEWLIB_NANO_FORMAT=y
CONFIG_ESP32_PANIC_PRINT_HALT=y
CONFIG_ESP32_DEBUG_STUBS_ENABLE=
CONFIG_ESP_ERR_TO_NAME_LOOKUP=
config APP_BUILD_TYPE_APP_2NDBOOT
bool
prompt "Default (binary application + 2nd stage bootloader)"
select APP_BUILD_GENERATE_BINARIES
select APP_BUILD_BOOTLOADER
select APP_BUILD_USE_FLASH_SECTIONS
config APP_BUILD_TYPE_ELF_RAM
bool
prompt "ELF file, loadable into RAM (EXPERIMENTAL))"
endchoice # APP_BUILD_TYPE
# Hidden options, set according to the choice above
config APP_BUILD_GENERATE_BINARIES
bool # Whether to generate .bin files or not
config APP_BUILD_BOOTLOADER
bool # Whether to build the bootloader
config APP_BUILD_USE_FLASH_SECTIONS
bool # Whether to place code/data into memory-mapped flash sections
endmenu # Build type
source "$COMPONENT_KCONFIGS_PROJBUILD_SOURCE_FILE"
menu "Compiler options"
choice COMPILER_OPTIMIZATION
prompt "Optimization Level"
default COMPILER_OPTIMIZATION_DEFAULT
help
This option sets compiler optimization level (gcc -O argument).
- The "Default" setting will add the -0g flag to CFLAGS.
- The "Size" setting will add the -0s flag to CFLAGS.
- The "Performance" setting will add the -O2 flag to CFLAGS.
- The "None" setting will add the -O0 flag to CFLAGS.
The "Size" setting cause the compiled code to be smaller and faster, but
may lead to difficulties of correlating code addresses to source file
lines when debugging.
The "Performance" setting causes the compiled code to be larger and faster,
but will be easier to correlated code addresses to source file lines.
"None" with -O0 produces compiled code without optimization.
Note that custom optimization levels may be unsupported.
config COMPILER_OPTIMIZATION_DEFAULT
bool "Debug (-Og)"
config COMPILER_OPTIMIZATION_SIZE
bool "Optimize for size (-Os)"
config COMPILER_OPTIMIZATION_PERF
bool "Optimize for performance (-O2)"
config COMPILER_OPTIMIZATION_NONE
bool "Debug without optimization (-O0)"
endchoice
choice COMPILER_OPTIMIZATION_ASSERTION_LEVEL
prompt "Assertion level"
default COMPILER_OPTIMIZATION_ASSERTIONS_ENABLE
help
Assertions can be:
- Enabled. Failure will print verbose assertion details. This is the default.
- Set to "silent" to save code size (failed assertions will abort() but user
needs to use the aborting address to find the line number with the failed assertion.)
- Disabled entirely (not recommended for most configurations.) -DNDEBUG is added
to CPPFLAGS in this case.
config COMPILER_OPTIMIZATION_ASSERTIONS_ENABLE
prompt "Enabled"
bool
help
Enable assertions. Assertion content and line number will be printed on failure.
config COMPILER_OPTIMIZATION_ASSERTIONS_SILENT
prompt "Silent (saves code size)"
bool
help
Enable silent assertions. Failed assertions will abort(), user needs to
use the aborting address to find the line number with the failed assertion.
config COMPILER_OPTIMIZATION_ASSERTIONS_DISABLE
prompt "Disabled (sets -DNDEBUG)"
bool
help
If assertions are disabled, -DNDEBUG is added to CPPFLAGS.
endchoice # assertions
menuconfig COMPILER_CXX_EXCEPTIONS
bool "Enable C++ exceptions"
default n
help
Enabling this option compiles all IDF C++ files with exception support enabled.
Disabling this option disables C++ exception support in all compiled files, and any libstdc++ code
which throws an exception will abort instead.
Enabling this option currently adds an additional ~500 bytes of heap overhead
when an exception is thrown in user code for the first time.
config COMPILER_CXX_EXCEPTIONS_EMG_POOL_SIZE
int "Emergency Pool Size"
default 0
depends on COMPILER_CXX_EXCEPTIONS
help
Size (in bytes) of the emergency memory pool for C++ exceptions. This pool will be used to allocate
memory for thrown exceptions when there is not enough memory on the heap.
config COMPILER_CXX_RTTI
bool "Enable C++ run-time type info (RTTI)"
default n
help
Enabling this option compiles all C++ files with RTTI support enabled.
This increases binary size (typically by tens of kB) but allows using
dynamic_cast conversion and typeid operator.
choice COMPILER_STACK_CHECK_MODE
prompt "Stack smashing protection mode"
default COMPILER_STACK_CHECK_MODE_NONE
help
Stack smashing protection mode. Emit extra code to check for buffer overflows, such as stack
smashing attacks. This is done by adding a guard variable to functions with vulnerable objects.
The guards are initialized when a function is entered and then checked when the function exits.
If a guard check fails, program is halted. Protection has the following modes:
- In NORMAL mode (GCC flag: -fstack-protector) only functions that call alloca, and functions with
buffers larger than 8 bytes are protected.
- STRONG mode (GCC flag: -fstack-protector-strong) is like NORMAL, but includes additional functions
to be protected -- those that have local array definitions, or have references to local frame
addresses.
- In OVERALL mode (GCC flag: -fstack-protector-all) all functions are protected.
Modes have the following impact on code performance and coverage:
- performance: NORMAL > STRONG > OVERALL
- coverage: NORMAL < STRONG < OVERALL
config COMPILER_STACK_CHECK_MODE_NONE
bool "None"
config COMPILER_STACK_CHECK_MODE_NORM
bool "Normal"
config COMPILER_STACK_CHECK_MODE_STRONG
bool "Strong"
config COMPILER_STACK_CHECK_MODE_ALL
bool "Overall"
endchoice
config COMPILER_STACK_CHECK
bool
default !COMPILER_STACK_CHECK_MODE_NONE
help
Stack smashing protection.
config COMPILER_WARN_WRITE_STRINGS
bool "Enable -Wwrite-strings warning flag"
default "n"
help
Adds -Wwrite-strings flag for the C/C++ compilers.
For C, this gives string constants the type ``const char[]`` so that
copying the address of one into a non-const ``char *`` pointer
produces a warning. This warning helps to find at compile time code
that tries to write into a string constant.
For C++, this warns about the deprecated conversion from string
literals to ``char *``.
config COMPILER_DISABLE_GCC8_WARNINGS
bool "Disable new warnings introduced in GCC 6 - 8"
default "n"
help
Enable this option if using GCC 6 or newer, and wanting to disable warnings which don't appear with
GCC 5.
endmenu # Compiler Options
menu "Component config"
source "$COMPONENT_KCONFIGS_SOURCE_FILE"
endmenu
menu "Compatibility options"
config LEGACY_INCLUDE_COMMON_HEADERS
bool "Include headers accross components as before IDF v4.0"
default n
help
Soc, esp32, and driver components, the most common
components. Some header of these components are included
implicitly by headers of other components before IDF v4.0.
It's not required for high-level components, but still
included through long header chain everywhere.
This is harmful to the modularity. So it's changed in IDF
v4.0.
You can still include these headers in a legacy way until it
is totally deprecated by enable this option.
endmenu #Compatibility options