mirror of
				https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
				synced 2025-11-04 16:52:06 +10:00 
			
		
		
		
	My first guess for "fujitsu" was it might be related to the fujitsu-laptop.c driver... Move the frv directory one level up since frv is the name of the architecture in the Linux kernel. Signed-off-by: Adrian Bunk <bunk@kernel.org>
		
			
				
	
	
		
			307 lines
		
	
	
		
			14 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			307 lines
		
	
	
		
			14 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
				 =================================
 | 
						|
				 FR451 MMU LINUX MEMORY MANAGEMENT
 | 
						|
				 =================================
 | 
						|
 | 
						|
============
 | 
						|
MMU HARDWARE
 | 
						|
============
 | 
						|
 | 
						|
FR451 MMU Linux puts the MMU into EDAT mode whilst running. This means that it uses both the SAT
 | 
						|
registers and the DAT TLB to perform address translation.
 | 
						|
 | 
						|
There are 8 IAMLR/IAMPR register pairs and 16 DAMLR/DAMPR register pairs for SAT mode.
 | 
						|
 | 
						|
In DAT mode, there is also a TLB organised in cache format as 64 lines x 2 ways. Each line spans a
 | 
						|
16KB range of addresses, but can match a larger region.
 | 
						|
 | 
						|
 | 
						|
===========================
 | 
						|
MEMORY MANAGEMENT REGISTERS
 | 
						|
===========================
 | 
						|
 | 
						|
Certain control registers are used by the kernel memory management routines:
 | 
						|
 | 
						|
	REGISTERS		USAGE
 | 
						|
	======================	==================================================
 | 
						|
	IAMR0, DAMR0		Kernel image and data mappings
 | 
						|
	IAMR1, DAMR1		First-chance TLB lookup mapping
 | 
						|
	DAMR2			Page attachment for cache flush by page
 | 
						|
	DAMR3			Current PGD mapping
 | 
						|
	SCR0, DAMR4		Instruction TLB PGE/PTD cache
 | 
						|
	SCR1, DAMR5		Data TLB PGE/PTD cache
 | 
						|
	DAMR6-10		kmap_atomic() mappings
 | 
						|
	DAMR11			I/O mapping
 | 
						|
	CXNR			mm_struct context ID
 | 
						|
	TTBR			Page directory (PGD) pointer (physical address)
 | 
						|
 | 
						|
 | 
						|
=====================
 | 
						|
GENERAL MEMORY LAYOUT
 | 
						|
=====================
 | 
						|
 | 
						|
The physical memory layout is as follows:
 | 
						|
 | 
						|
  PHYSICAL ADDRESS	CONTROLLER	DEVICE
 | 
						|
  ===================	==============	=======================================
 | 
						|
  00000000 - BFFFFFFF	SDRAM		SDRAM area
 | 
						|
  E0000000 - EFFFFFFF	L-BUS CS2#	VDK SLBUS/PCI window
 | 
						|
  F0000000 - F0FFFFFF	L-BUS CS5#	MB93493 CSC area (DAV daughter board)
 | 
						|
  F1000000 - F1FFFFFF	L-BUS CS7#	(CB70 CPU-card PCMCIA port I/O space)
 | 
						|
  FC000000 - FC0FFFFF	L-BUS CS1#	VDK MB86943 config space
 | 
						|
  FC100000 - FC1FFFFF	L-BUS CS6#	DM9000 NIC I/O space
 | 
						|
  FC200000 - FC2FFFFF	L-BUS CS3#	MB93493 CSR area (DAV daughter board)
 | 
						|
  FD000000 - FDFFFFFF	L-BUS CS4#	(CB70 CPU-card extra flash space)
 | 
						|
  FE000000 - FEFFFFFF			Internal CPU peripherals
 | 
						|
  FF000000 - FF1FFFFF	L-BUS CS0#	Flash 1
 | 
						|
  FF200000 - FF3FFFFF	L-BUS CS0#	Flash 2
 | 
						|
  FFC00000 - FFC0001F	L-BUS CS0#	FPGA
 | 
						|
 | 
						|
The virtual memory layout is:
 | 
						|
 | 
						|
  VIRTUAL ADDRESS    PHYSICAL	TRANSLATOR	FLAGS	SIZE	OCCUPATION
 | 
						|
  =================  ========	==============	=======	=======	===================================
 | 
						|
  00004000-BFFFFFFF  various	TLB,xAMR1	D-N-??V	3GB	Userspace
 | 
						|
  C0000000-CFFFFFFF  00000000	xAMPR0		-L-S--V	256MB	Kernel image and data
 | 
						|
  D0000000-D7FFFFFF  various	TLB,xAMR1	D-NS??V	128MB	vmalloc area
 | 
						|
  D8000000-DBFFFFFF  various	TLB,xAMR1	D-NS??V	64MB	kmap() area
 | 
						|
  DC000000-DCFFFFFF  various	TLB			1MB	Secondary kmap_atomic() frame
 | 
						|
  DD000000-DD27FFFF  various	DAMR			160KB	Primary kmap_atomic() frame
 | 
						|
  DD040000			DAMR2/IAMR2	-L-S--V	page	Page cache flush attachment point
 | 
						|
  DD080000			DAMR3		-L-SC-V	page	Page Directory (PGD)
 | 
						|
  DD0C0000			DAMR4		-L-SC-V	page	Cached insn TLB Page Table lookup
 | 
						|
  DD100000			DAMR5		-L-SC-V	page	Cached data TLB Page Table lookup
 | 
						|
  DD140000			DAMR6		-L-S--V	page	kmap_atomic(KM_BOUNCE_READ)
 | 
						|
  DD180000			DAMR7		-L-S--V	page	kmap_atomic(KM_SKB_SUNRPC_DATA)
 | 
						|
  DD1C0000			DAMR8		-L-S--V	page	kmap_atomic(KM_SKB_DATA_SOFTIRQ)
 | 
						|
  DD200000			DAMR9		-L-S--V	page	kmap_atomic(KM_USER0)
 | 
						|
  DD240000			DAMR10		-L-S--V	page	kmap_atomic(KM_USER1)
 | 
						|
  E0000000-FFFFFFFF  E0000000	DAMR11		-L-SC-V	512MB	I/O region
 | 
						|
 | 
						|
IAMPR1 and DAMPR1 are used as an extension to the TLB.
 | 
						|
 | 
						|
 | 
						|
====================
 | 
						|
KMAP AND KMAP_ATOMIC
 | 
						|
====================
 | 
						|
 | 
						|
To access pages in the page cache (which may not be directly accessible if highmem is available),
 | 
						|
the kernel calls kmap(), does the access and then calls kunmap(); or it calls kmap_atomic(), does
 | 
						|
the access and then calls kunmap_atomic().
 | 
						|
 | 
						|
kmap() creates an attachment between an arbitrary inaccessible page and a range of virtual
 | 
						|
addresses by installing a PTE in a special page table. The kernel can then access this page as it
 | 
						|
wills. When it's finished, the kernel calls kunmap() to clear the PTE.
 | 
						|
 | 
						|
kmap_atomic() does something slightly different. In the interests of speed, it chooses one of two
 | 
						|
strategies:
 | 
						|
 | 
						|
 (1) If possible, kmap_atomic() attaches the requested page to one of DAMPR5 through DAMPR10
 | 
						|
     register pairs; and the matching kunmap_atomic() clears the DAMPR. This makes high memory
 | 
						|
     support really fast as there's no need to flush the TLB or modify the page tables. The DAMLR
 | 
						|
     registers being used for this are preset during boot and don't change over the lifetime of the
 | 
						|
     process. There's a direct mapping between the first few kmap_atomic() types, DAMR number and
 | 
						|
     virtual address slot.
 | 
						|
 | 
						|
     However, there are more kmap_atomic() types defined than there are DAMR registers available,
 | 
						|
     so we fall back to:
 | 
						|
 | 
						|
 (2) kmap_atomic() uses a slot in the secondary frame (determined by the type parameter), and then
 | 
						|
     locks an entry in the TLB to translate that slot to the specified page. The number of slots is
 | 
						|
     obviously limited, and their positions are controlled such that each slot is matched by a
 | 
						|
     different line in the TLB. kunmap() ejects the entry from the TLB.
 | 
						|
 | 
						|
Note that the first three kmap atomic types are really just declared as placeholders. The DAMPR
 | 
						|
registers involved are actually modified directly.
 | 
						|
 | 
						|
Also note that kmap() itself may sleep, kmap_atomic() may never sleep and both always succeed;
 | 
						|
furthermore, a driver using kmap() may sleep before calling kunmap(), but may not sleep before
 | 
						|
calling kunmap_atomic() if it had previously called kmap_atomic().
 | 
						|
 | 
						|
 | 
						|
===============================
 | 
						|
USING MORE THAN 256MB OF MEMORY
 | 
						|
===============================
 | 
						|
 | 
						|
The kernel cannot access more than 256MB of memory directly. The physical layout, however, permits
 | 
						|
up to 3GB of SDRAM (possibly 3.25GB) to be made available. By using CONFIG_HIGHMEM, the kernel can
 | 
						|
allow userspace (by way of page tables) and itself (by way of kmap) to deal with the memory
 | 
						|
allocation.
 | 
						|
 | 
						|
External devices can, of course, still DMA to and from all of the SDRAM, even if the kernel can't
 | 
						|
see it directly. The kernel translates page references into real addresses for communicating to the
 | 
						|
devices.
 | 
						|
 | 
						|
 | 
						|
===================
 | 
						|
PAGE TABLE TOPOLOGY
 | 
						|
===================
 | 
						|
 | 
						|
The page tables are arranged in 2-layer format. There is a middle layer (PMD) that would be used in
 | 
						|
3-layer format tables but that is folded into the top layer (PGD) and so consumes no extra memory
 | 
						|
or processing power.
 | 
						|
 | 
						|
  +------+     PGD    PMD
 | 
						|
  | TTBR |--->+-------------------+
 | 
						|
  +------+    |      |      : STE |
 | 
						|
              | PGE0 | PME0 : STE |
 | 
						|
              |      |      : STE |
 | 
						|
              +-------------------+              Page Table
 | 
						|
              |      |      : STE -------------->+--------+ +0x0000
 | 
						|
              | PGE1 | PME0 : STE -----------+   | PTE0   |
 | 
						|
              |      |      : STE -------+   |   +--------+
 | 
						|
              +-------------------+      |   |   | PTE63  |
 | 
						|
              |      |      : STE |      |   +-->+--------+ +0x0100
 | 
						|
              | PGE2 | PME0 : STE |      |       | PTE64  |
 | 
						|
              |      |      : STE |      |       +--------+
 | 
						|
              +-------------------+      |       | PTE127 |
 | 
						|
              |      |      : STE |      +------>+--------+ +0x0200
 | 
						|
              | PGE3 | PME0 : STE |              | PTE128 |
 | 
						|
              |      |      : STE |              +--------+
 | 
						|
              +-------------------+              | PTE191 |
 | 
						|
                                                 +--------+ +0x0300
 | 
						|
 | 
						|
Each Page Directory (PGD) is 16KB (page size) in size and is divided into 64 entries (PGEs). Each
 | 
						|
PGE contains one Page Mid Directory (PMD).
 | 
						|
 | 
						|
Each PMD is 256 bytes in size and contains a single entry (PME). Each PME holds 64 FR451 MMU
 | 
						|
segment table entries of 4 bytes apiece. Each PME "points to" a page table. In practice, each STE
 | 
						|
points to a subset of the page table, the first to PT+0x0000, the second to PT+0x0100, the third to
 | 
						|
PT+0x200, and so on.
 | 
						|
 | 
						|
Each PGE and PME covers 64MB of the total virtual address space.
 | 
						|
 | 
						|
Each Page Table (PTD) is 16KB (page size) in size, and is divided into 4096 entries (PTEs). Each
 | 
						|
entry can point to one 16KB page. In practice, each Linux page table is subdivided into 64 FR451
 | 
						|
MMU page tables. But they are all grouped together to make management easier, in particular rmap
 | 
						|
support is then trivial.
 | 
						|
 | 
						|
Grouping page tables in this fashion makes PGE caching in SCR0/SCR1 more efficient because the
 | 
						|
coverage of the cached item is greater.
 | 
						|
 | 
						|
Page tables for the vmalloc area are allocated at boot time and shared between all mm_structs.
 | 
						|
 | 
						|
 | 
						|
=================
 | 
						|
USER SPACE LAYOUT
 | 
						|
=================
 | 
						|
 | 
						|
For MMU capable Linux, the regions userspace code are allowed to access are kept entirely separate
 | 
						|
from those dedicated to the kernel:
 | 
						|
 | 
						|
	VIRTUAL ADDRESS    SIZE   PURPOSE
 | 
						|
	=================  =====  ===================================
 | 
						|
	00000000-00003fff  4KB    NULL pointer access trap
 | 
						|
	00004000-01ffffff  ~32MB  lower mmap space (grows up)
 | 
						|
	02000000-021fffff  2MB    Stack space (grows down from top)
 | 
						|
	02200000-nnnnnnnn         Executable mapping
 | 
						|
        nnnnnnnn-                 brk space (grows up)
 | 
						|
	        -bfffffff         upper mmap space (grows down)
 | 
						|
 | 
						|
This is so arranged so as to make best use of the 16KB page tables and the way in which PGEs/PMEs
 | 
						|
are cached by the TLB handler. The lower mmap space is filled first, and then the upper mmap space
 | 
						|
is filled.
 | 
						|
 | 
						|
 | 
						|
===============================
 | 
						|
GDB-STUB MMU DEBUGGING SERVICES
 | 
						|
===============================
 | 
						|
 | 
						|
The gdb-stub included in this kernel provides a number of services to aid in the debugging of MMU
 | 
						|
related kernel services:
 | 
						|
 | 
						|
 (*) Every time the kernel stops, certain state information is dumped into __debug_mmu. This
 | 
						|
     variable is defined in arch/frv/kernel/gdb-stub.c. Note that the gdbinit file in this
 | 
						|
     directory has some useful macros for dealing with this.
 | 
						|
 | 
						|
     (*) __debug_mmu.tlb[]
 | 
						|
 | 
						|
	 This receives the current TLB contents. This can be viewed with the _tlb GDB macro:
 | 
						|
 | 
						|
		(gdb) _tlb
 | 
						|
		tlb[0x00]: 01000005 00718203  01000002 00718203
 | 
						|
		tlb[0x01]: 01004002 006d4201  01004005 006d4203
 | 
						|
		tlb[0x02]: 01008002 006d0201  01008006 00004200
 | 
						|
		tlb[0x03]: 0100c006 007f4202  0100c002 0064c202
 | 
						|
		tlb[0x04]: 01110005 00774201  01110002 00774201
 | 
						|
		tlb[0x05]: 01114005 00770201  01114002 00770201
 | 
						|
		tlb[0x06]: 01118002 0076c201  01118005 0076c201
 | 
						|
		...
 | 
						|
		tlb[0x3d]: 010f4002 00790200  001f4002 0054ca02
 | 
						|
		tlb[0x3e]: 010f8005 0078c201  010f8002 0078c201
 | 
						|
		tlb[0x3f]: 001fc002 0056ca01  001fc005 00538a01
 | 
						|
 | 
						|
     (*) __debug_mmu.iamr[]
 | 
						|
     (*) __debug_mmu.damr[]
 | 
						|
 | 
						|
	 These receive the current IAMR and DAMR contents. These can be viewed with the _amr
 | 
						|
	 GDB macro:
 | 
						|
 | 
						|
		(gdb) _amr
 | 
						|
		AMRx           DAMR                    IAMR
 | 
						|
		====   =====================   =====================
 | 
						|
		amr0 : L:c0000000 P:00000cb9 : L:c0000000 P:000004b9
 | 
						|
		amr1 : L:01070005 P:006f9203 : L:0102c005 P:006a1201
 | 
						|
		amr2 : L:d8d00000 P:00000000 : L:d8d00000 P:00000000
 | 
						|
		amr3 : L:d8d04000 P:00534c0d : L:00000000 P:00000000
 | 
						|
		amr4 : L:d8d08000 P:00554c0d : L:00000000 P:00000000
 | 
						|
		amr5 : L:d8d0c000 P:00554c0d : L:00000000 P:00000000
 | 
						|
		amr6 : L:d8d10000 P:00000000 : L:00000000 P:00000000
 | 
						|
		amr7 : L:d8d14000 P:00000000 : L:00000000 P:00000000
 | 
						|
		amr8 : L:d8d18000 P:00000000
 | 
						|
		amr9 : L:d8d1c000 P:00000000
 | 
						|
		amr10: L:d8d20000 P:00000000
 | 
						|
		amr11: L:e0000000 P:e0000ccd
 | 
						|
 | 
						|
 (*) The current task's page directory is bound to DAMR3.
 | 
						|
 | 
						|
     This can be viewed with the _pgd GDB macro:
 | 
						|
 | 
						|
	(gdb) _pgd
 | 
						|
	$3 = {{pge = {{ste = {0x554001, 0x554101, 0x554201, 0x554301, 0x554401,
 | 
						|
		  0x554501, 0x554601, 0x554701, 0x554801, 0x554901, 0x554a01,
 | 
						|
		  0x554b01, 0x554c01, 0x554d01, 0x554e01, 0x554f01, 0x555001,
 | 
						|
		  0x555101, 0x555201, 0x555301, 0x555401, 0x555501, 0x555601,
 | 
						|
		  0x555701, 0x555801, 0x555901, 0x555a01, 0x555b01, 0x555c01,
 | 
						|
		  0x555d01, 0x555e01, 0x555f01, 0x556001, 0x556101, 0x556201,
 | 
						|
		  0x556301, 0x556401, 0x556501, 0x556601, 0x556701, 0x556801,
 | 
						|
		  0x556901, 0x556a01, 0x556b01, 0x556c01, 0x556d01, 0x556e01,
 | 
						|
		  0x556f01, 0x557001, 0x557101, 0x557201, 0x557301, 0x557401,
 | 
						|
		  0x557501, 0x557601, 0x557701, 0x557801, 0x557901, 0x557a01,
 | 
						|
		  0x557b01, 0x557c01, 0x557d01, 0x557e01, 0x557f01}}}}, {pge = {{
 | 
						|
		ste = {0x0 <repeats 64 times>}}}} <repeats 51 times>, {pge = {{ste = {
 | 
						|
		  0x248001, 0x248101, 0x248201, 0x248301, 0x248401, 0x248501,
 | 
						|
		  0x248601, 0x248701, 0x248801, 0x248901, 0x248a01, 0x248b01,
 | 
						|
		  0x248c01, 0x248d01, 0x248e01, 0x248f01, 0x249001, 0x249101,
 | 
						|
		  0x249201, 0x249301, 0x249401, 0x249501, 0x249601, 0x249701,
 | 
						|
		  0x249801, 0x249901, 0x249a01, 0x249b01, 0x249c01, 0x249d01,
 | 
						|
		  0x249e01, 0x249f01, 0x24a001, 0x24a101, 0x24a201, 0x24a301,
 | 
						|
		  0x24a401, 0x24a501, 0x24a601, 0x24a701, 0x24a801, 0x24a901,
 | 
						|
		  0x24aa01, 0x24ab01, 0x24ac01, 0x24ad01, 0x24ae01, 0x24af01,
 | 
						|
		  0x24b001, 0x24b101, 0x24b201, 0x24b301, 0x24b401, 0x24b501,
 | 
						|
		  0x24b601, 0x24b701, 0x24b801, 0x24b901, 0x24ba01, 0x24bb01,
 | 
						|
		  0x24bc01, 0x24bd01, 0x24be01, 0x24bf01}}}}, {pge = {{ste = {
 | 
						|
		  0x0 <repeats 64 times>}}}} <repeats 11 times>}
 | 
						|
 | 
						|
 (*) The PTD last used by the instruction TLB miss handler is attached to DAMR4.
 | 
						|
 (*) The PTD last used by the data TLB miss handler is attached to DAMR5.
 | 
						|
 | 
						|
     These can be viewed with the _ptd_i and _ptd_d GDB macros:
 | 
						|
 | 
						|
	(gdb) _ptd_d
 | 
						|
	$5 = {{pte = 0x0} <repeats 127 times>, {pte = 0x539b01}, {
 | 
						|
	    pte = 0x0} <repeats 896 times>, {pte = 0x719303}, {pte = 0x6d5303}, {
 | 
						|
	    pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {
 | 
						|
	    pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x6a1303}, {
 | 
						|
	    pte = 0x0} <repeats 12 times>, {pte = 0x709303}, {pte = 0x0}, {pte = 0x0},
 | 
						|
	  {pte = 0x6fd303}, {pte = 0x6f9303}, {pte = 0x6f5303}, {pte = 0x0}, {
 | 
						|
	    pte = 0x6ed303}, {pte = 0x531b01}, {pte = 0x50db01}, {
 | 
						|
	    pte = 0x0} <repeats 13 times>, {pte = 0x5303}, {pte = 0x7f5303}, {
 | 
						|
	    pte = 0x509b01}, {pte = 0x505b01}, {pte = 0x7c9303}, {pte = 0x7b9303}, {
 | 
						|
	    pte = 0x7b5303}, {pte = 0x7b1303}, {pte = 0x7ad303}, {pte = 0x0}, {
 | 
						|
	    pte = 0x0}, {pte = 0x7a1303}, {pte = 0x0}, {pte = 0x795303}, {pte = 0x0}, {
 | 
						|
	    pte = 0x78d303}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {pte = 0x0}, {
 | 
						|
	    pte = 0x0}, {pte = 0x775303}, {pte = 0x771303}, {pte = 0x76d303}, {
 | 
						|
	    pte = 0x0}, {pte = 0x765303}, {pte = 0x7c5303}, {pte = 0x501b01}, {
 | 
						|
	    pte = 0x4f1b01}, {pte = 0x4edb01}, {pte = 0x0}, {pte = 0x4f9b01}, {
 | 
						|
	    pte = 0x4fdb01}, {pte = 0x0} <repeats 2992 times>}
 |