Kconfig 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163
  1. menu "AArch64 Architecture Configuration"
  2. config ARCH_TEXT_OFFSET
  3. hex "Text offset"
  4. default 0x200000
  5. help
  6. Offset of kernel text section from start of RAM.
  7. Defines where the kernel code (.text section) is located relative to
  8. the beginning of physical RAM. This space before the kernel is typically
  9. reserved for:
  10. - Bootloader and device tree blob (DTB)
  11. - Initial page tables
  12. - Boot-time data structures
  13. Default 0x200000 (2MB):
  14. - Provides 2MB for bootloader and DTB
  15. - Aligns with common ARM64 configurations
  16. - Compatible with 2MB page granularity
  17. Only change if you have specific bootloader requirements or memory layout.
  18. config ARCH_RAM_OFFSET
  19. hex "RAM offset"
  20. default 0
  21. help
  22. Physical address offset of the RAM start.
  23. Defines the starting physical address of system RAM. On many systems,
  24. RAM doesn't start at address 0x0.
  25. Common values:
  26. - 0x00000000: RAM starts at address 0 (some SoCs)
  27. - 0x40000000: Common for many ARM SoCs
  28. - 0x80000000: Some development boards
  29. This must match your hardware memory map. Check your SoC datasheet
  30. or bootloader configuration.
  31. Default 0 means RAM starts at physical address 0x0.
  32. config ARCH_SECONDARY_CPU_STACK_SIZE
  33. int "Secondary CPU stack size"
  34. default 4096
  35. help
  36. Stack size for secondary CPU cores in multi-core (SMP) systems.
  37. Each secondary CPU core (CPU1, CPU2, etc.) needs its own stack for
  38. initialization and exception handling before the scheduler starts.
  39. Default 4096 bytes (4KB):
  40. - Sufficient for standard initialization
  41. - Handles nested exceptions during boot
  42. Increase if:
  43. - Experiencing secondary CPU boot failures
  44. - Complex initialization routines
  45. - Deep call chains during CPU startup
  46. Total memory used: (Number of secondary cores) × stack size
  47. Note: After scheduler starts, each thread has its own stack.
  48. config ARCH_HAVE_EFFICIENT_UNALIGNED_ACCESS
  49. bool
  50. default y
  51. help
  52. ARMv8 supports efficient unaligned memory access.
  53. ARMv8 architecture can access unaligned memory addresses (addresses not
  54. aligned to word boundaries) without performance penalty or exceptions.
  55. Benefits:
  56. - Simpler code (no manual alignment required)
  57. - Network packet processing (headers often unaligned)
  58. - Reduced padding in data structures
  59. This is automatically enabled for ARMv8 - no configuration needed.
  60. Note: Some embedded systems may disable this for deterministic timing
  61. or to catch alignment bugs, but ARMv8 handles it efficiently in hardware.
  62. config ARCH_USING_GENERIC_CPUID
  63. bool "Using generic cpuid implemenation"
  64. select ARCH_USING_HW_THREAD_SELF
  65. default y if RT_USING_OFW
  66. default n
  67. help
  68. Use generic CPU identification implementation for multi-core systems.
  69. Provides standardized method to identify which CPU core is currently
  70. executing, essential for SMP (Symmetric Multi-Processing).
  71. When enabled:
  72. - Reads MPIDR_EL1 register for CPU ID
  73. - Maps hardware CPU IDs to logical CPU numbers
  74. - Enables proper per-CPU data structures
  75. Required for:
  76. - SMP systems with multiple cores
  77. - Per-CPU statistics and profiling
  78. - CPU affinity and core-specific operations
  79. Automatically enabled when using OpenFirmware/Device Tree (RT_USING_OFW).
  80. Enable if you have multi-core ARMv8 system. Disable for single-core
  81. to save minimal overhead.
  82. config ARCH_HEAP_SIZE
  83. hex "Size of system heap"
  84. default 0x4000000
  85. help
  86. Size of system heap for dynamic memory allocation.
  87. Defines the amount of memory available for rt_malloc() and related
  88. dynamic allocation functions.
  89. Default 0x4000000 (64MB):
  90. - Suitable for application-class systems with RT-Smart
  91. - Supports moderate number of dynamic allocations
  92. Adjust based on:
  93. - Available RAM in your system
  94. - Application memory requirements
  95. - Static vs dynamic allocation strategy
  96. Smaller values for resource-constrained systems.
  97. Larger values for systems with abundant RAM and heavy dynamic allocation.
  98. Note: Actual available memory depends on total RAM size.
  99. Example configurations:
  100. - 128MB RAM system: 0x4000000 (64MB) or less
  101. - 256MB RAM system: 0x8000000 (128MB) or more
  102. - 1GB+ RAM system: 0x20000000 (512MB) or more
  103. config ARCH_INIT_PAGE_SIZE
  104. hex "Size of init page region"
  105. default 0x200000
  106. help
  107. Size of initial page table region for early boot.
  108. Reserves memory for page tables used during system initialization
  109. before the full memory management is set up.
  110. Default 0x200000 (2MB):
  111. - Sufficient for initial kernel mappings
  112. - Covers typical early boot requirements
  113. - Aligns with 2MB page granularity
  114. This memory is used for:
  115. - Initial MMU page table entries
  116. - Early kernel virtual memory mappings
  117. - Temporary boot-time allocations
  118. Increase if:
  119. - Experiencing boot failures related to page tables
  120. - Large kernel image
  121. - Extensive early I/O mappings
  122. Decrease for memory-constrained systems (minimum ~1MB).
  123. Note: After full MM initialization, regular page allocation takes over.
  124. endmenu