arch/m68k/kernel/head.S
Source file repositories/reference/linux-study-clean/arch/m68k/kernel/head.S
File Facts
- System
- Linux kernel
- Corpus path
arch/m68k/kernel/head.S- Extension
.S- Size
- 90366 bytes
- Lines
- 3896
- Domain
- Architecture Layer
- Bucket
- arch/m68k
- Inferred role
- Architecture Layer: arch/m68k
- Status
- atlas-only
Why This File Exists
CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- CPU and platform-specific kernel glue: boot entry, traps, syscall entry, interrupts, page tables, context switch, and low-level barriers.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/linkage.hlinux/init.hlinux/pgtable.hasm/bootinfo.hasm/bootinfo-amiga.hasm/bootinfo-atari.hasm/bootinfo-hp300.hasm/bootinfo-mac.hasm/bootinfo-q40.hasm/bootinfo-virt.hasm/bootinfo-vme.hasm/setup.hasm/entry.hasm/page.hasm/asm-offsets.hasm/machw.h../mac/mac_penguin.S
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
jbsr start_kernel
/*
* Find a tag record in the bootinfo structure
* The bootinfo structure is located right after the kernel
* Returns: d0: size (-1 if not found)
* a0: data pointer (end-of-records if not found)
*/
func_start get_bi_record,%d1
movel ARG1,%d0
lea %pc@(_end),%a0
1: tstw %a0@(BIR_TAG)
jeq 3f
cmpw %a0@(BIR_TAG),%d0
jeq 2f
addw %a0@(BIR_SIZE),%a0
jra 1b
2: moveq #0,%d0
movew %a0@(BIR_SIZE),%d0
lea %a0@(BIR_DATA),%a0
jra 4f
3: moveq #-1,%d0
lea %a0@(BIR_SIZE),%a0
4:
func_return get_bi_record
/*
* MMU Initialization Begins Here
*
* The structure of the MMU tables on the 68k machines
* is thus:
* Root Table
* Logical addresses are translated through
* a hierarchical translation mechanism where the high-order
* seven bits of the logical address (LA) are used as an
* index into the "root table." Each entry in the root
* table has a bit which specifies if it's a valid pointer to a
* pointer table. Each entry defines a 32Meg range of memory.
* If an entry is invalid then that logical range of 32M is
* invalid and references to that range of memory (when the MMU
* is enabled) will fault. If the entry is valid, then it does
* one of two things. On 040/060 class machines, it points to
* a pointer table which then describes more finely the memory
* within that 32M range. On 020/030 class machines, a technique
* called "early terminating descriptors" are used. This technique
* allows an entire 32Meg to be described by a single entry in the
* root table. Thus, this entry in the root table, contains the
* physical address of the memory or I/O at the logical address
* which the entry represents and it also contains the necessary
* cache bits for this region.
*
* Pointer Tables
* Per the Root Table, there will be one or more
* pointer tables. Each pointer table defines a 32M range.
* Not all of the 32M range need be defined. Again, the next
* seven bits of the logical address are used an index into
* the pointer table to point to page tables (if the pointer
* is valid). There will undoubtedly be more than one
* pointer table for the kernel because each pointer table
* defines a range of only 32M. Valid pointer table entries
* point to page tables, or are early terminating entries
* themselves.
*
* Page Tables
* Per the Pointer Tables, each page table entry points
* to the physical page in memory that supports the logical
* address that translates to the particular index.
*
Annotation
- Immediate include surface: `linux/linkage.h`, `linux/init.h`, `linux/pgtable.h`, `asm/bootinfo.h`, `asm/bootinfo-amiga.h`, `asm/bootinfo-atari.h`, `asm/bootinfo-hp300.h`, `asm/bootinfo-mac.h`.
- Atlas domain: Architecture Layer / arch/m68k.
- Implementation status: atlas-only.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.