.. | .. |
---|
1 | 1 | # SPDX-License-Identifier: GPL-2.0 |
---|
2 | | -config ZONE_DMA |
---|
3 | | - def_bool y |
---|
4 | | - |
---|
5 | 2 | config XTENSA |
---|
6 | 3 | def_bool y |
---|
7 | | - select ARCH_HAS_SG_CHAIN |
---|
8 | | - select ARCH_HAS_SYNC_DMA_FOR_CPU |
---|
9 | | - select ARCH_HAS_SYNC_DMA_FOR_DEVICE |
---|
10 | | - select ARCH_NO_COHERENT_DMA_MMAP if !MMU |
---|
| 4 | + select ARCH_32BIT_OFF_T |
---|
| 5 | + select ARCH_HAS_BINFMT_FLAT if !MMU |
---|
| 6 | + select ARCH_HAS_DMA_PREP_COHERENT if MMU |
---|
| 7 | + select ARCH_HAS_SYNC_DMA_FOR_CPU if MMU |
---|
| 8 | + select ARCH_HAS_SYNC_DMA_FOR_DEVICE if MMU |
---|
| 9 | + select ARCH_HAS_DMA_SET_UNCACHED if MMU |
---|
| 10 | + select ARCH_USE_QUEUED_RWLOCKS |
---|
| 11 | + select ARCH_USE_QUEUED_SPINLOCKS |
---|
11 | 12 | select ARCH_WANT_FRAME_POINTERS |
---|
12 | 13 | select ARCH_WANT_IPC_PARSE_VERSION |
---|
13 | | - select BUILDTIME_EXTABLE_SORT |
---|
| 14 | + select BUILDTIME_TABLE_SORT |
---|
14 | 15 | select CLONE_BACKWARDS |
---|
15 | 16 | select COMMON_CLK |
---|
16 | | - select DMA_NONCOHERENT_OPS |
---|
| 17 | + select DMA_REMAP if MMU |
---|
17 | 18 | select GENERIC_ATOMIC64 |
---|
18 | 19 | select GENERIC_CLOCKEVENTS |
---|
19 | 20 | select GENERIC_IRQ_SHOW |
---|
20 | 21 | select GENERIC_PCI_IOMAP |
---|
21 | 22 | select GENERIC_SCHED_CLOCK |
---|
22 | 23 | select GENERIC_STRNCPY_FROM_USER if KASAN |
---|
23 | | - select HAVE_ARCH_KASAN if MMU |
---|
| 24 | + select HAVE_ARCH_AUDITSYSCALL |
---|
| 25 | + select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL |
---|
| 26 | + select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL |
---|
| 27 | + select HAVE_ARCH_SECCOMP_FILTER |
---|
| 28 | + select HAVE_ARCH_TRACEHOOK |
---|
24 | 29 | select HAVE_DEBUG_KMEMLEAK |
---|
25 | 30 | select HAVE_DMA_CONTIGUOUS |
---|
26 | 31 | select HAVE_EXIT_THREAD |
---|
.. | .. |
---|
28 | 33 | select HAVE_FUTEX_CMPXCHG if !MMU && FUTEX |
---|
29 | 34 | select HAVE_HW_BREAKPOINT if PERF_EVENTS |
---|
30 | 35 | select HAVE_IRQ_TIME_ACCOUNTING |
---|
31 | | - select HAVE_MEMBLOCK |
---|
32 | 36 | select HAVE_OPROFILE |
---|
| 37 | + select HAVE_PCI |
---|
33 | 38 | select HAVE_PERF_EVENTS |
---|
34 | 39 | select HAVE_STACKPROTECTOR |
---|
| 40 | + select HAVE_SYSCALL_TRACEPOINTS |
---|
35 | 41 | select IRQ_DOMAIN |
---|
36 | 42 | select MODULES_USE_ELF_RELA |
---|
37 | | - select NO_BOOTMEM |
---|
38 | 43 | select PERF_USE_VMALLOC |
---|
| 44 | + select SET_FS |
---|
39 | 45 | select VIRT_TO_BUS |
---|
40 | 46 | help |
---|
41 | 47 | Xtensa processors are 32-bit RISC machines designed by Tensilica |
---|
.. | .. |
---|
44 | 50 | architecture supports all processor configurations and extensions, |
---|
45 | 51 | with reasonable minimum requirements. The Xtensa Linux project has |
---|
46 | 52 | a home page at <http://www.linux-xtensa.org/>. |
---|
47 | | - |
---|
48 | | -config RWSEM_XCHGADD_ALGORITHM |
---|
49 | | - def_bool y |
---|
50 | 53 | |
---|
51 | 54 | config GENERIC_HWEIGHT |
---|
52 | 55 | def_bool y |
---|
.. | .. |
---|
121 | 124 | help |
---|
122 | 125 | Provide the name of a custom Xtensa processor variant. |
---|
123 | 126 | This CORENAME selects arch/xtensa/variant/CORENAME. |
---|
124 | | - Dont forget you have to select MMU if you have one. |
---|
| 127 | + Don't forget you have to select MMU if you have one. |
---|
125 | 128 | |
---|
126 | 129 | config XTENSA_VARIANT_NAME |
---|
127 | 130 | string |
---|
.. | .. |
---|
166 | 169 | If unsure, say N. |
---|
167 | 170 | |
---|
168 | 171 | config XTENSA_UNALIGNED_USER |
---|
169 | | - bool "Unaligned memory access in use space" |
---|
| 172 | + bool "Unaligned memory access in user space" |
---|
170 | 173 | help |
---|
171 | 174 | The Xtensa architecture currently does not handle unaligned |
---|
172 | 175 | memory accesses in hardware but through an exception handler. |
---|
.. | .. |
---|
179 | 182 | depends on XTENSA_VARIANT_CUSTOM |
---|
180 | 183 | select XTENSA_MX |
---|
181 | 184 | help |
---|
182 | | - This option is use to indicate that the system-on-a-chip (SOC) |
---|
| 185 | + This option is used to indicate that the system-on-a-chip (SOC) |
---|
183 | 186 | supports Multiprocessing. Multiprocessor support implemented above |
---|
184 | 187 | the CPU core definition and currently needs to be selected manually. |
---|
185 | 188 | |
---|
186 | | - Multiprocessor support in implemented with external cache and |
---|
| 189 | + Multiprocessor support is implemented with external cache and |
---|
187 | 190 | interrupt controllers. |
---|
188 | 191 | |
---|
189 | 192 | The MX interrupt distributer adds Interprocessor Interrupts |
---|
.. | .. |
---|
215 | 218 | |
---|
216 | 219 | Say N if you want to disable CPU hotplug. |
---|
217 | 220 | |
---|
218 | | -config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
219 | | - bool "Initialize Xtensa MMU inside the Linux kernel code" |
---|
220 | | - depends on !XTENSA_VARIANT_FSF && !XTENSA_VARIANT_DC232B |
---|
221 | | - default y if XTENSA_VARIANT_DC233C || XTENSA_VARIANT_CUSTOM |
---|
222 | | - help |
---|
223 | | - Earlier version initialized the MMU in the exception vector |
---|
224 | | - before jumping to _startup in head.S and had an advantage that |
---|
225 | | - it was possible to place a software breakpoint at 'reset' and |
---|
226 | | - then enter your normal kernel breakpoints once the MMU was mapped |
---|
227 | | - to the kernel mappings (0XC0000000). |
---|
228 | | - |
---|
229 | | - This unfortunately won't work for U-Boot and likely also wont |
---|
230 | | - work for using KEXEC to have a hot kernel ready for doing a |
---|
231 | | - KDUMP. |
---|
232 | | - |
---|
233 | | - So now the MMU is initialized in head.S but it's necessary to |
---|
234 | | - use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup. |
---|
235 | | - xt-gdb can't place a Software Breakpoint in the 0XD region prior |
---|
236 | | - to mapping the MMU and after mapping even if the area of low memory |
---|
237 | | - was mapped gdb wouldn't remove the breakpoint on hitting it as the |
---|
238 | | - PC wouldn't match. Since Hardware Breakpoints are recommended for |
---|
239 | | - Linux configurations it seems reasonable to just assume they exist |
---|
240 | | - and leave this older mechanism for unfortunate souls that choose |
---|
241 | | - not to follow Tensilica's recommendation. |
---|
242 | | - |
---|
243 | | - Selecting this will cause U-Boot to set the KERNEL Load and Entry |
---|
244 | | - address at 0x00003000 instead of the mapped std of 0xD0003000. |
---|
245 | | - |
---|
246 | | - If in doubt, say Y. |
---|
247 | | - |
---|
248 | | -config MEMMAP_CACHEATTR |
---|
249 | | - hex "Cache attributes for the memory address space" |
---|
250 | | - depends on !MMU |
---|
251 | | - default 0x22222222 |
---|
252 | | - help |
---|
253 | | - These cache attributes are set up for noMMU systems. Each hex digit |
---|
254 | | - specifies cache attributes for the corresponding 512MB memory |
---|
255 | | - region: bits 0..3 -- for addresses 0x00000000..0x1fffffff, |
---|
256 | | - bits 4..7 -- for addresses 0x20000000..0x3fffffff, and so on. |
---|
257 | | - |
---|
258 | | - Cache attribute values are specific for the MMU type, so e.g. |
---|
259 | | - for region protection MMUs: 2 is cache bypass, 4 is WB cached, |
---|
260 | | - 1 is WT cached, f is illegal. For ful MMU: bit 0 makes it executable, |
---|
261 | | - bit 1 makes it writable, bits 2..3 meaning is 0: cache bypass, |
---|
262 | | - 1: WB cache, 2: WT cache, 3: special (c and e are illegal, f is |
---|
263 | | - reserved). |
---|
264 | | - |
---|
265 | | -config KSEG_PADDR |
---|
266 | | - hex "Physical address of the KSEG mapping" |
---|
267 | | - depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX && MMU |
---|
268 | | - default 0x00000000 |
---|
269 | | - help |
---|
270 | | - This is the physical address where KSEG is mapped. Please refer to |
---|
271 | | - the chosen KSEG layout help for the required address alignment. |
---|
272 | | - Unpacked kernel image (including vectors) must be located completely |
---|
273 | | - within KSEG. |
---|
274 | | - Physical memory below this address is not available to linux. |
---|
275 | | - |
---|
276 | | - If unsure, leave the default value here. |
---|
277 | | - |
---|
278 | | -config KERNEL_LOAD_ADDRESS |
---|
279 | | - hex "Kernel load address" |
---|
280 | | - default 0x60003000 if !MMU |
---|
281 | | - default 0x00003000 if MMU && INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
282 | | - default 0xd0003000 if MMU && !INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
283 | | - help |
---|
284 | | - This is the address where the kernel is loaded. |
---|
285 | | - It is virtual address for MMUv2 configurations and physical address |
---|
286 | | - for all other configurations. |
---|
287 | | - |
---|
288 | | - If unsure, leave the default value here. |
---|
289 | | - |
---|
290 | | -config VECTORS_OFFSET |
---|
291 | | - hex "Kernel vectors offset" |
---|
292 | | - default 0x00003000 |
---|
293 | | - help |
---|
294 | | - This is the offset of the kernel image from the relocatable vectors |
---|
295 | | - base. |
---|
296 | | - |
---|
297 | | - If unsure, leave the default value here. |
---|
298 | | - |
---|
299 | | -choice |
---|
300 | | - prompt "KSEG layout" |
---|
301 | | - depends on MMU |
---|
302 | | - default XTENSA_KSEG_MMU_V2 |
---|
303 | | - |
---|
304 | | -config XTENSA_KSEG_MMU_V2 |
---|
305 | | - bool "MMUv2: 128MB cached + 128MB uncached" |
---|
306 | | - help |
---|
307 | | - MMUv2 compatible kernel memory map: TLB way 5 maps 128MB starting |
---|
308 | | - at KSEG_PADDR to 0xd0000000 with cache and to 0xd8000000 |
---|
309 | | - without cache. |
---|
310 | | - KSEG_PADDR must be aligned to 128MB. |
---|
311 | | - |
---|
312 | | -config XTENSA_KSEG_256M |
---|
313 | | - bool "256MB cached + 256MB uncached" |
---|
314 | | - depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
315 | | - help |
---|
316 | | - TLB way 6 maps 256MB starting at KSEG_PADDR to 0xb0000000 |
---|
317 | | - with cache and to 0xc0000000 without cache. |
---|
318 | | - KSEG_PADDR must be aligned to 256MB. |
---|
319 | | - |
---|
320 | | -config XTENSA_KSEG_512M |
---|
321 | | - bool "512MB cached + 512MB uncached" |
---|
322 | | - depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
323 | | - help |
---|
324 | | - TLB way 6 maps 512MB starting at KSEG_PADDR to 0xa0000000 |
---|
325 | | - with cache and to 0xc0000000 without cache. |
---|
326 | | - KSEG_PADDR must be aligned to 256MB. |
---|
327 | | - |
---|
328 | | -endchoice |
---|
329 | | - |
---|
330 | | -config HIGHMEM |
---|
331 | | - bool "High Memory Support" |
---|
332 | | - depends on MMU |
---|
333 | | - help |
---|
334 | | - Linux can use the full amount of RAM in the system by |
---|
335 | | - default. However, the default MMUv2 setup only maps the |
---|
336 | | - lowermost 128 MB of memory linearly to the areas starting |
---|
337 | | - at 0xd0000000 (cached) and 0xd8000000 (uncached). |
---|
338 | | - When there are more than 128 MB memory in the system not |
---|
339 | | - all of it can be "permanently mapped" by the kernel. |
---|
340 | | - The physical memory that's not permanently mapped is called |
---|
341 | | - "high memory". |
---|
342 | | - |
---|
343 | | - If you are compiling a kernel which will never run on a |
---|
344 | | - machine with more than 128 MB total physical RAM, answer |
---|
345 | | - N here. |
---|
346 | | - |
---|
347 | | - If unsure, say Y. |
---|
348 | | - |
---|
349 | 221 | config FAST_SYSCALL_XTENSA |
---|
350 | 222 | bool "Enable fast atomic syscalls" |
---|
351 | 223 | default n |
---|
.. | .. |
---|
372 | 244 | |
---|
373 | 245 | If unsure, say N. |
---|
374 | 246 | |
---|
| 247 | +config USER_ABI_CALL0 |
---|
| 248 | + bool |
---|
| 249 | + |
---|
| 250 | +choice |
---|
| 251 | + prompt "Userspace ABI" |
---|
| 252 | + default USER_ABI_DEFAULT |
---|
| 253 | + help |
---|
| 254 | + Select supported userspace ABI. |
---|
| 255 | + |
---|
| 256 | + If unsure, choose the default ABI. |
---|
| 257 | + |
---|
| 258 | +config USER_ABI_DEFAULT |
---|
| 259 | + bool "Default ABI only" |
---|
| 260 | + help |
---|
| 261 | + Assume default userspace ABI. For XEA2 cores it is windowed ABI. |
---|
| 262 | + call0 ABI binaries may be run on such kernel, but signal delivery |
---|
| 263 | + will not work correctly for them. |
---|
| 264 | + |
---|
| 265 | +config USER_ABI_CALL0_ONLY |
---|
| 266 | + bool "Call0 ABI only" |
---|
| 267 | + select USER_ABI_CALL0 |
---|
| 268 | + help |
---|
| 269 | + Select this option to support only call0 ABI in userspace. |
---|
| 270 | + Windowed ABI binaries will crash with a segfault caused by |
---|
| 271 | + an illegal instruction exception on the first 'entry' opcode. |
---|
| 272 | + |
---|
| 273 | + Choose this option if you're planning to run only user code |
---|
| 274 | + built with call0 ABI. |
---|
| 275 | + |
---|
| 276 | +config USER_ABI_CALL0_PROBE |
---|
| 277 | + bool "Support both windowed and call0 ABI by probing" |
---|
| 278 | + select USER_ABI_CALL0 |
---|
| 279 | + help |
---|
| 280 | + Select this option to support both windowed and call0 userspace |
---|
| 281 | + ABIs. When enabled all processes are started with PS.WOE disabled |
---|
| 282 | + and a fast user exception handler for an illegal instruction is |
---|
| 283 | + used to turn on PS.WOE bit on the first 'entry' opcode executed by |
---|
| 284 | + the userspace. |
---|
| 285 | + |
---|
| 286 | + This option should be enabled for the kernel that must support |
---|
| 287 | + both call0 and windowed ABIs in userspace at the same time. |
---|
| 288 | + |
---|
| 289 | + Note that Xtensa ISA does not guarantee that entry opcode will |
---|
| 290 | + raise an illegal instruction exception on cores with XEA2 when |
---|
| 291 | + PS.WOE is disabled, check whether the target core supports it. |
---|
| 292 | + |
---|
| 293 | +endchoice |
---|
| 294 | + |
---|
375 | 295 | endmenu |
---|
376 | 296 | |
---|
377 | 297 | config XTENSA_CALIBRATE_CCOUNT |
---|
.. | .. |
---|
384 | 304 | config SERIAL_CONSOLE |
---|
385 | 305 | def_bool n |
---|
386 | 306 | |
---|
387 | | -menu "Bus options" |
---|
388 | | - |
---|
389 | | -config PCI |
---|
390 | | - bool "PCI support" |
---|
391 | | - default y |
---|
392 | | - help |
---|
393 | | - Find out whether you have a PCI motherboard. PCI is the name of a |
---|
394 | | - bus system, i.e. the way the CPU talks to the other stuff inside |
---|
395 | | - your box. Other bus systems are ISA, EISA, MicroChannel (MCA) or |
---|
396 | | - VESA. If you have PCI, say Y, otherwise N. |
---|
397 | | - |
---|
398 | | -source "drivers/pci/Kconfig" |
---|
399 | | - |
---|
400 | | -endmenu |
---|
| 307 | +config PLATFORM_HAVE_XIP |
---|
| 308 | + def_bool n |
---|
401 | 309 | |
---|
402 | 310 | menu "Platform options" |
---|
403 | 311 | |
---|
.. | .. |
---|
425 | 333 | select PLATFORM_WANT_DEFAULT_MEM if !MMU |
---|
426 | 334 | select SERIAL_CONSOLE |
---|
427 | 335 | select XTENSA_CALIBRATE_CCOUNT |
---|
| 336 | + select PLATFORM_HAVE_XIP |
---|
428 | 337 | help |
---|
429 | 338 | XTFPGA is the name of Tensilica board family (LX60, LX110, LX200, ML605). |
---|
430 | 339 | This hardware is capable of running a full Linux distribution. |
---|
.. | .. |
---|
464 | 373 | bool "Flattened Device Tree support" |
---|
465 | 374 | select OF |
---|
466 | 375 | select OF_EARLY_FLATTREE |
---|
467 | | - select OF_RESERVED_MEM |
---|
468 | 376 | help |
---|
469 | 377 | Include support for flattened device tree machine descriptions. |
---|
470 | 378 | |
---|
471 | | -config BUILTIN_DTB |
---|
| 379 | +config BUILTIN_DTB_SOURCE |
---|
472 | 380 | string "DTB to build into the kernel image" |
---|
473 | 381 | depends on OF |
---|
474 | 382 | |
---|
.. | .. |
---|
517 | 425 | Another simulated disk in a host file for a buildroot-independent |
---|
518 | 426 | storage. |
---|
519 | 427 | |
---|
520 | | -config FORCE_MAX_ZONEORDER |
---|
521 | | - int "Maximum zone order" |
---|
522 | | - default "11" |
---|
523 | | - help |
---|
524 | | - The kernel memory allocator divides physically contiguous memory |
---|
525 | | - blocks into "zones", where each zone is a power of two number of |
---|
526 | | - pages. This option selects the largest power of two that the kernel |
---|
527 | | - keeps in the memory allocator. If you need to allocate very large |
---|
528 | | - blocks of physically contiguous memory, then you may need to |
---|
529 | | - increase this value. |
---|
530 | | - |
---|
531 | | - This config option is actually maximum order plus one. For example, |
---|
532 | | - a value of 11 means that the largest free memory block is 2^10 pages. |
---|
533 | | - |
---|
534 | | -source "drivers/pcmcia/Kconfig" |
---|
535 | | - |
---|
536 | | -config PLATFORM_WANT_DEFAULT_MEM |
---|
537 | | - def_bool n |
---|
538 | | - |
---|
539 | | -config DEFAULT_MEM_START |
---|
540 | | - hex |
---|
541 | | - prompt "PAGE_OFFSET/PHYS_OFFSET" if !MMU && PLATFORM_WANT_DEFAULT_MEM |
---|
542 | | - default 0x60000000 if PLATFORM_WANT_DEFAULT_MEM |
---|
543 | | - default 0x00000000 |
---|
544 | | - help |
---|
545 | | - This is the base address used for both PAGE_OFFSET and PHYS_OFFSET |
---|
546 | | - in noMMU configurations. |
---|
547 | | - |
---|
548 | | - If unsure, leave the default value here. |
---|
549 | | - |
---|
550 | 428 | config XTFPGA_LCD |
---|
551 | 429 | bool "Enable XTFPGA LCD driver" |
---|
552 | 430 | depends on XTENSA_PLATFORM_XTFPGA |
---|
.. | .. |
---|
577 | 455 | only be used with 8-bit interface. Please consult prototyping user |
---|
578 | 456 | guide for your board for the correct interface width. |
---|
579 | 457 | |
---|
| 458 | +comment "Kernel memory layout" |
---|
| 459 | + |
---|
| 460 | +config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
| 461 | + bool "Initialize Xtensa MMU inside the Linux kernel code" |
---|
| 462 | + depends on !XTENSA_VARIANT_FSF && !XTENSA_VARIANT_DC232B |
---|
| 463 | + default y if XTENSA_VARIANT_DC233C || XTENSA_VARIANT_CUSTOM |
---|
| 464 | + help |
---|
| 465 | + Earlier version initialized the MMU in the exception vector |
---|
| 466 | + before jumping to _startup in head.S and had an advantage that |
---|
| 467 | + it was possible to place a software breakpoint at 'reset' and |
---|
| 468 | + then enter your normal kernel breakpoints once the MMU was mapped |
---|
| 469 | + to the kernel mappings (0XC0000000). |
---|
| 470 | + |
---|
| 471 | + This unfortunately won't work for U-Boot and likely also wont |
---|
| 472 | + work for using KEXEC to have a hot kernel ready for doing a |
---|
| 473 | + KDUMP. |
---|
| 474 | + |
---|
| 475 | + So now the MMU is initialized in head.S but it's necessary to |
---|
| 476 | + use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup. |
---|
| 477 | + xt-gdb can't place a Software Breakpoint in the 0XD region prior |
---|
| 478 | + to mapping the MMU and after mapping even if the area of low memory |
---|
| 479 | + was mapped gdb wouldn't remove the breakpoint on hitting it as the |
---|
| 480 | + PC wouldn't match. Since Hardware Breakpoints are recommended for |
---|
| 481 | + Linux configurations it seems reasonable to just assume they exist |
---|
| 482 | + and leave this older mechanism for unfortunate souls that choose |
---|
| 483 | + not to follow Tensilica's recommendation. |
---|
| 484 | + |
---|
| 485 | + Selecting this will cause U-Boot to set the KERNEL Load and Entry |
---|
| 486 | + address at 0x00003000 instead of the mapped std of 0xD0003000. |
---|
| 487 | + |
---|
| 488 | + If in doubt, say Y. |
---|
| 489 | + |
---|
| 490 | +config XIP_KERNEL |
---|
| 491 | + bool "Kernel Execute-In-Place from ROM" |
---|
| 492 | + depends on PLATFORM_HAVE_XIP |
---|
| 493 | + help |
---|
| 494 | + Execute-In-Place allows the kernel to run from non-volatile storage |
---|
| 495 | + directly addressable by the CPU, such as NOR flash. This saves RAM |
---|
| 496 | + space since the text section of the kernel is not loaded from flash |
---|
| 497 | + to RAM. Read-write sections, such as the data section and stack, |
---|
| 498 | + are still copied to RAM. The XIP kernel is not compressed since |
---|
| 499 | + it has to run directly from flash, so it will take more space to |
---|
| 500 | + store it. The flash address used to link the kernel object files, |
---|
| 501 | + and for storing it, is configuration dependent. Therefore, if you |
---|
| 502 | + say Y here, you must know the proper physical address where to |
---|
| 503 | + store the kernel image depending on your own flash memory usage. |
---|
| 504 | + |
---|
| 505 | + Also note that the make target becomes "make xipImage" rather than |
---|
| 506 | + "make Image" or "make uImage". The final kernel binary to put in |
---|
| 507 | + ROM memory will be arch/xtensa/boot/xipImage. |
---|
| 508 | + |
---|
| 509 | + If unsure, say N. |
---|
| 510 | + |
---|
| 511 | +config MEMMAP_CACHEATTR |
---|
| 512 | + hex "Cache attributes for the memory address space" |
---|
| 513 | + depends on !MMU |
---|
| 514 | + default 0x22222222 |
---|
| 515 | + help |
---|
| 516 | + These cache attributes are set up for noMMU systems. Each hex digit |
---|
| 517 | + specifies cache attributes for the corresponding 512MB memory |
---|
| 518 | + region: bits 0..3 -- for addresses 0x00000000..0x1fffffff, |
---|
| 519 | + bits 4..7 -- for addresses 0x20000000..0x3fffffff, and so on. |
---|
| 520 | + |
---|
| 521 | + Cache attribute values are specific for the MMU type. |
---|
| 522 | + For region protection MMUs: |
---|
| 523 | + 1: WT cached, |
---|
| 524 | + 2: cache bypass, |
---|
| 525 | + 4: WB cached, |
---|
| 526 | + f: illegal. |
---|
| 527 | + For full MMU: |
---|
| 528 | + bit 0: executable, |
---|
| 529 | + bit 1: writable, |
---|
| 530 | + bits 2..3: |
---|
| 531 | + 0: cache bypass, |
---|
| 532 | + 1: WB cache, |
---|
| 533 | + 2: WT cache, |
---|
| 534 | + 3: special (c and e are illegal, f is reserved). |
---|
| 535 | + For MPU: |
---|
| 536 | + 0: illegal, |
---|
| 537 | + 1: WB cache, |
---|
| 538 | + 2: WB, no-write-allocate cache, |
---|
| 539 | + 3: WT cache, |
---|
| 540 | + 4: cache bypass. |
---|
| 541 | + |
---|
| 542 | +config KSEG_PADDR |
---|
| 543 | + hex "Physical address of the KSEG mapping" |
---|
| 544 | + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX && MMU |
---|
| 545 | + default 0x00000000 |
---|
| 546 | + help |
---|
| 547 | + This is the physical address where KSEG is mapped. Please refer to |
---|
| 548 | + the chosen KSEG layout help for the required address alignment. |
---|
| 549 | + Unpacked kernel image (including vectors) must be located completely |
---|
| 550 | + within KSEG. |
---|
| 551 | + Physical memory below this address is not available to linux. |
---|
| 552 | + |
---|
| 553 | + If unsure, leave the default value here. |
---|
| 554 | + |
---|
| 555 | +config KERNEL_VIRTUAL_ADDRESS |
---|
| 556 | + hex "Kernel virtual address" |
---|
| 557 | + depends on MMU && XIP_KERNEL |
---|
| 558 | + default 0xd0003000 |
---|
| 559 | + help |
---|
| 560 | + This is the virtual address where the XIP kernel is mapped. |
---|
| 561 | + XIP kernel may be mapped into KSEG or KIO region, virtual address |
---|
| 562 | + provided here must match kernel load address provided in |
---|
| 563 | + KERNEL_LOAD_ADDRESS. |
---|
| 564 | + |
---|
| 565 | +config KERNEL_LOAD_ADDRESS |
---|
| 566 | + hex "Kernel load address" |
---|
| 567 | + default 0x60003000 if !MMU |
---|
| 568 | + default 0x00003000 if MMU && INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
| 569 | + default 0xd0003000 if MMU && !INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
| 570 | + help |
---|
| 571 | + This is the address where the kernel is loaded. |
---|
| 572 | + It is virtual address for MMUv2 configurations and physical address |
---|
| 573 | + for all other configurations. |
---|
| 574 | + |
---|
| 575 | + If unsure, leave the default value here. |
---|
| 576 | + |
---|
| 577 | +choice |
---|
| 578 | + prompt "Relocatable vectors location" |
---|
| 579 | + default XTENSA_VECTORS_IN_TEXT |
---|
| 580 | + help |
---|
| 581 | + Choose whether relocatable vectors are merged into the kernel .text |
---|
| 582 | + or placed separately at runtime. This option does not affect |
---|
| 583 | + configurations without VECBASE register where vectors are always |
---|
| 584 | + placed at their hardware-defined locations. |
---|
| 585 | + |
---|
| 586 | +config XTENSA_VECTORS_IN_TEXT |
---|
| 587 | + bool "Merge relocatable vectors into kernel text" |
---|
| 588 | + depends on !MTD_XIP |
---|
| 589 | + help |
---|
| 590 | + This option puts relocatable vectors into the kernel .text section |
---|
| 591 | + with proper alignment. |
---|
| 592 | + This is a safe choice for most configurations. |
---|
| 593 | + |
---|
| 594 | +config XTENSA_VECTORS_SEPARATE |
---|
| 595 | + bool "Put relocatable vectors at fixed address" |
---|
| 596 | + help |
---|
| 597 | + This option puts relocatable vectors at specific virtual address. |
---|
| 598 | + Vectors are merged with the .init data in the kernel image and |
---|
| 599 | + are copied into their designated location during kernel startup. |
---|
| 600 | + Use it to put vectors into IRAM or out of FLASH on kernels with |
---|
| 601 | + XIP-aware MTD support. |
---|
| 602 | + |
---|
| 603 | +endchoice |
---|
| 604 | + |
---|
| 605 | +config VECTORS_ADDR |
---|
| 606 | + hex "Kernel vectors virtual address" |
---|
| 607 | + default 0x00000000 |
---|
| 608 | + depends on XTENSA_VECTORS_SEPARATE |
---|
| 609 | + help |
---|
| 610 | + This is the virtual address of the (relocatable) vectors base. |
---|
| 611 | + It must be within KSEG if MMU is used. |
---|
| 612 | + |
---|
| 613 | +config XIP_DATA_ADDR |
---|
| 614 | + hex "XIP kernel data virtual address" |
---|
| 615 | + depends on XIP_KERNEL |
---|
| 616 | + default 0x00000000 |
---|
| 617 | + help |
---|
| 618 | + This is the virtual address where XIP kernel data is copied. |
---|
| 619 | + It must be within KSEG if MMU is used. |
---|
| 620 | + |
---|
| 621 | +config PLATFORM_WANT_DEFAULT_MEM |
---|
| 622 | + def_bool n |
---|
| 623 | + |
---|
| 624 | +config DEFAULT_MEM_START |
---|
| 625 | + hex |
---|
| 626 | + prompt "PAGE_OFFSET/PHYS_OFFSET" if !MMU && PLATFORM_WANT_DEFAULT_MEM |
---|
| 627 | + default 0x60000000 if PLATFORM_WANT_DEFAULT_MEM |
---|
| 628 | + default 0x00000000 |
---|
| 629 | + help |
---|
| 630 | + This is the base address used for both PAGE_OFFSET and PHYS_OFFSET |
---|
| 631 | + in noMMU configurations. |
---|
| 632 | + |
---|
| 633 | + If unsure, leave the default value here. |
---|
| 634 | + |
---|
| 635 | +choice |
---|
| 636 | + prompt "KSEG layout" |
---|
| 637 | + depends on MMU |
---|
| 638 | + default XTENSA_KSEG_MMU_V2 |
---|
| 639 | + |
---|
| 640 | +config XTENSA_KSEG_MMU_V2 |
---|
| 641 | + bool "MMUv2: 128MB cached + 128MB uncached" |
---|
| 642 | + help |
---|
| 643 | + MMUv2 compatible kernel memory map: TLB way 5 maps 128MB starting |
---|
| 644 | + at KSEG_PADDR to 0xd0000000 with cache and to 0xd8000000 |
---|
| 645 | + without cache. |
---|
| 646 | + KSEG_PADDR must be aligned to 128MB. |
---|
| 647 | + |
---|
| 648 | +config XTENSA_KSEG_256M |
---|
| 649 | + bool "256MB cached + 256MB uncached" |
---|
| 650 | + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
| 651 | + help |
---|
| 652 | + TLB way 6 maps 256MB starting at KSEG_PADDR to 0xb0000000 |
---|
| 653 | + with cache and to 0xc0000000 without cache. |
---|
| 654 | + KSEG_PADDR must be aligned to 256MB. |
---|
| 655 | + |
---|
| 656 | +config XTENSA_KSEG_512M |
---|
| 657 | + bool "512MB cached + 512MB uncached" |
---|
| 658 | + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX |
---|
| 659 | + help |
---|
| 660 | + TLB way 6 maps 512MB starting at KSEG_PADDR to 0xa0000000 |
---|
| 661 | + with cache and to 0xc0000000 without cache. |
---|
| 662 | + KSEG_PADDR must be aligned to 256MB. |
---|
| 663 | + |
---|
| 664 | +endchoice |
---|
| 665 | + |
---|
| 666 | +config HIGHMEM |
---|
| 667 | + bool "High Memory Support" |
---|
| 668 | + depends on MMU |
---|
| 669 | + select KMAP_LOCAL |
---|
| 670 | + help |
---|
| 671 | + Linux can use the full amount of RAM in the system by |
---|
| 672 | + default. However, the default MMUv2 setup only maps the |
---|
| 673 | + lowermost 128 MB of memory linearly to the areas starting |
---|
| 674 | + at 0xd0000000 (cached) and 0xd8000000 (uncached). |
---|
| 675 | + When there are more than 128 MB memory in the system not |
---|
| 676 | + all of it can be "permanently mapped" by the kernel. |
---|
| 677 | + The physical memory that's not permanently mapped is called |
---|
| 678 | + "high memory". |
---|
| 679 | + |
---|
| 680 | + If you are compiling a kernel which will never run on a |
---|
| 681 | + machine with more than 128 MB total physical RAM, answer |
---|
| 682 | + N here. |
---|
| 683 | + |
---|
| 684 | + If unsure, say Y. |
---|
| 685 | + |
---|
| 686 | +config FORCE_MAX_ZONEORDER |
---|
| 687 | + int "Maximum zone order" |
---|
| 688 | + default "11" |
---|
| 689 | + help |
---|
| 690 | + The kernel memory allocator divides physically contiguous memory |
---|
| 691 | + blocks into "zones", where each zone is a power of two number of |
---|
| 692 | + pages. This option selects the largest power of two that the kernel |
---|
| 693 | + keeps in the memory allocator. If you need to allocate very large |
---|
| 694 | + blocks of physically contiguous memory, then you may need to |
---|
| 695 | + increase this value. |
---|
| 696 | + |
---|
| 697 | + This config option is actually maximum order plus one. For example, |
---|
| 698 | + a value of 11 means that the largest free memory block is 2^10 pages. |
---|
| 699 | + |
---|
580 | 700 | endmenu |
---|
581 | 701 | |
---|
582 | 702 | menu "Power management options" |
---|