Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) Memory alignment
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) Too many problems popped up because of unnoticed misaligned memory access in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) kernel code lately.  Therefore the alignment fixup is now unconditionally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) configured in for SA11x0 based targets.  According to Alan Cox, this is a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) bad idea to configure it out, but Russell King has some good reasons for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9) doing so on some f***ed up ARM architectures like the EBSA110.  However
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) this is not the case on many design I'm aware of, like all SA11x0 based
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) ones.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) Of course this is a bad idea to rely on the alignment trap to perform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) unaligned memory access in general.  If those access are predictable, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) are better to use the macros provided by include/asm/unaligned.h.  The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) alignment trap can fixup misaligned access for the exception cases, but at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) a high performance cost.  It better be rare.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) Now for user space applications, it is possible to configure the alignment
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) trap to SIGBUS any code performing unaligned access (good for debugging bad
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) code), or even fixup the access by software like for kernel code.  The later
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) mode isn't recommended for performance reasons (just think about the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) floating point emulation that works about the same way).  Fix your code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) instead!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) Please note that randomly changing the behaviour without good thought is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) real bad - it changes the behaviour of all unaligned instructions in user
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) space, and might cause programs to fail unexpectedly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) To change the alignment trap behavior, simply echo a number into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) /proc/cpu/alignment.  The number is made up from various bits:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) ===		========================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) bit		behavior when set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) ===		========================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) 0		A user process performing an unaligned memory access
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) 		will cause the kernel to print a message indicating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 		process name, pid, pc, instruction, address, and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) 		fault code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) 1		The kernel will attempt to fix up the user process
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) 		performing the unaligned access.  This is of course
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) 		slow (think about the floating point emulator) and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) 		not recommended for production use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 2		The kernel will send a SIGBUS signal to the user process
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) 		performing the unaligned access.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) ===		========================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) Note that not all combinations are supported - only values 0 through 5.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) (6 and 7 don't make sense).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) For example, the following will turn on the warnings, but without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) fixing up or sending SIGBUS signals::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) 	echo 1 > /proc/cpu/alignment
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) You can also read the content of the same file to get statistical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) information on unaligned access occurrences plus the current mode of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) operation for user space code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) Nicolas Pitre, Mar 13, 2001.  Modified Russell King, Nov 30, 2001.