Add comprehensive help descriptions to Kconfig files in libcpu and components

Co-authored-by: Rbb666 <64397326+Rbb666@users.noreply.github.com>

components/Kconfig

@@ -3,27 +3,120 @@ menu "RT-Thread Components"
 config RT_USING_COMPONENTS_INIT
     bool
     default n
+    help
+        Enable automatic component initialization framework.
+        
+        When enabled, components marked with INIT_EXPORT() macros will be
+        automatically initialized during system startup in proper order.
+        
+        Initialization levels (in order):
+        - INIT_BOARD_EXPORT: Board-level initialization (pins, clocks)
+        - INIT_PREV_EXPORT: Early driver initialization
+        - INIT_DEVICE_EXPORT: Device driver initialization
+        - INIT_COMPONENT_EXPORT: Component initialization
+        - INIT_ENV_EXPORT: Environment initialization
+        - INIT_APP_EXPORT: Application initialization
+        
+        Benefits:
+        - Automatic dependency ordering
+        - Cleaner code (no manual init function calls)
+        - Consistent initialization across components
+        
+        Note: Most RT-Thread components rely on this. Usually enabled automatically
+        by build system.
 
 config RT_USING_USER_MAIN
     bool
     default n
+    help
+        Use user-defined main() function as entry point.
+        
+        When enabled, RT-Thread creates a main thread that calls your main() function,
+        allowing traditional C programming style entry point.
+        
+        Without this option: You must manually create threads from application
+        With this option: Your main() function runs in a dedicated main thread
+        
+        The main thread:
+        - Runs after system initialization
+        - Has configurable stack size and priority
+        - Can use RT-Thread APIs like any other thread
+        - Can create additional threads
+        
+        Enable this for easier application development and familiar entry point.
 
     if RT_USING_USER_MAIN
         config RT_MAIN_THREAD_STACK_SIZE
             int "Set main thread stack size"
             default 6144 if ARCH_CPU_64BIT
             default 2048
+            help
+                Stack size in bytes for the main thread.
+                
+                Default values:
+                - 64-bit architectures: 6144 bytes (6KB)
+                - 32-bit architectures: 2048 bytes (2KB)
+                
+                Increase if:
+                - Deep recursion in main()
+                - Large local variables
+                - Stack overflow in main thread
+                - Complex initialization requiring more stack
+                
+                Decrease for memory-constrained systems if main() is simple.
+                
+                Note: Each thread's stack is separate. This only affects main thread.
 
         config RT_MAIN_THREAD_PRIORITY
             int "Set main thread priority"
             default 4   if RT_THREAD_PRIORITY_8
             default 10  if RT_THREAD_PRIORITY_32
             default 85  if RT_THREAD_PRIORITY_256
+            help
+                Priority of the main thread (lower number = higher priority).
+                
+                Default values scale with priority levels:
+                - 8 levels: Priority 4 (middle-low priority)
+                - 32 levels: Priority 10 (medium priority)
+                - 256 levels: Priority 85 (medium-low priority)
+                
+                Lower values (higher priority) if:
+                - Main thread needs to preempt other tasks
+                - Time-critical initialization in main()
+                
+                Higher values (lower priority) if:
+                - Main thread is just coordination/monitoring
+                - Other threads need priority over main
+                
+                Note: Priority 0 is highest, maximum is configured by RT_THREAD_PRIORITY_MAX.
     endif
 
 config RT_USING_LEGACY
     bool "Support legacy version for compatibility"
     default n
+    help
+        Enable compatibility layer for legacy RT-Thread versions.
+        
+        Provides deprecated APIs and compatibility shims for older code,
+        allowing gradual migration to newer RT-Thread versions.
+        
+        Includes:
+        - Deprecated API wrappers
+        - Legacy component interfaces
+        - Backward-compatible behavior
+        
+        Enable if:
+        - Porting code from older RT-Thread versions
+        - Using third-party libraries requiring legacy APIs
+        - Gradual migration strategy
+        
+        Disable for:
+        - New projects (use modern APIs)
+        - Smaller code size
+        - Better performance (no compatibility overhead)
+        
+        Note: Legacy support may be removed in future versions.
+        Plan to migrate to current APIs.
 
 if RT_USING_CONSOLE
 rsource "finsh/Kconfig"

components/mprotect/Kconfig

@@ -4,25 +4,165 @@ config RT_USING_MEM_PROTECTION
     bool "Enable memory protection"
     default n
     select RT_USING_HEAP
+    help
+        Enable memory protection framework using MPU (Memory Protection Unit).
+        
+        Provides hardware-based memory protection to prevent:
+        - Stack overflow and underflow
+        - Buffer overruns
+        - Unauthorized access to memory regions
+        - Corruption of kernel data structures
+        
+        Features:
+        - Per-thread memory protection
+        - Stack guard regions
+        - Configurable memory regions with access permissions
+        - Exclusive regions for sensitive data
+        
+        Requirements:
+        - CPU with MPU support (Cortex-M3/M4/M7/M33/R52, etc.)
+        - ARCH_MM_MPU or ARCH_ARM_MPU enabled
+        - RT_USING_HEAP (dynamic memory)
+        
+        Benefits:
+        - Catch memory bugs early (development)
+        - Improve system safety (production)
+        - Isolate thread memory spaces
+        
+        Costs:
+        - Context switch overhead (save/restore MPU regions)
+        - Configuration complexity
+        - Slight runtime overhead
+        
+        Ideal for safety-critical applications and debugging memory issues.
 
 config RT_USING_HW_STACK_GUARD
     bool "Enable hardware stack guard"
     default n
     select RT_USING_MEM_PROTECTION
+    help
+        Enable hardware-based stack overflow protection using MPU.
+        
+        Automatically creates guard regions at the end of each thread's stack
+        to detect stack overflow at the moment it occurs.
+        
+        How it works:
+        - Configures MPU region below stack as no-access
+        - Stack overflow triggers immediate MPU fault
+        - Exception handler identifies the overflowing thread
+        
+        Benefits:
+        - Immediate detection (vs periodic checks)
+        - Precise identification of overflow location
+        - No runtime overhead (hardware-based)
+        - Catches stack corruption before it spreads
+        
+        Requirements:
+        - RT_USING_MEM_PROTECTION enabled
+        - Sufficient MPU regions (at least 1 per thread)
+        
+        Recommended for:
+        - Development and debugging
+        - Safety-critical systems
+        - Systems with limited stack space
+        
+        Note: Requires one MPU region per thread. Check NUM_MEM_REGIONS configuration.
 
 if RT_USING_MEM_PROTECTION
     config USE_MEM_PROTECTION_EXAMPLES
     bool "Use memory protection examples"
     default y
+    help
+        Build and include memory protection example code.
+        
+        Provides demonstration code showing how to:
+        - Configure memory protection regions
+        - Set up stack guards
+        - Add exclusive regions
+        - Handle protection faults
+        
+        Useful for:
+        - Learning memory protection concepts
+        - Testing MPU functionality
+        - Debugging protection configurations
+        
+        Disable for production builds to save code space.
 
     config NUM_MEM_REGIONS
     int "Total number of memory protection regions supported by hardware"
+    help
+        Total number of MPU regions available in hardware.
+        
+        This depends on your CPU architecture:
+        - Cortex-M3/M4: Typically 8 regions
+        - Cortex-M7: 8 or 16 regions
+        - Cortex-M33/M85: 8 or 16 regions (configurable in silicon)
+        - Cortex-R52: 16 or 32 regions
+        
+        Check your MCU datasheet or reference manual for exact count.
+        
+        Usage breakdown:
+        - Stack guard per thread: 1 region per thread
+        - Exclusive regions: NUM_EXCLUSIVE_REGIONS
+        - Configurable per thread: NUM_CONFIGURABLE_REGIONS
+        
+        Formula: NUM_MEM_REGIONS = 1 (stack) + NUM_EXCLUSIVE_REGIONS + NUM_CONFIGURABLE_REGIONS
+        
+        Example for 8-region MPU with 2 threads:
+        - Thread 1 stack guard: 1 region
+        - Thread 2 stack guard: 1 region
+        - Shared exclusive regions: 2 regions
+        - Per-thread config: 2 regions per thread
+        Total: 2 + 2 + 4 = 8 regions
 
     config NUM_EXCLUSIVE_REGIONS
     int "Total number of exclusive memory regions added using rt_mprotect_add_exclusive_region API"
+    help
+        Number of shared exclusive memory protection regions.
+        
+        Exclusive regions are memory areas with specific access permissions
+        shared across all threads (e.g., peripheral registers, kernel data).
+        
+        Use cases:
+        - Protect peripheral registers from thread access
+        - Mark flash memory as read-only/execute-only
+        - Protect kernel data structures
+        - Define shared memory with specific permissions
+        
+        Example configurations:
+        - Peripheral protection: 1-2 regions
+        - Kernel data protection: 1 region
+        - Shared buffers: 0-2 regions
+        
+        Note: These regions are configured once and apply to all threads.
+        Set based on your system's protection requirements.
 
     config NUM_CONFIGURABLE_REGIONS
     int "Maximum number of configurable memory regions for each thread, excluding stack guard and exclusive regions added using rt_mprotect_add_exclusive_region API"
+    help
+        Per-thread configurable memory protection regions.
+        
+        These regions are specific to each thread and can be configured independently
+        for thread-specific memory protection needs.
+        
+        Use cases:
+        - Protect thread's private data buffers
+        - Restrict access to thread-local peripherals
+        - Define custom memory permissions per thread
+        
+        Calculation:
+        NUM_CONFIGURABLE_REGIONS = NUM_MEM_REGIONS - 1 (stack) - NUM_EXCLUSIVE_REGIONS
+        
+        Example for 8-region MPU with 2 exclusive regions:
+        NUM_CONFIGURABLE_REGIONS = 8 - 1 - 2 = 5 regions per thread
+        
+        More regions = more flexibility but:
+        - Increased configuration complexity
+        - Longer context switch time
+        - More memory for region descriptors
+        
+        Set based on your application's per-thread protection needs.
+        Typical values: 1-4 regions per thread.
 endif
 
 endmenu

libcpu/aarch64/Kconfig

@@ -2,24 +2,162 @@ menu "AArch64 Architecture Configuration"
     config ARCH_TEXT_OFFSET
         hex "Text offset"
         default 0x200000
+        help
+            Offset of kernel text section from start of RAM.
+            
+            Defines where the kernel code (.text section) is located relative to
+            the beginning of physical RAM. This space before the kernel is typically
+            reserved for:
+            - Bootloader and device tree blob (DTB)
+            - Initial page tables
+            - Boot-time data structures
+            
+            Default 0x200000 (2MB):
+            - Provides 2MB for bootloader and DTB
+            - Aligns with common ARM64 configurations
+            - Compatible with 2MB page granularity
+            
+            Only change if you have specific bootloader requirements or memory layout.
+
     config ARCH_RAM_OFFSET
         hex "RAM offset"
         default 0
+        help
+            Physical address offset of the RAM start.
+            
+            Defines the starting physical address of system RAM. On many systems,
+            RAM doesn't start at address 0x0.
+            
+            Common values:
+            - 0x00000000: RAM starts at address 0 (some SoCs)
+            - 0x40000000: Common for many ARM SoCs
+            - 0x80000000: Some development boards
+            
+            This must match your hardware memory map. Check your SoC datasheet
+            or bootloader configuration.
+            
+            Default 0 means RAM starts at physical address 0x0.
+
     config ARCH_SECONDARY_CPU_STACK_SIZE
         int "Secondary CPU stack size"
         default 4096
+        help
+            Stack size for secondary CPU cores in multi-core (SMP) systems.
+            
+            Each secondary CPU core (CPU1, CPU2, etc.) needs its own stack for
+            initialization and exception handling before the scheduler starts.
+            
+            Default 4096 bytes (4KB):
+            - Sufficient for standard initialization
+            - Handles nested exceptions during boot
+            
+            Increase if:
+            - Experiencing secondary CPU boot failures
+            - Complex initialization routines
+            - Deep call chains during CPU startup
+            
+            Total memory used: (Number of secondary cores) × stack size
+            
+            Note: After scheduler starts, each thread has its own stack.
+
     config ARCH_HAVE_EFFICIENT_UNALIGNED_ACCESS
         bool
         default y
+        help
+            ARMv8 supports efficient unaligned memory access.
+            
+            ARMv8 architecture can access unaligned memory addresses (addresses not
+            aligned to word boundaries) without performance penalty or exceptions.
+            
+            Benefits:
+            - Simpler code (no manual alignment required)
+            - Network packet processing (headers often unaligned)
+            - Reduced padding in data structures
+            
+            This is automatically enabled for ARMv8 - no configuration needed.
+            
+            Note: Some embedded systems may disable this for deterministic timing
+            or to catch alignment bugs, but ARMv8 handles it efficiently in hardware.
+
     config ARCH_USING_GENERIC_CPUID
         bool "Using generic cpuid implemenation"
         select ARCH_USING_HW_THREAD_SELF
         default y if RT_USING_OFW
         default n
+        help
+            Use generic CPU identification implementation for multi-core systems.
+            
+            Provides standardized method to identify which CPU core is currently
+            executing, essential for SMP (Symmetric Multi-Processing).
+            
+            When enabled:
+            - Reads MPIDR_EL1 register for CPU ID
+            - Maps hardware CPU IDs to logical CPU numbers
+            - Enables proper per-CPU data structures
+            
+            Required for:
+            - SMP systems with multiple cores
+            - Per-CPU statistics and profiling
+            - CPU affinity and core-specific operations
+            
+            Automatically enabled when using OpenFirmware/Device Tree (RT_USING_OFW).
+            
+            Enable if you have multi-core ARMv8 system. Disable for single-core
+            to save minimal overhead.
+
     config ARCH_HEAP_SIZE
         hex "Size of system heap"
         default 0x4000000
+        help
+            Size of system heap for dynamic memory allocation.
+            
+            Defines the amount of memory available for rt_malloc() and related
+            dynamic allocation functions.
+            
+            Default 0x4000000 (64MB):
+            - Suitable for application-class systems with RT-Smart
+            - Supports moderate number of dynamic allocations
+            
+            Adjust based on:
+            - Available RAM in your system
+            - Application memory requirements
+            - Static vs dynamic allocation strategy
+            
+            Smaller values for resource-constrained systems.
+            Larger values for systems with abundant RAM and heavy dynamic allocation.
+            
+            Note: Actual available memory depends on total RAM size.
+            
+            Example configurations:
+            - 128MB RAM system: 0x4000000 (64MB) or less
+            - 256MB RAM system: 0x8000000 (128MB) or more
+            - 1GB+ RAM system: 0x20000000 (512MB) or more
+
     config ARCH_INIT_PAGE_SIZE
         hex "Size of init page region"
         default 0x200000
+        help
+            Size of initial page table region for early boot.
+            
+            Reserves memory for page tables used during system initialization
+            before the full memory management is set up.
+            
+            Default 0x200000 (2MB):
+            - Sufficient for initial kernel mappings
+            - Covers typical early boot requirements
+            - Aligns with 2MB page granularity
+            
+            This memory is used for:
+            - Initial MMU page table entries
+            - Early kernel virtual memory mappings
+            - Temporary boot-time allocations
+            
+            Increase if:
+            - Experiencing boot failures related to page tables
+            - Large kernel image
+            - Extensive early I/O mappings
+            
+            Decrease for memory-constrained systems (minimum ~1MB).
+            
+            Note: After full MM initialization, regular page allocation takes over.
 endmenu