summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorAndreas Baumann <mail@andreasbaumann.cc>2023-04-10 14:59:20 +0200
committerAndreas Baumann <mail@andreasbaumann.cc>2023-04-10 14:59:20 +0200
commit1b82c5dbf6a1c953073906e14567e91f9fd6f266 (patch)
tree555a90f4d45ea9af51a65172626f03fe37ad8d15 /doc
parent7a51b6745d785f0a003a81c4d1fb819620224154 (diff)
downloaduflbbl-1b82c5dbf6a1c953073906e14567e91f9fd6f266.tar.gz
uflbbl-1b82c5dbf6a1c953073906e14567e91f9fd6f266.tar.bz2
moved documentation
Diffstat (limited to 'doc')
-rw-r--r--doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-1.txt897
-rw-r--r--doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-2.txt937
-rw-r--r--doc/doc/dc0d32.blogspot.com_2010_06_real-mode-in-c-with-gcc-writing.txt892
-rw-r--r--doc/doc/fossbytes_com_redditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486.txt339
-rw-r--r--doc/doc/people.freedesktop.org_~narmstrong_meson_drm_doc_admin-guide_initrd.txt453
-rw-r--r--doc/doc/www.kernel.org_doc_html_latest_x86_boot.txt2349
-rw-r--r--doc/doc/www.kernel.org_doc_html_latest_x86_zero-page.txt424
7 files changed, 6291 insertions, 0 deletions
diff --git a/doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-1.txt b/doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-1.txt
new file mode 100644
index 0000000..d1e1971
--- /dev/null
+++ b/doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-1.txt
@@ -0,0 +1,897 @@
+ #[1]next [2]prev
+
+ IFRAME:
+ [3]https://archive.org/includes/donate.php?as_page=1&platform=wb&refere
+ r=https%3A//web.archive.org/web/20230308144716/https%3A//0xax.gitbooks.
+ io/linux-insides/content/Booting/linux-bootstrap-1.html
+
+ [4]Wayback Machine
+ https://0xax.gitbook Go
+ [5]86 captures
+ 01 Feb 2015 - 22 Mar 2023
+ [6]Jan MAR Apr
+ [7]Previous capture 08 [8]Next capture
+ [9]2022 2023 2024
+ success
+ fail
+ [10]About this capture
+ COLLECTED BY
+ Collection: [11]mega002
+ TIMESTAMPS
+ loading
+
+ The Wayback Machine -
+ https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/lin
+ ux-insides/content/Booting/linux-bootstrap-1.html
+
+ ____________________
+
+ * [12]Linux Inside
+ *
+ * Summary
+ * [13]Introduction
+ * [14]Booting
+ + [15]From bootloader to kernel
+ + [16]First steps in the kernel setup code
+ + [17]Video mode initialization and transition to protected mode
+ + [18]Transition to 64-bit mode
+ + [19]Kernel decompression
+ + [20]Kernel load address randomization
+ * [21]Initialization
+ + [22]First steps in the kernel
+ + [23]Early interrupts handler
+ + [24]Last preparations before the kernel entry point
+ + [25]Kernel entry point
+ + [26]Continue architecture-specific boot-time initializations
+ + [27]Architecture-specific initializations, again...
+ + [28]End of the architecture-specific initializations,
+ almost...
+ + [29]Scheduler initialization
+ + [30]RCU initialization
+ + [31]End of initialization
+ * [32]Interrupts
+ + [33]Introduction
+ + [34]Start to dive into interrupts
+ + [35]Interrupt handlers
+ + [36]Initialization of non-early interrupt gates
+ + [37]Implementation of some exception handlers
+ + [38]Handling Non-Maskable interrupts
+ + [39]Dive into external hardware interrupts
+ + [40]Initialization of external hardware interrupts structures
+ + [41]Softirq, Tasklets and Workqueues
+ + [42]Last part
+ * [43]System calls
+ + [44]Introduction to system calls
+ + [45]How the Linux kernel handles a system call
+ + [46]vsyscall and vDSO
+ + [47]How the Linux kernel runs a program
+ + [48]Implementation of the open system call
+ + [49]Limits on resources in Linux
+ * [50]Timers and time management
+ + [51]Introduction
+ + [52]Clocksource framework
+ + [53]The tick broadcast framework and dyntick
+ + [54]Introduction to timers
+ + [55]Clockevents framework
+ + [56]x86 related clock sources
+ + [57]Time related system calls
+ * [58]Synchronization primitives
+ + [59]Introduction to spinlocks
+ + [60]Queued spinlocks
+ + [61]Semaphores
+ + [62]Mutex
+ + [63]Reader/Writer semaphores
+ + [64]SeqLock
+ + RCU
+ + Lockdep
+ * [65]Memory management
+ + [66]Memblock
+ + [67]Fixmaps and ioremap
+ + [68]kmemcheck
+ * [69]Cgroups
+ + [70]Introduction to Control Groups
+ * SMP
+ * [71]Concepts
+ + [72]Per-CPU variables
+ + [73]Cpumasks
+ + [74]The initcall mechanism
+ + [75]Notification Chains
+ * [76]Data Structures in the Linux Kernel
+ + [77]Doubly linked list
+ + [78]Radix tree
+ + [79]Bit arrays
+ * [80]Theory
+ + [81]Paging
+ + [82]Elf64
+ + [83]Inline assembly
+ + CPUID
+ + MSR
+ * Initial ram disk
+ + initrd
+ * [84]Misc
+ + [85]Linux kernel development
+ + [86]How the kernel is compiled
+ + [87]Linkers
+ + [88]Program startup process in userspace
+ + Write and Submit your first Linux kernel Patch
+ + Data types in the kernel
+ * [89]KernelStructures
+ + [90]IDT
+ * [91]Useful links
+ * [92]Contributors
+ *
+
+ Powered by GitBook
+
+[93]From bootloader to kernel
+
+Kernel booting process. Part 1.
+
+From the bootloader to the kernel
+
+ If you read my previous [94]blog posts, you might have noticed that I
+ have been involved with low-level programming for some time. I wrote
+ some posts about assembly programming for x86_64 Linux and, at the same
+ time, started to dive into the Linux kernel source code.
+
+ I have a great interest in understanding how low-level things work, how
+ programs run on my computer, how they are located in memory, how the
+ kernel manages processes and memory, how the network stack works at a
+ low level, and many many other things. So, I decided to write yet
+ another series of posts about the Linux kernel for the x86_64
+ architecture.
+
+ Note that I'm not a professional kernel hacker and I don't write code
+ for the kernel at work. It's just a hobby. I just like low-level stuff,
+ and it is interesting for me to see how these things work. So if you
+ notice anything confusing, or if you have any questions/remarks, ping
+ me on Twitter [95]0xAX, drop me an [96]email or just create an
+ [97]issue. I appreciate it.
+
+ All posts will also be accessible at [98]github repo and, if you find
+ something wrong with my English or the post content, feel free to send
+ a pull request.
+
+ Note that this isn't official documentation, just learning and sharing
+ knowledge.
+
+ Required knowledge
+ * Understanding C code
+ * Understanding assembly code (AT&T syntax)
+
+ Anyway, if you're just starting to learn such tools, I will try to
+ explain some parts during this and the following posts. Alright, this
+ is the end of the simple introduction. Let's start to dive into the
+ Linux kernel and low-level stuff!
+
+ I started writing these posts at the time of the 3.18 Linux kernel, and
+ many things have changed since that time. If there are changes, I will
+ update the posts accordingly.
+
+The Magical Power Button, What happens next?
+
+ Although this is a series of posts about the Linux kernel, we won't
+ start directly from the kernel code. As soon as you press the magical
+ power button on your laptop or desktop computer, it starts working. The
+ motherboard sends a signal to the [99]power supply device. After
+ receiving the signal, the power supply provides the proper amount of
+ electricity to the computer. Once the motherboard receives the
+ [100]power good signal, it tries to start the CPU. The CPU resets all
+ leftover data in its registers and sets predefined values for each of
+ them.
+
+ The [101]80386 and later CPUs define the following predefined data in
+ CPU registers after the computer resets:
+IP 0xfff0
+CS selector 0xf000
+CS base 0xffff0000
+
+ The processor starts working in [102]real mode. Let's back up a little
+ and try to understand [103]memory segmentation in this mode. Real mode
+ is supported on all x86-compatible processors, from the [104]8086 CPU
+ all the way to the modern Intel 64-bit CPUs. The 8086 processor has a
+ 20-bit address bus, which means that it could work with a 0-0xFFFFF or
+ 1 megabyte address space. But it only has 16-bit registers, which have
+ a maximum address of 2^16 - 1 or 0xffff (64 kilobytes).
+
+ [105]Memory segmentation is used to make use of all the address space
+ available. All memory is divided into small, fixed-size segments of
+ 65536 bytes (64 KB). Since we cannot address memory above 64 KB with
+ 16-bit registers, an alternate method was devised.
+
+ An address consists of two parts: a segment selector, which has a base
+ address; and an offset from this base address. In real mode, the
+ associated base address of a segment selector is Segment Selector * 16.
+ Thus, to get a physical address in memory, we need to multiply the
+ segment selector part by 16 and add the offset to it:
+PhysicalAddress = Segment Selector * 16 + Offset
+
+ For example, if CS:IP is 0x2000:0x0010, then the corresponding physical
+ address will be:
+>>> hex((0x2000 << 4) + 0x0010)
+'0x20010'
+
+ But, if we take the largest segment selector and offset, 0xffff:0xffff,
+ then the resulting address will be:
+>>> hex((0xffff << 4) + 0xffff)
+'0x10ffef'
+
+ which is 65520 bytes past the first megabyte. Since only one megabyte
+ is accessible in real mode, 0x10ffef becomes 0x00ffef with the [106]A20
+ line disabled.
+
+ Ok, now we know a little bit about real mode and its memory addressing.
+ Let's get back to discussing register values after reset.
+
+ The CS register consists of two parts: the visible segment selector and
+ the hidden base address. While the base address is normally formed by
+ multiplying the segment selector value by 16, during a hardware reset
+ the segment selector in the CS register is loaded with 0xf000 and the
+ base address is loaded with 0xffff0000. The processor uses this special
+ base address until CS changes.
+
+ The starting address is formed by adding the base address to the value
+ in the EIP register:
+>>> 0xffff0000 + 0xfff0
+'0xfffffff0'
+
+ We get 0xfffffff0, which is 16 bytes below 4GB. This point is called
+ the [107]reset vector. It's the memory location at which the CPU
+ expects to find the first instruction to execute after reset. It
+ contains a [108]jump (jmp) instruction that usually points to the
+ [109]BIOS (Basic Input/Output System) entry point. For example, if we
+ look in the [110]coreboot source code (src/cpu/x86/16bit/reset16.inc),
+ we see:
+ .section ".reset", "ax", %progbits
+ .code16
+.globl _start
+_start:
+ .byte 0xe9
+ .int _start16bit - ( . + 2 )
+ ...
+
+ Here we can see the jmp instruction [111]opcode, which is 0xe9, and its
+ destination address at _start16bit - ( . + 2).
+
+ We also see that the reset section is 16 bytes and is compiled to start
+ from the address 0xfffffff0 (src/cpu/x86/16bit/reset16.ld):
+SECTIONS {
+ /* Trigger an error if I have an unuseable start address */
+ _bogus = ASSERT(_start16bit >= 0xffff0000, "_start16bit too low. Please repo
+rt.");
+ _ROMTOP = 0xfffffff0;
+ . = _ROMTOP;
+ .reset . : {
+ *(.reset);
+ . = 15;
+ BYTE(0x00);
+ }
+}
+
+ Now the BIOS starts. After initializing and checking the hardware, the
+ BIOS needs to find a bootable device. A boot order is stored in the
+ BIOS configuration, controlling which devices the BIOS attempts to boot
+ from. When attempting to boot from a hard drive, the BIOS tries to find
+ a boot sector. On hard drives partitioned with an [112]MBR partition
+ layout, the boot sector is stored in the first 446 bytes of the first
+ sector, where each sector is 512 bytes. The final two bytes of the
+ first sector are 0x55 and 0xaa, which designates to the BIOS that this
+ device is bootable.
+
+ For example:
+;
+; Note: this example is written in Intel Assembly syntax
+;
+[BITS 16]
+
+boot:
+ mov al, '!'
+ mov ah, 0x0e
+ mov bh, 0x00
+ mov bl, 0x07
+
+ int 0x10
+ jmp $
+
+times 510-($-$$) db 0
+
+db 0x55
+db 0xaa
+
+ Build and run this with:
+nasm -f bin boot.nasm && qemu-system-x86_64 boot
+
+ This will instruct [113]QEMU to use the boot binary that we just built
+ as a disk image. Since the binary generated by the assembly code above
+ fulfills the requirements of the boot sector (the origin is set to
+ 0x7c00 and we end it with the magic sequence), QEMU will treat the
+ binary as the master boot record (MBR) of a disk image.
+
+ You will see:
+
+ Simple bootloader which prints only `!`
+
+ In this example, we can see that the code will be executed in 16-bit
+ real mode and will start at 0x7c00 in memory. After starting, it calls
+ the [114]0x10 interrupt, which just prints the ! symbol. It fills the
+ remaining 510 bytes with zeros and finishes with the two magic bytes
+ 0xaa and 0x55.
+
+ You can see a binary dump of this using the objdump utility:
+nasm -f bin boot.nasm
+objdump -D -b binary -mi386 -Maddr16,data16,intel boot
+
+ A real-world boot sector has code for continuing the boot process and a
+ partition table instead of a bunch of 0's and an exclamation mark. :)
+ From this point onwards, the BIOS hands control over to the bootloader.
+
+ NOTE: As explained above, the CPU is in real mode. In real mode,
+ calculating the physical address in memory is done as follows:
+PhysicalAddress = Segment Selector * 16 + Offset
+
+ just as explained above. We have only 16-bit general purpose registers,
+ which has a maximum value of 0xffff, so if we take the largest values
+ the result will be:
+>>> hex((0xffff * 16) + 0xffff)
+'0x10ffef'
+
+ where 0x10ffef is equal to 1MB + 64KB - 16b. An [115]8086 processor
+ (which was the first processor with real mode), in contrast, has a
+ 20-bit address line. Since 2^20 = 1048576 is 1MB, this means that the
+ actual available memory is 1MB.
+
+ In general, real mode's memory map is as follows:
+0x00000000 - 0x000003FF - Real Mode Interrupt Vector Table
+0x00000400 - 0x000004FF - BIOS Data Area
+0x00000500 - 0x00007BFF - Unused
+0x00007C00 - 0x00007DFF - Our Bootloader
+0x00007E00 - 0x0009FFFF - Unused
+0x000A0000 - 0x000BFFFF - Video RAM (VRAM) Memory
+0x000B0000 - 0x000B7777 - Monochrome Video Memory
+0x000B8000 - 0x000BFFFF - Color Video Memory
+0x000C0000 - 0x000C7FFF - Video ROM BIOS
+0x000C8000 - 0x000EFFFF - BIOS Shadow Area
+0x000F0000 - 0x000FFFFF - System BIOS
+
+ At the beginning of this post, I wrote that the first instruction
+ executed by the CPU is located at address 0xFFFFFFF0, which is much
+ larger than 0xFFFFF (1MB). How can the CPU access this address in real
+ mode? The answer is in the [116]coreboot documentation:
+0xFFFE_0000 - 0xFFFF_FFFF: 128 kilobyte ROM mapped into address space
+
+ At the start of execution, the BIOS is not in RAM, but in ROM.
+
+Bootloader
+
+ There are a number of bootloaders that can boot Linux, such as
+ [117]GRUB 2 and [118]syslinux. The Linux kernel has a [119]Boot
+ protocol which specifies the requirements for a bootloader to implement
+ Linux support. This example will describe GRUB 2.
+
+ Continuing from before, now that the BIOS has chosen a boot device and
+ transferred control to the boot sector code, execution starts from
+ [120]boot.img. Its code is very simple, due to the limited amount of
+ space available. It contains a pointer which is used to jump to the
+ location of GRUB 2's core image. The core image begins with
+ [121]diskboot.img, which is usually stored immediately after the first
+ sector in the unused space before the first partition. The above code
+ loads the rest of the core image, which contains GRUB 2's kernel and
+ drivers for handling filesystems, into memory. After loading the rest
+ of the core image, it executes the [122]grub_main function.
+
+ The grub_main function initializes the console, gets the base address
+ for modules, sets the root device, loads/parses the grub configuration
+ file, loads modules, etc. At the end of execution, the grub_main
+ function moves grub to normal mode. The grub_normal_execute function
+ (from the grub-core/normal/main.c source code file) completes the final
+ preparations and shows a menu to select an operating system. When we
+ select one of the grub menu entries, the grub_menu_execute_entry
+ function runs, executing the grub boot command and booting the selected
+ operating system.
+
+ As we can read in the kernel boot protocol, the bootloader must read
+ and fill some fields of the kernel setup header, which starts at offset
+ 0x01f1 from the kernel setup code. You may look at the boot [123]linker
+ script to confirm the value of this offset. The kernel header
+ [124]arch/x86/boot/header.S starts from:
+ .globl hdr
+hdr:
+ setup_sects: .byte 0
+ root_flags: .word ROOT_RDONLY
+ syssize: .long 0
+ ram_size: .word 0
+ vid_mode: .word SVGA_MODE
+ root_dev: .word 0
+ boot_flag: .word 0xAA55
+
+ The bootloader must fill this and the rest of the headers (which are
+ only marked as being type write in the Linux boot protocol, such as in
+ [125]this example) with values either received from the command line or
+ calculated during booting. (We will not go over full descriptions and
+ explanations for all fields of the kernel setup header for now, but we
+ shall do so when discussing how the kernel uses them. You can find a
+ description of all fields in the [126]boot protocol.)
+
+ As we can see in the kernel boot protocol, memory will be mapped as
+ follows after loading the kernel:
+ | Protected-mode kernel |
+100000 +------------------------+
+ | I/O memory hole |
+0A0000 +------------------------+
+ | Reserved for BIOS | Leave as much as possible unused
+ ~ ~
+ | Command line | (Can also be below the X+10000 mark)
+X+10000 +------------------------+
+ | Stack/heap | For use by the kernel real-mode code.
+X+08000 +------------------------+
+ | Kernel setup | The kernel real-mode code.
+ | Kernel boot sector | The kernel legacy boot sector.
+ X +------------------------+
+ | Boot loader | <- Boot sector entry point 0x7C00
+001000 +------------------------+
+ | Reserved for MBR/BIOS |
+000800 +------------------------+
+ | Typically used by MBR |
+000600 +------------------------+
+ | BIOS use only |
+000000 +------------------------+
+
+ When the bootloader transfers control to the kernel, it starts at:
+X + sizeof(KernelBootSector) + 1
+
+ where X is the address of the kernel boot sector being loaded. In my
+ case, X is 0x10000, as we can see in a memory dump:
+
+ kernel first address
+
+ The bootloader has now loaded the Linux kernel into memory, filled the
+ header fields, and then jumped to the corresponding memory address. We
+ now move directly to the kernel setup code.
+
+The Beginning of the Kernel Setup Stage
+
+ Finally, we are in the kernel! Technically, the kernel hasn't run yet.
+ First, the kernel setup part must configure stuff such as the
+ decompressor and some memory management related things, to name a few.
+ After all these things are done, the kernel setup part will decompress
+ the actual kernel and jump to it. Execution of the setup part starts
+ from [127]arch/x86/boot/header.S at the [128]_start symbol.
+
+ It may look a bit strange at first sight, as there are several
+ instructions before it. A long time ago, the Linux kernel had its own
+ bootloader. Now, however, if you run, for example,
+qemu-system-x86_64 vmlinuz-3.18-generic
+
+ then you will see:
+
+ Try vmlinuz in qemu
+
+ Actually, the file header.S starts with the magic number [129]MZ (see
+ image above), the error message that displays and, following that, the
+ [130]PE header:
+#ifdef CONFIG_EFI_STUB
+# "MZ", MS-DOS header
+.byte 0x4d
+.byte 0x5a
+#endif
+...
+...
+...
+pe_header:
+ .ascii "PE"
+ .word 0
+
+ It needs this to load an operating system with [131]UEFI support. We
+ won't be looking into its inner workings right now but will cover it in
+ upcoming chapters.
+
+ The actual kernel setup entry point is:
+// header.S line 292
+.globl _start
+_start:
+
+ The bootloader (GRUB 2 and others) knows about this point (at an offset
+ of 0x200 from MZ) and jumps directly to it, despite the fact that
+ header.S starts from the .bstext section, which prints an error
+ message:
+//
+// arch/x86/boot/setup.ld
+//
+. = 0; // current position
+.bstext : { *(.bstext) } // put .bstext section to position 0
+.bsdata : { *(.bsdata) }
+
+ The kernel setup entry point is:
+ .globl _start
+_start:
+ .byte 0xeb
+ .byte start_of_setup-1f
+1:
+ //
+ // rest of the header
+ //
+
+ Here we can see a jmp instruction opcode (0xeb) that jumps to the
+ start_of_setup-1f point. In Nf notation, 2f, for example, refers to the
+ local label 2:. In our case, it's label 1: that is present right after
+ the jump, and contains the rest of the setup [132]header. Right after
+ the setup header, we see the .entrytext section, which starts at the
+ start_of_setup label.
+
+ This is the first code that actually runs (aside from the previous jump
+ instructions, of course). After the kernel setup part receives control
+ from the bootloader, the first jmp instruction is located at the 0x200
+ offset from the start of the kernel real mode, i.e., after the first
+ 512 bytes. This can be seen in both the Linux kernel boot protocol and
+ the GRUB 2 source code:
+segment = grub_linux_real_target >> 4;
+state.gs = state.fs = state.es = state.ds = state.ss = segment;
+state.cs = segment + 0x20;
+
+ In my case, the kernel is loaded at the physical address 0x10000. This
+ means that segment registers have the following values after kernel
+ setup starts:
+gs = fs = es = ds = ss = 0x1000
+cs = 0x1020
+
+ After the jump to start_of_setup, the kernel needs to do the following:
+ * Make sure that all segment register values are equal
+ * Set up a correct stack, if needed
+ * Set up [133]bss
+ * Jump to the C code in [134]arch/x86/boot/main.c
+
+ Let's look at the implementation.
+
+Aligning the Segment Registers
+
+ First of all, the kernel ensures that the ds and es segment registers
+ point to the same address. Next, it clears the direction flag using the
+ cld instruction:
+ movw %ds, %ax
+ movw %ax, %es
+ cld
+
+ As I wrote earlier, grub2 loads kernel setup code at address 0x10000 by
+ default and cs at 0x1020 because execution doesn't start from the start
+ of the file, but from the jump here:
+_start:
+ .byte 0xeb
+ .byte start_of_setup-1f
+
+ which is at a 512 byte offset from [135]4d 5a. We also need to align cs
+ from 0x1020 to 0x1000, as well as all other segment registers. After
+ that, we set up the stack:
+ pushw %ds
+ pushw $6f
+ lretw
+
+ which pushes the value of ds to the stack, followed by the address of
+ the [136]6 label and executes the lretw instruction. When the lretw
+ instruction is called, it loads the address of label 6 into the
+ [137]instruction pointer register and loads cs with the value of ds.
+ Afterward, ds and cs will have the same values.
+
+Stack Setup
+
+ Almost all of the setup code is for preparing the C language
+ environment in real mode. The next [138]step is checking the ss
+ register's value and setting up a correct stack if ss is wrong:
+ movw %ss, %dx
+ cmpw %ax, %dx
+ movw %sp, %dx
+ je 2f
+
+ This can lead to 3 different scenarios:
+ * ss has a valid value 0x1000 (as do all the other segment registers
+ besides cs)
+ * ss is invalid and the CAN_USE_HEAP flag is set (see below)
+ * ss is invalid and the CAN_USE_HEAP flag is not set (see below)
+
+ Let's look at all three of these scenarios in turn:
+ * ss has a correct address (0x1000). In this case, we go to label
+ [139]2:
+
+2: andw $~3, %dx
+ jnz 3f
+ movw $0xfffc, %dx
+3: movw %ax, %ss
+ movzwl %dx, %esp
+ sti
+
+ Here we set the alignment of dx (which contains the value of sp as
+ given by the bootloader) to 4 bytes and check if it is zero. If it is,
+ we set dx to 0xfffc (The last 4-byte aligned address in a 64KB
+ segment). If it is not zero, we continue to use the value of sp given
+ by the bootloader (0xf7f4 in my case). Afterwards, we put the value of
+ ax (0x1000) into ss. We now have a correct stack:
+
+ stack
+ * The second scenario, (ss != ds). First, we put the value of
+ [140]_end (the address of the end of the setup code) into dx and
+ check the loadflags header field using the testb instruction to see
+ whether we can use the heap. [141]loadflags is a bitmask header
+ defined as:
+
+#define LOADED_HIGH (1<<0)
+#define QUIET_FLAG (1<<5)
+#define KEEP_SEGMENTS (1<<6)
+#define CAN_USE_HEAP (1<<7)
+
+ and as we can read in the boot protocol:
+Field name: loadflags
+
+ This field is a bitmask.
+
+ Bit 7 (write): CAN_USE_HEAP
+ Set this bit to 1 to indicate that the value entered in the
+ heap_end_ptr is valid. If this field is clear, some setup code
+ functionality will be disabled.
+
+ If the CAN_USE_HEAP bit is set, we put heap_end_ptr into dx (which
+ points to _end) and add STACK_SIZE (the minimum stack size, 1024 bytes)
+ to it. After this, if dx is not carried (it will not be carried, dx =
+ _end + 1024), jump to label 2 (as in the previous case) and make a
+ correct stack.
+
+ stack
+ * When CAN_USE_HEAP is not set, we just use a minimal stack from _end
+ to _end + STACK_SIZE:
+
+ minimal stack
+
+BSS Setup
+
+ The last two steps that need to happen before we can jump to the main C
+ code are setting up the [142]BSS area and checking the "magic"
+ signature. First, signature checking:
+ cmpl $0x5a5aaa55, setup_sig
+ jne setup_bad
+
+ This simply compares the [143]setup_sig with the magic number
+ 0x5a5aaa55. If they are not equal, a fatal error is reported.
+
+ If the magic number matches, knowing we have a set of correct segment
+ registers and a stack, we only need to set up the BSS section before
+ jumping into the C code.
+
+ The BSS section is used to store statically allocated, uninitialized
+ data. Linux carefully ensures this area of memory is first zeroed using
+ the following code:
+ movw $__bss_start, %di
+ movw $_end+3, %cx
+ xorl %eax, %eax
+ subw %di, %cx
+ shrw $2, %cx
+ rep; stosl
+
+ First, the [144]__bss_start address is moved into di. Next, the _end +
+ 3 address (+3 - aligns to 4 bytes) is moved into cx. The eax register
+ is cleared (using the xor instruction), and the bss section size (cx -
+ di) is calculated and put into cx. Then, cx is divided by four (the
+ size of a 'word'), and the stosl instruction is used repeatedly,
+ storing the value of eax (zero) into the address pointed to by di,
+ automatically increasing di by four, repeating until cx reaches zero.
+ The net effect of this code is that zeros are written through all words
+ in memory from __bss_start to _end:
+
+ bss
+
+Jump to main
+
+ That's all! We have the stack and BSS, so we can jump to the main() C
+ function:
+ calll main
+
+ The main() function is located in [145]arch/x86/boot/main.c. You can
+ read about what this does in the next part.
+
+Conclusion
+
+ This is the end of the first part about Linux kernel insides. If you
+ have questions or suggestions, ping me on Twitter [146]0xAX, drop me an
+ [147]email, or just create an [148]issue. In the next part, we will see
+ the first C code that executes in the Linux kernel setup, the
+ implementation of memory routines such as memset, memcpy, earlyprintk,
+ early console implementation and initialization, and much more.
+
+ Please note that English is not my first language and I am really sorry
+ for any inconvenience. If you find any mistakes please send me PR to
+ [149]linux-insides.
+
+Links
+
+ * [150]Intel 80386 programmer's reference manual 1986
+ * [151]Minimal Boot Loader for Intel® Architecture
+ * [152]Minimal Boot Loader in Assembler with comments
+ * [153]8086
+ * [154]80386
+ * [155]Reset vector
+ * [156]Real mode
+ * [157]Linux kernel boot protocol
+ * [158]coreboot developer manual
+ * [159]Ralf Brown's Interrupt List
+ * [160]Power supply
+ * [161]Power good signal
+
+results matching ""
+
+No results matching ""
+
+References
+
+ Visible links:
+ 1. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 2. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/
+ 3. https://archive.org/includes/donate.php?as_page=1&platform=wb&referer=https%3A//web.archive.org/web/20230308144716/https%3A//0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 4. https://web.archive.org/web/
+ 5. https://web.archive.org/web/20230308144716*/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 6. https://web.archive.org/web/20230125232251/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 7. https://web.archive.org/web/20230221231350/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 8. https://web.archive.org/web/20230322150040/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 9. https://web.archive.org/web/20220120153936/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 10. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html#expand
+ 11. https://archive.org/details/mega-002
+ 12. https://web.archive.org/web/20230308144716/https://legacy.gitbook.com/book/0xax/linux-insides
+ 13. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/
+ 14. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/
+ 15. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 16. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 17. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-3.html
+ 18. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-4.html
+ 19. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-5.html
+ 20. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-6.html
+ 21. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/
+ 22. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-1.html
+ 23. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-2.html
+ 24. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-3.html
+ 25. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-4.html
+ 26. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-5.html
+ 27. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-6.html
+ 28. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-7.html
+ 29. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-8.html
+ 30. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-9.html
+ 31. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-10.html
+ 32. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/
+ 33. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-1.html
+ 34. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-2.html
+ 35. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-3.html
+ 36. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-4.html
+ 37. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-5.html
+ 38. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-6.html
+ 39. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-7.html
+ 40. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-8.html
+ 41. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-9.html
+ 42. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-10.html
+ 43. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SysCall/
+ 44. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-1.html
+ 45. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-2.html
+ 46. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-3.html
+ 47. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-4.html
+ 48. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-5.html
+ 49. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-6.html
+ 50. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/
+ 51. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-1.html
+ 52. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-2.html
+ 53. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-3.html
+ 54. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-4.html
+ 55. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-5.html
+ 56. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-6.html
+ 57. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-7.html
+ 58. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/
+ 59. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-1.html
+ 60. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-2.html
+ 61. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-3.html
+ 62. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-4.html
+ 63. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-5.html
+ 64. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-6.html
+ 65. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/MM/
+ 66. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/MM/linux-mm-1.html
+ 67. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/MM/linux-mm-2.html
+ 68. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/MM/linux-mm-3.html
+ 69. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Cgroups/
+ 70. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Cgroups/linux-cgroups-1.html
+ 71. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Concepts/
+ 72. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-1.html
+ 73. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-2.html
+ 74. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-3.html
+ 75. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-4.html
+ 76. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/DataStructures/
+ 77. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/DataStructures/linux-datastructures-1.html
+ 78. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/DataStructures/linux-datastructures-2.html
+ 79. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/DataStructures/linux-datastructures-3.html
+ 80. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Theory/
+ 81. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-1.html
+ 82. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-2.html
+ 83. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-3.html
+ 84. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Misc/
+ 85. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-1.html
+ 86. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-2.html
+ 87. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-3.html
+ 88. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-4.html
+ 89. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/KernelStructures/
+ 90. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/KernelStructures/linux-kernelstructure-1.html
+ 91. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/LINKS.html
+ 92. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/contributors.html
+ 93. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/
+ 94. https://web.archive.org/web/20230308144716/https://0xax.github.io/categories/assembler/
+ 95. https://web.archive.org/web/20230308144716/https://twitter.com/0xAX
+ 96. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/anotherworldofworld@gmail.com
+ 97. https://web.archive.org/web/20230308144716/https://github.com/0xAX/linux-insides/issues/new
+ 98. https://web.archive.org/web/20230308144716/https://github.com/0xAX/linux-insides
+ 99. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Power_supply
+ 100. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Power_good_signal
+ 101. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Intel_80386
+ 102. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Real_mode
+ 103. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Memory_segmentation
+ 104. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Intel_8086
+ 105. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Memory_segmentation
+ 106. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/A20_line
+ 107. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Reset_vector
+ 108. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/JMP_%28x86_instruction%29
+ 109. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/BIOS
+ 110. https://web.archive.org/web/20230308144716/https://www.coreboot.org/
+ 111. https://web.archive.org/web/20230308144716/http://ref.x86asm.net/coder32.html#xE9
+ 112. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Master_boot_record
+ 113. https://web.archive.org/web/20230308144716/https://www.qemu.org/
+ 114. https://web.archive.org/web/20230308144716/http://www.ctyme.com/intr/rb-0106.htm
+ 115. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Intel_8086
+ 116. https://web.archive.org/web/20230308144716/https://www.coreboot.org/Developer_Manual/Memory_map
+ 117. https://web.archive.org/web/20230308144716/https://www.gnu.org/software/grub/
+ 118. https://web.archive.org/web/20230308144716/http://www.syslinux.org/wiki/index.php/The_Syslinux_Project
+ 119. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/Documentation/x86/boot.txt
+ 120. https://web.archive.org/web/20230308144716/http://git.savannah.gnu.org/gitweb/?p=grub.git;a=blob;f=grub-core/boot/i386/pc/boot.S;hb=HEAD
+ 121. https://web.archive.org/web/20230308144716/http://git.savannah.gnu.org/gitweb/?p=grub.git;a=blob;f=grub-core/boot/i386/pc/diskboot.S;hb=HEAD
+ 122. https://web.archive.org/web/20230308144716/http://git.savannah.gnu.org/gitweb/?p=grub.git;a=blob;f=grub-core/kern/main.c
+ 123. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/setup.ld
+ 124. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S
+ 125. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/Documentation/x86/boot.txt#L354
+ 126. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/Documentation/x86/boot.txt#L156
+ 127. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S
+ 128. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L292
+ 129. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/DOS_MZ_executable
+ 130. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Portable_Executable
+ 131. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
+ 132. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/Documentation/x86/boot.txt#L156
+ 133. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/.bss
+ 134. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 135. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L46
+ 136. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L602
+ 137. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Program_counter
+ 138. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L575
+ 139. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L589
+ 140. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/setup.ld
+ 141. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L320
+ 142. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/.bss
+ 143. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/setup.ld
+ 144. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/setup.ld
+ 145. https://web.archive.org/web/20230308144716/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 146. https://web.archive.org/web/20230308144716/https://twitter.com/0xAX
+ 147. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/anotherworldofworld@gmail.com
+ 148. https://web.archive.org/web/20230308144716/https://github.com/0xAX/linux-internals/issues/new
+ 149. https://web.archive.org/web/20230308144716/https://github.com/0xAX/linux-internals
+ 150. https://web.archive.org/web/20230308144716/http://css.csail.mit.edu/6.858/2014/readings/i386.pdf
+ 151. https://web.archive.org/web/20230308144716/https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf
+ 152. https://web.archive.org/web/20230308144716/https://github.com/Stefan20162016/linux-insides-code/blob/master/bootloader.asm
+ 153. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Intel_8086
+ 154. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Intel_80386
+ 155. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Reset_vector
+ 156. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Real_mode
+ 157. https://web.archive.org/web/20230308144716/https://www.kernel.org/doc/Documentation/x86/boot.txt
+ 158. https://web.archive.org/web/20230308144716/https://www.coreboot.org/Developer_Manual
+ 159. https://web.archive.org/web/20230308144716/http://www.ctyme.com/intr/int.htm
+ 160. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Power_supply
+ 161. https://web.archive.org/web/20230308144716/https://en.wikipedia.org/wiki/Power_good_signal
+
+ Hidden links:
+ 163. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 164. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 165. https://archive.org/account/login.php
+ 166. http://faq.web.archive.org/
+ 167. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html#close
+ 168. https://web.archive.org/web/20230308144716/http://web.archive.org/screenshot/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 169. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 170. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 171. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 172. https://web.archive.org/web/20230308144716/https://www.gitbook.com/?utm_source=public_site_legacy&utm_medium=referral&utm_campaign=trademark&utm_term=0xax&utm_content=powered_by
+ 173. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/
+ 174. https://web.archive.org/web/20230308144716/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
diff --git a/doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-2.txt b/doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-2.txt
new file mode 100644
index 0000000..c0663b3
--- /dev/null
+++ b/doc/doc/0xax.gitbooks.io_linux-insides_content_Booting_linux-bootstrap-2.txt
@@ -0,0 +1,937 @@
+ #[1]next [2]prev
+
+ IFRAME:
+ [3]https://archive.org/includes/donate.php?as_page=1&platform=wb&refere
+ r=https%3A//web.archive.org/web/20230308144724/https%3A//0xax.gitbooks.
+ io/linux-insides/content/Booting/linux-bootstrap-2.html
+
+ [4]Wayback Machine
+ https://0xax.gitbook Go
+ [5]47 captures
+ 02 Feb 2015 - 22 Mar 2023
+ [6]Dec MAR Apr
+ [7]Previous capture 08 [8]Next capture
+ [9]2022 2023 2024
+ success
+ fail
+ [10]About this capture
+ COLLECTED BY
+ Collection: [11]mega002
+ TIMESTAMPS
+ loading
+
+ The Wayback Machine -
+ https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/lin
+ ux-insides/content/Booting/linux-bootstrap-2.html
+
+ ____________________
+
+ * [12]Linux Inside
+ *
+ * Summary
+ * [13]Introduction
+ * [14]Booting
+ + [15]From bootloader to kernel
+ + [16]First steps in the kernel setup code
+ + [17]Video mode initialization and transition to protected mode
+ + [18]Transition to 64-bit mode
+ + [19]Kernel decompression
+ + [20]Kernel load address randomization
+ * [21]Initialization
+ + [22]First steps in the kernel
+ + [23]Early interrupts handler
+ + [24]Last preparations before the kernel entry point
+ + [25]Kernel entry point
+ + [26]Continue architecture-specific boot-time initializations
+ + [27]Architecture-specific initializations, again...
+ + [28]End of the architecture-specific initializations,
+ almost...
+ + [29]Scheduler initialization
+ + [30]RCU initialization
+ + [31]End of initialization
+ * [32]Interrupts
+ + [33]Introduction
+ + [34]Start to dive into interrupts
+ + [35]Interrupt handlers
+ + [36]Initialization of non-early interrupt gates
+ + [37]Implementation of some exception handlers
+ + [38]Handling Non-Maskable interrupts
+ + [39]Dive into external hardware interrupts
+ + [40]Initialization of external hardware interrupts structures
+ + [41]Softirq, Tasklets and Workqueues
+ + [42]Last part
+ * [43]System calls
+ + [44]Introduction to system calls
+ + [45]How the Linux kernel handles a system call
+ + [46]vsyscall and vDSO
+ + [47]How the Linux kernel runs a program
+ + [48]Implementation of the open system call
+ + [49]Limits on resources in Linux
+ * [50]Timers and time management
+ + [51]Introduction
+ + [52]Clocksource framework
+ + [53]The tick broadcast framework and dyntick
+ + [54]Introduction to timers
+ + [55]Clockevents framework
+ + [56]x86 related clock sources
+ + [57]Time related system calls
+ * [58]Synchronization primitives
+ + [59]Introduction to spinlocks
+ + [60]Queued spinlocks
+ + [61]Semaphores
+ + [62]Mutex
+ + [63]Reader/Writer semaphores
+ + [64]SeqLock
+ + RCU
+ + Lockdep
+ * [65]Memory management
+ + [66]Memblock
+ + [67]Fixmaps and ioremap
+ + [68]kmemcheck
+ * [69]Cgroups
+ + [70]Introduction to Control Groups
+ * SMP
+ * [71]Concepts
+ + [72]Per-CPU variables
+ + [73]Cpumasks
+ + [74]The initcall mechanism
+ + [75]Notification Chains
+ * [76]Data Structures in the Linux Kernel
+ + [77]Doubly linked list
+ + [78]Radix tree
+ + [79]Bit arrays
+ * [80]Theory
+ + [81]Paging
+ + [82]Elf64
+ + [83]Inline assembly
+ + CPUID
+ + MSR
+ * Initial ram disk
+ + initrd
+ * [84]Misc
+ + [85]Linux kernel development
+ + [86]How the kernel is compiled
+ + [87]Linkers
+ + [88]Program startup process in userspace
+ + Write and Submit your first Linux kernel Patch
+ + Data types in the kernel
+ * [89]KernelStructures
+ + [90]IDT
+ * [91]Useful links
+ * [92]Contributors
+ *
+
+ Powered by GitBook
+
+[93]First steps in the kernel setup code
+
+Kernel booting process. Part 2.
+
+First steps in the kernel setup
+
+ We started to dive into the linux kernel's insides in the previous
+ [94]part and saw the initial part of the kernel setup code. We stopped
+ at the first call to the main function (which is the first function
+ written in C) from [95]arch/x86/boot/main.c.
+
+ In this part, we will continue to research the kernel setup code and go
+ over
+ * what protected mode is,
+ * the transition into it,
+ * the initialization of the heap and the console,
+ * memory detection, CPU validation and keyboard initialization
+ * and much much more.
+
+ So, let's go ahead.
+
+Protected mode
+
+ Before we can move to the native Intel64 [96]Long Mode, the kernel must
+ switch the CPU into protected mode.
+
+ What is [97]protected mode? Protected mode was first added to the x86
+ architecture in 1982 and was the main mode of Intel processors from the
+ [98]80286 processor until Intel 64 and long mode came.
+
+ The main reason to move away from [99]Real mode is that there is very
+ limited access to the RAM. As you may remember from the previous part,
+ there are only 2^20 bytes or 1 Megabyte, sometimes even only 640
+ Kilobytes of RAM available in Real mode.
+
+ Protected mode brought many changes, but the main one is the difference
+ in memory management. The 20-bit address bus was replaced with a 32-bit
+ address bus. It allowed access to 4 Gigabytes of memory vs the 1
+ Megabyte in Real mode. Also, [100]paging support was added, which you
+ can read about in the next sections.
+
+ Memory management in Protected mode is divided into two, almost
+ independent parts:
+ * Segmentation
+ * Paging
+
+ Here we will only talk about segmentation. Paging will be discussed in
+ the next sections.
+
+ As you can read in the previous part, addresses consist of two parts in
+ Real mode:
+ * Base address of the segment
+ * Offset from the segment base
+
+ And we can get the physical address if we know these two parts by:
+PhysicalAddress = Segment Base * 16 + Offset
+
+ Memory segmentation was completely redone in protected mode. There are
+ no 64 Kilobyte fixed-size segments. Instead, the size and location of
+ each segment is described by an associated data structure called the
+ Segment Descriptor. These segment descriptors are stored in a data
+ structure called the Global Descriptor Table (GDT).
+
+ The GDT is a structure which resides in memory. It has no fixed place
+ in the memory, so its address is stored in the special GDTR register.
+ Later we will see how the GDT is loaded in the Linux kernel code. There
+ will be an operation for loading it from memory, something like:
+lgdt gdt
+
+ where the lgdt instruction loads the base address and limit(size) of
+ the global descriptor table to the GDTR register. GDTR is a 48-bit
+ register and consists of two parts:
+ * the size(16-bit) of the global descriptor table;
+ * the address(32-bit) of the global descriptor table.
+
+ As mentioned above, the GDT contains segment descriptors which describe
+ memory segments. Each descriptor is 64-bits in size. The general scheme
+ of a descriptor is:
+ 63 56 51 48 45 39 32
+------------------------------------------------------------
+| | |B| |A| | | | |0|E|W|A| |
+| BASE 31:24 |G|/|L|V| LIMIT |P|DPL|S| TYPE | BASE 23:16 |
+| | |D| |L| 19:16 | | | |1|C|R|A| |
+------------------------------------------------------------
+
+ 31 16 15 0
+------------------------------------------------------------
+| | |
+| BASE 15:0 | LIMIT 15:0 |
+| | |
+------------------------------------------------------------
+
+ Don't worry, I know it looks a little scary after Real mode, but it's
+ easy. For example LIMIT 15:0 means that bits 0-15 of the segment limit
+ are located at the beginning of the Descriptor. The rest of it is in
+ LIMIT 19:16, which is located at bits 48-51 of the Descriptor. So, the
+ size of Limit is 0-19 i.e 20-bits. Let's take a closer look at it:
+ 1. Limit[20-bits] is split between bits 0-15 and 48-51. It defines the
+ length_of_segment - 1. It depends on the G(Granularity) bit.
+ + if G (bit 55) is 0 and the segment limit is 0, the size of the
+ segment is 1 Byte
+ + if G is 1 and the segment limit is 0, the size of the segment
+ is 4096 Bytes
+ + if G is 0 and the segment limit is 0xfffff, the size of the
+ segment is 1 Megabyte
+ + if G is 1 and the segment limit is 0xfffff, the size of the
+ segment is 4 Gigabytes
+ So, what this means is
+ + if G is 0, Limit is interpreted in terms of 1 Byte and the
+ maximum size of the segment can be 1 Megabyte.
+ + if G is 1, Limit is interpreted in terms of 4096 Bytes = 4
+ KBytes = 1 Page and the maximum size of the segment can be 4
+ Gigabytes. Actually, when G is 1, the value of Limit is
+ shifted to the left by 12 bits. So, 20 bits + 12 bits = 32
+ bits and 2^32 = 4 Gigabytes.
+ 2. Base[32-bits] is split between bits 16-31, 32-39 and 56-63. It
+ defines the physical address of the segment's starting location.
+ 3. Type/Attribute[5-bits] is represented by bits 40-44. It defines the
+ type of segment and how it can be accessed.
+ + The S flag at bit 44 specifies the descriptor type. If S is 0
+ then this segment is a system segment, whereas if S is 1 then
+ this is a code or data segment (Stack segments are data
+ segments which must be read/write segments).
+
+ To determine if the segment is a code or data segment, we can check its
+ Ex(bit 43) Attribute (marked as 0 in the above diagram). If it is 0,
+ then the segment is a Data segment, otherwise, it is a code segment.
+
+ A segment can be of one of the following types:
+--------------------------------------------------------------------------------
+------
+| Type Field | Descriptor Type | Description
+ |
+|-----------------------------|-----------------|-------------------------------
+-----|
+| Decimal | |
+ |
+| 0 E W A | |
+ |
+| 0 0 0 0 0 | Data | Read-Only
+ |
+| 1 0 0 0 1 | Data | Read-Only, accessed
+ |
+| 2 0 0 1 0 | Data | Read/Write
+ |
+| 3 0 0 1 1 | Data | Read/Write, accessed
+ |
+| 4 0 1 0 0 | Data | Read-Only, expand-down
+ |
+| 5 0 1 0 1 | Data | Read-Only, expand-down, access
+ed |
+| 6 0 1 1 0 | Data | Read/Write, expand-down
+ |
+| 7 0 1 1 1 | Data | Read/Write, expand-down, acces
+sed |
+| C R A | |
+ |
+| 8 1 0 0 0 | Code | Execute-Only
+ |
+| 9 1 0 0 1 | Code | Execute-Only, accessed
+ |
+| 10 1 0 1 0 | Code | Execute/Read
+ |
+| 11 1 0 1 1 | Code | Execute/Read, accessed
+ |
+| 12 1 1 0 0 | Code | Execute-Only, conforming
+ |
+| 14 1 1 0 1 | Code | Execute-Only, conforming, acce
+ssed |
+| 13 1 1 1 0 | Code | Execute/Read, conforming
+ |
+| 15 1 1 1 1 | Code | Execute/Read, conforming, acce
+ssed |
+--------------------------------------------------------------------------------
+------
+
+ As we can see the first bit(bit 43) is 0 for a data segment and 1 for a
+ code segment. The next three bits (40, 41, 42) are either EWA(Expansion
+ Writable Accessible) or CRA(Conforming Readable Accessible).
+ * if E(bit 42) is 0, expand up, otherwise, expand down. Read more
+ [101]here.
+ * if W(bit 41)(for Data Segments) is 1, write access is allowed, and
+ if it is 0, the segment is read-only. Note that read access is
+ always allowed on data segments.
+ * A(bit 40) controls whether the segment can be accessed by the
+ processor or not.
+ * C(bit 43) is the conforming bit(for code selectors). If C is 1, the
+ segment code can be executed from a lower level privilege (e.g.
+ user) level. If C is 0, it can only be executed from the same
+ privilege level.
+ * R(bit 41) controls read access to code segments; when it is 1, the
+ segment can be read from. Write access is never granted for code
+ segments.
+
+ 1. DPL[2-bits] (Descriptor Privilege Level) comprises the bits 45-46.
+ It defines the privilege level of the segment. It can be 0-3 where
+ 0 is the most privileged level.
+ 2. The P flag(bit 47) indicates if the segment is present in memory or
+ not. If P is 0, the segment will be presented as invalid and the
+ processor will refuse to read from this segment.
+ 3. AVL flag(bit 52) - Available and reserved bits. It is ignored in
+ Linux.
+ 4. The L flag(bit 53) indicates whether a code segment contains native
+ 64-bit code. If it is set, then the code segment executes in 64-bit
+ mode.
+ 5. The D/B flag(bit 54) (Default/Big flag) represents the operand size
+ i.e 16/32 bits. If set, operand size is 32 bits. Otherwise, it is
+ 16 bits.
+
+ Segment registers contain segment selectors as in real mode. However,
+ in protected mode, a segment selector is handled differently. Each
+ Segment Descriptor has an associated Segment Selector which is a 16-bit
+ structure:
+ 15 3 2 1 0
+-----------------------------
+| Index | TI | RPL |
+-----------------------------
+
+ Where,
+ * Index stores the index number of the descriptor in the GDT.
+ * TI(Table Indicator) indicates where to search for the descriptor.
+ If it is 0 then the descriptor is searched for in the Global
+ Descriptor Table(GDT). Otherwise, it will be searched for in the
+ Local Descriptor Table(LDT).
+ * And RPL contains the Requester's Privilege Level.
+
+ Every segment register has a visible and a hidden part.
+ * Visible - The Segment Selector is stored here.
+ * Hidden - The Segment Descriptor (which contains the base, limit,
+ attributes & flags) is stored here.
+
+ The following steps are needed to get a physical address in protected
+ mode:
+ * The segment selector must be loaded in one of the segment
+ registers.
+ * The CPU tries to find a segment descriptor at the offset GDT
+ address + Index from the selector and then loads the descriptor
+ into the hidden part of the segment register.
+ * If paging is disabled, the linear address of the segment, or its
+ physical address, is given by the formula: Base address (found in
+ the descriptor obtained in the previous step) + Offset.
+
+ Schematically it will look like this:
+
+ linear address
+
+ The algorithm for the transition from real mode into protected mode is:
+ * Disable interrupts
+ * Describe and load the GDT with the lgdt instruction
+ * Set the PE (Protection Enable) bit in CR0 (Control Register 0)
+ * Jump to protected mode code
+
+ We will see the complete transition to protected mode in the linux
+ kernel in the next part, but before we can move to protected mode, we
+ need to do some more preparations.
+
+ Let's look at [102]arch/x86/boot/main.c. We can see some routines there
+ which perform keyboard initialization, heap initialization, etc...
+ Let's take a look.
+
+Copying boot parameters into the "zeropage"
+
+ We will start from the main routine in "main.c". The first function
+ which is called in main is [103]copy_boot_params(void). It copies the
+ kernel setup header into the corresponding field of the boot_params
+ structure which is defined in the
+ [104]arch/x86/include/uapi/asm/bootparam.h header file.
+
+ The boot_params structure contains the struct setup_header hdr field.
+ This structure contains the same fields as defined in the [105]linux
+ boot protocol and is filled by the boot loader and also at kernel
+ compile/build time. copy_boot_params does two things:
+ 1. It copies hdr from [106]header.S to the setup_header field in
+ boot_params structure.
+ 2. It updates the pointer to the kernel command line if the kernel was
+ loaded with the old command line protocol.
+
+ Note that it copies hdr with the memcpy function, defined in the
+ [107]copy.S source file. Let's have a look inside:
+GLOBAL(memcpy)
+ pushw %si
+ pushw %di
+ movw %ax, %di
+ movw %dx, %si
+ pushw %cx
+ shrw $2, %cx
+ rep; movsl
+ popw %cx
+ andw $3, %cx
+ rep; movsb
+ popw %di
+ popw %si
+ retl
+ENDPROC(memcpy)
+
+ Yeah, we just moved to C code and now assembly again :) First of all,
+ we can see that memcpy and other routines which are defined here, start
+ and end with the two macros: GLOBAL and ENDPROC. GLOBAL is described in
+ [108]arch/x86/include/asm/linkage.h which defines the globl directive
+ and its label. ENDPROC is described in [109]include/linux/linkage.h and
+ marks the name symbol as a function name and ends with the size of the
+ name symbol.
+
+ The implementation of memcpy is simple. At first, it pushes values from
+ the si and di registers to the stack to preserve their values because
+ they will change during the memcpy. As we can see in the
+ REALMODE_CFLAGS in arch/x86/Makefile, the kernel build system uses the
+ -mregparm=3 option of GCC, so functions get the first three parameters
+ from ax, dx and cx registers. Calling memcpy looks like this:
+memcpy(&boot_params.hdr, &hdr, sizeof hdr);
+
+ So,
+ * ax will contain the address of boot_params.hdr
+ * dx will contain the address of hdr
+ * cx will contain the size of hdr in bytes.
+
+ memcpy puts the address of boot_params.hdr into di and saves cx on the
+ stack. After this it shifts the value right 2 times (or divides it by
+ 4) and copies four bytes from the address at si to the address at di.
+ After this, we restore the size of hdr again, align it by 4 bytes and
+ copy the rest of the bytes from the address at si to the address at di
+ byte by byte (if there is more). Now the values of si and di are
+ restored from the stack and the copying operation is finished.
+
+Console initialization
+
+ After hdr is copied into boot_params.hdr, the next step is to
+ initialize the console by calling the console_init function, defined in
+ [110]arch/x86/boot/early_serial_console.c.
+
+ It tries to find the earlyprintk option in the command line and if the
+ search was successful, it parses the port address and baud rate of the
+ serial port and initializes the serial port. The value of the
+ earlyprintk command line option can be one of these:
+ * serial,0x3f8,115200
+ * serial,ttyS0,115200
+ * ttyS0,115200
+
+ After serial port initialization we can see the first output:
+if (cmdline_find_option_bool("debug"))
+ puts("early console in setup code\n");
+
+ The definition of puts is in [111]tty.c. As we can see it prints
+ character by character in a loop by calling the putchar function. Let's
+ look into the putchar implementation:
+void __attribute__((section(".inittext"))) putchar(int ch)
+{
+ if (ch == '\n')
+ putchar('\r');
+
+ bios_putchar(ch);
+
+ if (early_serial_base != 0)
+ serial_putchar(ch);
+}
+
+ __attribute__((section(".inittext"))) means that this code will be in
+ the .inittext section. We can find it in the linker file [112]setup.ld.
+
+ First of all, putchar checks for the \n symbol and if it is found,
+ prints \r before. After that it prints the character on the VGA screen
+ by calling the BIOS with the 0x10 interrupt call:
+static void __attribute__((section(".inittext"))) bios_putchar(int ch)
+{
+ struct biosregs ireg;
+
+ initregs(&ireg);
+ ireg.bx = 0x0007;
+ ireg.cx = 0x0001;
+ ireg.ah = 0x0e;
+ ireg.al = ch;
+ intcall(0x10, &ireg, NULL);
+}
+
+ Here initregs takes the biosregs structure and first fills biosregs
+ with zeros using the memset function and then fills it with register
+ values.
+ memset(reg, 0, sizeof *reg);
+ reg->eflags |= X86_EFLAGS_CF;
+ reg->ds = ds();
+ reg->es = ds();
+ reg->fs = fs();
+ reg->gs = gs();
+
+ Let's look at the implementation of [113]memset:
+GLOBAL(memset)
+ pushw %di
+ movw %ax, %di
+ movzbl %dl, %eax
+ imull $0x01010101,%eax
+ pushw %cx
+ shrw $2, %cx
+ rep; stosl
+ popw %cx
+ andw $3, %cx
+ rep; stosb
+ popw %di
+ retl
+ENDPROC(memset)
+
+ As you can read above, it uses the same calling conventions as the
+ memcpy function, which means that the function gets its parameters from
+ the ax, dx and cx registers.
+
+ The implementation of memset is similar to that of memcpy. It saves the
+ value of the di register on the stack and puts the value ofax, which
+ stores the address of the biosregs structure, into di . Next is the
+ movzbl instruction, which copies the value of dl to the lowermost byte
+ of the eax register. The remaining 3 high bytes of eax will be filled
+ with zeros.
+
+ The next instruction multiplies eax with 0x01010101. It needs to
+ because memset will copy 4 bytes at the same time. For example, if we
+ need to fill a structure whose size is 4 bytes with the value 0x7 with
+ memset, eax will contain the 0x00000007. So if we multiply eax with
+ 0x01010101, we will get 0x07070707 and now we can copy these 4 bytes
+ into the structure. memset uses the rep; stosl instruction to copy eax
+ into es:di.
+
+ The rest of the memset function does almost the same thing as memcpy.
+
+ After the biosregs structure is filled with memset, bios_putchar calls
+ the [114]0x10 interrupt which prints a character. Afterwards it checks
+ if the serial port was initialized or not and writes a character there
+ with [115]serial_putchar and inb/outb instructions if it was set.
+
+Heap initialization
+
+ After the stack and bss section have been prepared in [116]header.S
+ (see previous [117]part), the kernel needs to initialize the [118]heap
+ with the [119]init_heap function.
+
+ First of all init_heap checks the [120]CAN_USE_HEAP flag from the
+ [121]loadflags structure in the kernel setup header and calculates the
+ end of the stack if this flag was set:
+ char *stack_end;
+
+ if (boot_params.hdr.loadflags & CAN_USE_HEAP) {
+ asm("leal %P1(%%esp),%0"
+ : "=r" (stack_end) : "i" (-STACK_SIZE));
+
+ or in other words stack_end = esp - STACK_SIZE.
+
+ Then there is the heap_end calculation:
+ heap_end = (char *)((size_t)boot_params.hdr.heap_end_ptr + 0x200);
+
+ which means heap_end_ptr or _end + 512 (0x200h). The last check is
+ whether heap_end is greater than stack_end. If it is then stack_end is
+ assigned to heap_end to make them equal.
+
+ Now the heap is initialized and we can use it using the GET_HEAP
+ method. We will see what it is used for, how to use it and how it is
+ implemented in the next posts.
+
+CPU validation
+
+ The next step as we can see is cpu validation through the validate_cpu
+ function from [122]arch/x86/boot/cpu.c source code file.
+
+ It calls the [123]check_cpu function and passes cpu level and required
+ cpu level to it and checks that the kernel launches on the right cpu
+ level.
+check_cpu(&cpu_level, &req_level, &err_flags);
+if (cpu_level < req_level) {
+ ...
+ return -1;
+}
+
+ The check_cpu function checks the CPU's flags, the presence of
+ [124]long mode in the case of x86_64(64-bit) CPU, checks the
+ processor's vendor and makes preparations for certain vendors like
+ turning off SSE+SSE2 for AMD if they are missing, etc.
+
+ at the next step, we may see a call to the set_bios_mode function after
+ setup code found that a CPU is suitable. As we may see, this function
+ is implemented only for the x86_64 mode:
+static void set_bios_mode(void)
+{
+#ifdef CONFIG_X86_64
+ struct biosregs ireg;
+
+ initregs(&ireg);
+ ireg.ax = 0xec00;
+ ireg.bx = 2;
+ intcall(0x15, &ireg, NULL);
+#endif
+}
+
+ The set_bios_mode function executes the 0x15 BIOS interrupt to tell the
+ BIOS that [125]long mode (if bx == 2) will be used.
+
+Memory detection
+
+ The next step is memory detection through the detect_memory function.
+ detect_memory basically provides a map of available RAM to the CPU. It
+ uses different programming interfaces for memory detection like 0xe820,
+ 0xe801 and 0x88. We will see only the implementation of the 0xE820
+ interface here.
+
+ Let's look at the implementation of the detect_memory_e820 function
+ from the [126]arch/x86/boot/memory.c source file. First of all, the
+ detect_memory_e820 function initializes the biosregs structure as we
+ saw above and fills registers with special values for the 0xe820 call:
+ initregs(&ireg);
+ ireg.ax = 0xe820;
+ ireg.cx = sizeof buf;
+ ireg.edx = SMAP;
+ ireg.di = (size_t)&buf;
+
+ * ax contains the number of the function (0xe820 in our case)
+ * cx contains the size of the buffer which will contain data about
+ the memory
+ * edx must contain the SMAP magic number
+ * es:di must contain the address of the buffer which will contain
+ memory data
+ * ebx has to be zero.
+
+ Next is a loop where data about the memory will be collected. It starts
+ with a call to the 0x15 BIOS interrupt, which writes one line from the
+ address allocation table. For getting the next line we need to call
+ this interrupt again (which we do in the loop). Before the next call
+ ebx must contain the value returned previously:
+ intcall(0x15, &ireg, &oreg);
+ ireg.ebx = oreg.ebx;
+
+ Ultimately, this function collects data from the address allocation
+ table and writes this data into the e820_entry array:
+ * start of memory segment
+ * size of memory segment
+ * type of memory segment (whether the particular segment is usable or
+ reserved)
+
+ You can see the result of this in the dmesg output, something like:
+[ 0.000000] e820: BIOS-provided physical RAM map:
+[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
+[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
+[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffdffff] usable
+[ 0.000000] BIOS-e820: [mem 0x000000003ffe0000-0x000000003fffffff] reserved
+[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
+
+Keyboard initialization
+
+ The next step is the initialization of the keyboard with a call to the
+ [127]keyboard_init function. At first keyboard_init initializes
+ registers using the initregs function. It then calls the [128]0x16
+ interrupt to query the status of the keyboard.
+ initregs(&ireg);
+ ireg.ah = 0x02; /* Get keyboard status */
+ intcall(0x16, &ireg, &oreg);
+ boot_params.kbd_status = oreg.al;
+
+ After this it calls [129]0x16 again to set the repeat rate and delay.
+ ireg.ax = 0x0305; /* Set keyboard repeat rate */
+ intcall(0x16, &ireg, NULL);
+
+Querying
+
+ The next couple of steps are queries for different parameters. We will
+ not dive into details about these queries but we will get back to them
+ in later parts. Let's take a short look at these functions:
+
+ The first step is getting [130]Intel SpeedStep information by calling
+ the query_ist function. It checks the CPU level and if it is correct,
+ calls 0x15 to get the info and saves the result to boot_params.
+
+ Next, the [131]query_apm_bios function gets [132]Advanced Power
+ Management information from the BIOS. query_apm_bios calls the 0x15
+ BIOS interruption too, but with ah = 0x53 to check APM installation.
+ After 0x15 finishes executing, the query_apm_bios functions check the
+ PM signature (it must be 0x504d), the carry flag (it must be 0 if APM
+ supported) and the value of the cx register (if it's 0x02, the
+ protected mode interface is supported).
+
+ Next, it calls 0x15 again, but with ax = 0x5304 to disconnect the APM
+ interface and connect the 32-bit protected mode interface. In the end,
+ it fills boot_params.apm_bios_info with values obtained from the BIOS.
+
+ Note that query_apm_bios will be executed only if the CONFIG_APM or
+ CONFIG_APM_MODULE compile time flag was set in the configuration file:
+#if defined(CONFIG_APM) || defined(CONFIG_APM_MODULE)
+ query_apm_bios();
+#endif
+
+ The last is the [133]query_edd function, which queries Enhanced Disk
+ Drive information from the BIOS. Let's look at how query_edd is
+ implemented.
+
+ First of all, it reads the [134]edd option from the kernel's command
+ line and if it was set to off then query_edd just returns.
+
+ If EDD is enabled, query_edd goes over BIOS-supported hard disks and
+ queries EDD information in the following loop:
+for (devno = 0x80; devno < 0x80+EDD_MBR_SIG_MAX; devno++) {
+ if (!get_edd_info(devno, &ei) && boot_params.eddbuf_entries < EDDMAXNR) {
+ memcpy(edp, &ei, sizeof ei);
+ edp++;
+ boot_params.eddbuf_entries++;
+ }
+ ...
+ ...
+ ...
+ }
+
+ where 0x80 is the first hard drive and the value of the EDD_MBR_SIG_MAX
+ macro is 16. It collects data into an array of [135]edd_info
+ structures. get_edd_info checks that EDD is present by invoking the
+ 0x13 interrupt with ah as 0x41 and if EDD is present, get_edd_info
+ again calls the 0x13 interrupt, but with ah as 0x48 and si containing
+ the address of the buffer where EDD information will be stored.
+
+Conclusion
+
+ This is the end of the second part about the insides of the Linux
+ kernel. In the next part, we will see video mode setting and the rest
+ of the preparations before the transition to protected mode and
+ directly transitioning into it.
+
+ If you have any questions or suggestions write me a comment or ping me
+ at [136]twitter.
+
+ Please note that English is not my first language, And I am really
+ sorry for any inconvenience. If you find any mistakes please send me a
+ PR to [137]linux-insides.
+
+Links
+
+ * [138]Protected mode
+ * [139]Protected mode
+ * [140]Long mode
+ * [141]Nice explanation of CPU Modes with code
+ * [142]How to Use Expand Down Segments on Intel 386 and Later CPUs
+ * [143]earlyprintk documentation
+ * [144]Kernel Parameters
+ * [145]Serial console
+ * [146]Intel SpeedStep
+ * [147]APM
+ * [148]EDD specification
+ * [149]TLDP documentation for Linux Boot Process (old)
+ * [150]Previous Part
+
+results matching ""
+
+No results matching ""
+
+References
+
+ Visible links:
+ 1. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-3.html
+ 2. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 3. https://archive.org/includes/donate.php?as_page=1&platform=wb&referer=https%3A//web.archive.org/web/20230308144724/https%3A//0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 4. https://web.archive.org/web/
+ 5. https://web.archive.org/web/20230308144724*/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 6. https://web.archive.org/web/20221206122118/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 7. https://web.archive.org/web/20221206122118/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 8. https://web.archive.org/web/20230322150041/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 9. https://web.archive.org/web/20220123200511/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 10. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html#expand
+ 11. https://archive.org/details/mega-002
+ 12. https://web.archive.org/web/20230308144724/https://legacy.gitbook.com/book/0xax/linux-insides
+ 13. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/
+ 14. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/
+ 15. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 16. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 17. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-3.html
+ 18. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-4.html
+ 19. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-5.html
+ 20. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-6.html
+ 21. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/
+ 22. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-1.html
+ 23. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-2.html
+ 24. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-3.html
+ 25. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-4.html
+ 26. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-5.html
+ 27. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-6.html
+ 28. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-7.html
+ 29. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-8.html
+ 30. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-9.html
+ 31. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Initialization/linux-initialization-10.html
+ 32. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/
+ 33. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-1.html
+ 34. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-2.html
+ 35. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-3.html
+ 36. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-4.html
+ 37. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-5.html
+ 38. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-6.html
+ 39. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-7.html
+ 40. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-8.html
+ 41. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-9.html
+ 42. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-10.html
+ 43. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SysCall/
+ 44. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-1.html
+ 45. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-2.html
+ 46. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-3.html
+ 47. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-4.html
+ 48. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-5.html
+ 49. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-6.html
+ 50. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/
+ 51. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-1.html
+ 52. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-2.html
+ 53. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-3.html
+ 54. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-4.html
+ 55. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-5.html
+ 56. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-6.html
+ 57. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Timers/linux-timers-7.html
+ 58. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/
+ 59. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-1.html
+ 60. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-2.html
+ 61. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-3.html
+ 62. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-4.html
+ 63. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-5.html
+ 64. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/SyncPrim/linux-sync-6.html
+ 65. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/MM/
+ 66. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/MM/linux-mm-1.html
+ 67. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/MM/linux-mm-2.html
+ 68. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/MM/linux-mm-3.html
+ 69. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Cgroups/
+ 70. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Cgroups/linux-cgroups-1.html
+ 71. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Concepts/
+ 72. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-1.html
+ 73. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-2.html
+ 74. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-3.html
+ 75. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Concepts/linux-cpu-4.html
+ 76. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/DataStructures/
+ 77. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/DataStructures/linux-datastructures-1.html
+ 78. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/DataStructures/linux-datastructures-2.html
+ 79. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/DataStructures/linux-datastructures-3.html
+ 80. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Theory/
+ 81. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-1.html
+ 82. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-2.html
+ 83. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Theory/linux-theory-3.html
+ 84. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Misc/
+ 85. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-1.html
+ 86. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-2.html
+ 87. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-3.html
+ 88. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Misc/linux-misc-4.html
+ 89. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/KernelStructures/
+ 90. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/KernelStructures/linux-kernelstructure-1.html
+ 91. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/LINKS.html
+ 92. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/contributors.html
+ 93. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/
+ 94. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 95. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 96. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/Long_mode
+ 97. https://web.archive.org/web/20230308144724/https://en.wikipedia.org/wiki/Protected_mode
+ 98. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/Intel_80286
+ 99. https://web.archive.org/web/20230308144724/http://wiki.osdev.org/Real_Mode
+ 100. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/Paging
+ 101. https://web.archive.org/web/20230308144724/http://www.sudleyplace.com/dpmione/expanddown.html
+ 102. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 103. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 104. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/include/uapi/asm/bootparam.h
+ 105. https://web.archive.org/web/20230308144724/https://www.kernel.org/doc/Documentation/x86/boot.txt
+ 106. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L280
+ 107. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/copy.S
+ 108. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/include/asm/linkage.h
+ 109. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/include/linux/linkage.h
+ 110. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/early_serial_console.c
+ 111. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/tty.c
+ 112. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/setup.ld
+ 113. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/copy.S#L36
+ 114. https://web.archive.org/web/20230308144724/http://www.ctyme.com/intr/rb-0106.htm
+ 115. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/tty.c
+ 116. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S
+ 117. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 118. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 119. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 120. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/include/uapi/asm/bootparam.h#L24
+ 121. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/header.S#L320
+ 122. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/cpu.c
+ 123. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/cpucheck.c
+ 124. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/Long_mode
+ 125. https://web.archive.org/web/20230308144724/https://en.wikipedia.org/wiki/Long_mode
+ 126. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/memory.c
+ 127. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/main.c
+ 128. https://web.archive.org/web/20230308144724/http://www.ctyme.com/intr/rb-1756.htm
+ 129. https://web.archive.org/web/20230308144724/http://www.ctyme.com/intr/rb-1757.htm
+ 130. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/SpeedStep
+ 131. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/apm.c#L21
+ 132. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/Advanced_Power_Management
+ 133. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/arch/x86/boot/edd.c#L122
+ 134. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/Documentation/admin-guide/kernel-parameters.rst
+ 135. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/include/uapi/linux/edd.h
+ 136. https://web.archive.org/web/20230308144724/https://twitter.com/0xAX
+ 137. https://web.archive.org/web/20230308144724/https://github.com/0xAX/linux-internals
+ 138. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/Protected_mode
+ 139. https://web.archive.org/web/20230308144724/http://wiki.osdev.org/Protected_Mode
+ 140. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/Long_mode
+ 141. https://web.archive.org/web/20230308144724/http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for
+ 142. https://web.archive.org/web/20230308144724/http://www.sudleyplace.com/dpmione/expanddown.html
+ 143. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/Documentation/x86/earlyprintk.txt
+ 144. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/Documentation/admin-guide/kernel-parameters.rst
+ 145. https://web.archive.org/web/20230308144724/https://github.com/torvalds/linux/blob/v4.16/Documentation/admin-guide/serial-console.rst
+ 146. https://web.archive.org/web/20230308144724/http://en.wikipedia.org/wiki/SpeedStep
+ 147. https://web.archive.org/web/20230308144724/https://en.wikipedia.org/wiki/Advanced_Power_Management
+ 148. https://web.archive.org/web/20230308144724/http://www.t13.org/documents/UploadedDocuments/docs2004/d1572r3-EDD3.pdf
+ 149. https://web.archive.org/web/20230308144724/http://www.tldp.org/HOWTO/Linux-i386-Boot-Code-HOWTO/setup.html
+ 150. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+
+ Hidden links:
+ 152. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 153. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 154. https://archive.org/account/login.php
+ 155. http://faq.web.archive.org/
+ 156. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html#close
+ 157. https://web.archive.org/web/20230308144724/http://web.archive.org/screenshot/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 158. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 159. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 160. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-2.html
+ 161. https://web.archive.org/web/20230308144724/https://www.gitbook.com/?utm_source=public_site_legacy&utm_medium=referral&utm_campaign=trademark&utm_term=0xax&utm_content=powered_by
+ 162. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-1.html
+ 163. https://web.archive.org/web/20230308144724/https://0xax.gitbooks.io/linux-insides/content/Booting/linux-bootstrap-3.html
diff --git a/doc/doc/dc0d32.blogspot.com_2010_06_real-mode-in-c-with-gcc-writing.txt b/doc/doc/dc0d32.blogspot.com_2010_06_real-mode-in-c-with-gcc-writing.txt
new file mode 100644
index 0000000..6834acd
--- /dev/null
+++ b/doc/doc/dc0d32.blogspot.com_2010_06_real-mode-in-c-with-gcc-writing.txt
@@ -0,0 +1,892 @@
+ #[1]dc0d32 - Atom [2]dc0d32 - RSS [3]dc0d32 - Atom
+
+[4]dc0d32
+
+Tuesday, June 15, 2010
+
+Real mode in C with gcc : writing a bootloader
+
+ Usually the x86 boot loader is written in assembler. We will be
+ exploring the possibility of writing one in C language (as much as
+ possible) compiled with gcc, and runs in real mode. Note that you can
+ also use the 16 bit bcc or TurboC compiler, but we will be focusing on
+ gcc in this post. Most open source kernels are compiled with gcc, and
+ it makes sense to write C bootloader with gcc instead of bcc as you get
+ a much cleaner toolchain :)
+ As of today (20100614), gcc 4.4.4 officially only emits code for
+ protected/long mode and does not support the real mode natively (this
+ may [5]change in future).
+ Also note that we will not discuss the very fundamentals of booting.
+ This article is fairly advanced and assumes that you know what it takes
+ to write a simple boot-loader in assembler. It is also expected that
+ you know how to write gcc inline assembly. Not everything can be done
+ in C!
+
+getting the tool-chain working
+
+.code16gcc
+
+ As we will be running in 16 bit real mode, this tells gas that the
+ assembler was generated by gcc and is intended to be run in real mode.
+ With this directive, gas automatically adds addr32 prefix wherever
+ required. For each C file which contains code to be run in real mode,
+ this directive should be present at the top of effectively generated
+ assembler code. This can be ensured by defining in a header and
+ including it before any other.
+#ifndef _CODE16GCC_H_
+#define _CODE16GCC_H_
+__asm__(".code16gcc\n");
+#endif
+
+ This is great for bootloaders as well as parts of kernel that must run
+ in real mode but are desired written in C instead of asm. In my opinion
+ C code is a lot easier to debug and maintain than asm code, at expense
+ of code size and performance at times.
+
+Special linking
+
+ As bootloader is supposed to run at physical 0x7C00, we need to tell
+ that to linker. The mbr/vbr should end with the proper boot signature
+ 0xaa55.
+ All this can be taken care of by a simple linker script.
+ENTRY(main);
+SECTIONS
+{
+ . = 0x7C00;
+ .text : AT(0x7C00)
+ {
+ _text = .;
+ *(.text);
+ _text_end = .;
+ }
+ .data :
+ {
+ _data = .;
+ *(.bss);
+ *(.bss*);
+ *(.data);
+ *(.rodata*);
+ *(COMMON)
+ _data_end = .;
+ }
+ .sig : AT(0x7DFE)
+ {
+ SHORT(0xaa55);
+ }
+ /DISCARD/ :
+ {
+ *(.note*);
+ *(.iplt*);
+ *(.igot*);
+ *(.rel*);
+ *(.comment);
+/* add any unwanted sections spewed out by your version of gcc and flags here */
+ }
+}
+
+ gcc emits elf binaries with sections, whereas a bootloader is a
+ monolithic plain binary with no sections. Conversion from elf to binary
+ can be done as follows:
+$ objcopy -O binary vbr.elf vbr.bin
+
+The code
+
+ With the toolchain set up, we can start writing our hello world
+ bootloader!
+ vbr.c (the only source file) looks something like this:
+/*
+ * A simple bootloader skeleton for x86, using gcc.
+ *
+ * Prashant Borole (boroleprashant at Google mail)
+ * */
+
+/* XXX these must be at top */
+#include "code16gcc.h"
+__asm__ ("jmpl $0, $main\n");
+
+
+#define __NOINLINE __attribute__((noinline))
+#define __REGPARM __attribute__ ((regparm(3)))
+#define __NORETURN __attribute__((noreturn))
+
+/* BIOS interrupts must be done with inline assembly */
+void __NOINLINE __REGPARM print(const char *s){
+ while(*s){
+ __asm__ __volatile__ ("int $0x10" : : "a"(0x0E00 | *s), "b"(7))
+;
+ s++;
+ }
+}
+/* and for everything else you can use C! Be it traversing the filesystem, or ve
+rifying the kernel image etc.*/
+
+void __NORETURN main(){
+ print("woo hoo!\r\n:)");
+ while(1);
+}
+
+
+ compile it as
+$ gcc -c -g -Os -march=i686 -ffreestanding -Wall -Werror -I. -o vbr.o vbr.c
+$ ld -static -Tlinker.ld -nostdlib --nmagic -o vbr.elf vbr.o
+$ objcopy -O binary vbr.elf vbr.bin
+
+ and that should have created vbr.elf file (which you can use as a
+ symbols file with gdb for source level debugging the vbr with gdbstub
+ and qemu/bochs) as well as 512 byte vbr.bin. To test it, first create a
+ dummy 1.44M floppy image, and overwrite it's mbr by vbr.bin with dd.
+$ dd if=/dev/zero of=floppy.img bs=1024 count=1440
+$ dd if=vbr.bin of=floppy.img bs=1 count=512 conv=notrunc
+
+ and now we are ready to test it out :D
+$ qemu -fda floppy.img -boot a
+
+ and you should see the message!
+ Once you get to this stage, you are pretty much set with respect to the
+ tooling itself. Now you can go ahead and write code to read the
+ filesystem, search for next stage or kernel and pass control to it.
+ Here is a simple example of a floppy boot record with no filesystem,
+ and the next stage or kernel written to the floppy immediately after
+ the boot record. The next image LMA and entry are fixed in a bunch of
+ macros. It simply reads the image starting one sector after boot record
+ and passes control to it. There are many obvious holes, which I left
+ open for sake of brevity.
+/*
+ * A simple bootloader skeleton for x86, using gcc.
+ *
+ * Prashant Borole (boroleprashant at Google mail)
+ * */
+
+/* XXX these must be at top */
+#include "code16gcc.h"
+__asm__ ("jmpl $0, $main\n");
+
+
+#define __NOINLINE __attribute__((noinline))
+#define __REGPARM __attribute__ ((regparm(3)))
+#define __PACKED __attribute__((packed))
+#define __NORETURN __attribute__((noreturn))
+
+#define IMAGE_SIZE 8192
+#define BLOCK_SIZE 512
+#define IMAGE_LMA 0x8000
+#define IMAGE_ENTRY 0x800c
+
+/* BIOS interrupts must be done with inline assembly */
+void __NOINLINE __REGPARM print(const char *s){
+ while(*s){
+ __asm__ __volatile__ ("int $0x10" : : "a"(0x0E00 | *s), "b"(7))
+;
+ s++;
+ }
+}
+
+#if 0
+/* use this for the HD/USB/Optical boot sector */
+typedef struct __PACKED TAGaddress_packet_t{
+ char size;
+ char :8;
+ unsigned short blocks;
+ unsigned short buffer_offset;
+ unsigned short buffer_segment;
+ unsigned long long lba;
+ unsigned long long flat_buffer;
+}address_packet_t ;
+
+int __REGPARM lba_read(const void *buffer, unsigned int lba, unsigned short
+blocks, unsigned char bios_drive){
+ int i;
+ unsigned short failed = 0;
+ address_packet_t packet = {.size = sizeof(address_packet_t), .blocks
+= blocks, .buffer_offset = 0xFFFF, .buffer_segment = 0xFFFF, .lba = lba, .flat_b
+uffer = (unsigned long)buffer};
+ for(i = 0; i < 3; i++){
+ packet.blocks = blocks;
+ __asm__ __volatile__ (
+ "movw $0, %0\n"
+ "int $0x13\n"
+ "setcb %0\n"
+ :"=m"(failed) : "a"(0x4200), "d"(bios_drive), "S
+"(&packet) : "cc" );
+ /* do something with the error_code */
+ if(!failed)
+ break;
+ }
+ return failed;
+}
+#else
+/* use for floppy, or as a fallback */
+typedef struct {
+ unsigned char spt;
+ unsigned char numh;
+}drive_params_t;
+
+int __REGPARM __NOINLINE get_drive_params(drive_params_t *p, unsigned char
+bios_drive){
+ unsigned short failed = 0;
+ unsigned short tmp1, tmp2;
+ __asm__ __volatile__
+ (
+ "movw $0, %0\n"
+ "int $0x13\n"
+ "setcb %0\n"
+ : "=m"(failed), "=c"(tmp1), "=d"(tmp2)
+ : "a"(0x0800), "d"(bios_drive), "D"(0)
+ : "cc", "bx"
+ );
+ if(failed)
+ return failed;
+ p->spt = tmp1 & 0x3F;
+ p->numh = tmp2 >> 8;
+ return failed;
+}
+
+int __REGPARM __NOINLINE lba_read(const void *buffer, unsigned int lba, uns
+igned char blocks, unsigned char bios_drive, drive_params_t *p){
+ unsigned char c, h, s;
+ c = lba / (p->numh * p->spt);
+ unsigned short t = lba % (p->numh * p->spt);
+ h = t / p->spt;
+ s = (t % p->spt) + 1;
+ unsigned char failed = 0;
+ unsigned char num_blocks_transferred = 0;
+ __asm__ __volatile__
+ (
+ "movw $0, %0\n"
+ "int $0x13\n"
+ "setcb %0"
+ : "=m"(failed), "=a"(num_blocks_transferred)
+ : "a"(0x0200 | blocks), "c"((s << 8) | s), "d"((h << 8) | bios_driv
+e), "b"(buffer)
+ );
+ return failed || (num_blocks_transferred != blocks);
+}
+#endif
+
+/* and for everything else you can use C! Be it traversing the filesystem, or ve
+rifying the kernel image etc.*/
+
+void __NORETURN main(){
+ unsigned char bios_drive = 0;
+ __asm__ __volatile__("movb %%dl, %0" : "=r"(bios_drive)); /* the B
+IOS drive number of the device we booted from is passed in dl register */
+
+ drive_params_t p = {};
+ get_drive_params(&p, bios_drive);
+
+ void *buff = (void*)IMAGE_LMA;
+ unsigned short num_blocks = ((IMAGE_SIZE / BLOCK_SIZE) + (IMAGE_SIZE %
+BLOCK_SIZE == 0 ? 0 : 1));
+ if(lba_read(buff, 1, num_blocks, bios_drive, &p) != 0){
+ print("read error :(\r\n");
+ while(1);
+ }
+ print("Running next image...\r\n");
+ void* e = (void*)IMAGE_ENTRY;
+ __asm__ __volatile__("" : : "d"(bios_drive));
+ goto *e;
+}
+
+
+ removing __NOINLINE may result in even smaller code in this case. I had
+ it in place so that I could figure out what was happening.
+
+Concluding remarks
+
+ C in no way matches the code size and performance of hand tuned
+ size/speed optimized assembler. Also, because of an extra byte (0x66,
+ 0x67) wasted (in addr32) with almost every instruction, it is highly
+ unlikely that you can cram up the same amount of functionality as
+ assembler.
+ Global and static variables, initialized as well as uninitialized, can
+ quickly fill those precious 446 bytes. Changing them to local and
+ passing around instead may increase or decrease size; there is no thumb
+ rule and it has to be worked out on per case basis. Same goes for
+ function in-lining.
+ You also need to be extremely careful with various gcc optimization
+ flags. For example, if you have a loop in your code whose number of
+ iterations are small and deducible at compile time, and the loop body
+ is relatively small (even 20 bytes), with default -Os, gcc will unroll
+ that loop. If the loop is not unrolled (-fno-tree-loop-optimize), you
+ might be able to shave off big chunk of bytes there. Same holds true
+ for frame setups on i386 - you may want to get rid of them whenever not
+ required using -fomit-frame-pointer. Moral of the story : you need to
+ be extra careful with gcc flags as well as version update. This is not
+ much of an issue for other real mode modules of the kernel where size
+ is not of this prime importance.
+ Also, you must be very cautious with assembler warnings when compiling
+ with .code16gcc. Truncation is common. It is a very good idea to use
+ --save-temp and analyze the assembler code generated from your C and
+ inline assembly. Always take care not to mess with the C calling
+ convention in inline assembly and meticulously check and update the
+ clobber list for inline assembly doing BIOS or APM calls (but you
+ already knew it, right?).
+ It is likely that you want to switch to protected/long mode as early as
+ possible, though. Even then, I still think that maintainability wins
+ over asm's size/speed in case of a bootloader as well as the real mode
+ portions of the kernel.
+ It would be interesting if someone could try this with
+ c++/java/fortran. Please let me know if you do!
+ at [6]June 15, 2010
+ [7]Email This[8]BlogThis![9]Share to Twitter[10]Share to
+ Facebook[11]Share to Pinterest
+ Labels: [12]assembler, [13]bootloader, [14]c, [15]gas, [16]gcc,
+ [17]kernel, [18]osdev
+
+25 comments:
+
+ 1. [19]Girija[20]Tuesday, June 15, 2010 at 6:12:00 PM GMT+5:30
+ Dokyaawarun 10 foot.. kiwwa jaastach.
+ :-|
+ Reply[21]Delete
+ Replies
+ Reply
+ 2. [22]descent[23]Tuesday, December 21, 2010 at 1:10:00 PM GMT+5:30
+ Hi,
+ Thank you for your sharing.
+ in void __NOINLINE __REGPARM print(const char *s)
+ I change the print function to access pointer,
+ like this:
+ videoram[0]='H';
+ but I got the warning message:
+ /tmp/cc5qsy9l.s:33: Warning: 00000000000b8000 shortened to
+ 0000000000008000
+ Do I miss something?
+ Reply[24]Delete
+ Replies
+ Reply
+ 3. [25]descent[26]Tuesday, December 21, 2010 at 2:05:00 PM GMT+5:30
+ Hi,
+ I use gcc-3.4 to compile again.
+ I see no warning message, but in qemu,
+ I still cannot see char H.
+ videoram is static variable.
+ static unsigned char *videoram = (unsigned char *) 0xb8000;
+ Reply[27]Delete
+ Replies
+ Reply
+ 4. [28]descent[29]Tuesday, December 21, 2010 at 3:16:00 PM GMT+5:30
+ Hi,
+ I got something. In 16bit mode, the pointer is 16bit length. So
+ 0xb8000 shortened to 0x8000.
+ I write a c file and a function,
+ void put_char()
+ {
+ unsigned char *videoram = (unsigned char *) 0xb8000;
+ videoram[0]='H';
+ videoram[2]='H';
+ videoram[40]='H';
+ }
+ no include code16gcc.h, I think the pointer is 32bits length, but I
+ still can not see the H character.
+ Reply[30]Delete
+ Replies
+ Reply
+ 5. [31]Prashant[32]Tuesday, December 21, 2010 at 7:16:00 PM GMT+5:30
+ @descent: check the '--save-temps' preserved assembler version of
+ the C function.
+ This article assumes that the reader has low level programming
+ experience with x86.
+ To access the vidmem with b8000h, you have 2 options:
+ 1. write inline assembly to set es to b800h, and di to the address
+ in the real mode segment. Then write byte/word to es:di.
+ 2. Enter unreal mode. Then you can use the full 4G memory,
+ one-to-one mapped.
+ I personally would not recommend any of these methods for printing
+ - BIOS int 10h is pretty good. Remember - do not try and do
+ anything fancy in the (m/v)br; do it in the next stage instead as
+ you have pretty much unconstrained image size in later stages.
+ Reply[33]Delete
+ Replies
+ Reply
+ 6. [34]descent[35]Wednesday, December 22, 2010 at 9:41:00 AM GMT+5:30
+ Hi Prashant,
+ Thank you for your explanation.
+ Because in protected mode, I can use C,
+ and direct access 0xb8000, so I am confused.
+ real/protect mode, gcc/gas 16/32 bit also confuse me.
+ They are very complicate.
+ Reply[36]Delete
+ Replies
+ Reply
+ 7. [37]Sebastian[38]Saturday, March 12, 2011 at 6:26:00 PM GMT+5:30
+ you are a genius!
+ Reply[39]Delete
+ Replies
+ Reply
+ 8. [40]Unknown[41]Sunday, April 17, 2011 at 5:48:00 AM GMT+5:30
+ I've got that infamous runtime error...
+ bootloader.exe has encountered a problem and needs to close. We are
+ sorry for the inconvenience.
+ Reply[42]Delete
+ Replies
+ Reply
+ 9. [43]Unknown[44]Saturday, May 21, 2011 at 2:39:00 AM GMT+5:30
+ Managed to do it in C++.
+ Code is the same.
+ Linker file needs to discard eh_frame.
+ When building on x86-64 add -m32 to g++ and -melf_i386 on ld
+ command line.
+ Trying to rewrite it in a more c++-ish style.
+ My e-mail is boskovits@cogito-top.hu .
+ Reply[45]Delete
+ Replies
+ Reply
+ 10. [46]Prashant[47]Saturday, May 21, 2011 at 3:02:00 AM GMT+5:30
+ @abraker95: are you trying to run the MZ/PE image in windows? that
+ is like sinning and then spitting on the devil when in hell.
+ @boskov1985: cool man! let us know how it goes :D
+ Reply[48]Delete
+ Replies
+ Reply
+ 11. Anonymous[49]Friday, November 25, 2011 at 2:50:00 AM GMT+5:30
+ It's easier to to this without objcopy. Modern ld versions support
+ --oformat=binary , so just one line does the direct compilation
+ job.
+ gcc -g -Os -march=i686 -ffreestanding -Wall -Werror -I. -static
+ -nostdlib -Wl,-Tlinker.ld -Wl,--nmagic -Wl,--oformat=binary -o
+ loader.bin loader.c
+ Reply[50]Delete
+ Replies
+ Reply
+ 12. [51]Prashant[52]Friday, November 25, 2011 at 8:01:00 AM GMT+5:30
+ I can't verify right now whether it works, but thanks for letting
+ us know, rpfh!
+ Reply[53]Delete
+ Replies
+ Reply
+ 13. [54]descent[55]Sunday, December 4, 2011 at 9:42:00 PM GMT+5:30
+ Hi,
+ The c code uses function call, why need not set stack (ss:esp)?
+ Reply[56]Delete
+ Replies
+ Reply
+ 14. [57]Prashant[58]Tuesday, December 6, 2011 at 10:18:00 AM GMT+5:30
+ good point @decent. I guess you will need to set up the stack first
+ in main, probably in assembler.
+ Reply[59]Delete
+ Replies
+ Reply
+ 15. [60]descent[61]Saturday, December 24, 2011 at 8:02:00 PM GMT+5:30
+ I change %ss:%esp to 0x07a0:0000,
+ Is any side effect?
+ void __NORETURN main(){
+ __asm__ ("mov %cs, %ax\n");
+ __asm__ ("mov %ax, %ds\n");
+ __asm__ ("mov $0x07a0, %ax\n");
+ __asm__ ("mov %ax, %ss\n");
+ __asm__ ("mov $0, %esp\n");
+ print("woo hoo!\r\n:)");
+ while(1);
+ }
+ Reply[62]Delete
+ Replies
+ Reply
+ 16. [63]descent[64]Monday, July 30, 2012 at 8:16:00 AM GMT+5:30
+ Hi,
+ I test c bootloader in real machine, in my eeepc 904, need add some
+ code to setup stack.
+ http://descent-incoming.blogspot.tw/2012/05/x86-bootloader-hello-wo
+ rld.html
+ The article is written by Chinese, but the code, picture can give
+ some reference.
+ cppb.cpp is cpp version (compile by g++), it can work, I test it in
+ real machine(eeepc 904).
+ Reply[65]Delete
+ Replies
+ Reply
+ 17. [66]axiomfinity[67]Saturday, April 20, 2013 at 10:46:00 AM GMT+5:30
+ linker fails whats up with it..?
+ Reply[68]Delete
+ Replies
+ Reply
+ 18. [69]Prashant[70]Sunday, April 21, 2013 at 9:34:00 AM GMT+5:30
+ Fails how? Can you please elaborate?
+ Reply[71]Delete
+ Replies
+ Reply
+ 19. [72]Unknown[73]Wednesday, November 13, 2013 at 12:51:00 PM GMT+5:30
+ Thank you for detaile explanation
+ Linker failed nt sure why..ld: error: load segment overlap [0x7c00
+ -> 0x7e50] and [0x7dfe -> 0x7e00]
+ Reply[74]Delete
+ Replies
+ Reply
+ 20. [75]osdev[76]Saturday, May 31, 2014 at 1:35:00 AM GMT+5:30
+ someone here? I need to test, but...
+ "c"((s << 8) | s) <-- duplicate s in CH and CL?
+ c = lba / (p->numh * p->spt); <-- 'c' is never used...
+ maybe -> "c"((c << 8) | s)
+ Reply[77]Delete
+ Replies
+ Reply
+ 21. [78]Unknown[79]Thursday, February 5, 2015 at 8:39:00 PM GMT+5:30
+ Thank you for your nice post! I'm trying to run it on my x86-64
+ linux box, but gcc reports errors like "bad register name rax", I'm
+ a little confused by the various compiler options here, could you
+ please give me suggestions on how to compile the C source file on
+ x86-64 machines? Thanks
+ Reply[80]Delete
+ Replies
+ 1. [81]Jose Fernando Lopez Fernandez[82]Friday, January 20, 2017
+ at 2:56:00 PM GMT+5:30
+ rax is a 64 bit register. A bootloader is running in 16 bits,
+ so you cannot use rax (64 bit) or eax (32 bit). You have to
+ use ax.
+ Also, you said your computer is an x86-64. Which one is it?
+ x86 (32 bit) or 64 (64 bit)? If you have an x86, it will have
+ no idea what rax is, since it has no knowledge of 64 bit
+ registers.
+ I'm just speculating as to your problem here, though. If
+ anything here is incorrect/misguided by all means let me know,
+ I'm only a beginner too
+ [83]Delete
+ Replies
+ Reply
+ 2. [84]Jose Fernando Lopez Fernandez[85]Friday, January 20, 2017
+ at 2:57:00 PM GMT+5:30
+ @Jing Peng
+ rax is a 64 bit register. A bootloader is running in 16 bits,
+ so you cannot use rax (64 bit) or eax (32 bit). You have to
+ use ax.
+ Also, you said your computer is an x86-64. Which one is it?
+ x86 (32 bit) or 64 (64 bit)? If you have an x86, it will have
+ no idea what rax is, since it has no knowledge of 64 bit
+ registers.
+ I'm just speculating as to your problem here, though. If
+ anything here is incorrect/misguided by all means let me know,
+ I'm only a beginner too
+ [86]Delete
+ Replies
+ Reply
+ Reply
+ 22. [87]Unknown[88]Thursday, February 5, 2015 at 8:40:00 PM GMT+5:30
+ Thank you for your nice post! I'm trying to run it on my x86-64
+ linux box, but gcc reports errors like "bad register name rax", I'm
+ a little confused by the various compiler options here, could you
+ please give me suggestions on how to compile the C source file on
+ x86-64 machines? Thanks
+ Reply[89]Delete
+ Replies
+ Reply
+ 23. [90]Unknown[91]Sunday, February 7, 2016 at 8:43:00 PM GMT+5:30
+ hello i ma atif
+ Reply[92]Delete
+ Replies
+ Reply
+
+ Add comment
+ Load more...
+
+ [93]Newer Post [94]Older Post [95]Home
+ Subscribe to: [96]Post Comments (Atom)
+ * [97]Real mode in C with gcc : writing a bootloader
+ Usually the x86 boot loader is written in assembler. We will be
+ exploring the possibility of writing one in C language (as much as
+ possible)...
+ * [98]Writing kernel in Windows with Visual Studio C/C++
+ Most hobby osdev projects prefer *nix+gcc combination these days,
+ primarily because there are a bunch of nice tutorials and examples
+ availab...
+ * [99]Debugging kernel with qemu and gdb
+ Assuming that you have your (or Linux/*BSD/Solaris/Windows or any
+ other) kernel on a bootable device, you can debug the kernel and
+ also the ...
+
+Blog Archive
+
+ * [100]|> [101]2012 (1)
+ + [102]|> [103]Feb 2012 (1)
+
+ * [104]v [105]2010 (7)
+ + [106]v [107]Jun 2010 (2)
+ o [108]Cold boot attack
+ o [109]Real mode in C with gcc : writing a bootloader
+ + [110]|> [111]May 2010 (2)
+ + [112]|> [113]Apr 2010 (1)
+ + [114]|> [115]Mar 2010 (1)
+ + [116]|> [117]Feb 2010 (1)
+
+ * [118]|> [119]2009 (12)
+ + [120]|> [121]Dec 2009 (1)
+ + [122]|> [123]Nov 2009 (2)
+ + [124]|> [125]Sep 2009 (1)
+ + [126]|> [127]Aug 2009 (1)
+ + [128]|> [129]Jul 2009 (2)
+ + [130]|> [131]Feb 2009 (2)
+ + [132]|> [133]Jan 2009 (3)
+
+ * [134]|> [135]2008 (9)
+ + [136]|> [137]Nov 2008 (2)
+ + [138]|> [139]Oct 2008 (3)
+ + [140]|> [141]Aug 2008 (1)
+ + [142]|> [143]Jun 2008 (3)
+
+Labels
+
+ [144]linux [145]kernel [146]8800 [147]FreeBSD [148]gdb [149]nvidia
+ [150]osdev [151]windows 7 [152]bochs [153]boot [154]bootloader
+ [155]debug [156]dual boot [157]gas [158]gcc [159]overclock [160]pidgin
+ [161]windows [162]windows server 2008 [163]2k8 [164]3DMark [165]3DMark
+ vantage [166]820 [167]DRAM [168]Directx 10 [169]Dirext 11 [170]Java
+ [171]OpenJDK [172]OpenOffice [173]Pentium D [174]RAID [175]Sun
+ [176]UUID [177]Unicode [178]VirtualBox [179]X [180]Xorg [181]ageis
+ [182]assembler [183]authentication [184]bash [185]c [186]coolbits
+ [187]dx10 [188]fedora [189]fortune [190]gdm [191]ghostscript [192]gnome
+ [193]google [194]gs [195]gtalk [196]heat sink [197]invisible
+ [198]jabber [199]kde [200]latex [201]lvm [202]lyx [203]mount
+ [204]networked audio [205]networked sound [206]nvclock [207]oolatex
+ [208]ooolatex [209]perl [210]phonon [211]physics [212]physx [213]picasa
+ [214]plugin [215]proxy [216]pulseaudio [217]qemu [218]rsync [219]rtp
+ [220]scp [221]scp stdin [222]security [223]server [224]shell [225]squid
+ [226]ssh [227]sync [228]tar [229]udev [230]unix [231]xdm [232]xfce
+ [233]xmpp [234]xorg.conf [235]zsh
+ [236]visit counter for blogspot
+
+ Theme images by [237]5ugarless. Powered by [238]Blogger.
+
+References
+
+ Visible links:
+ 1. http://dc0d32.blogspot.com/feeds/posts/default
+ 2. http://dc0d32.blogspot.com/feeds/posts/default?alt=rss
+ 3. http://dc0d32.blogspot.com/feeds/6370208028763486595/comments/default
+ 4. http://dc0d32.blogspot.com/
+ 5. http://gcc.gnu.org/ml/gcc/1999-07n/msg00483.html
+ 6. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html
+ 7. https://www.blogger.com/share-post.g?blogID=35813921&postID=6370208028763486595&target=email
+ 8. https://www.blogger.com/share-post.g?blogID=35813921&postID=6370208028763486595&target=blog
+ 9. https://www.blogger.com/share-post.g?blogID=35813921&postID=6370208028763486595&target=twitter
+ 10. https://www.blogger.com/share-post.g?blogID=35813921&postID=6370208028763486595&target=facebook
+ 11. https://www.blogger.com/share-post.g?blogID=35813921&postID=6370208028763486595&target=pinterest
+ 12. http://dc0d32.blogspot.com/search/label/assembler
+ 13. http://dc0d32.blogspot.com/search/label/bootloader
+ 14. http://dc0d32.blogspot.com/search/label/c
+ 15. http://dc0d32.blogspot.com/search/label/gas
+ 16. http://dc0d32.blogspot.com/search/label/gcc
+ 17. http://dc0d32.blogspot.com/search/label/kernel
+ 18. http://dc0d32.blogspot.com/search/label/osdev
+ 19. https://www.blogger.com/profile/06904019980664523275
+ 20. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1276605767623#c7537756629084768590
+ 21. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=7537756629084768590
+ 22. https://www.blogger.com/profile/17992312956580227764
+ 23. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1292917257855#c7916645211913421716
+ 24. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=7916645211913421716
+ 25. https://www.blogger.com/profile/17992312956580227764
+ 26. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1292920505936#c6914976194912758237
+ 27. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=6914976194912758237
+ 28. https://www.blogger.com/profile/17992312956580227764
+ 29. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1292924802000#c3509490007866551116
+ 30. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=3509490007866551116
+ 31. https://www.blogger.com/profile/15716533043357974705
+ 32. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1292939196737#c8552773997968662641
+ 33. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=8552773997968662641
+ 34. https://www.blogger.com/profile/17992312956580227764
+ 35. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1292991102048#c3691472389082213083
+ 36. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=3691472389082213083
+ 37. https://www.blogger.com/profile/04546527990311411722
+ 38. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1299934567958#c8861407369344586215
+ 39. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=8861407369344586215
+ 40. https://www.blogger.com/profile/13931402888317484377
+ 41. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1302999537204#c1796379189090357880
+ 42. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=1796379189090357880
+ 43. https://www.blogger.com/profile/10664008816666619973
+ 44. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1305925792707#c309698377277262219
+ 45. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=309698377277262219
+ 46. https://www.blogger.com/profile/15716533043357974705
+ 47. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1305927124224#c7619831240140737017
+ 48. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=7619831240140737017
+ 49. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1322169605658#c1693276418345545837
+ 50. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=1693276418345545837
+ 51. https://www.blogger.com/profile/15716533043357974705
+ 52. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1322188282688#c6259496576598783959
+ 53. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=6259496576598783959
+ 54. https://www.blogger.com/profile/17992312956580227764
+ 55. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1323015134989#c3945832952459710949
+ 56. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=3945832952459710949
+ 57. https://www.blogger.com/profile/15716533043357974705
+ 58. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1323146939454#c2066813635755540091
+ 59. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=2066813635755540091
+ 60. https://www.blogger.com/profile/17992312956580227764
+ 61. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1324737140263#c7908397772486068687
+ 62. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=7908397772486068687
+ 63. https://www.blogger.com/profile/17992312956580227764
+ 64. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1343616406999#c8117194716929362278
+ 65. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=8117194716929362278
+ 66. https://www.blogger.com/profile/00410755183408310829
+ 67. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1366435009449#c1258130037332531147
+ 68. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=1258130037332531147
+ 69. https://www.blogger.com/profile/15716533043357974705
+ 70. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1366517094365#c8123329091843779139
+ 71. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=8123329091843779139
+ 72. https://www.blogger.com/profile/17234059656421576642
+ 73. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1384327289704#c4134298820836763034
+ 74. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=4134298820836763034
+ 75. https://www.blogger.com/profile/16683260877229099988
+ 76. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1401480336214#c455729903293178418
+ 77. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=455729903293178418
+ 78. https://www.blogger.com/profile/07765096042053323038
+ 79. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1423148995473#c7126019925062815723
+ 80. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=7126019925062815723
+ 81. https://www.blogger.com/profile/01833111909520604012
+ 82. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1484904386672#c7038618115198897417
+ 83. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=7038618115198897417
+ 84. https://www.blogger.com/profile/01833111909520604012
+ 85. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1484904424918#c1284220459583274955
+ 86. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=1284220459583274955
+ 87. https://www.blogger.com/profile/07765096042053323038
+ 88. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1423149010339#c2287827836063649127
+ 89. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=2287827836063649127
+ 90. https://www.blogger.com/profile/17596900636592437710
+ 91. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html?showComment=1454858010555#c4198004625201390279
+ 92. https://www.blogger.com/delete-comment.g?blogID=35813921&postID=4198004625201390279
+ 93. http://dc0d32.blogspot.com/2010/06/cold-boot-attack.html
+ 94. http://dc0d32.blogspot.com/2010/05/how-not-to-look-like-fool-on-facebook.html
+ 95. http://dc0d32.blogspot.com/
+ 96. http://dc0d32.blogspot.com/feeds/6370208028763486595/comments/default
+ 97. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html
+ 98. http://dc0d32.blogspot.com/2012/02/writing-kernel-in-windows-with-visual.html
+ 99. http://dc0d32.blogspot.com/2010/03/debugging-kernel-with-qemu-and-gdb.html
+ 100. javascript:void(0)
+ 101. http://dc0d32.blogspot.com/2012/
+ 102. javascript:void(0)
+ 103. http://dc0d32.blogspot.com/2012/02/
+ 104. javascript:void(0)
+ 105. http://dc0d32.blogspot.com/2010/
+ 106. javascript:void(0)
+ 107. http://dc0d32.blogspot.com/2010/06/
+ 108. http://dc0d32.blogspot.com/2010/06/cold-boot-attack.html
+ 109. http://dc0d32.blogspot.com/2010/06/real-mode-in-c-with-gcc-writing.html
+ 110. javascript:void(0)
+ 111. http://dc0d32.blogspot.com/2010/05/
+ 112. javascript:void(0)
+ 113. http://dc0d32.blogspot.com/2010/04/
+ 114. javascript:void(0)
+ 115. http://dc0d32.blogspot.com/2010/03/
+ 116. javascript:void(0)
+ 117. http://dc0d32.blogspot.com/2010/02/
+ 118. javascript:void(0)
+ 119. http://dc0d32.blogspot.com/2009/
+ 120. javascript:void(0)
+ 121. http://dc0d32.blogspot.com/2009/12/
+ 122. javascript:void(0)
+ 123. http://dc0d32.blogspot.com/2009/11/
+ 124. javascript:void(0)
+ 125. http://dc0d32.blogspot.com/2009/09/
+ 126. javascript:void(0)
+ 127. http://dc0d32.blogspot.com/2009/08/
+ 128. javascript:void(0)
+ 129. http://dc0d32.blogspot.com/2009/07/
+ 130. javascript:void(0)
+ 131. http://dc0d32.blogspot.com/2009/02/
+ 132. javascript:void(0)
+ 133. http://dc0d32.blogspot.com/2009/01/
+ 134. javascript:void(0)
+ 135. http://dc0d32.blogspot.com/2008/
+ 136. javascript:void(0)
+ 137. http://dc0d32.blogspot.com/2008/11/
+ 138. javascript:void(0)
+ 139. http://dc0d32.blogspot.com/2008/10/
+ 140. javascript:void(0)
+ 141. http://dc0d32.blogspot.com/2008/08/
+ 142. javascript:void(0)
+ 143. http://dc0d32.blogspot.com/2008/06/
+ 144. http://dc0d32.blogspot.com/search/label/linux
+ 145. http://dc0d32.blogspot.com/search/label/kernel
+ 146. http://dc0d32.blogspot.com/search/label/8800
+ 147. http://dc0d32.blogspot.com/search/label/FreeBSD
+ 148. http://dc0d32.blogspot.com/search/label/gdb
+ 149. http://dc0d32.blogspot.com/search/label/nvidia
+ 150. http://dc0d32.blogspot.com/search/label/osdev
+ 151. http://dc0d32.blogspot.com/search/label/windows%207
+ 152. http://dc0d32.blogspot.com/search/label/bochs
+ 153. http://dc0d32.blogspot.com/search/label/boot
+ 154. http://dc0d32.blogspot.com/search/label/bootloader
+ 155. http://dc0d32.blogspot.com/search/label/debug
+ 156. http://dc0d32.blogspot.com/search/label/dual%20boot
+ 157. http://dc0d32.blogspot.com/search/label/gas
+ 158. http://dc0d32.blogspot.com/search/label/gcc
+ 159. http://dc0d32.blogspot.com/search/label/overclock
+ 160. http://dc0d32.blogspot.com/search/label/pidgin
+ 161. http://dc0d32.blogspot.com/search/label/windows
+ 162. http://dc0d32.blogspot.com/search/label/windows%20server%202008
+ 163. http://dc0d32.blogspot.com/search/label/2k8
+ 164. http://dc0d32.blogspot.com/search/label/3DMark
+ 165. http://dc0d32.blogspot.com/search/label/3DMark%20vantage
+ 166. http://dc0d32.blogspot.com/search/label/820
+ 167. http://dc0d32.blogspot.com/search/label/DRAM
+ 168. http://dc0d32.blogspot.com/search/label/Directx%2010
+ 169. http://dc0d32.blogspot.com/search/label/Dirext%2011
+ 170. http://dc0d32.blogspot.com/search/label/Java
+ 171. http://dc0d32.blogspot.com/search/label/OpenJDK
+ 172. http://dc0d32.blogspot.com/search/label/OpenOffice
+ 173. http://dc0d32.blogspot.com/search/label/Pentium%20D
+ 174. http://dc0d32.blogspot.com/search/label/RAID
+ 175. http://dc0d32.blogspot.com/search/label/Sun
+ 176. http://dc0d32.blogspot.com/search/label/UUID
+ 177. http://dc0d32.blogspot.com/search/label/Unicode
+ 178. http://dc0d32.blogspot.com/search/label/VirtualBox
+ 179. http://dc0d32.blogspot.com/search/label/X
+ 180. http://dc0d32.blogspot.com/search/label/Xorg
+ 181. http://dc0d32.blogspot.com/search/label/ageis
+ 182. http://dc0d32.blogspot.com/search/label/assembler
+ 183. http://dc0d32.blogspot.com/search/label/authentication
+ 184. http://dc0d32.blogspot.com/search/label/bash
+ 185. http://dc0d32.blogspot.com/search/label/c
+ 186. http://dc0d32.blogspot.com/search/label/coolbits
+ 187. http://dc0d32.blogspot.com/search/label/dx10
+ 188. http://dc0d32.blogspot.com/search/label/fedora
+ 189. http://dc0d32.blogspot.com/search/label/fortune
+ 190. http://dc0d32.blogspot.com/search/label/gdm
+ 191. http://dc0d32.blogspot.com/search/label/ghostscript
+ 192. http://dc0d32.blogspot.com/search/label/gnome
+ 193. http://dc0d32.blogspot.com/search/label/google
+ 194. http://dc0d32.blogspot.com/search/label/gs
+ 195. http://dc0d32.blogspot.com/search/label/gtalk
+ 196. http://dc0d32.blogspot.com/search/label/heat%20sink
+ 197. http://dc0d32.blogspot.com/search/label/invisible
+ 198. http://dc0d32.blogspot.com/search/label/jabber
+ 199. http://dc0d32.blogspot.com/search/label/kde
+ 200. http://dc0d32.blogspot.com/search/label/latex
+ 201. http://dc0d32.blogspot.com/search/label/lvm
+ 202. http://dc0d32.blogspot.com/search/label/lyx
+ 203. http://dc0d32.blogspot.com/search/label/mount
+ 204. http://dc0d32.blogspot.com/search/label/networked%20audio
+ 205. http://dc0d32.blogspot.com/search/label/networked%20sound
+ 206. http://dc0d32.blogspot.com/search/label/nvclock
+ 207. http://dc0d32.blogspot.com/search/label/oolatex
+ 208. http://dc0d32.blogspot.com/search/label/ooolatex
+ 209. http://dc0d32.blogspot.com/search/label/perl
+ 210. http://dc0d32.blogspot.com/search/label/phonon
+ 211. http://dc0d32.blogspot.com/search/label/physics
+ 212. http://dc0d32.blogspot.com/search/label/physx
+ 213. http://dc0d32.blogspot.com/search/label/picasa
+ 214. http://dc0d32.blogspot.com/search/label/plugin
+ 215. http://dc0d32.blogspot.com/search/label/proxy
+ 216. http://dc0d32.blogspot.com/search/label/pulseaudio
+ 217. http://dc0d32.blogspot.com/search/label/qemu
+ 218. http://dc0d32.blogspot.com/search/label/rsync
+ 219. http://dc0d32.blogspot.com/search/label/rtp
+ 220. http://dc0d32.blogspot.com/search/label/scp
+ 221. http://dc0d32.blogspot.com/search/label/scp%20stdin
+ 222. http://dc0d32.blogspot.com/search/label/security
+ 223. http://dc0d32.blogspot.com/search/label/server
+ 224. http://dc0d32.blogspot.com/search/label/shell
+ 225. http://dc0d32.blogspot.com/search/label/squid
+ 226. http://dc0d32.blogspot.com/search/label/ssh
+ 227. http://dc0d32.blogspot.com/search/label/sync
+ 228. http://dc0d32.blogspot.com/search/label/tar
+ 229. http://dc0d32.blogspot.com/search/label/udev
+ 230. http://dc0d32.blogspot.com/search/label/unix
+ 231. http://dc0d32.blogspot.com/search/label/xdm
+ 232. http://dc0d32.blogspot.com/search/label/xfce
+ 233. http://dc0d32.blogspot.com/search/label/xmpp
+ 234. http://dc0d32.blogspot.com/search/label/xorg.conf
+ 235. http://dc0d32.blogspot.com/search/label/zsh
+ 236. http://www.statcounter.com/blogger/
+ 237. http://www.istockphoto.com/portfolio/5ugarless?platform=blogger
+ 238. https://www.blogger.com/
+
+ Hidden links:
+ 240. https://www.blogger.com/post-edit.g?blogID=35813921&postID=6370208028763486595&from=pencil
+ 241. https://www.blogger.com/comment/frame/35813921?po=6370208028763486595&hl=en
diff --git a/doc/doc/fossbytes_com_redditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486.txt b/doc/doc/fossbytes_com_redditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486.txt
new file mode 100644
index 0000000..72c3e20
--- /dev/null
+++ b/doc/doc/fossbytes_com_redditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486.txt
@@ -0,0 +1,339 @@
+ #[1]Fossbytes » Feed [2]Fossbytes » Comments Feed [3]Fossbytes »
+ Redditor Boots Linux Kernel 5.8 On 30-Year-Old Intel Processor via
+ Floppy Disk Comments Feed [4]alternate [5]alternate [6]alternate
+
+ [7]Skip to content
+
+ [8]FOSSBYTES TECH SIMPLIFIED LOGO
+ [9]Facebook
+ [10]Twitter
+ [11]Instagram
+
+ * [12]News
+ * [13]Geek
+ * [14]Hacked
+ * [15]Gaming
+ * [16]Drive X
+ * [17]How To
+ * [18]Top X
+ * [19]Tools
+
+ Menu
+
+ * [20]News
+ * [21]Geek
+ * [22]Hacked
+ * [23]Gaming
+ * [24]Drive X
+ * [25]How To
+ * [26]Top X
+ * [27]Tools
+
+ Search
+ ____________________
+
+ Menu
+
+ * [28]News
+ * [29]Geek
+ * [30]Hacked
+ * [31]Gaming
+ * [32]Drive X
+ * [33]How To
+ * [34]Top X
+ * [35]Tools
+
+ [36]FOSSBYTES TECH SIMPLIFIED LOGO
+ Search
+ ____________________
+ Close
+
+ News
+
+ * [37]Privacy
+ * [38]Facebook
+ * [39]Apple
+ * [40]Google
+ * [41]Microsoft
+ * [42]Linux
+ * [43]Tesla
+ * [44]EV
+
+ Menu
+
+ * [45]Privacy
+ * [46]Facebook
+ * [47]Apple
+ * [48]Google
+ * [49]Microsoft
+ * [50]Linux
+ * [51]Tesla
+ * [52]EV
+
+ * [53]Geek, [54]News
+
+Redditor Boots Linux Kernel 5.8 On 30-Year-Old Intel Processor via Floppy
+Disk
+
+ * [55]Sarvottam Kumar
+ * [56]June 30, 2020
+
+ Redditor Booted Linux Kernel 5.8.0-rc2+ From A Floppy On Intel 80486
+
+ Do you remember your first PC on which you booted Linux from floppy?
+ Well, Floppy disk is almost dead. The majority of people now use USB
+ sticks or DVDs to install Linux distros on their PCs. However, retro
+ enthusiasts love to revive their old hardware and relive the flashback.
+
+ Recently, a Redditor who goes by the name
+ `FozzTexx' [57]demonstrated the latest stable Linux Kernel 5.8.0-rc2+
+ running from his floppy disk. He successfully booted a tiny kernel on a
+ 30-year-old 32-bit Intel 80486 (i486 or 486) CPU.
+
+ Now, if you think Linux kernel has dropped support for anything older
+ than i686, it may prove you wrong. You know that freedom,
+ customization, and support for legacy hardware are the characteristics
+ of Linux.
+
+ Speaking of booting OS, if you're 90s kid, you may remember installing
+ Linux with boot floppies or installation CDs offered by Linux distros.
+ Nowadays, the scenario has changed as people download the ISO from
+ official websites and install it by creating a bootable USB or DVD.
+
+ In case you're still wondering about booting Linux from floppy, a retro
+ enthusiasts FozzTexx did it using a single 1.44MB floppy disk on his
+ i486 CPU.
+ Booting Linux from 1.44MB floppy Booting Linux from 1.44MB floppy
+
+ He pulled the fresh Kernel 5.8.0-rc2+ from the git repo and shrank it
+ to fit on a floppy using make tinyconfig. Then, he booted it on 486
+ into a busybox shell using rootfs.cpio.gz from Aboriginal Linux.
+
+ The tiny kernel surely misses network support or any other functional
+ support. Though it may seem useless, the Redditor also added options
+ like IDE support. Surprisingly, when he attached a hard drive and
+ booted into the shell, he could see the drive as connected and its full
+ capacity. You can see the result in the picture below.
+ Hard disk attached to 486 CPU Hard disk attached to 486 CPU
+
+ You can also read the Twitter [58]thread describing how he started
+ loading kernel 5.8 on a 486 from floppy.
+
+ This is for all you [59]#floppy lovers out there: Linux 5.8.0-rc2+
+ pulled fresh from the git repo this morning booting into a busybox
+ shell using the rootfs.cpio.gz from Aboriginal Linux.
+ [60]#RetroComputing [61]pic.twitter.com/zaB9lpggPX
+ -- FozzTexx (@FozzTexx) [62]June 28, 2020
+
+ If you also have a 486 system lying around and want to load Linux, you
+ can follow the tutorial which he'll put on his [63]blog site soon.
+ [64]Sarvottam Kumar
+ [65]
+
+Sarvottam Kumar
+
+ Being a fossbyter, I cover the latest releases, news, information, and
+ trends in the world of Linux and Open source.
+
+Leave a Comment [66]Cancel Reply
+
+ Your email address will not be published. Required fields are marked *
+
+ Type here..
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+ _____________________________________________
+
+ Name* ______________________________
+
+ Email* ______________________________
+
+ Website ______________________________
+
+ [ ] Save my name, email, and website in this browser for the next time
+ I comment.
+
+ Post Comment »
+
+News & Opeds
+
+ Tesla Model S and Model X
+
+[67]Why NHTSA Is Asking Tesla To Recall 158,000 Model S And Model X?
+
+ Netflix Movies 2021 All 70 Movies Coming To Netflix This Year
+
+[68]Netflix Movies 2021: All 70 Movies Releasing On Netflix This Year
+
+ Official Best of CES 2021 awards
+
+[69]CES 2021 Awards: This Is The Tech To Look Forward To In 2021
+
+ More From Fossbytes
+
+Popular In News
+
+ How do electric cars work_
+
+[70]How Do Electric Cars Work? Electric Motors And Batteries Explained
+
+ Netflix Movies 2021 All 70 Movies Coming To Netflix This Year
+
+[71]Netflix Movies 2021: All 70 Movies Releasing On Netflix This Year
+
+ Security-Focused Tails OS Plans To Switch From Xorg To Wayland
+
+[72]Security-Focused Tails OS Plans To Switch From Xorg To Wayland
+
+[73]CloudLinux Renames Its CentOS Alternative `Project Lenix' To `AlmaLinux'
+
+ FOSSBYTES
+
+ * [74]About Us
+ * [75]Privacy Policy
+ * [76]Cookie Policy
+
+ [77]Facebook
+ [78]Twitter
+ [79]Instagram
+ * [80]Contact Us
+ * [81]Our Team
+ * [82]Work With Us
+
+Learn Something New Today
+
+ [83]Academy
+
+ Fossbytes Media Pvt Ltd © 2021
+
+ FOSSBYTES
+
+ [84]Facebook
+ [85]Twitter
+ [86]Instagram
+
+Learn Something New Today
+
+ [87]Academy
+ * [88]About Us
+ * [89]Privacy Policy
+ * [90]Cookie Policy
+
+ * [91]Contact Us
+ * [92]Our Team
+ * [93]Work With Us
+
+ Fossbytes Media Pvt Ltd © 2021
+
+ Scroll to Top
+
+References
+
+ Visible links:
+ 1. https://fossbytes.com/feed/
+ 2. https://fossbytes.com/comments/feed/
+ 3. https://fossbytes.com/redditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486/feed/
+ 4. https://fossbytes.com/wp-json/wp/v2/posts/173003
+ 5. https://fossbytes.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Ffossbytes.com%2Fredditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486%2F
+ 6. https://fossbytes.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Ffossbytes.com%2Fredditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486%2F&format=xml
+ 7. https://fossbytes.com/redditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486/#content
+ 8. https://fossbytes.com/
+ 9. https://www.facebook.com/fossbytes
+ 10. https://twitter.com/Fossbytes14
+ 11. https://instagram.com/fossbytes
+ 12. https://fossbytes.com/category/news/
+ 13. https://fossbytes.com/category/geek/
+ 14. https://fossbytes.com/category/security/
+ 15. https://fossbytes.com/category/entertainment/gaming-and-sports/
+ 16. https://fossbytes.com/category/transportation/
+ 17. https://fossbytes.com/category/how-to/
+ 18. https://fossbytes.com/category/more/lists/
+ 19. https://fossbytes.com/tools/
+ 20. https://fossbytes.com/category/news/
+ 21. https://fossbytes.com/category/geek/
+ 22. https://fossbytes.com/category/security/
+ 23. https://fossbytes.com/category/entertainment/gaming-and-sports/
+ 24. https://fossbytes.com/category/transportation/
+ 25. https://fossbytes.com/category/how-to/
+ 26. https://fossbytes.com/category/more/lists/
+ 27. https://fossbytes.com/tools/
+ 28. https://fossbytes.com/category/news/
+ 29. https://fossbytes.com/category/geek/
+ 30. https://fossbytes.com/category/security/
+ 31. https://fossbytes.com/category/entertainment/gaming-and-sports/
+ 32. https://fossbytes.com/category/transportation/
+ 33. https://fossbytes.com/category/how-to/
+ 34. https://fossbytes.com/category/more/lists/
+ 35. https://fossbytes.com/tools/
+ 36. https://fossbytes.com/
+ 37. https://fossbytes.com/tag/privacy/
+ 38. https://fossbytes.com/tag/facebook/
+ 39. https://fossbytes.com/tag/apple/
+ 40. https://fossbytes.com/tag/google/
+ 41. https://fossbytes.com/tag/microsoft/
+ 42. https://fossbytes.com/tag/linux/
+ 43. https://fossbytes.com/tag/tesla/
+ 44. https://fossbytes.com/tag/electric-cars/
+ 45. https://fossbytes.com/tag/privacy/
+ 46. https://fossbytes.com/tag/facebook/
+ 47. https://fossbytes.com/tag/apple/
+ 48. https://fossbytes.com/tag/google/
+ 49. https://fossbytes.com/tag/microsoft/
+ 50. https://fossbytes.com/tag/linux/
+ 51. https://fossbytes.com/tag/tesla/
+ 52. https://fossbytes.com/tag/electric-cars/
+ 53. https://fossbytes.com/category/geek/
+ 54. https://fossbytes.com/category/news/
+ 55. https://fossbytes.com/author/sarvottam/
+ 56. https://fossbytes.com/2020/06/30/
+ 57. https://www.reddit.com/r/retrobattlestations/comments/hi3kbq/booting_linux_kernel_580rc2_from_a_single_floppy/
+ 58. https://twitter.com/FozzTexx/status/1277251556010676225
+ 59. https://twitter.com/hashtag/floppy?src=hash&ref_src=twsrc%5Etfw
+ 60. https://twitter.com/hashtag/RetroComputing?src=hash&ref_src=twsrc%5Etfw
+ 61. https://t.co/zaB9lpggPX
+ 62. https://twitter.com/FozzTexx/status/1277296880813105152?ref_src=twsrc%5Etfw
+ 63. https://www.insentricity.com/
+ 64. https://fossbytes.com/author/sarvottam/
+ 65. https://fossbytes.com/author/sarvottam/
+ 66. https://fossbytes.com/redditor-boots-linux-kernel-5-8-0-rc2-floppy-intel-80486/#respond
+ 67. https://fossbytes.com/why-nhtsa-is-asking-tesla-to-recall-158000-model-s-and-model-x/
+ 68. https://fossbytes.com/netflix-movies-2021-all-70-movies-releasing-on-netflix-this-year/
+ 69. https://fossbytes.com/official-best-of-ces-2021/
+ 70. https://fossbytes.com/how-do-electric-cars-work-electric-motors-and-batteries-explained/
+ 71. https://fossbytes.com/netflix-movies-2021-all-70-movies-releasing-on-netflix-this-year/
+ 72. https://fossbytes.com/security-focused-tails-os-plans-to-switch-from-xorg-to-wayland/
+ 73. https://fossbytes.com/cloudlinux-renames-centos-alternative-project-lenix-to-almalinux/
+ 74. https://fossbytes.com/about/
+ 75. https://fossbytes.com/privacy-policy/
+ 76. https://fossbytes.com/cookie-policy-for-fossbytes/
+ 77. https://www.facebook.com/fossbytes
+ 78. https://twitter.com/Fossbytes14
+ 79. https://instagram.com/fossbytes
+ 80. https://fossbytes.com/contact-us/
+ 81. https://fossbytes.com/fossbytes-team/
+ 82. https://fossbytes.com/jobs/
+ 83. https://academy.fossbytes.com/
+ 84. https://www.facebook.com/fossbytes
+ 85. https://twitter.com/Fossbytes14
+ 86. https://instagram.com/fossbytes
+ 87. https://academy.fossbytes.com/
+ 88. https://fossbytes.com/about/
+ 89. https://fossbytes.com/privacy-policy/
+ 90. https://fossbytes.com/cookie-policy-for-fossbytes/
+ 91. https://fossbytes.com/contact-us/
+ 92. https://fossbytes.com/fossbytes-team/
+ 93. https://fossbytes.com/jobs/
+
+ Hidden links:
+ 95. https://fossbytes.com/why-nhtsa-is-asking-tesla-to-recall-158000-model-s-and-model-x/
+ 96. https://fossbytes.com/netflix-movies-2021-all-70-movies-releasing-on-netflix-this-year/
+ 97. https://fossbytes.com/official-best-of-ces-2021/
+ 98. https://fossbytes.com/how-do-electric-cars-work-electric-motors-and-batteries-explained/
+ 99. https://fossbytes.com/netflix-movies-2021-all-70-movies-releasing-on-netflix-this-year/
+ 100. https://fossbytes.com/security-focused-tails-os-plans-to-switch-from-xorg-to-wayland/
+ 101. https://fossbytes.com/cloudlinux-renames-centos-alternative-project-lenix-to-almalinux/
diff --git a/doc/doc/people.freedesktop.org_~narmstrong_meson_drm_doc_admin-guide_initrd.txt b/doc/doc/people.freedesktop.org_~narmstrong_meson_drm_doc_admin-guide_initrd.txt
new file mode 100644
index 0000000..0c2351e
--- /dev/null
+++ b/doc/doc/people.freedesktop.org_~narmstrong_meson_drm_doc_admin-guide_initrd.txt
@@ -0,0 +1,453 @@
+ #[1]The Linux Kernel 4.11.0-rc4-00191-g7de6e5d documentation [2]The
+ Linux kernel user's and administrator's guide [3]Linux Serial Console
+ [4]Rules on how to access information in sysfs
+
+Navigation
+
+ * [5]index
+ * [6]next |
+ * [7]previous |
+ * [8]The Linux Kernel 4.11.0-rc4-00191-g7de6e5d documentation »
+ * [9]The Linux kernel user's and administrator's guide »
+
+Using the initial RAM disk (initrd)[10]¶
+
+ Written 1996,2000 by Werner Almesberger
+ <[11]werner.almesberger@epfl.ch> and Hans Lermen <[12]lermen@fgan.de>
+
+ initrd provides the capability to load a RAM disk by the boot loader.
+ This RAM disk can then be mounted as the root file system and programs
+ can be run from it. Afterwards, a new root file system can be mounted
+ from a different device. The previous root (from initrd) is then moved
+ to a directory and can be subsequently unmounted.
+
+ initrd is mainly designed to allow system startup to occur in two
+ phases, where the kernel comes up with a minimum set of compiled-in
+ drivers, and where additional modules are loaded from initrd.
+
+ This document gives a brief overview of the use of initrd. A more
+ detailed discussion of the boot process can be found in [13][1].
+
+Operation[14]¶
+
+ When using initrd, the system typically boots as follows:
+
+ 1. the boot loader loads the kernel and the initial RAM disk
+ 2. the kernel converts initrd into a "normal" RAM disk and frees the
+ memory used by initrd
+ 3. if the root device is not /dev/ram0, the old (deprecated)
+ change_root procedure is followed. see the "Obsolete root change
+ mechanism" section below.
+ 4. root device is mounted. if it is /dev/ram0, the initrd image is
+ then mounted as root
+ 5. /sbin/init is executed (this can be any valid executable, including
+ shell scripts; it is run with uid 0 and can do basically everything
+ init can do).
+ 6. init mounts the "real" root file system
+ 7. init places the root file system at the root directory using the
+ pivot_root system call
+ 8. init execs the /sbin/init on the new root filesystem, performing
+ the usual boot sequence
+ 9. the initrd file system is removed
+
+ Note that changing the root directory does not involve unmounting it.
+ It is therefore possible to leave processes running on initrd during
+ that procedure. Also note that file systems mounted under initrd
+ continue to be accessible.
+
+Boot command-line options[15]¶
+
+ initrd adds the following new options:
+initrd=<path> (e.g. LOADLIN)
+
+ Loads the specified file as the initial RAM disk. When using LILO, you
+ have to specify the RAM disk image file in /etc/lilo.conf, using the
+ INITRD configuration variable.
+
+noinitrd
+
+ initrd data is preserved but it is not converted to a RAM disk and
+ the "normal" root file system is mounted. initrd data can be read
+ from /dev/initrd. Note that the data in initrd can have any structure
+ in this case and doesn't necessarily have to be a file system image.
+ This option is used mainly for debugging.
+
+ Note: /dev/initrd is read-only and it can only be used once. As soon
+ as the last process has closed it, all data is freed and /dev/initrd
+ can't be opened anymore.
+
+root=/dev/ram0
+
+ initrd is mounted as root, and the normal boot procedure is followed,
+ with the RAM disk mounted as root.
+
+Compressed cpio images[16]¶
+
+ Recent kernels have support for populating a ramdisk from a compressed
+ cpio archive. On such systems, the creation of a ramdisk image doesn't
+ need to involve special block devices or loopbacks; you merely create a
+ directory on disk with the desired initrd content, cd to that
+ directory, and run (as an example):
+find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/imagefile.img
+
+ Examining the contents of an existing image file is just as simple:
+mkdir /tmp/imagefile
+cd /tmp/imagefile
+gzip -cd /boot/imagefile.img | cpio -imd --quiet
+
+Installation[17]¶
+
+ First, a directory for the initrd file system has to be created on the
+ "normal" root file system, e.g.:
+# mkdir /initrd
+
+ The name is not relevant. More details can be found on the
+ pivot_root(2) man page.
+
+ If the root file system is created during the boot procedure (i.e. if
+ you're building an install floppy), the root file system creation
+ procedure should create the /initrd directory.
+
+ If initrd will not be mounted in some cases, its content is still
+ accessible if the following device has been created:
+# mknod /dev/initrd b 1 250
+# chmod 400 /dev/initrd
+
+ Second, the kernel has to be compiled with RAM disk support and with
+ support for the initial RAM disk enabled. Also, at least all components
+ needed to execute programs from initrd (e.g. executable format and file
+ system) must be compiled into the kernel.
+
+ Third, you have to create the RAM disk image. This is done by creating
+ a file system on a block device, copying files to it as needed, and
+ then copying the content of the block device to the initrd file. With
+ recent kernels, at least three types of devices are suitable for that:
+
+ * a floppy disk (works everywhere but it's painfully slow)
+ * a RAM disk (fast, but allocates physical memory)
+ * a loopback device (the most elegant solution)
+
+ We'll describe the loopback device method:
+
+ 1. make sure loopback block devices are configured into the kernel
+ 2. create an empty file system of the appropriate size, e.g.:
+# dd if=/dev/zero of=initrd bs=300k count=1
+# mke2fs -F -m0 initrd
+
+ (if space is critical, you may want to use the Minix FS instead of
+ Ext2)
+ 3. mount the file system, e.g.:
+# mount -t ext2 -o loop initrd /mnt
+
+ 4. create the console device:
+# mkdir /mnt/dev
+# mknod /mnt/dev/console c 5 1
+
+ 5. copy all the files that are needed to properly use the initrd
+ environment. Don't forget the most important file, /sbin/init
+ Note
+ /sbin/init permissions must include "x" (execute).
+ 6. correct operation the initrd environment can frequently be tested
+ even without rebooting with the command:
+# chroot /mnt /sbin/init
+
+ This is of course limited to initrds that do not interfere with the
+ general system state (e.g. by reconfiguring network interfaces,
+ overwriting mounted devices, trying to start already running
+ demons, etc. Note however that it is usually possible to use
+ pivot_root in such a chroot'ed initrd environment.)
+ 7. unmount the file system:
+# umount /mnt
+
+ 8. the initrd is now in the file "initrd". Optionally, it can now be
+ compressed:
+# gzip -9 initrd
+
+ For experimenting with initrd, you may want to take a rescue floppy and
+ only add a symbolic link from /sbin/init to /bin/sh. Alternatively, you
+ can try the experimental newlib environment [18][2] to create a small
+ initrd.
+
+ Finally, you have to boot the kernel and load initrd. Almost all Linux
+ boot loaders support initrd. Since the boot process is still compatible
+ with an older mechanism, the following boot command line parameters
+ have to be given:
+root=/dev/ram0 rw
+
+ (rw is only necessary if writing to the initrd file system.)
+
+ With LOADLIN, you simply execute:
+LOADLIN <kernel> initrd=<disk_image>
+
+ e.g.:
+LOADLIN C:\LINUX\BZIMAGE initrd=C:\LINUX\INITRD.GZ root=/dev/ram0 rw
+
+ With LILO, you add the option INITRD=<path> to either the global
+ section or to the section of the respective kernel in /etc/lilo.conf,
+ and pass the options using APPEND, e.g.:
+image = /bzImage
+ initrd = /boot/initrd.gz
+ append = "root=/dev/ram0 rw"
+
+ and run /sbin/lilo
+
+ For other boot loaders, please refer to the respective documentation.
+
+ Now you can boot and enjoy using initrd.
+
+Changing the root device[19]¶
+
+ When finished with its duties, init typically changes the root device
+ and proceeds with starting the Linux system on the "real" root device.
+
+ The procedure involves the following steps:
+
+ + mounting the new root file system
+ + turning it into the root file system
+ + removing all accesses to the old (initrd) root file system
+ + unmounting the initrd file system and de-allocating the RAM
+ disk
+
+ Mounting the new root file system is easy: it just needs to be mounted
+ on a directory under the current root. Example:
+# mkdir /new-root
+# mount -o ro /dev/hda1 /new-root
+
+ The root change is accomplished with the pivot_root system call, which
+ is also available via the pivot_root utility (see pivot_root(8) man
+ page; pivot_root is distributed with util-linux version 2.10h or higher
+ [20][3]). pivot_root moves the current root to a directory under the
+ new root, and puts the new root at its place. The directory for the old
+ root must exist before calling pivot_root. Example:
+# cd /new-root
+# mkdir initrd
+# pivot_root . initrd
+
+ Now, the init process may still access the old root via its executable,
+ shared libraries, standard input/output/error, and its current root
+ directory. All these references are dropped by the following command:
+# exec chroot . what-follows <dev/console >dev/console 2>&1
+
+ Where what-follows is a program under the new root, e.g. /sbin/init If
+ the new root file system will be used with udev and has no valid /dev
+ directory, udev must be initialized before invoking chroot in order to
+ provide /dev/console.
+
+ Note: implementation details of pivot_root may change with time. In
+ order to ensure compatibility, the following points should be observed:
+
+ * before calling pivot_root, the current directory of the invoking
+ process should point to the new root directory
+ * use . as the first argument, and the _relative_ path of the
+ directory for the old root as the second argument
+ * a chroot program must be available under the old and the new root
+ * chroot to the new root afterwards
+ * use relative paths for dev/console in the exec command
+
+ Now, the initrd can be unmounted and the memory allocated by the RAM
+ disk can be freed:
+# umount /initrd
+# blockdev --flushbufs /dev/ram0
+
+ It is also possible to use initrd with an NFS-mounted root, see the
+ pivot_root(8) man page for details.
+
+Usage scenarios[21]¶
+
+ The main motivation for implementing initrd was to allow for modular
+ kernel configuration at system installation. The procedure would work
+ as follows:
+
+ 1. system boots from floppy or other media with a minimal kernel (e.g.
+ support for RAM disks, initrd, a.out, and the Ext2 FS) and loads
+ initrd
+ 2. /sbin/init determines what is needed to (1) mount the "real" root
+ FS (i.e. device type, device drivers, file system) and (2) the
+ distribution media (e.g. CD-ROM, network, tape, ...). This can be
+ done by asking the user, by auto-probing, or by using a hybrid
+ approach.
+ 3. /sbin/init loads the necessary kernel modules
+ 4. /sbin/init creates and populates the root file system (this doesn't
+ have to be a very usable system yet)
+ 5. /sbin/init invokes pivot_root to change the root file system and
+ execs - via chroot - a program that continues the installation
+ 6. the boot loader is installed
+ 7. the boot loader is configured to load an initrd with the set of
+ modules that was used to bring up the system (e.g. /initrd can be
+ modified, then unmounted, and finally, the image is written from
+ /dev/ram0 or /dev/rd/0 to a file)
+ 8. now the system is bootable and additional installation tasks can be
+ performed
+
+ The key role of initrd here is to re-use the configuration data during
+ normal system operation without requiring the use of a bloated
+ "generic" kernel or re-compiling or re-linking the kernel.
+
+ A second scenario is for installations where Linux runs on systems with
+ different hardware configurations in a single administrative domain. In
+ such cases, it is desirable to generate only a small set of kernels
+ (ideally only one) and to keep the system-specific part of
+ configuration information as small as possible. In this case, a common
+ initrd could be generated with all the necessary modules. Then, only
+ /sbin/init or a file read by it would have to be different.
+
+ A third scenario is more convenient recovery disks, because information
+ like the location of the root FS partition doesn't have to be provided
+ at boot time, but the system loaded from initrd can invoke a
+ user-friendly dialog and it can also perform some sanity checks (or
+ even some form of auto-detection).
+
+ Last not least, CD-ROM distributors may use it for better installation
+ from CD, e.g. by using a boot floppy and bootstrapping a bigger RAM
+ disk via initrd from CD; or by booting via a loader like LOADLIN or
+ directly from the CD-ROM, and loading the RAM disk from CD without need
+ of floppies.
+
+Obsolete root change mechanism[22]¶
+
+ The following mechanism was used before the introduction of pivot_root.
+ Current kernels still support it, but you should _not_ rely on its
+ continued availability.
+
+ It works by mounting the "real" root device (i.e. the one set with rdev
+ in the kernel image or with root=... at the boot command line) as the
+ root file system when linuxrc exits. The initrd file system is then
+ unmounted, or, if it is still busy, moved to a directory /initrd, if
+ such a directory exists on the new root file system.
+
+ In order to use this mechanism, you do not have to specify the boot
+ command options root, init, or rw. (If specified, they will affect the
+ real root file system, not the initrd environment.)
+
+ If /proc is mounted, the "real" root device can be changed from within
+ linuxrc by writing the number of the new root FS device to the special
+ file /proc/sys/kernel/real-root-dev, e.g.:
+# echo 0x301 >/proc/sys/kernel/real-root-dev
+
+ Note that the mechanism is incompatible with NFS and similar file
+ systems.
+
+ This old, deprecated mechanism is commonly called change_root, while
+ the new, supported mechanism is called pivot_root.
+
+Mixed change_root and pivot_root mechanism[23]¶
+
+ In case you did not want to use root=/dev/ram0 to trigger the
+ pivot_root mechanism, you may create both /linuxrc and /sbin/init in
+ your initrd image.
+
+ /linuxrc would contain only the following:
+#! /bin/sh
+mount -n -t proc proc /proc
+echo 0x0100 >/proc/sys/kernel/real-root-dev
+umount -n /proc
+
+ Once linuxrc exited, the kernel would mount again your initrd as root,
+ this time executing /sbin/init. Again, it would be the duty of this
+ init to build the right environment (maybe using the root= device
+ passed on the cmdline) before the final execution of the real
+ /sbin/init.
+
+Resources[24]¶
+
+ [25][1] Almesberger, Werner; "Booting Linux: The History and the
+ Future" [26]http://www.almesberger.net/cv/papers/ols2k-9.ps.gz
+ [27][2] newlib package (experimental), with initrd example
+ [28]https://www.sourceware.org/newlib/
+ [29][3] util-linux: Miscellaneous utilities for Linux
+ [30]https://www.kernel.org/pub/linux/utils/util-linux/
+
+[31]Table Of Contents
+
+ * [32]Using the initial RAM disk (initrd)
+ + [33]Operation
+ + [34]Boot command-line options
+ + [35]Compressed cpio images
+ + [36]Installation
+ + [37]Changing the root device
+ + [38]Usage scenarios
+ + [39]Obsolete root change mechanism
+ + [40]Mixed change_root and pivot_root mechanism
+ + [41]Resources
+
+Previous topic
+
+ [42]Rules on how to access information in sysfs
+
+Next topic
+
+ [43]Linux Serial Console
+
+This Page
+
+ * [44]Show Source
+
+Quick search
+
+ ____________________ Go
+
+ Enter search terms or a module, class or function name.
+
+Navigation
+
+ * [45]index
+ * [46]next |
+ * [47]previous |
+ * [48]The Linux Kernel 4.11.0-rc4-00191-g7de6e5d documentation »
+ * [49]The Linux kernel user's and administrator's guide »
+
+ © Copyright The kernel development community. Created using [50]Sphinx
+ 1.2.2.
+
+References
+
+ 1. https://people.freedesktop.org/~narmstrong/meson_drm_doc/index.html
+ 2. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/index.html
+ 3. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/serial-console.html
+ 4. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/sysfs-rules.html
+ 5. https://people.freedesktop.org/~narmstrong/meson_drm_doc/genindex.html
+ 6. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/serial-console.html
+ 7. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/sysfs-rules.html
+ 8. https://people.freedesktop.org/~narmstrong/meson_drm_doc/index.html
+ 9. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/index.html
+ 10. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#using-the-initial-ram-disk-initrd
+ 11. mailto:werner.almesberger%40epfl.ch
+ 12. mailto:lermen%40fgan.de
+ 13. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#f1
+ 14. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#operation
+ 15. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#boot-command-line-options
+ 16. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#compressed-cpio-images
+ 17. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#installation
+ 18. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#f2
+ 19. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#changing-the-root-device
+ 20. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#f3
+ 21. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#usage-scenarios
+ 22. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#obsolete-root-change-mechanism
+ 23. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#mixed-change-root-and-pivot-root-mechanism
+ 24. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#resources
+ 25. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#id1
+ 26. http://www.almesberger.net/cv/papers/ols2k-9.ps.gz
+ 27. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#id2
+ 28. https://www.sourceware.org/newlib/
+ 29. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#id3
+ 30. https://www.kernel.org/pub/linux/utils/util-linux/
+ 31. https://people.freedesktop.org/~narmstrong/meson_drm_doc/index.html
+ 32. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html
+ 33. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#operation
+ 34. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#boot-command-line-options
+ 35. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#compressed-cpio-images
+ 36. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#installation
+ 37. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#changing-the-root-device
+ 38. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#usage-scenarios
+ 39. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#obsolete-root-change-mechanism
+ 40. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#mixed-change-root-and-pivot-root-mechanism
+ 41. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/initrd.html#resources
+ 42. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/sysfs-rules.html
+ 43. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/serial-console.html
+ 44. https://people.freedesktop.org/~narmstrong/meson_drm_doc/_sources/admin-guide/initrd.txt
+ 45. https://people.freedesktop.org/~narmstrong/meson_drm_doc/genindex.html
+ 46. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/serial-console.html
+ 47. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/sysfs-rules.html
+ 48. https://people.freedesktop.org/~narmstrong/meson_drm_doc/index.html
+ 49. https://people.freedesktop.org/~narmstrong/meson_drm_doc/admin-guide/index.html
+ 50. http://sphinx-doc.org/
diff --git a/doc/doc/www.kernel.org_doc_html_latest_x86_boot.txt b/doc/doc/www.kernel.org_doc_html_latest_x86_boot.txt
new file mode 100644
index 0000000..0ef56f7
--- /dev/null
+++ b/doc/doc/www.kernel.org_doc_html_latest_x86_boot.txt
@@ -0,0 +1,2349 @@
+ #[1]Index [2]Search [3]2. DeviceTree Booting [4]x86-specific
+ Documentation
+
+[5]The Linux Kernel
+
+ 6.3.0-rc6
+
+Quick search
+
+ ____________________ Go
+
+Contents
+
+ [X]
+ * [6]A guide to the Kernel Development Process
+ * [7]Submitting patches: the essential guide to getting your code
+ into the kernel
+ * [8]Code of conduct
+ * [9]Kernel Maintainer Handbook
+ * [10]All development-process docs
+
+ * [11]Core API Documentation
+ * [12]Driver implementer's API guide
+ * [13]Kernel subsystem documentation
+ * [14]Locking in the kernel
+
+ * [15]Linux kernel licensing rules
+ * [16]How to write kernel documentation
+ * [17]Development tools for the kernel
+ * [18]Kernel Testing Guide
+ * [19]Kernel Hacking Guides
+ * [20]Linux Tracing Technologies
+ * [21]fault-injection
+ * [22]Kernel Livepatching
+ * [23]Rust
+
+ * [24]The Linux kernel user's and administrator's guide
+ * [25]The kernel build system
+ * [26]Reporting issues
+ * [27]User-space tools
+ * [28]The Linux kernel user-space API guide
+
+ * [29]The Linux kernel firmware guide
+ * [30]Open Firmware and Devicetree
+
+ * [31]CPU Architectures
+ + [32]ARC architecture
+ + [33]ARM Architecture
+ + [34]ARM64 Architecture
+ + [35]IA-64 Architecture
+ + [36]LoongArch Architecture
+ + [37]m68k Architecture
+ + [38]MIPS-specific Documentation
+ + [39]Nios II Specific Documentation
+ + [40]OpenRISC Architecture
+ + [41]PA-RISC Architecture
+ + [42]powerpc
+ + [43]RISC-V architecture
+ + [44]s390 Architecture
+ + [45]SuperH Interfaces Guide
+ + [46]Sparc Architecture
+ + [47]x86-specific Documentation
+ o [48]1. The Linux/x86 Boot Protocol
+ o [49]2. DeviceTree Booting
+ o [50]3. x86 Feature Flags
+ o [51]4. x86 Topology
+ o [52]5. Kernel level exception handling
+ o [53]6. Kernel Stacks
+ o [54]7. Kernel Entries
+ o [55]8. Early Printk
+ o [56]9. ORC unwinder
+ o [57]10. Zero Page
+ o [58]11. The TLB
+ o [59]12. MTRR (Memory Type Range Register) control
+ o [60]13. PAT (Page Attribute Table)
+ o [61]14. Hardware-Feedback Interface for scheduling on
+ Intel Hardware
+ o [62]15. x86 IOMMU Support
+ o [63]16. Intel(R) TXT Overview
+ o [64]17. AMD Memory Encryption
+ o [65]18. AMD HSMP interface
+ o [66]19. Intel Trust Domain Extensions (TDX)
+ o [67]20. Page Table Isolation (PTI)
+ o [68]21. Microarchitectural Data Sampling (MDS) mitigation
+ o [69]22. The Linux Microcode Loader
+ o [70]23. User Interface for Resource Control feature
+ o [71]24. TSX Async Abort (TAA) mitigation
+ o [72]25. Bus lock detection and handling
+ o [73]26. USB Legacy support
+ o [74]27. i386 Support
+ o [75]28. x86_64 Support
+ o [76]29. In-Field Scan
+ o [77]30. Shared Virtual Addressing (SVA) with ENQCMD
+ o [78]31. Software Guard eXtensions (SGX)
+ o [79]32. Feature status on x86 architecture
+ o [80]33. x86-specific ELF Auxiliary Vectors
+ o [81]34. Using XSTATE features in user space applications
+ + [82]Xtensa Architecture
+
+ * [83]Unsorted Documentation
+
+ * [84]Translations
+
+This Page
+
+ * [85]Show Source
+
+1. The Linux/x86 Boot Protocol[86]¶
+
+ On the x86 platform, the Linux kernel uses a rather complicated boot
+ convention. This has evolved partially due to historical aspects, as
+ well as the desire in the early days to have the kernel itself be a
+ bootable image, the complicated PC memory model and due to changed
+ expectations in the PC industry caused by the effective demise of
+ real-mode DOS as a mainstream operating system.
+
+ Currently, the following versions of the Linux/x86 boot protocol exist.
+
+ Old kernels
+
+ zImage/Image support only. Some very early kernels may not even support
+ a command line.
+
+ Protocol 2.00
+
+ (Kernel 1.3.73) Added bzImage and initrd support, as well as a
+ formalized way to communicate between the boot loader and the kernel.
+ setup.S made relocatable, although the traditional setup area still
+ assumed writable.
+
+ Protocol 2.01
+
+ (Kernel 1.3.76) Added a heap overrun warning.
+
+ Protocol 2.02
+
+ (Kernel 2.4.0-test3-pre3) New command line protocol. Lower the
+ conventional memory ceiling. No overwrite of the traditional setup
+ area, thus making booting safe for systems which use the EBDA from SMM
+ or 32-bit BIOS entry points. zImage deprecated but still supported.
+
+ Protocol 2.03
+
+ (Kernel 2.4.18-pre1) Explicitly makes the highest possible initrd
+ address available to the bootloader.
+
+ Protocol 2.04
+
+ (Kernel 2.6.14) Extend the syssize field to four bytes.
+
+ Protocol 2.05
+
+ (Kernel 2.6.20) Make protected mode kernel relocatable. Introduce
+ relocatable_kernel and kernel_alignment fields.
+
+ Protocol 2.06
+
+ (Kernel 2.6.22) Added a field that contains the size of the boot
+ command line.
+
+ Protocol 2.07
+
+ (Kernel 2.6.24) Added paravirtualised boot protocol. Introduced
+ hardware_subarch and hardware_subarch_data and KEEP_SEGMENTS flag in
+ load_flags.
+
+ Protocol 2.08
+
+ (Kernel 2.6.26) Added crc32 checksum and ELF format payload. Introduced
+ payload_offset and payload_length fields to aid in locating the
+ payload.
+
+ Protocol 2.09
+
+ (Kernel 2.6.26) Added a field of 64-bit physical pointer to single
+ linked list of struct setup_data.
+
+ Protocol 2.10
+
+ (Kernel 2.6.31) Added a protocol for relaxed alignment beyond the
+ kernel_alignment added, new init_size and pref_address fields. Added
+ extended boot loader IDs.
+
+ Protocol 2.11
+
+ (Kernel 3.6) Added a field for offset of EFI handover protocol entry
+ point.
+
+ Protocol 2.12
+
+ (Kernel 3.8) Added the xloadflags field and extension fields to struct
+ boot_params for loading bzImage and ramdisk above 4G in 64bit.
+
+ Protocol 2.13
+
+ (Kernel 3.14) Support 32- and 64-bit flags being set in xloadflags to
+ support booting a 64-bit kernel from 32-bit EFI
+
+ Protocol 2.14
+
+ BURNT BY INCORRECT COMMIT ae7e1238e68f2a472a125673ab506d49158c1889
+ (x86/boot: Add ACPI RSDP address to setup_header) DO NOT USE!!! ASSUME
+ SAME AS 2.13.
+
+ Protocol 2.15
+
+ (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
+
+ Note
+
+ The protocol version number should be changed only if the setup header
+ is changed. There is no need to update the version number if
+ boot_params or kernel_info are changed. Additionally, it is recommended
+ to use xloadflags (in this case the protocol version number should not
+ be updated either) or kernel_info to communicate supported Linux kernel
+ features to the boot loader. Due to very limited space available in the
+ original setup header every update to it should be considered with
+ great care. Starting from the protocol 2.15 the primary way to
+ communicate things to the boot loader is the kernel_info.
+
+1.1. Memory Layout[87]¶
+
+ The traditional memory map for the kernel loader, used for Image or
+ zImage kernels, typically looks like:
+ | |
+0A0000 +------------------------+
+ | Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
+09A000 +------------------------+
+ | Command line |
+ | Stack/heap | For use by the kernel real-mode code.
+098000 +------------------------+
+ | Kernel setup | The kernel real-mode code.
+090200 +------------------------+
+ | Kernel boot sector | The kernel legacy boot sector.
+090000 +------------------------+
+ | Protected-mode kernel | The bulk of the kernel image.
+010000 +------------------------+
+ | Boot loader | <- Boot sector entry point 0000:7C00
+001000 +------------------------+
+ | Reserved for MBR/BIOS |
+000800 +------------------------+
+ | Typically used by MBR |
+000600 +------------------------+
+ | BIOS use only |
+000000 +------------------------+
+
+ When using bzImage, the protected-mode kernel was relocated to 0x100000
+ ("high memory"), and the kernel real-mode block (boot sector, setup,
+ and stack/heap) was made relocatable to any address between 0x10000 and
+ end of low memory. Unfortunately, in protocols 2.00 and 2.01 the
+ 0x90000+ memory range is still used internally by the kernel; the 2.02
+ protocol resolves that problem.
+
+ It is desirable to keep the "memory ceiling" - the highest point in low
+ memory touched by the boot loader - as low as possible, since some
+ newer BIOSes have begun to allocate some rather large amounts of
+ memory, called the Extended BIOS Data Area, near the top of low memory.
+ The boot loader should use the "INT 12h" BIOS call to verify how much
+ low memory is available.
+
+ Unfortunately, if INT 12h reports that the amount of memory is too low,
+ there is usually nothing the boot loader can do but to report an error
+ to the user. The boot loader should therefore be designed to take up as
+ little space in low memory as it reasonably can. For zImage or old
+ bzImage kernels, which need data written into the 0x90000 segment, the
+ boot loader should make sure not to use memory above the 0x9A000 point;
+ too many BIOSes will break above that point.
+
+ For a modern bzImage kernel with boot protocol version >= 2.02, a
+ memory layout like the following is suggested:
+ ~ ~
+ | Protected-mode kernel |
+ 100000 +------------------------+
+ | I/O memory hole |
+ 0A0000 +------------------------+
+ | Reserved for BIOS | Leave as much as possible unused
+ ~ ~
+ | Command line | (Can also be below the X+10000 mar
+k)
+ X+10000 +------------------------+
+ | Stack/heap | For use by the kernel real-mode co
+de.
+ X+08000 +------------------------+
+ | Kernel setup | The kernel real-mode code.
+ | Kernel boot sector | The kernel legacy boot sector.
+ X +------------------------+
+ | Boot loader | <- Boot sector entry point 0000:7C
+00
+ 001000 +------------------------+
+ | Reserved for MBR/BIOS |
+ 000800 +------------------------+
+ | Typically used by MBR |
+ 000600 +------------------------+
+ | BIOS use only |
+ 000000 +------------------------+
+
+... where the address X is as low as the design of the boot loader permits.
+
+1.2. The Real-Mode Kernel Header[88]¶
+
+ In the following text, and anywhere in the kernel boot sequence, "a
+ sector" refers to 512 bytes. It is independent of the actual sector
+ size of the underlying medium.
+
+ The first step in loading a Linux kernel should be to load the
+ real-mode code (boot sector and setup code) and then examine the
+ following header at offset 0x01f1. The real-mode code can total up to
+ 32K, although the boot loader may choose to load only the first two
+ sectors (1K) and then examine the bootup sector size.
+
+ The header looks like:
+
+ Offset/Size
+
+ Proto
+
+ Name
+
+ Meaning
+
+ 01F1/1
+
+ ALL(1)
+
+ setup_sects
+
+ The size of the setup in sectors
+
+ 01F2/2
+
+ ALL
+
+ root_flags
+
+ If set, the root is mounted readonly
+
+ 01F4/4
+
+ 2.04+(2)
+
+ syssize
+
+ The size of the 32-bit code in 16-byte paras
+
+ 01F8/2
+
+ ALL
+
+ ram_size
+
+ DO NOT USE - for bootsect.S use only
+
+ 01FA/2
+
+ ALL
+
+ vid_mode
+
+ Video mode control
+
+ 01FC/2
+
+ ALL
+
+ root_dev
+
+ Default root device number
+
+ 01FE/2
+
+ ALL
+
+ boot_flag
+
+ 0xAA55 magic number
+
+ 0200/2
+
+ 2.00+
+
+ jump
+
+ Jump instruction
+
+ 0202/4
+
+ 2.00+
+
+ header
+
+ Magic signature "HdrS"
+
+ 0206/2
+
+ 2.00+
+
+ version
+
+ Boot protocol version supported
+
+ 0208/4
+
+ 2.00+
+
+ realmode_swtch
+
+ Boot loader hook (see below)
+
+ 020C/2
+
+ 2.00+
+
+ start_sys_seg
+
+ The load-low segment (0x1000) (obsolete)
+
+ 020E/2
+
+ 2.00+
+
+ kernel_version
+
+ Pointer to kernel version string
+
+ 0210/1
+
+ 2.00+
+
+ type_of_loader
+
+ Boot loader identifier
+
+ 0211/1
+
+ 2.00+
+
+ loadflags
+
+ Boot protocol option flags
+
+ 0212/2
+
+ 2.00+
+
+ setup_move_size
+
+ Move to high memory size (used with hooks)
+
+ 0214/4
+
+ 2.00+
+
+ code32_start
+
+ Boot loader hook (see below)
+
+ 0218/4
+
+ 2.00+
+
+ ramdisk_image
+
+ initrd load address (set by boot loader)
+
+ 021C/4
+
+ 2.00+
+
+ ramdisk_size
+
+ initrd size (set by boot loader)
+
+ 0220/4
+
+ 2.00+
+
+ bootsect_kludge
+
+ DO NOT USE - for bootsect.S use only
+
+ 0224/2
+
+ 2.01+
+
+ heap_end_ptr
+
+ Free memory after setup end
+
+ 0226/1
+
+ 2.02+(3)
+
+ ext_loader_ver
+
+ Extended boot loader version
+
+ 0227/1
+
+ 2.02+(3)
+
+ ext_loader_type
+
+ Extended boot loader ID
+
+ 0228/4
+
+ 2.02+
+
+ cmd_line_ptr
+
+ 32-bit pointer to the kernel command line
+
+ 022C/4
+
+ 2.03+
+
+ initrd_addr_max
+
+ Highest legal initrd address
+
+ 0230/4
+
+ 2.05+
+
+ kernel_alignment
+
+ Physical addr alignment required for kernel
+
+ 0234/1
+
+ 2.05+
+
+ relocatable_kernel
+
+ Whether kernel is relocatable or not
+
+ 0235/1
+
+ 2.10+
+
+ min_alignment
+
+ Minimum alignment, as a power of two
+
+ 0236/2
+
+ 2.12+
+
+ xloadflags
+
+ Boot protocol option flags
+
+ 0238/4
+
+ 2.06+
+
+ cmdline_size
+
+ Maximum size of the kernel command line
+
+ 023C/4
+
+ 2.07+
+
+ hardware_subarch
+
+ Hardware subarchitecture
+
+ 0240/8
+
+ 2.07+
+
+ hardware_subarch_data
+
+ Subarchitecture-specific data
+
+ 0248/4
+
+ 2.08+
+
+ payload_offset
+
+ Offset of kernel payload
+
+ 024C/4
+
+ 2.08+
+
+ payload_length
+
+ Length of kernel payload
+
+ 0250/8
+
+ 2.09+
+
+ setup_data
+
+ 64-bit physical pointer to linked list of struct setup_data
+
+ 0258/8
+
+ 2.10+
+
+ pref_address
+
+ Preferred loading address
+
+ 0260/4
+
+ 2.10+
+
+ init_size
+
+ Linear memory required during initialization
+
+ 0264/4
+
+ 2.11+
+
+ handover_offset
+
+ Offset of handover entry point
+
+ 0268/4
+
+ 2.15+
+
+ kernel_info_offset
+
+ Offset of the kernel_info
+
+ Note
+ 1. For backwards compatibility, if the setup_sects field contains 0,
+ the real value is 4.
+ 2. For boot protocol prior to 2.04, the upper two bytes of the syssize
+ field are unusable, which means the size of a bzImage kernel cannot
+ be determined.
+ 3. Ignored, but safe to set, for boot protocols 2.02-2.09.
+
+ If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
+ the boot protocol version is "old". Loading an old kernel, the
+ following parameters should be assumed:
+Image type = zImage
+initrd not supported
+Real-mode kernel must be located at 0x90000.
+
+ Otherwise, the "version" field contains the protocol version, e.g.
+ protocol version 2.01 will contain 0x0201 in this field. When setting
+ fields in the header, you must make sure only to set fields supported
+ by the protocol version in use.
+
+1.3. Details of Header Fields[89]¶
+
+ For each field, some are information from the kernel to the bootloader
+ ("read"), some are expected to be filled out by the bootloader
+ ("write"), and some are expected to be read and modified by the
+ bootloader ("modify").
+
+ All general purpose boot loaders should write the fields marked
+ (obligatory). Boot loaders who want to load the kernel at a nonstandard
+ address should fill in the fields marked (reloc); other boot loaders
+ can ignore those fields.
+
+ The byte order of all fields is littleendian (this is x86, after all.)
+
+ Field name:
+
+ setup_sects
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x1f1/1
+
+ Protocol:
+
+ ALL
+
+ The size of the setup code in 512-byte sectors. If this field is 0, the
+ real value is 4. The real-mode code consists of the boot sector (always
+ one 512-byte sector) plus the setup code.
+
+ Field name:
+
+ root_flags
+
+ Type:
+
+ modify (optional)
+
+ Offset/size:
+
+ 0x1f2/2
+
+ Protocol:
+
+ ALL
+
+ If this field is nonzero, the root defaults to readonly. The use of
+ this field is deprecated; use the "ro" or "rw" options on the command
+ line instead.
+
+ Field name:
+
+ syssize
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x1f4/4 (protocol 2.04+) 0x1f4/2 (protocol ALL)
+
+ Protocol:
+
+ 2.04+
+
+ The size of the protected-mode code in units of 16-byte paragraphs. For
+ protocol versions older than 2.04 this field is only two bytes wide,
+ and therefore cannot be trusted for the size of a kernel if the
+ LOAD_HIGH flag is set.
+
+ Field name:
+
+ ram_size
+
+ Type:
+
+ kernel internal
+
+ Offset/size:
+
+ 0x1f8/2
+
+ Protocol:
+
+ ALL
+
+ This field is obsolete.
+
+ Field name:
+
+ vid_mode
+
+ Type:
+
+ modify (obligatory)
+
+ Offset/size:
+
+ 0x1fa/2
+
+ Please see the section on SPECIAL COMMAND LINE OPTIONS.
+
+ Field name:
+
+ root_dev
+
+ Type:
+
+ modify (optional)
+
+ Offset/size:
+
+ 0x1fc/2
+
+ Protocol:
+
+ ALL
+
+ The default root device device number. The use of this field is
+ deprecated, use the "root=" option on the command line instead.
+
+ Field name:
+
+ boot_flag
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x1fe/2
+
+ Protocol:
+
+ ALL
+
+ Contains 0xAA55. This is the closest thing old Linux kernels have to a
+ magic number.
+
+ Field name:
+
+ jump
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x200/2
+
+ Protocol:
+
+ 2.00+
+
+ Contains an x86 jump instruction, 0xEB followed by a signed offset
+ relative to byte 0x202. This can be used to determine the size of the
+ header.
+
+ Field name:
+
+ header
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x202/4
+
+ Protocol:
+
+ 2.00+
+
+ Contains the magic number "HdrS" (0x53726448).
+
+ Field name:
+
+ version
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x206/2
+
+ Protocol:
+
+ 2.00+
+
+ Contains the boot protocol version, in (major << 8)+minor format, e.g.
+ 0x0204 for version 2.04, and 0x0a11 for a hypothetical version 10.17.
+
+ Field name:
+
+ realmode_swtch
+
+ Type:
+
+ modify (optional)
+
+ Offset/size:
+
+ 0x208/4
+
+ Protocol:
+
+ 2.00+
+
+ Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.)
+
+ Field name:
+
+ start_sys_seg
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x20c/2
+
+ Protocol:
+
+ 2.00+
+
+ The load low segment (0x1000). Obsolete.
+
+ Field name:
+
+ kernel_version
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x20e/2
+
+ Protocol:
+
+ 2.00+
+
+ If set to a nonzero value, contains a pointer to a NUL-terminated
+ human-readable kernel version number string, less 0x200. This can be
+ used to display the kernel version to the user. This value should be
+ less than (0x200*setup_sects).
+
+ For example, if this value is set to 0x1c00, the kernel version number
+ string can be found at offset 0x1e00 in the kernel file. This is a
+ valid value if and only if the "setup_sects" field contains the value
+ 15 or higher, as:
+0x1c00 < 15*0x200 (= 0x1e00) but
+0x1c00 >= 14*0x200 (= 0x1c00)
+
+0x1c00 >> 9 = 14, So the minimum value for setup_secs is 15.
+
+ Field name:
+
+ type_of_loader
+
+ Type:
+
+ write (obligatory)
+
+ Offset/size:
+
+ 0x210/1
+
+ Protocol:
+
+ 2.00+
+
+ If your boot loader has an assigned id (see table below), enter 0xTV
+ here, where T is an identifier for the boot loader and V is a version
+ number. Otherwise, enter 0xFF here.
+
+ For boot loader IDs above T = 0xD, write T = 0xE to this field and
+ write the extended ID minus 0x10 to the ext_loader_type field.
+ Similarly, the ext_loader_ver field can be used to provide more than
+ four bits for the bootloader version.
+
+ For example, for T = 0x15, V = 0x234, write:
+type_of_loader <- 0xE4
+ext_loader_type <- 0x05
+ext_loader_ver <- 0x23
+
+ Assigned boot loader ids (hexadecimal):
+
+ 0
+
+ LILO (0x00 reserved for pre-2.00 bootloader)
+
+ 1
+
+ Loadlin
+
+ 2
+
+ bootsect-loader (0x20, all other values reserved)
+
+ 3
+
+ Syslinux
+
+ 4
+
+ Etherboot/gPXE/iPXE
+
+ 5
+
+ ELILO
+
+ 7
+
+ GRUB
+
+ 8
+
+ U-Boot
+
+ 9
+
+ Xen
+
+ A
+
+ Gujin
+
+ B
+
+ Qemu
+
+ C
+
+ Arcturus Networks uCbootloader
+
+ D
+
+ kexec-tools
+
+ E
+
+ Extended (see ext_loader_type)
+
+ F
+
+ Special (0xFF = undefined)
+
+ 10
+
+ Reserved
+
+ 11
+
+ Minimal Linux Bootloader <[90]http://sebastian-plotz.blogspot.de>
+
+ 12
+
+ OVMF UEFI virtualization stack
+
+ 13
+
+ barebox
+
+ Please contact <[91]hpa@zytor.com> if you need a bootloader ID value
+ assigned.
+
+ Field name:
+
+ loadflags
+
+ Type:
+
+ modify (obligatory)
+
+ Offset/size:
+
+ 0x211/1
+
+ Protocol:
+
+ 2.00+
+
+ This field is a bitmask.
+
+ Bit 0 (read): LOADED_HIGH
+
+ * If 0, the protected-mode code is loaded at 0x10000.
+ * If 1, the protected-mode code is loaded at 0x100000.
+
+ Bit 1 (kernel internal): KASLR_FLAG
+
+ * Used internally by the compressed kernel to communicate KASLR
+ status to kernel proper.
+
+ + If 1, KASLR enabled.
+ + If 0, KASLR disabled.
+
+ Bit 5 (write): QUIET_FLAG
+
+ * If 0, print early messages.
+ * If 1, suppress early messages.
+
+ This requests to the kernel (decompressor and early kernel) to not
+ write early messages that require accessing the display hardware
+ directly.
+
+ Bit 6 (obsolete): KEEP_SEGMENTS
+
+ Protocol: 2.07+
+ * This flag is obsolete.
+
+ Bit 7 (write): CAN_USE_HEAP
+
+ Set this bit to 1 to indicate that the value entered in the
+ heap_end_ptr is valid. If this field is clear, some setup code
+ functionality will be disabled.
+
+ Field name:
+
+ setup_move_size
+
+ Type:
+
+ modify (obligatory)
+
+ Offset/size:
+
+ 0x212/2
+
+ Protocol:
+
+ 2.00-2.01
+
+ When using protocol 2.00 or 2.01, if the real mode kernel is not loaded
+ at 0x90000, it gets moved there later in the loading sequence. Fill in
+ this field if you want additional data (such as the kernel command
+ line) moved in addition to the real-mode kernel itself.
+
+ The unit is bytes starting with the beginning of the boot sector.
+
+ This field is can be ignored when the protocol is 2.02 or higher, or if
+ the real-mode code is loaded at 0x90000.
+
+ Field name:
+
+ code32_start
+
+ Type:
+
+ modify (optional, reloc)
+
+ Offset/size:
+
+ 0x214/4
+
+ Protocol:
+
+ 2.00+
+
+ The address to jump to in protected mode. This defaults to the load
+ address of the kernel, and can be used by the boot loader to determine
+ the proper load address.
+
+ This field can be modified for two purposes:
+
+ 1. as a boot loader hook (see Advanced Boot Loader Hooks below.)
+ 2. if a bootloader which does not install a hook loads a relocatable
+ kernel at a nonstandard address it will have to modify this field
+ to point to the load address.
+
+ Field name:
+
+ ramdisk_image
+
+ Type:
+
+ write (obligatory)
+
+ Offset/size:
+
+ 0x218/4
+
+ Protocol:
+
+ 2.00+
+
+ The 32-bit linear address of the initial ramdisk or ramfs. Leave at
+ zero if there is no initial ramdisk/ramfs.
+
+ Field name:
+
+ ramdisk_size
+
+ Type:
+
+ write (obligatory)
+
+ Offset/size:
+
+ 0x21c/4
+
+ Protocol:
+
+ 2.00+
+
+ Size of the initial ramdisk or ramfs. Leave at zero if there is no
+ initial ramdisk/ramfs.
+
+ Field name:
+
+ bootsect_kludge
+
+ Type:
+
+ kernel internal
+
+ Offset/size:
+
+ 0x220/4
+
+ Protocol:
+
+ 2.00+
+
+ This field is obsolete.
+
+ Field name:
+
+ heap_end_ptr
+
+ Type:
+
+ write (obligatory)
+
+ Offset/size:
+
+ 0x224/2
+
+ Protocol:
+
+ 2.01+
+
+ Set this field to the offset (from the beginning of the real-mode code)
+ of the end of the setup stack/heap, minus 0x0200.
+
+ Field name:
+
+ ext_loader_ver
+
+ Type:
+
+ write (optional)
+
+ Offset/size:
+
+ 0x226/1
+
+ Protocol:
+
+ 2.02+
+
+ This field is used as an extension of the version number in the
+ type_of_loader field. The total version number is considered to be
+ (type_of_loader & 0x0f) + (ext_loader_ver << 4).
+
+ The use of this field is boot loader specific. If not written, it is
+ zero.
+
+ Kernels prior to 2.6.31 did not recognize this field, but it is safe to
+ write for protocol version 2.02 or higher.
+
+ Field name:
+
+ ext_loader_type
+
+ Type:
+
+ write (obligatory if (type_of_loader & 0xf0) == 0xe0)
+
+ Offset/size:
+
+ 0x227/1
+
+ Protocol:
+
+ 2.02+
+
+ This field is used as an extension of the type number in type_of_loader
+ field. If the type in type_of_loader is 0xE, then the actual type is
+ (ext_loader_type + 0x10).
+
+ This field is ignored if the type in type_of_loader is not 0xE.
+
+ Kernels prior to 2.6.31 did not recognize this field, but it is safe to
+ write for protocol version 2.02 or higher.
+
+ Field name:
+
+ cmd_line_ptr
+
+ Type:
+
+ write (obligatory)
+
+ Offset/size:
+
+ 0x228/4
+
+ Protocol:
+
+ 2.02+
+
+ Set this field to the linear address of the kernel command line. The
+ kernel command line can be located anywhere between the end of the
+ setup heap and 0xA0000; it does not have to be located in the same 64K
+ segment as the real-mode code itself.
+
+ Fill in this field even if your boot loader does not support a command
+ line, in which case you can point this to an empty string (or better
+ yet, to the string "auto".) If this field is left at zero, the kernel
+ will assume that your boot loader does not support the 2.02+ protocol.
+
+ Field name:
+
+ initrd_addr_max
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x22c/4
+
+ Protocol:
+
+ 2.03+
+
+ The maximum address that may be occupied by the initial ramdisk/ramfs
+ contents. For boot protocols 2.02 or earlier, this field is not
+ present, and the maximum address is 0x37FFFFFF. (This address is
+ defined as the address of the highest safe byte, so if your ramdisk is
+ exactly 131072 bytes long and this field is 0x37FFFFFF, you can start
+ your ramdisk at 0x37FE0000.)
+
+ Field name:
+
+ kernel_alignment
+
+ Type:
+
+ read/modify (reloc)
+
+ Offset/size:
+
+ 0x230/4
+
+ Protocol:
+
+ 2.05+ (read), 2.10+ (modify)
+
+ Alignment unit required by the kernel (if relocatable_kernel is true.)
+ A relocatable kernel that is loaded at an alignment incompatible with
+ the value in this field will be realigned during kernel initialization.
+
+ Starting with protocol version 2.10, this reflects the kernel alignment
+ preferred for optimal performance; it is possible for the loader to
+ modify this field to permit a lesser alignment. See the min_alignment
+ and pref_address field below.
+
+ Field name:
+
+ relocatable_kernel
+
+ Type:
+
+ read (reloc)
+
+ Offset/size:
+
+ 0x234/1
+
+ Protocol:
+
+ 2.05+
+
+ If this field is nonzero, the protected-mode part of the kernel can be
+ loaded at any address that satisfies the kernel_alignment field. After
+ loading, the boot loader must set the code32_start field to point to
+ the loaded code, or to a boot loader hook.
+
+ Field name:
+
+ min_alignment
+
+ Type:
+
+ read (reloc)
+
+ Offset/size:
+
+ 0x235/1
+
+ Protocol:
+
+ 2.10+
+
+ This field, if nonzero, indicates as a power of two the minimum
+ alignment required, as opposed to preferred, by the kernel to boot. If
+ a boot loader makes use of this field, it should update the
+ kernel_alignment field with the alignment unit desired; typically:
+kernel_alignment = 1 << min_alignment
+
+ There may be a considerable performance cost with an excessively
+ misaligned kernel. Therefore, a loader should typically try each
+ power-of-two alignment from kernel_alignment down to this alignment.
+
+ Field name:
+
+ xloadflags
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x236/2
+
+ Protocol:
+
+ 2.12+
+
+ This field is a bitmask.
+
+ Bit 0 (read): XLF_KERNEL_64
+
+ * If 1, this kernel has the legacy 64-bit entry point at 0x200.
+
+ Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+
+ * If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+
+ Bit 2 (read): XLF_EFI_HANDOVER_32
+
+ * If 1, the kernel supports the 32-bit EFI handoff entry point given
+ at handover_offset.
+
+ Bit 3 (read): XLF_EFI_HANDOVER_64
+
+ * If 1, the kernel supports the 64-bit EFI handoff entry point given
+ at handover_offset + 0x200.
+
+ Bit 4 (read): XLF_EFI_KEXEC
+
+ * If 1, the kernel supports kexec EFI boot with EFI runtime support.
+
+ Field name:
+
+ cmdline_size
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x238/4
+
+ Protocol:
+
+ 2.06+
+
+ The maximum size of the command line without the terminating zero. This
+ means that the command line can contain at most cmdline_size
+ characters. With protocol version 2.05 and earlier, the maximum size
+ was 255.
+
+ Field name:
+
+ hardware_subarch
+
+ Type:
+
+ write (optional, defaults to x86/PC)
+
+ Offset/size:
+
+ 0x23c/4
+
+ Protocol:
+
+ 2.07+
+
+ In a paravirtualized environment the hardware low level architectural
+ pieces such as interrupt handling, page table handling, and accessing
+ process control registers needs to be done differently.
+
+ This field allows the bootloader to inform the kernel we are in one one
+ of those environments.
+
+ 0x00000000
+
+ The default x86/PC environment
+
+ 0x00000001
+
+ lguest
+
+ 0x00000002
+
+ Xen
+
+ 0x00000003
+
+ Moorestown MID
+
+ 0x00000004
+
+ CE4100 TV Platform
+
+ Field name:
+
+ hardware_subarch_data
+
+ Type:
+
+ write (subarch-dependent)
+
+ Offset/size:
+
+ 0x240/8
+
+ Protocol:
+
+ 2.07+
+
+ A pointer to data that is specific to hardware subarch This field is
+ currently unused for the default x86/PC environment, do not modify.
+
+ Field name:
+
+ payload_offset
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x248/4
+
+ Protocol:
+
+ 2.08+
+
+ If non-zero then this field contains the offset from the beginning of
+ the protected-mode code to the payload.
+
+ The payload may be compressed. The format of both the compressed and
+ uncompressed data should be determined using the standard magic
+ numbers. The currently supported compression formats are gzip (magic
+ numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA (magic number
+ 5D 00), XZ (magic number FD 37), LZ4 (magic number 02 21) and ZSTD
+ (magic number 28 B5). The uncompressed payload is currently always ELF
+ (magic number 7F 45 4C 46).
+
+ Field name:
+
+ payload_length
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x24c/4
+
+ Protocol:
+
+ 2.08+
+
+ The length of the payload.
+
+ Field name:
+
+ setup_data
+
+ Type:
+
+ write (special)
+
+ Offset/size:
+
+ 0x250/8
+
+ Protocol:
+
+ 2.09+
+
+ The 64-bit physical pointer to NULL terminated single linked list of
+ struct setup_data. This is used to define a more extensible boot
+ parameters passing mechanism. The definition of struct setup_data is as
+ follow:
+struct setup_data {
+ u64 next;
+ u32 type;
+ u32 len;
+ u8 data[0];
+};
+
+ Where, the next is a 64-bit physical pointer to the next node of linked
+ list, the next field of the last node is 0; the type is used to
+ identify the contents of data; the len is the length of data field; the
+ data holds the real payload.
+
+ This list may be modified at a number of points during the bootup
+ process. Therefore, when modifying this list one should always make
+ sure to consider the case where the linked list already contains
+ entries.
+
+ The setup_data is a bit awkward to use for extremely large data
+ objects, both because the setup_data header has to be adjacent to the
+ data object and because it has a 32-bit length field. However, it is
+ important that intermediate stages of the boot process have a way to
+ identify which chunks of memory are occupied by kernel data.
+
+ Thus setup_indirect struct and SETUP_INDIRECT type were introduced in
+ protocol 2.15:
+struct setup_indirect {
+ __u32 type;
+ __u32 reserved; /* Reserved, must be set to zero. */
+ __u64 len;
+ __u64 addr;
+};
+
+ The type member is a SETUP_INDIRECT | SETUP_* type. However, it cannot
+ be SETUP_INDIRECT itself since making the setup_indirect a tree
+ structure could require a lot of stack space in something that needs to
+ parse it and stack space can be limited in boot contexts.
+
+ Let's give an example how to point to SETUP_E820_EXT data using
+ setup_indirect. In this case setup_data and setup_indirect will look
+ like this:
+struct setup_data {
+ __u64 next = 0 or <addr_of_next_setup_data_struct>;
+ __u32 type = SETUP_INDIRECT;
+ __u32 len = sizeof(setup_indirect);
+ __u8 data[sizeof(setup_indirect)] = struct setup_indirect {
+ __u32 type = SETUP_INDIRECT | SETUP_E820_EXT;
+ __u32 reserved = 0;
+ __u64 len = <len_of_SETUP_E820_EXT_data>;
+ __u64 addr = <addr_of_SETUP_E820_EXT_data>;
+ }
+}
+
+ Note
+
+ SETUP_INDIRECT | SETUP_NONE objects cannot be properly distinguished
+ from SETUP_INDIRECT itself. So, this kind of objects cannot be provided
+ by the bootloaders.
+
+ Field name:
+
+ pref_address
+
+ Type:
+
+ read (reloc)
+
+ Offset/size:
+
+ 0x258/8
+
+ Protocol:
+
+ 2.10+
+
+ This field, if nonzero, represents a preferred load address for the
+ kernel. A relocating bootloader should attempt to load at this address
+ if possible.
+
+ A non-relocatable kernel will unconditionally move itself and to run at
+ this address.
+
+ Field name:
+
+ init_size
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x260/4
+
+ This field indicates the amount of linear contiguous memory starting at
+ the kernel runtime start address that the kernel needs before it is
+ capable of examining its memory map. This is not the same thing as the
+ total amount of memory the kernel needs to boot, but it can be used by
+ a relocating boot loader to help select a safe load address for the
+ kernel.
+
+ The kernel runtime start address is determined by the following
+ algorithm:
+if (relocatable_kernel)
+runtime_start = align_up(load_address, kernel_alignment)
+else
+runtime_start = pref_address
+
+ Field name:
+
+ handover_offset
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x264/4
+
+ This field is the offset from the beginning of the kernel image to the
+ EFI handover protocol entry point. Boot loaders using the EFI handover
+ protocol to boot the kernel should jump to this offset.
+
+ See EFI HANDOVER PROTOCOL below for more details.
+
+ Field name:
+
+ kernel_info_offset
+
+ Type:
+
+ read
+
+ Offset/size:
+
+ 0x268/4
+
+ Protocol:
+
+ 2.15+
+
+ This field is the offset from the beginning of the kernel image to the
+ kernel_info. The kernel_info structure is embedded in the Linux image
+ in the uncompressed protected mode region.
+
+1.4. The kernel_info[92]¶
+
+ The relationships between the headers are analogous to the various data
+ sections:
+
+ setup_header = .data boot_params/setup_data = .bss
+
+ What is missing from the above list? That's right:
+
+ kernel_info = .rodata
+
+ We have been (ab)using .data for things that could go into .rodata or
+ .bss for a long time, for lack of alternatives and - especially early
+ on - inertia. Also, the BIOS stub is responsible for creating
+ boot_params, so it isn't available to a BIOS-based loader (setup_data
+ is, though).
+
+ setup_header is permanently limited to 144 bytes due to the reach of
+ the 2-byte jump field, which doubles as a length field for the
+ structure, combined with the size of the "hole" in struct boot_params
+ that a protected-mode loader or the BIOS stub has to copy it into. It
+ is currently 119 bytes long, which leaves us with 25 very precious
+ bytes. This isn't something that can be fixed without revising the boot
+ protocol entirely, breaking backwards compatibility.
+
+ boot_params proper is limited to 4096 bytes, but can be arbitrarily
+ extended by adding setup_data entries. It cannot be used to communicate
+ properties of the kernel image, because it is .bss and has no
+ image-provided content.
+
+ kernel_info solves this by providing an extensible place for
+ information about the kernel image. It is readonly, because the kernel
+ cannot rely on a bootloader copying its contents anywhere, but that is
+ OK; if it becomes necessary it can still contain data items that an
+ enabled bootloader would be expected to copy into a setup_data chunk.
+
+ All kernel_info data should be part of this structure. Fixed size data
+ have to be put before kernel_info_var_len_data label. Variable size
+ data have to be put after kernel_info_var_len_data label. Each chunk of
+ variable size data has to be prefixed with header/magic and its size,
+ e.g.:
+kernel_info:
+ .ascii "LToP" /* Header, Linux top (structure). */
+ .long kernel_info_var_len_data - kernel_info
+ .long kernel_info_end - kernel_info
+ .long 0x01234567 /* Some fixed size data for the bootloaders. */
+kernel_info_var_len_data:
+example_struct: /* Some variable size data for the bootloaders.
+*/
+ .ascii "0123" /* Header/Magic. */
+ .long example_struct_end - example_struct
+ .ascii "Struct"
+ .long 0x89012345
+example_struct_end:
+example_strings: /* Some variable size data for the bootloaders.
+*/
+ .ascii "ABCD" /* Header/Magic. */
+ .long example_strings_end - example_strings
+ .asciz "String_0"
+ .asciz "String_1"
+example_strings_end:
+kernel_info_end:
+
+ This way the kernel_info is self-contained blob.
+
+ Note
+
+ Each variable size data header/magic can be any 4-character string,
+ without 0 at the end of the string, which does not collide with
+ existing variable length data headers/magics.
+
+1.5. Details of the kernel_info Fields[93]¶
+
+ Field name:
+
+ header
+
+ Offset/size:
+
+ 0x0000/4
+
+ Contains the magic number "LToP" (0x506f544c).
+
+ Field name:
+
+ size
+
+ Offset/size:
+
+ 0x0004/4
+
+ This field contains the size of the kernel_info including
+ kernel_info.header. It does not count
+ kernel_info.kernel_info_var_len_data size. This field should be used by
+ the bootloaders to detect supported fixed size fields in the
+ kernel_info and beginning of kernel_info.kernel_info_var_len_data.
+
+ Field name:
+
+ size_total
+
+ Offset/size:
+
+ 0x0008/4
+
+ This field contains the size of the kernel_info including
+ kernel_info.header and kernel_info.kernel_info_var_len_data.
+
+ Field name:
+
+ setup_type_max
+
+ Offset/size:
+
+ 0x000c/4
+
+ This field contains maximal allowed type for setup_data and
+ setup_indirect structs.
+
+1.6. The Image Checksum[94]¶
+
+ From boot protocol version 2.08 onwards the CRC-32 is calculated over
+ the entire file using the characteristic polynomial 0x04C11DB7 and an
+ initial remainder of 0xffffffff. The checksum is appended to the file;
+ therefore the CRC of the file up to the limit specified in the syssize
+ field of the header is always 0.
+
+1.7. The Kernel Command Line[95]¶
+
+ The kernel command line has become an important way for the boot loader
+ to communicate with the kernel. Some of its options are also relevant
+ to the boot loader itself, see "special command line options" below.
+
+ The kernel command line is a null-terminated string. The maximum length
+ can be retrieved from the field cmdline_size. Before protocol version
+ 2.06, the maximum was 255 characters. A string that is too long will be
+ automatically truncated by the kernel.
+
+ If the boot protocol version is 2.02 or later, the address of the
+ kernel command line is given by the header field cmd_line_ptr (see
+ above.) This address can be anywhere between the end of the setup heap
+ and 0xA0000.
+
+ If the protocol version is not 2.02 or higher, the kernel command line
+ is entered using the following protocol:
+
+ * At offset 0x0020 (word), "cmd_line_magic", enter the magic number
+ 0xA33F.
+ * At offset 0x0022 (word), "cmd_line_offset", enter the offset of the
+ kernel command line (relative to the start of the real-mode
+ kernel).
+ * The kernel command line must be within the memory region covered by
+ setup_move_size, so you may need to adjust this field.
+
+1.8. Memory Layout of The Real-Mode Code[96]¶
+
+ The real-mode code requires a stack/heap to be set up, as well as
+ memory allocated for the kernel command line. This needs to be done in
+ the real-mode accessible memory in bottom megabyte.
+
+ It should be noted that modern machines often have a sizable Extended
+ BIOS Data Area (EBDA). As a result, it is advisable to use as little of
+ the low megabyte as possible.
+
+ Unfortunately, under the following circumstances the 0x90000 memory
+ segment has to be used:
+
+ * When loading a zImage kernel ((loadflags & 0x01) == 0).
+ * When loading a 2.01 or earlier boot protocol kernel.
+
+ Note
+
+ For the 2.00 and 2.01 boot protocols, the real-mode code can be loaded
+ at another address, but it is internally relocated to 0x90000. For the
+ "old" protocol, the real-mode code must be loaded at 0x90000.
+
+ When loading at 0x90000, avoid using memory above 0x9a000.
+
+ For boot protocol 2.02 or higher, the command line does not have to be
+ located in the same 64K segment as the real-mode setup code; it is thus
+ permitted to give the stack/heap the full 64K segment and locate the
+ command line above it.
+
+ The kernel command line should not be located below the real-mode code,
+ nor should it be located in high memory.
+
+1.9. Sample Boot Configuartion[97]¶
+
+ As a sample configuration, assume the following layout of the real mode
+ segment.
+
+ When loading below 0x90000, use the entire segment:
+
+ 0x0000-0x7fff
+
+ Real mode kernel
+
+ 0x8000-0xdfff
+
+ Stack and heap
+
+ 0xe000-0xffff
+
+ Kernel command line
+
+ When loading at 0x90000 OR the protocol version is 2.01 or earlier:
+
+ 0x0000-0x7fff
+
+ Real mode kernel
+
+ 0x8000-0x97ff
+
+ Stack and heap
+
+ 0x9800-0x9fff
+
+ Kernel command line
+
+ Such a boot loader should enter the following fields in the header:
+unsigned long base_ptr; /* base address for real-mode segment */
+
+if ( setup_sects == 0 ) {
+ setup_sects = 4;
+}
+
+if ( protocol >= 0x0200 ) {
+ type_of_loader = <type code>;
+ if ( loading_initrd ) {
+ ramdisk_image = <initrd_address>;
+ ramdisk_size = <initrd_size>;
+ }
+
+ if ( protocol >= 0x0202 && loadflags & 0x01 )
+ heap_end = 0xe000;
+ else
+ heap_end = 0x9800;
+
+ if ( protocol >= 0x0201 ) {
+ heap_end_ptr = heap_end - 0x200;
+ loadflags |= 0x80; /* CAN_USE_HEAP */
+ }
+
+ if ( protocol >= 0x0202 ) {
+ cmd_line_ptr = base_ptr + heap_end;
+ strcpy(cmd_line_ptr, cmdline);
+ } else {
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = heap_end;
+ setup_move_size = heap_end + strlen(cmdline)+1;
+ strcpy(base_ptr+cmd_line_offset, cmdline);
+ }
+} else {
+ /* Very old kernel */
+
+ heap_end = 0x9800;
+
+ cmd_line_magic = 0xA33F;
+ cmd_line_offset = heap_end;
+
+ /* A very old kernel MUST have its real-mode code
+ loaded at 0x90000 */
+
+ if ( base_ptr != 0x90000 ) {
+ /* Copy the real-mode kernel */
+ memcpy(0x90000, base_ptr, (setup_sects+1)*512);
+ base_ptr = 0x90000; /* Relocated */
+ }
+
+ strcpy(0x90000+cmd_line_offset, cmdline);
+
+ /* It is recommended to clear memory up to the 32K mark */
+ memset(0x90000 + (setup_sects+1)*512, 0,
+ (64-(setup_sects+1))*512);
+}
+
+1.10. Loading The Rest of The Kernel[98]¶
+
+ The 32-bit (non-real-mode) kernel starts at offset (setup_sects+1)*512
+ in the kernel file (again, if setup_sects == 0 the real value is 4.) It
+ should be loaded at address 0x10000 for Image/zImage kernels and
+ 0x100000 for bzImage kernels.
+
+ The kernel is a bzImage kernel if the protocol >= 2.00 and the 0x01 bit
+ (LOAD_HIGH) in the loadflags field is set:
+is_bzImage = (protocol >= 0x0200) && (loadflags & 0x01);
+load_address = is_bzImage ? 0x100000 : 0x10000;
+
+ Note that Image/zImage kernels can be up to 512K in size, and thus use
+ the entire 0x10000-0x90000 range of memory. This means it is pretty
+ much a requirement for these kernels to load the real-mode part at
+ 0x90000. bzImage kernels allow much more flexibility.
+
+1.11. Special Command Line Options[99]¶
+
+ If the command line provided by the boot loader is entered by the user,
+ the user may expect the following command line options to work. They
+ should normally not be deleted from the kernel command line even though
+ not all of them are actually meaningful to the kernel. Boot loader
+ authors who need additional command line options for the boot loader
+ itself should get them registered in [100]The kernel's command-line
+ parameters to make sure they will not conflict with actual kernel
+ options now or in the future.
+
+ vga=<mode>
+ <mode> here is either an integer (in C notation, either decimal,
+ octal, or hexadecimal) or one of the strings "normal" (meaning
+ 0xFFFF), "ext" (meaning 0xFFFE) or "ask" (meaning 0xFFFD). This
+ value should be entered into the vid_mode field, as it is used
+ by the kernel before the command line is parsed.
+
+ mem=<size>
+ <size> is an integer in C notation optionally followed by (case
+ insensitive) K, M, G, T, P or E (meaning << 10, << 20, << 30, <<
+ 40, << 50 or << 60). This specifies the end of memory to the
+ kernel. This affects the possible placement of an initrd, since
+ an initrd should be placed near end of memory. Note that this is
+ an option to both the kernel and the bootloader!
+
+ initrd=<file>
+ An initrd should be loaded. The meaning of <file> is obviously
+ bootloader-dependent, and some boot loaders (e.g. LILO) do not
+ have such a command.
+
+ In addition, some boot loaders add the following options to the
+ user-specified command line:
+
+ BOOT_IMAGE=<file>
+ The boot image which was loaded. Again, the meaning of <file> is
+ obviously bootloader-dependent.
+
+ auto
+ The kernel was booted without explicit user intervention.
+
+ If these options are added by the boot loader, it is highly recommended
+ that they are located first, before the user-specified or
+ configuration-specified command line. Otherwise, "init=/bin/sh" gets
+ confused by the "auto" option.
+
+1.12. Running the Kernel[101]¶
+
+ The kernel is started by jumping to the kernel entry point, which is
+ located at segment offset 0x20 from the start of the real mode kernel.
+ This means that if you loaded your real-mode kernel code at 0x90000,
+ the kernel entry point is 9020:0000.
+
+ At entry, ds = es = ss should point to the start of the real-mode
+ kernel code (0x9000 if the code is loaded at 0x90000), sp should be set
+ up properly, normally pointing to the top of the heap, and interrupts
+ should be disabled. Furthermore, to guard against bugs in the kernel,
+ it is recommended that the boot loader sets fs = gs = ds = es = ss.
+
+ In our example from above, we would do:
+/* Note: in the case of the "old" kernel protocol, base_ptr must
+ be == 0x90000 at this point; see the previous sample code */
+
+seg = base_ptr >> 4;
+
+cli(); /* Enter with interrupts disabled! */
+
+/* Set up the real-mode kernel stack */
+_SS = seg;
+_SP = heap_end;
+
+_DS = _ES = _FS = _GS = seg;
+jmp_far(seg+0x20, 0); /* Run the kernel */
+
+ If your boot sector accesses a floppy drive, it is recommended to
+ switch off the floppy motor before running the kernel, since the kernel
+ boot leaves interrupts off and thus the motor will not be switched off,
+ especially if the loaded kernel has the floppy driver as a
+ demand-loaded module!
+
+1.13. Advanced Boot Loader Hooks[102]¶
+
+ If the boot loader runs in a particularly hostile environment (such as
+ LOADLIN, which runs under DOS) it may be impossible to follow the
+ standard memory location requirements. Such a boot loader may use the
+ following hooks that, if set, are invoked by the kernel at the
+ appropriate time. The use of these hooks should probably be considered
+ an absolutely last resort!
+
+ IMPORTANT: All the hooks are required to preserve %esp, %ebp, %esi and
+ %edi across invocation.
+
+ realmode_swtch:
+ A 16-bit real mode far subroutine invoked immediately before
+ entering protected mode. The default routine disables NMI, so
+ your routine should probably do so, too.
+
+ code32_start:
+ A 32-bit flat-mode routine jumped to immediately after the
+ transition to protected mode, but before the kernel is
+ uncompressed. No segments, except CS, are guaranteed to be set
+ up (current kernels do, but older ones do not); you should set
+ them up to BOOT_DS (0x18) yourself.
+
+ After completing your hook, you should jump to the address that
+ was in this field before your boot loader overwrote it
+ (relocated, if appropriate.)
+
+1.14. 32-bit Boot Protocol[103]¶
+
+ For machine with some new BIOS other than legacy BIOS, such as EFI,
+ LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
+ based on legacy BIOS can not be used, so a 32-bit boot protocol needs
+ to be defined.
+
+ In 32-bit boot protocol, the first step in loading a Linux kernel
+ should be to setup the boot parameters (struct boot_params,
+ traditionally known as "zero page"). The memory for struct boot_params
+ should be allocated and initialized to all zero. Then the setup header
+ from offset 0x01f1 of kernel image on should be loaded into struct
+ boot_params and examined. The end of setup header can be calculated as
+ follow:
+0x0202 + byte value at offset 0x0201
+
+ In addition to read/modify/write the setup header of the struct
+ boot_params as that of 16-bit boot protocol, the boot loader should
+ also fill the additional fields of the struct boot_params as described
+ in chapter [104]Zero Page.
+
+ After setting up the struct boot_params, the boot loader can load the
+ 32/64-bit kernel in the same way as that of 16-bit boot protocol.
+
+ In 32-bit boot protocol, the kernel is started by jumping to the 32-bit
+ kernel entry point, which is the start address of loaded 32/64-bit
+ kernel.
+
+ At entry, the CPU must be in 32-bit protected mode with paging
+ disabled; a GDT must be loaded with the descriptors for selectors
+ __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
+ segment; __BOOT_CS must have execute/read permission, and __BOOT_DS
+ must have read/write permission; CS must be __BOOT_CS and DS, ES, SS
+ must be __BOOT_DS; interrupt must be disabled; %esi must hold the base
+ address of the struct boot_params; %ebp, %edi and %ebx must be zero.
+
+1.15. 64-bit Boot Protocol[105]¶
+
+ For machine with 64bit cpus and 64bit kernel, we could use 64bit
+ bootloader and we need a 64-bit boot protocol.
+
+ In 64-bit boot protocol, the first step in loading a Linux kernel
+ should be to setup the boot parameters (struct boot_params,
+ traditionally known as "zero page"). The memory for struct boot_params
+ could be allocated anywhere (even above 4G) and initialized to all
+ zero. Then, the setup header at offset 0x01f1 of kernel image on should
+ be loaded into struct boot_params and examined. The end of setup header
+ can be calculated as follows:
+0x0202 + byte value at offset 0x0201
+
+ In addition to read/modify/write the setup header of the struct
+ boot_params as that of 16-bit boot protocol, the boot loader should
+ also fill the additional fields of the struct boot_params as described
+ in chapter [106]Zero Page.
+
+ After setting up the struct boot_params, the boot loader can load
+ 64-bit kernel in the same way as that of 16-bit boot protocol, but
+ kernel could be loaded above 4G.
+
+ In 64-bit boot protocol, the kernel is started by jumping to the 64-bit
+ kernel entry point, which is the start address of loaded 64-bit kernel
+ plus 0x200.
+
+ At entry, the CPU must be in 64-bit mode with paging enabled. The range
+ with setup_header.init_size from start address of loaded kernel and
+ zero page and command line buffer get ident mapping; a GDT must be
+ loaded with the descriptors for selectors __BOOT_CS(0x10) and
+ __BOOT_DS(0x18); both descriptors must be 4G flat segment; __BOOT_CS
+ must have execute/read permission, and __BOOT_DS must have read/write
+ permission; CS must be __BOOT_CS and DS, ES, SS must be __BOOT_DS;
+ interrupt must be disabled; %rsi must hold the base address of the
+ struct boot_params.
+
+1.16. EFI Handover Protocol (deprecated)[107]¶
+
+ This protocol allows boot loaders to defer initialisation to the EFI
+ boot stub. The boot loader is required to load the kernel/initrd(s)
+ from the boot media and jump to the EFI handover protocol entry point
+ which is hdr->handover_offset bytes from the beginning of
+ startup_{32,64}.
+
+ The boot loader MUST respect the kernel's PE/COFF metadata when it
+ comes to section alignment, the memory footprint of the executable
+ image beyond the size of the file itself, and any other aspect of the
+ PE/COFF header that may affect correct operation of the image as a
+ PE/COFF binary in the execution context provided by the EFI firmware.
+
+ The function prototype for the handover entry point looks like this:
+efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
+
+ `handle' is the EFI image handle passed to the boot loader by the EFI
+ firmware, `table' is the EFI system table - these are the first two
+ arguments of the "handoff state" as described in section 2.3 of the
+ UEFI specification. `bp' is the boot loader-allocated boot params.
+
+ The boot loader must fill out the following fields in bp:
+- hdr.cmd_line_ptr
+- hdr.ramdisk_image (if applicable)
+- hdr.ramdisk_size (if applicable)
+
+ All other fields should be zero.
+
+ NOTE: The EFI Handover Protocol is deprecated in favour of the ordinary
+ PE/COFF
+ entry point, combined with the LINUX_EFI_INITRD_MEDIA_GUID based
+ initrd loading protocol (refer to [0] for an example of the
+ bootloader side of this), which removes the need for any
+ knowledge on the part of the EFI bootloader regarding the
+ internal representation of boot_params or any
+ requirements/limitations regarding the placement of the command
+ line and ramdisk in memory, or the placement of the kernel image
+ itself.
+
+ [0]
+ [108]https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5
+ d717d4739b0fd0
+
+ ©The kernel development community. | Powered by [109]Sphinx 5.0.1 &
+ [110]Alabaster 0.7.12 | [111]Page source
+
+References
+
+ 1. https://www.kernel.org/doc/html/latest/genindex.html
+ 2. https://www.kernel.org/doc/html/latest/search.html
+ 3. https://www.kernel.org/doc/html/latest/x86/booting-dt.html
+ 4. https://www.kernel.org/doc/html/latest/x86/index.html
+ 5. https://www.kernel.org/doc/html/latest/index.html
+ 6. https://www.kernel.org/doc/html/latest/process/development-process.html
+ 7. https://www.kernel.org/doc/html/latest/process/submitting-patches.html
+ 8. https://www.kernel.org/doc/html/latest/process/code-of-conduct.html
+ 9. https://www.kernel.org/doc/html/latest/maintainer/index.html
+ 10. https://www.kernel.org/doc/html/latest/process/index.html
+ 11. https://www.kernel.org/doc/html/latest/core-api/index.html
+ 12. https://www.kernel.org/doc/html/latest/driver-api/index.html
+ 13. https://www.kernel.org/doc/html/latest/subsystem-apis.html
+ 14. https://www.kernel.org/doc/html/latest/locking/index.html
+ 15. https://www.kernel.org/doc/html/latest/process/license-rules.html
+ 16. https://www.kernel.org/doc/html/latest/doc-guide/index.html
+ 17. https://www.kernel.org/doc/html/latest/dev-tools/index.html
+ 18. https://www.kernel.org/doc/html/latest/dev-tools/testing-overview.html
+ 19. https://www.kernel.org/doc/html/latest/kernel-hacking/index.html
+ 20. https://www.kernel.org/doc/html/latest/trace/index.html
+ 21. https://www.kernel.org/doc/html/latest/fault-injection/index.html
+ 22. https://www.kernel.org/doc/html/latest/livepatch/index.html
+ 23. https://www.kernel.org/doc/html/latest/rust/index.html
+ 24. https://www.kernel.org/doc/html/latest/admin-guide/index.html
+ 25. https://www.kernel.org/doc/html/latest/kbuild/index.html
+ 26. https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
+ 27. https://www.kernel.org/doc/html/latest/tools/index.html
+ 28. https://www.kernel.org/doc/html/latest/userspace-api/index.html
+ 29. https://www.kernel.org/doc/html/latest/firmware-guide/index.html
+ 30. https://www.kernel.org/doc/html/latest/devicetree/index.html
+ 31. https://www.kernel.org/doc/html/latest/arch.html
+ 32. https://www.kernel.org/doc/html/latest/arc/index.html
+ 33. https://www.kernel.org/doc/html/latest/arm/index.html
+ 34. https://www.kernel.org/doc/html/latest/arm64/index.html
+ 35. https://www.kernel.org/doc/html/latest/ia64/index.html
+ 36. https://www.kernel.org/doc/html/latest/loongarch/index.html
+ 37. https://www.kernel.org/doc/html/latest/m68k/index.html
+ 38. https://www.kernel.org/doc/html/latest/mips/index.html
+ 39. https://www.kernel.org/doc/html/latest/nios2/index.html
+ 40. https://www.kernel.org/doc/html/latest/openrisc/index.html
+ 41. https://www.kernel.org/doc/html/latest/parisc/index.html
+ 42. https://www.kernel.org/doc/html/latest/powerpc/index.html
+ 43. https://www.kernel.org/doc/html/latest/riscv/index.html
+ 44. https://www.kernel.org/doc/html/latest/s390/index.html
+ 45. https://www.kernel.org/doc/html/latest/sh/index.html
+ 46. https://www.kernel.org/doc/html/latest/sparc/index.html
+ 47. https://www.kernel.org/doc/html/latest/x86/index.html
+ 48. https://www.kernel.org/doc/html/latest/x86/boot.html
+ 49. https://www.kernel.org/doc/html/latest/x86/booting-dt.html
+ 50. https://www.kernel.org/doc/html/latest/x86/cpuinfo.html
+ 51. https://www.kernel.org/doc/html/latest/x86/topology.html
+ 52. https://www.kernel.org/doc/html/latest/x86/exception-tables.html
+ 53. https://www.kernel.org/doc/html/latest/x86/kernel-stacks.html
+ 54. https://www.kernel.org/doc/html/latest/x86/entry_64.html
+ 55. https://www.kernel.org/doc/html/latest/x86/earlyprintk.html
+ 56. https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
+ 57. https://www.kernel.org/doc/html/latest/x86/zero-page.html
+ 58. https://www.kernel.org/doc/html/latest/x86/tlb.html
+ 59. https://www.kernel.org/doc/html/latest/x86/mtrr.html
+ 60. https://www.kernel.org/doc/html/latest/x86/pat.html
+ 61. https://www.kernel.org/doc/html/latest/x86/intel-hfi.html
+ 62. https://www.kernel.org/doc/html/latest/x86/iommu.html
+ 63. https://www.kernel.org/doc/html/latest/x86/intel_txt.html
+ 64. https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html
+ 65. https://www.kernel.org/doc/html/latest/x86/amd_hsmp.html
+ 66. https://www.kernel.org/doc/html/latest/x86/tdx.html
+ 67. https://www.kernel.org/doc/html/latest/x86/pti.html
+ 68. https://www.kernel.org/doc/html/latest/x86/mds.html
+ 69. https://www.kernel.org/doc/html/latest/x86/microcode.html
+ 70. https://www.kernel.org/doc/html/latest/x86/resctrl.html
+ 71. https://www.kernel.org/doc/html/latest/x86/tsx_async_abort.html
+ 72. https://www.kernel.org/doc/html/latest/x86/buslock.html
+ 73. https://www.kernel.org/doc/html/latest/x86/usb-legacy-support.html
+ 74. https://www.kernel.org/doc/html/latest/x86/i386/index.html
+ 75. https://www.kernel.org/doc/html/latest/x86/x86_64/index.html
+ 76. https://www.kernel.org/doc/html/latest/x86/ifs.html
+ 77. https://www.kernel.org/doc/html/latest/x86/sva.html
+ 78. https://www.kernel.org/doc/html/latest/x86/sgx.html
+ 79. https://www.kernel.org/doc/html/latest/x86/features.html
+ 80. https://www.kernel.org/doc/html/latest/x86/elf_auxvec.html
+ 81. https://www.kernel.org/doc/html/latest/x86/xstate.html
+ 82. https://www.kernel.org/doc/html/latest/xtensa/index.html
+ 83. https://www.kernel.org/doc/html/latest/staging/index.html
+ 84. https://www.kernel.org/doc/html/latest/translations/index.html
+ 85. https://www.kernel.org/doc/html/latest/_sources/x86/boot.rst.txt
+ 86. https://www.kernel.org/doc/html/latest/x86/boot.html#the-linux-x86-boot-protocol
+ 87. https://www.kernel.org/doc/html/latest/x86/boot.html#memory-layout
+ 88. https://www.kernel.org/doc/html/latest/x86/boot.html#the-real-mode-kernel-header
+ 89. https://www.kernel.org/doc/html/latest/x86/boot.html#details-of-header-fields
+ 90. http://sebastian-plotz.blogspot.de/
+ 91. mailto:hpa%40zytor.com
+ 92. https://www.kernel.org/doc/html/latest/x86/boot.html#the-kernel-info
+ 93. https://www.kernel.org/doc/html/latest/x86/boot.html#details-of-the-kernel-info-fields
+ 94. https://www.kernel.org/doc/html/latest/x86/boot.html#the-image-checksum
+ 95. https://www.kernel.org/doc/html/latest/x86/boot.html#the-kernel-command-line
+ 96. https://www.kernel.org/doc/html/latest/x86/boot.html#memory-layout-of-the-real-mode-code
+ 97. https://www.kernel.org/doc/html/latest/x86/boot.html#sample-boot-configuartion
+ 98. https://www.kernel.org/doc/html/latest/x86/boot.html#loading-the-rest-of-the-kernel
+ 99. https://www.kernel.org/doc/html/latest/x86/boot.html#special-command-line-options
+ 100. https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
+ 101. https://www.kernel.org/doc/html/latest/x86/boot.html#running-the-kernel
+ 102. https://www.kernel.org/doc/html/latest/x86/boot.html#advanced-boot-loader-hooks
+ 103. https://www.kernel.org/doc/html/latest/x86/boot.html#bit-boot-protocol
+ 104. https://www.kernel.org/doc/html/latest/x86/zero-page.html
+ 105. https://www.kernel.org/doc/html/latest/x86/boot.html#id1
+ 106. https://www.kernel.org/doc/html/latest/x86/zero-page.html
+ 107. https://www.kernel.org/doc/html/latest/x86/boot.html#efi-handover-protocol-deprecated
+ 108. https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0
+ 109. http://sphinx-doc.org/
+ 110. https://github.com/bitprophet/alabaster
+ 111. https://www.kernel.org/doc/html/latest/_sources/x86/boot.rst.txt
diff --git a/doc/doc/www.kernel.org_doc_html_latest_x86_zero-page.txt b/doc/doc/www.kernel.org_doc_html_latest_x86_zero-page.txt
new file mode 100644
index 0000000..da384f1
--- /dev/null
+++ b/doc/doc/www.kernel.org_doc_html_latest_x86_zero-page.txt
@@ -0,0 +1,424 @@
+ #[1]Index [2]Search [3]11. The TLB [4]9. ORC unwinder
+
+[5]The Linux Kernel
+
+ 6.3.0-rc6
+
+Quick search
+
+ ____________________ Go
+
+Contents
+
+ [X]
+ * [6]A guide to the Kernel Development Process
+ * [7]Submitting patches: the essential guide to getting your code
+ into the kernel
+ * [8]Code of conduct
+ * [9]Kernel Maintainer Handbook
+ * [10]All development-process docs
+
+ * [11]Core API Documentation
+ * [12]Driver implementer's API guide
+ * [13]Kernel subsystem documentation
+ * [14]Locking in the kernel
+
+ * [15]Linux kernel licensing rules
+ * [16]How to write kernel documentation
+ * [17]Development tools for the kernel
+ * [18]Kernel Testing Guide
+ * [19]Kernel Hacking Guides
+ * [20]Linux Tracing Technologies
+ * [21]fault-injection
+ * [22]Kernel Livepatching
+ * [23]Rust
+
+ * [24]The Linux kernel user's and administrator's guide
+ * [25]The kernel build system
+ * [26]Reporting issues
+ * [27]User-space tools
+ * [28]The Linux kernel user-space API guide
+
+ * [29]The Linux kernel firmware guide
+ * [30]Open Firmware and Devicetree
+
+ * [31]CPU Architectures
+ + [32]ARC architecture
+ + [33]ARM Architecture
+ + [34]ARM64 Architecture
+ + [35]IA-64 Architecture
+ + [36]LoongArch Architecture
+ + [37]m68k Architecture
+ + [38]MIPS-specific Documentation
+ + [39]Nios II Specific Documentation
+ + [40]OpenRISC Architecture
+ + [41]PA-RISC Architecture
+ + [42]powerpc
+ + [43]RISC-V architecture
+ + [44]s390 Architecture
+ + [45]SuperH Interfaces Guide
+ + [46]Sparc Architecture
+ + [47]x86-specific Documentation
+ o [48]1. The Linux/x86 Boot Protocol
+ o [49]2. DeviceTree Booting
+ o [50]3. x86 Feature Flags
+ o [51]4. x86 Topology
+ o [52]5. Kernel level exception handling
+ o [53]6. Kernel Stacks
+ o [54]7. Kernel Entries
+ o [55]8. Early Printk
+ o [56]9. ORC unwinder
+ o [57]10. Zero Page
+ o [58]11. The TLB
+ o [59]12. MTRR (Memory Type Range Register) control
+ o [60]13. PAT (Page Attribute Table)
+ o [61]14. Hardware-Feedback Interface for scheduling on
+ Intel Hardware
+ o [62]15. x86 IOMMU Support
+ o [63]16. Intel(R) TXT Overview
+ o [64]17. AMD Memory Encryption
+ o [65]18. AMD HSMP interface
+ o [66]19. Intel Trust Domain Extensions (TDX)
+ o [67]20. Page Table Isolation (PTI)
+ o [68]21. Microarchitectural Data Sampling (MDS) mitigation
+ o [69]22. The Linux Microcode Loader
+ o [70]23. User Interface for Resource Control feature
+ o [71]24. TSX Async Abort (TAA) mitigation
+ o [72]25. Bus lock detection and handling
+ o [73]26. USB Legacy support
+ o [74]27. i386 Support
+ o [75]28. x86_64 Support
+ o [76]29. In-Field Scan
+ o [77]30. Shared Virtual Addressing (SVA) with ENQCMD
+ o [78]31. Software Guard eXtensions (SGX)
+ o [79]32. Feature status on x86 architecture
+ o [80]33. x86-specific ELF Auxiliary Vectors
+ o [81]34. Using XSTATE features in user space applications
+ + [82]Xtensa Architecture
+
+ * [83]Unsorted Documentation
+
+ * [84]Translations
+
+This Page
+
+ * [85]Show Source
+
+10. Zero Page[86]¶
+
+ The additional fields in struct boot_params as a part of 32-bit boot
+ protocol of kernel. These should be filled by bootloader or 16-bit
+ real-mode setup code of the kernel. References/settings to it mainly
+ are in:
+arch/x86/include/uapi/asm/bootparam.h
+
+ Offset/Size
+
+ Proto
+
+ Name
+
+ Meaning
+
+ 000/040
+
+ ALL
+
+ screen_info
+
+ Text mode or frame buffer information (struct screen_info)
+
+ 040/014
+
+ ALL
+
+ apm_bios_info
+
+ APM BIOS information (struct apm_bios_info)
+
+ 058/008
+
+ ALL
+
+ tboot_addr
+
+ Physical address of tboot shared page
+
+ 060/010
+
+ ALL
+
+ ist_info
+
+ Intel SpeedStep (IST) BIOS support information (struct ist_info)
+
+ 070/008
+
+ ALL
+
+ acpi_rsdp_addr
+
+ Physical address of ACPI RSDP table
+
+ 080/010
+
+ ALL
+
+ hd0_info
+
+ hd0 disk parameter, OBSOLETE!!
+
+ 090/010
+
+ ALL
+
+ hd1_info
+
+ hd1 disk parameter, OBSOLETE!!
+
+ 0A0/010
+
+ ALL
+
+ sys_desc_table
+
+ System description table (struct sys_desc_table), OBSOLETE!!
+
+ 0B0/010
+
+ ALL
+
+ olpc_ofw_header
+
+ OLPC's OpenFirmware CIF and friends
+
+ 0C0/004
+
+ ALL
+
+ ext_ramdisk_image
+
+ ramdisk_image high 32bits
+
+ 0C4/004
+
+ ALL
+
+ ext_ramdisk_size
+
+ ramdisk_size high 32bits
+
+ 0C8/004
+
+ ALL
+
+ ext_cmd_line_ptr
+
+ cmd_line_ptr high 32bits
+
+ 13C/004
+
+ ALL
+
+ cc_blob_address
+
+ Physical address of Confidential Computing blob
+
+ 140/080
+
+ ALL
+
+ edid_info
+
+ Video mode setup (struct edid_info)
+
+ 1C0/020
+
+ ALL
+
+ efi_info
+
+ EFI 32 information (struct efi_info)
+
+ 1E0/004
+
+ ALL
+
+ alt_mem_k
+
+ Alternative mem check, in KB
+
+ 1E4/004
+
+ ALL
+
+ scratch
+
+ Scratch field for the kernel setup code
+
+ 1E8/001
+
+ ALL
+
+ e820_entries
+
+ Number of entries in e820_table (below)
+
+ 1E9/001
+
+ ALL
+
+ eddbuf_entries
+
+ Number of entries in eddbuf (below)
+
+ 1EA/001
+
+ ALL
+
+ edd_mbr_sig_buf_entries
+
+ Number of entries in edd_mbr_sig_buffer (below)
+
+ 1EB/001
+
+ ALL
+
+ kbd_status
+
+ Numlock is enabled
+
+ 1EC/001
+
+ ALL
+
+ secure_boot
+
+ Secure boot is enabled in the firmware
+
+ 1EF/001
+
+ ALL
+
+ sentinel
+
+ Used to detect broken bootloaders
+
+ 290/040
+
+ ALL
+
+ edd_mbr_sig_buffer
+
+ EDD MBR signatures
+
+ 2D0/A00
+
+ ALL
+
+ e820_table
+
+ E820 memory map table (array of struct e820_entry)
+
+ D00/1EC
+
+ ALL
+
+ eddbuf
+
+ EDD data (array of struct edd_info)
+
+ ©The kernel development community. | Powered by [87]Sphinx 5.0.1 &
+ [88]Alabaster 0.7.12 | [89]Page source
+
+References
+
+ 1. https://www.kernel.org/doc/html/latest/genindex.html
+ 2. https://www.kernel.org/doc/html/latest/search.html
+ 3. https://www.kernel.org/doc/html/latest/x86/tlb.html
+ 4. https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
+ 5. https://www.kernel.org/doc/html/latest/index.html
+ 6. https://www.kernel.org/doc/html/latest/process/development-process.html
+ 7. https://www.kernel.org/doc/html/latest/process/submitting-patches.html
+ 8. https://www.kernel.org/doc/html/latest/process/code-of-conduct.html
+ 9. https://www.kernel.org/doc/html/latest/maintainer/index.html
+ 10. https://www.kernel.org/doc/html/latest/process/index.html
+ 11. https://www.kernel.org/doc/html/latest/core-api/index.html
+ 12. https://www.kernel.org/doc/html/latest/driver-api/index.html
+ 13. https://www.kernel.org/doc/html/latest/subsystem-apis.html
+ 14. https://www.kernel.org/doc/html/latest/locking/index.html
+ 15. https://www.kernel.org/doc/html/latest/process/license-rules.html
+ 16. https://www.kernel.org/doc/html/latest/doc-guide/index.html
+ 17. https://www.kernel.org/doc/html/latest/dev-tools/index.html
+ 18. https://www.kernel.org/doc/html/latest/dev-tools/testing-overview.html
+ 19. https://www.kernel.org/doc/html/latest/kernel-hacking/index.html
+ 20. https://www.kernel.org/doc/html/latest/trace/index.html
+ 21. https://www.kernel.org/doc/html/latest/fault-injection/index.html
+ 22. https://www.kernel.org/doc/html/latest/livepatch/index.html
+ 23. https://www.kernel.org/doc/html/latest/rust/index.html
+ 24. https://www.kernel.org/doc/html/latest/admin-guide/index.html
+ 25. https://www.kernel.org/doc/html/latest/kbuild/index.html
+ 26. https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
+ 27. https://www.kernel.org/doc/html/latest/tools/index.html
+ 28. https://www.kernel.org/doc/html/latest/userspace-api/index.html
+ 29. https://www.kernel.org/doc/html/latest/firmware-guide/index.html
+ 30. https://www.kernel.org/doc/html/latest/devicetree/index.html
+ 31. https://www.kernel.org/doc/html/latest/arch.html
+ 32. https://www.kernel.org/doc/html/latest/arc/index.html
+ 33. https://www.kernel.org/doc/html/latest/arm/index.html
+ 34. https://www.kernel.org/doc/html/latest/arm64/index.html
+ 35. https://www.kernel.org/doc/html/latest/ia64/index.html
+ 36. https://www.kernel.org/doc/html/latest/loongarch/index.html
+ 37. https://www.kernel.org/doc/html/latest/m68k/index.html
+ 38. https://www.kernel.org/doc/html/latest/mips/index.html
+ 39. https://www.kernel.org/doc/html/latest/nios2/index.html
+ 40. https://www.kernel.org/doc/html/latest/openrisc/index.html
+ 41. https://www.kernel.org/doc/html/latest/parisc/index.html
+ 42. https://www.kernel.org/doc/html/latest/powerpc/index.html
+ 43. https://www.kernel.org/doc/html/latest/riscv/index.html
+ 44. https://www.kernel.org/doc/html/latest/s390/index.html
+ 45. https://www.kernel.org/doc/html/latest/sh/index.html
+ 46. https://www.kernel.org/doc/html/latest/sparc/index.html
+ 47. https://www.kernel.org/doc/html/latest/x86/index.html
+ 48. https://www.kernel.org/doc/html/latest/x86/boot.html
+ 49. https://www.kernel.org/doc/html/latest/x86/booting-dt.html
+ 50. https://www.kernel.org/doc/html/latest/x86/cpuinfo.html
+ 51. https://www.kernel.org/doc/html/latest/x86/topology.html
+ 52. https://www.kernel.org/doc/html/latest/x86/exception-tables.html
+ 53. https://www.kernel.org/doc/html/latest/x86/kernel-stacks.html
+ 54. https://www.kernel.org/doc/html/latest/x86/entry_64.html
+ 55. https://www.kernel.org/doc/html/latest/x86/earlyprintk.html
+ 56. https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
+ 57. https://www.kernel.org/doc/html/latest/x86/zero-page.html
+ 58. https://www.kernel.org/doc/html/latest/x86/tlb.html
+ 59. https://www.kernel.org/doc/html/latest/x86/mtrr.html
+ 60. https://www.kernel.org/doc/html/latest/x86/pat.html
+ 61. https://www.kernel.org/doc/html/latest/x86/intel-hfi.html
+ 62. https://www.kernel.org/doc/html/latest/x86/iommu.html
+ 63. https://www.kernel.org/doc/html/latest/x86/intel_txt.html
+ 64. https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html
+ 65. https://www.kernel.org/doc/html/latest/x86/amd_hsmp.html
+ 66. https://www.kernel.org/doc/html/latest/x86/tdx.html
+ 67. https://www.kernel.org/doc/html/latest/x86/pti.html
+ 68. https://www.kernel.org/doc/html/latest/x86/mds.html
+ 69. https://www.kernel.org/doc/html/latest/x86/microcode.html
+ 70. https://www.kernel.org/doc/html/latest/x86/resctrl.html
+ 71. https://www.kernel.org/doc/html/latest/x86/tsx_async_abort.html
+ 72. https://www.kernel.org/doc/html/latest/x86/buslock.html
+ 73. https://www.kernel.org/doc/html/latest/x86/usb-legacy-support.html
+ 74. https://www.kernel.org/doc/html/latest/x86/i386/index.html
+ 75. https://www.kernel.org/doc/html/latest/x86/x86_64/index.html
+ 76. https://www.kernel.org/doc/html/latest/x86/ifs.html
+ 77. https://www.kernel.org/doc/html/latest/x86/sva.html
+ 78. https://www.kernel.org/doc/html/latest/x86/sgx.html
+ 79. https://www.kernel.org/doc/html/latest/x86/features.html
+ 80. https://www.kernel.org/doc/html/latest/x86/elf_auxvec.html
+ 81. https://www.kernel.org/doc/html/latest/x86/xstate.html
+ 82. https://www.kernel.org/doc/html/latest/xtensa/index.html
+ 83. https://www.kernel.org/doc/html/latest/staging/index.html
+ 84. https://www.kernel.org/doc/html/latest/translations/index.html
+ 85. https://www.kernel.org/doc/html/latest/_sources/x86/zero-page.rst.txt
+ 86. https://www.kernel.org/doc/html/latest/x86/zero-page.html#zero-page
+ 87. http://sphinx-doc.org/
+ 88. https://github.com/bitprophet/alabaster
+ 89. https://www.kernel.org/doc/html/latest/_sources/x86/zero-page.rst.txt
generated by cgit v1.2.3-54-g00ecf (git 2.45.1) at 2024-05-20 15:33:45 +0000