From b22da3d8526a935aa31e086e63f60ff3246cb61c Mon Sep 17 00:00:00 2001 From: hc <hc@nodka.com> Date: Sat, 09 Dec 2023 07:24:11 +0000 Subject: [PATCH] add stmac read mac form eeprom --- kernel/arch/xtensa/Kconfig | 512 +++++++++++++++++++++++++++++++++++--------------------- 1 files changed, 316 insertions(+), 196 deletions(-) diff --git a/kernel/arch/xtensa/Kconfig b/kernel/arch/xtensa/Kconfig index d9b0709..03cbf6b 100644 --- a/kernel/arch/xtensa/Kconfig +++ b/kernel/arch/xtensa/Kconfig @@ -1,26 +1,31 @@ # SPDX-License-Identifier: GPL-2.0 -config ZONE_DMA - def_bool y - config XTENSA def_bool y - select ARCH_HAS_SG_CHAIN - select ARCH_HAS_SYNC_DMA_FOR_CPU - select ARCH_HAS_SYNC_DMA_FOR_DEVICE - select ARCH_NO_COHERENT_DMA_MMAP if !MMU + select ARCH_32BIT_OFF_T + select ARCH_HAS_BINFMT_FLAT if !MMU + select ARCH_HAS_DMA_PREP_COHERENT if MMU + select ARCH_HAS_SYNC_DMA_FOR_CPU if MMU + select ARCH_HAS_SYNC_DMA_FOR_DEVICE if MMU + select ARCH_HAS_DMA_SET_UNCACHED if MMU + select ARCH_USE_QUEUED_RWLOCKS + select ARCH_USE_QUEUED_SPINLOCKS select ARCH_WANT_FRAME_POINTERS select ARCH_WANT_IPC_PARSE_VERSION - select BUILDTIME_EXTABLE_SORT + select BUILDTIME_TABLE_SORT select CLONE_BACKWARDS select COMMON_CLK - select DMA_NONCOHERENT_OPS + select DMA_REMAP if MMU select GENERIC_ATOMIC64 select GENERIC_CLOCKEVENTS select GENERIC_IRQ_SHOW select GENERIC_PCI_IOMAP select GENERIC_SCHED_CLOCK select GENERIC_STRNCPY_FROM_USER if KASAN - select HAVE_ARCH_KASAN if MMU + select HAVE_ARCH_AUDITSYSCALL + select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL + select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL + select HAVE_ARCH_SECCOMP_FILTER + select HAVE_ARCH_TRACEHOOK select HAVE_DEBUG_KMEMLEAK select HAVE_DMA_CONTIGUOUS select HAVE_EXIT_THREAD @@ -28,14 +33,15 @@ select HAVE_FUTEX_CMPXCHG if !MMU && FUTEX select HAVE_HW_BREAKPOINT if PERF_EVENTS select HAVE_IRQ_TIME_ACCOUNTING - select HAVE_MEMBLOCK select HAVE_OPROFILE + select HAVE_PCI select HAVE_PERF_EVENTS select HAVE_STACKPROTECTOR + select HAVE_SYSCALL_TRACEPOINTS select IRQ_DOMAIN select MODULES_USE_ELF_RELA - select NO_BOOTMEM select PERF_USE_VMALLOC + select SET_FS select VIRT_TO_BUS help Xtensa processors are 32-bit RISC machines designed by Tensilica @@ -44,9 +50,6 @@ architecture supports all processor configurations and extensions, with reasonable minimum requirements. The Xtensa Linux project has a home page at <http://www.linux-xtensa.org/>. - -config RWSEM_XCHGADD_ALGORITHM - def_bool y config GENERIC_HWEIGHT def_bool y @@ -121,7 +124,7 @@ help Provide the name of a custom Xtensa processor variant. This CORENAME selects arch/xtensa/variant/CORENAME. - Dont forget you have to select MMU if you have one. + Don't forget you have to select MMU if you have one. config XTENSA_VARIANT_NAME string @@ -166,7 +169,7 @@ If unsure, say N. config XTENSA_UNALIGNED_USER - bool "Unaligned memory access in use space" + bool "Unaligned memory access in user space" help The Xtensa architecture currently does not handle unaligned memory accesses in hardware but through an exception handler. @@ -179,11 +182,11 @@ depends on XTENSA_VARIANT_CUSTOM select XTENSA_MX help - This option is use to indicate that the system-on-a-chip (SOC) + This option is used to indicate that the system-on-a-chip (SOC) supports Multiprocessing. Multiprocessor support implemented above the CPU core definition and currently needs to be selected manually. - Multiprocessor support in implemented with external cache and + Multiprocessor support is implemented with external cache and interrupt controllers. The MX interrupt distributer adds Interprocessor Interrupts @@ -215,137 +218,6 @@ Say N if you want to disable CPU hotplug. -config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX - bool "Initialize Xtensa MMU inside the Linux kernel code" - depends on !XTENSA_VARIANT_FSF && !XTENSA_VARIANT_DC232B - default y if XTENSA_VARIANT_DC233C || XTENSA_VARIANT_CUSTOM - help - Earlier version initialized the MMU in the exception vector - before jumping to _startup in head.S and had an advantage that - it was possible to place a software breakpoint at 'reset' and - then enter your normal kernel breakpoints once the MMU was mapped - to the kernel mappings (0XC0000000). - - This unfortunately won't work for U-Boot and likely also wont - work for using KEXEC to have a hot kernel ready for doing a - KDUMP. - - So now the MMU is initialized in head.S but it's necessary to - use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup. - xt-gdb can't place a Software Breakpoint in the 0XD region prior - to mapping the MMU and after mapping even if the area of low memory - was mapped gdb wouldn't remove the breakpoint on hitting it as the - PC wouldn't match. Since Hardware Breakpoints are recommended for - Linux configurations it seems reasonable to just assume they exist - and leave this older mechanism for unfortunate souls that choose - not to follow Tensilica's recommendation. - - Selecting this will cause U-Boot to set the KERNEL Load and Entry - address at 0x00003000 instead of the mapped std of 0xD0003000. - - If in doubt, say Y. - -config MEMMAP_CACHEATTR - hex "Cache attributes for the memory address space" - depends on !MMU - default 0x22222222 - help - These cache attributes are set up for noMMU systems. Each hex digit - specifies cache attributes for the corresponding 512MB memory - region: bits 0..3 -- for addresses 0x00000000..0x1fffffff, - bits 4..7 -- for addresses 0x20000000..0x3fffffff, and so on. - - Cache attribute values are specific for the MMU type, so e.g. - for region protection MMUs: 2 is cache bypass, 4 is WB cached, - 1 is WT cached, f is illegal. For ful MMU: bit 0 makes it executable, - bit 1 makes it writable, bits 2..3 meaning is 0: cache bypass, - 1: WB cache, 2: WT cache, 3: special (c and e are illegal, f is - reserved). - -config KSEG_PADDR - hex "Physical address of the KSEG mapping" - depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX && MMU - default 0x00000000 - help - This is the physical address where KSEG is mapped. Please refer to - the chosen KSEG layout help for the required address alignment. - Unpacked kernel image (including vectors) must be located completely - within KSEG. - Physical memory below this address is not available to linux. - - If unsure, leave the default value here. - -config KERNEL_LOAD_ADDRESS - hex "Kernel load address" - default 0x60003000 if !MMU - default 0x00003000 if MMU && INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX - default 0xd0003000 if MMU && !INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX - help - This is the address where the kernel is loaded. - It is virtual address for MMUv2 configurations and physical address - for all other configurations. - - If unsure, leave the default value here. - -config VECTORS_OFFSET - hex "Kernel vectors offset" - default 0x00003000 - help - This is the offset of the kernel image from the relocatable vectors - base. - - If unsure, leave the default value here. - -choice - prompt "KSEG layout" - depends on MMU - default XTENSA_KSEG_MMU_V2 - -config XTENSA_KSEG_MMU_V2 - bool "MMUv2: 128MB cached + 128MB uncached" - help - MMUv2 compatible kernel memory map: TLB way 5 maps 128MB starting - at KSEG_PADDR to 0xd0000000 with cache and to 0xd8000000 - without cache. - KSEG_PADDR must be aligned to 128MB. - -config XTENSA_KSEG_256M - bool "256MB cached + 256MB uncached" - depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX - help - TLB way 6 maps 256MB starting at KSEG_PADDR to 0xb0000000 - with cache and to 0xc0000000 without cache. - KSEG_PADDR must be aligned to 256MB. - -config XTENSA_KSEG_512M - bool "512MB cached + 512MB uncached" - depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX - help - TLB way 6 maps 512MB starting at KSEG_PADDR to 0xa0000000 - with cache and to 0xc0000000 without cache. - KSEG_PADDR must be aligned to 256MB. - -endchoice - -config HIGHMEM - bool "High Memory Support" - depends on MMU - help - Linux can use the full amount of RAM in the system by - default. However, the default MMUv2 setup only maps the - lowermost 128 MB of memory linearly to the areas starting - at 0xd0000000 (cached) and 0xd8000000 (uncached). - When there are more than 128 MB memory in the system not - all of it can be "permanently mapped" by the kernel. - The physical memory that's not permanently mapped is called - "high memory". - - If you are compiling a kernel which will never run on a - machine with more than 128 MB total physical RAM, answer - N here. - - If unsure, say Y. - config FAST_SYSCALL_XTENSA bool "Enable fast atomic syscalls" default n @@ -372,6 +244,54 @@ If unsure, say N. +config USER_ABI_CALL0 + bool + +choice + prompt "Userspace ABI" + default USER_ABI_DEFAULT + help + Select supported userspace ABI. + + If unsure, choose the default ABI. + +config USER_ABI_DEFAULT + bool "Default ABI only" + help + Assume default userspace ABI. For XEA2 cores it is windowed ABI. + call0 ABI binaries may be run on such kernel, but signal delivery + will not work correctly for them. + +config USER_ABI_CALL0_ONLY + bool "Call0 ABI only" + select USER_ABI_CALL0 + help + Select this option to support only call0 ABI in userspace. + Windowed ABI binaries will crash with a segfault caused by + an illegal instruction exception on the first 'entry' opcode. + + Choose this option if you're planning to run only user code + built with call0 ABI. + +config USER_ABI_CALL0_PROBE + bool "Support both windowed and call0 ABI by probing" + select USER_ABI_CALL0 + help + Select this option to support both windowed and call0 userspace + ABIs. When enabled all processes are started with PS.WOE disabled + and a fast user exception handler for an illegal instruction is + used to turn on PS.WOE bit on the first 'entry' opcode executed by + the userspace. + + This option should be enabled for the kernel that must support + both call0 and windowed ABIs in userspace at the same time. + + Note that Xtensa ISA does not guarantee that entry opcode will + raise an illegal instruction exception on cores with XEA2 when + PS.WOE is disabled, check whether the target core supports it. + +endchoice + endmenu config XTENSA_CALIBRATE_CCOUNT @@ -384,20 +304,8 @@ config SERIAL_CONSOLE def_bool n -menu "Bus options" - -config PCI - bool "PCI support" - default y - help - Find out whether you have a PCI motherboard. PCI is the name of a - bus system, i.e. the way the CPU talks to the other stuff inside - your box. Other bus systems are ISA, EISA, MicroChannel (MCA) or - VESA. If you have PCI, say Y, otherwise N. - -source "drivers/pci/Kconfig" - -endmenu +config PLATFORM_HAVE_XIP + def_bool n menu "Platform options" @@ -425,6 +333,7 @@ select PLATFORM_WANT_DEFAULT_MEM if !MMU select SERIAL_CONSOLE select XTENSA_CALIBRATE_CCOUNT + select PLATFORM_HAVE_XIP help XTFPGA is the name of Tensilica board family (LX60, LX110, LX200, ML605). This hardware is capable of running a full Linux distribution. @@ -464,11 +373,10 @@ bool "Flattened Device Tree support" select OF select OF_EARLY_FLATTREE - select OF_RESERVED_MEM help Include support for flattened device tree machine descriptions. -config BUILTIN_DTB +config BUILTIN_DTB_SOURCE string "DTB to build into the kernel image" depends on OF @@ -517,36 +425,6 @@ Another simulated disk in a host file for a buildroot-independent storage. -config FORCE_MAX_ZONEORDER - int "Maximum zone order" - default "11" - help - The kernel memory allocator divides physically contiguous memory - blocks into "zones", where each zone is a power of two number of - pages. This option selects the largest power of two that the kernel - keeps in the memory allocator. If you need to allocate very large - blocks of physically contiguous memory, then you may need to - increase this value. - - This config option is actually maximum order plus one. For example, - a value of 11 means that the largest free memory block is 2^10 pages. - -source "drivers/pcmcia/Kconfig" - -config PLATFORM_WANT_DEFAULT_MEM - def_bool n - -config DEFAULT_MEM_START - hex - prompt "PAGE_OFFSET/PHYS_OFFSET" if !MMU && PLATFORM_WANT_DEFAULT_MEM - default 0x60000000 if PLATFORM_WANT_DEFAULT_MEM - default 0x00000000 - help - This is the base address used for both PAGE_OFFSET and PHYS_OFFSET - in noMMU configurations. - - If unsure, leave the default value here. - config XTFPGA_LCD bool "Enable XTFPGA LCD driver" depends on XTENSA_PLATFORM_XTFPGA @@ -577,6 +455,248 @@ only be used with 8-bit interface. Please consult prototyping user guide for your board for the correct interface width. +comment "Kernel memory layout" + +config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + bool "Initialize Xtensa MMU inside the Linux kernel code" + depends on !XTENSA_VARIANT_FSF && !XTENSA_VARIANT_DC232B + default y if XTENSA_VARIANT_DC233C || XTENSA_VARIANT_CUSTOM + help + Earlier version initialized the MMU in the exception vector + before jumping to _startup in head.S and had an advantage that + it was possible to place a software breakpoint at 'reset' and + then enter your normal kernel breakpoints once the MMU was mapped + to the kernel mappings (0XC0000000). + + This unfortunately won't work for U-Boot and likely also wont + work for using KEXEC to have a hot kernel ready for doing a + KDUMP. + + So now the MMU is initialized in head.S but it's necessary to + use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup. + xt-gdb can't place a Software Breakpoint in the 0XD region prior + to mapping the MMU and after mapping even if the area of low memory + was mapped gdb wouldn't remove the breakpoint on hitting it as the + PC wouldn't match. Since Hardware Breakpoints are recommended for + Linux configurations it seems reasonable to just assume they exist + and leave this older mechanism for unfortunate souls that choose + not to follow Tensilica's recommendation. + + Selecting this will cause U-Boot to set the KERNEL Load and Entry + address at 0x00003000 instead of the mapped std of 0xD0003000. + + If in doubt, say Y. + +config XIP_KERNEL + bool "Kernel Execute-In-Place from ROM" + depends on PLATFORM_HAVE_XIP + help + Execute-In-Place allows the kernel to run from non-volatile storage + directly addressable by the CPU, such as NOR flash. This saves RAM + space since the text section of the kernel is not loaded from flash + to RAM. Read-write sections, such as the data section and stack, + are still copied to RAM. The XIP kernel is not compressed since + it has to run directly from flash, so it will take more space to + store it. The flash address used to link the kernel object files, + and for storing it, is configuration dependent. Therefore, if you + say Y here, you must know the proper physical address where to + store the kernel image depending on your own flash memory usage. + + Also note that the make target becomes "make xipImage" rather than + "make Image" or "make uImage". The final kernel binary to put in + ROM memory will be arch/xtensa/boot/xipImage. + + If unsure, say N. + +config MEMMAP_CACHEATTR + hex "Cache attributes for the memory address space" + depends on !MMU + default 0x22222222 + help + These cache attributes are set up for noMMU systems. Each hex digit + specifies cache attributes for the corresponding 512MB memory + region: bits 0..3 -- for addresses 0x00000000..0x1fffffff, + bits 4..7 -- for addresses 0x20000000..0x3fffffff, and so on. + + Cache attribute values are specific for the MMU type. + For region protection MMUs: + 1: WT cached, + 2: cache bypass, + 4: WB cached, + f: illegal. + For full MMU: + bit 0: executable, + bit 1: writable, + bits 2..3: + 0: cache bypass, + 1: WB cache, + 2: WT cache, + 3: special (c and e are illegal, f is reserved). + For MPU: + 0: illegal, + 1: WB cache, + 2: WB, no-write-allocate cache, + 3: WT cache, + 4: cache bypass. + +config KSEG_PADDR + hex "Physical address of the KSEG mapping" + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX && MMU + default 0x00000000 + help + This is the physical address where KSEG is mapped. Please refer to + the chosen KSEG layout help for the required address alignment. + Unpacked kernel image (including vectors) must be located completely + within KSEG. + Physical memory below this address is not available to linux. + + If unsure, leave the default value here. + +config KERNEL_VIRTUAL_ADDRESS + hex "Kernel virtual address" + depends on MMU && XIP_KERNEL + default 0xd0003000 + help + This is the virtual address where the XIP kernel is mapped. + XIP kernel may be mapped into KSEG or KIO region, virtual address + provided here must match kernel load address provided in + KERNEL_LOAD_ADDRESS. + +config KERNEL_LOAD_ADDRESS + hex "Kernel load address" + default 0x60003000 if !MMU + default 0x00003000 if MMU && INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + default 0xd0003000 if MMU && !INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + help + This is the address where the kernel is loaded. + It is virtual address for MMUv2 configurations and physical address + for all other configurations. + + If unsure, leave the default value here. + +choice + prompt "Relocatable vectors location" + default XTENSA_VECTORS_IN_TEXT + help + Choose whether relocatable vectors are merged into the kernel .text + or placed separately at runtime. This option does not affect + configurations without VECBASE register where vectors are always + placed at their hardware-defined locations. + +config XTENSA_VECTORS_IN_TEXT + bool "Merge relocatable vectors into kernel text" + depends on !MTD_XIP + help + This option puts relocatable vectors into the kernel .text section + with proper alignment. + This is a safe choice for most configurations. + +config XTENSA_VECTORS_SEPARATE + bool "Put relocatable vectors at fixed address" + help + This option puts relocatable vectors at specific virtual address. + Vectors are merged with the .init data in the kernel image and + are copied into their designated location during kernel startup. + Use it to put vectors into IRAM or out of FLASH on kernels with + XIP-aware MTD support. + +endchoice + +config VECTORS_ADDR + hex "Kernel vectors virtual address" + default 0x00000000 + depends on XTENSA_VECTORS_SEPARATE + help + This is the virtual address of the (relocatable) vectors base. + It must be within KSEG if MMU is used. + +config XIP_DATA_ADDR + hex "XIP kernel data virtual address" + depends on XIP_KERNEL + default 0x00000000 + help + This is the virtual address where XIP kernel data is copied. + It must be within KSEG if MMU is used. + +config PLATFORM_WANT_DEFAULT_MEM + def_bool n + +config DEFAULT_MEM_START + hex + prompt "PAGE_OFFSET/PHYS_OFFSET" if !MMU && PLATFORM_WANT_DEFAULT_MEM + default 0x60000000 if PLATFORM_WANT_DEFAULT_MEM + default 0x00000000 + help + This is the base address used for both PAGE_OFFSET and PHYS_OFFSET + in noMMU configurations. + + If unsure, leave the default value here. + +choice + prompt "KSEG layout" + depends on MMU + default XTENSA_KSEG_MMU_V2 + +config XTENSA_KSEG_MMU_V2 + bool "MMUv2: 128MB cached + 128MB uncached" + help + MMUv2 compatible kernel memory map: TLB way 5 maps 128MB starting + at KSEG_PADDR to 0xd0000000 with cache and to 0xd8000000 + without cache. + KSEG_PADDR must be aligned to 128MB. + +config XTENSA_KSEG_256M + bool "256MB cached + 256MB uncached" + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + help + TLB way 6 maps 256MB starting at KSEG_PADDR to 0xb0000000 + with cache and to 0xc0000000 without cache. + KSEG_PADDR must be aligned to 256MB. + +config XTENSA_KSEG_512M + bool "512MB cached + 512MB uncached" + depends on INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX + help + TLB way 6 maps 512MB starting at KSEG_PADDR to 0xa0000000 + with cache and to 0xc0000000 without cache. + KSEG_PADDR must be aligned to 256MB. + +endchoice + +config HIGHMEM + bool "High Memory Support" + depends on MMU + select KMAP_LOCAL + help + Linux can use the full amount of RAM in the system by + default. However, the default MMUv2 setup only maps the + lowermost 128 MB of memory linearly to the areas starting + at 0xd0000000 (cached) and 0xd8000000 (uncached). + When there are more than 128 MB memory in the system not + all of it can be "permanently mapped" by the kernel. + The physical memory that's not permanently mapped is called + "high memory". + + If you are compiling a kernel which will never run on a + machine with more than 128 MB total physical RAM, answer + N here. + + If unsure, say Y. + +config FORCE_MAX_ZONEORDER + int "Maximum zone order" + default "11" + help + The kernel memory allocator divides physically contiguous memory + blocks into "zones", where each zone is a power of two number of + pages. This option selects the largest power of two that the kernel + keeps in the memory allocator. If you need to allocate very large + blocks of physically contiguous memory, then you may need to + increase this value. + + This config option is actually maximum order plus one. For example, + a value of 11 means that the largest free memory block is 2^10 pages. + endmenu menu "Power management options" -- Gitblit v1.6.2