{
	"id": "6f244d06-0e3a-4b0a-a06c-0801fd3a5ec5",
	"created_at": "2026-04-06T00:11:41.251629Z",
	"updated_at": "2026-04-10T03:32:26.467687Z",
	"deleted_at": null,
	"sha1_hash": "2ea47ee3caf45c7eea548e479295854aa201d78b",
	"title": "Booting",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 740610,
	"plain_text": "Booting\r\nBy Contributors to Wikimedia projects\r\nPublished: 2002-02-25 · Archived: 2026-04-05 22:48:38 UTC\r\nThis article is about bootstrapping operating systems. For the general concept, see Bootstrapping.\r\nA flow diagram of a computer booting\r\nIn computing, booting is the process of starting a computer as initiated via hardware such as a physical button on\r\nthe computer or by a software command, first described in the 1950s as the \"bootstrap technique.\"[1] After it is\r\nswitched on, a computer's central processing unit (CPU) has no software in its main memory, so some process\r\nmust load software into memory before it can be executed. This may be done by hardware or firmware in the\r\nCPU, or by a separate processor in the computer system. On some systems, a power-on reset (POR) does not\r\ninitiate booting, and the operator must initiate booting after POR completes. IBM uses the term Initial Program\r\nLoad (IPL) on some[nb 1] product lines.\r\nRestarting a computer is also called rebooting, which can be \"hard\", e.g., after electrical power to the CPU is\r\nswitched from off to on, or \"soft\", where the power is not cut. On some systems, a soft boot may optionally clear\r\nRAM to zero. Both hard and soft booting can be initiated by hardware, such as a button press, or by a software\r\ncommand. Booting is complete when the operative runtime system, typically the operating system and some\r\napplications,[nb 2] is attained.\r\nThe process of returning a computer from a state of sleep (suspension) does not involve booting; however,\r\nrestoring it from a state of hibernation does. Minimally, some embedded systems do not require a noticeable boot\r\nsequence to begin functioning, and when turned on, may simply run operational programs that are stored in read-https://en.wikipedia.org/wiki/Booting\r\nPage 1 of 25\n\nonly memory (ROM). All computing systems are state machines, and a reboot may be the only method to return to\r\na designated zero-state from an unintended, locked state.\r\nIn addition to loading an operating system or stand-alone utility, the boot process can also load a storage dump\r\nprogram for diagnosing problems in an operating system.\r\nBoot is short for bootstrap[2][3] and derives from the phrase to pull oneself up by one's bootstraps.\r\n[4][5]\r\n The usage\r\ncalls attention to the requirement that, if most software is loaded onto a computer by other software already\r\nrunning on the computer, some mechanism must exist to load the initial software onto the computer.\r\n[6]\r\n Early\r\ncomputers used a variety of ad-hoc methods to get a small program (the \"bootstrap loader\" or \"bootstrap\") into\r\nmemory to solve this problem. The invention of ROM of various types solved this paradox by allowing computers\r\nto be shipped with a start-up program, stored in the boot ROM of the computer, that could not be erased. Growth\r\nin the capacity of ROM has allowed ever more elaborate start-up procedures to be implemented.\r\nThe earliest known recorded use of \"boot\" as the shortened form for \"bootstrap\" is 1975.[7]\r\nSwitches and cables used to program ENIAC (1946)\r\nThere are many different methods available to load a short initial program into a computer. These methods range\r\nfrom simple, physical input to removable media that can hold more complex programs.\r\nPre integrated-circuit-ROM examples\r\n[edit]\r\nEarly computers in the 1940s and 1950s were one-of-a-kind engineering efforts that could take weeks to program,\r\nand program loading was one of many problems that had to be solved. An early computer, ENIAC, had no\r\nprogram stored in memory but was set up for each problem by a configuration of interconnecting cables.\r\nBootstrapping did not apply to ENIAC, whose hardware configuration was ready for solving problems as soon as\r\npower was applied.\r\nThe EDSAC system, the second stored-program computer to be built, used stepping switches to transfer a fixed\r\nprogram into memory when its start button was pressed. The program stored on this device, which David Wheeler\r\ncompleted in late 1948, loaded further instructions from punched tape and then executed them.[8][9]\r\nFirst commercial computers\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 2 of 25\n\n[edit]\r\nThe first programmable computers for commercial sale, such as the UNIVAC I and the IBM 701[10] included\r\nfeatures to make their operation simpler. They typically included instructions that performed a complete input or\r\noutput operation. The same hardware logic could be used to load the contents of a punch card (the most typical\r\nones) or other input media, such as a magnetic drum or magnetic tape, that contained a bootstrap program by\r\npressing a single button. This booting concept was called a variety of names for IBM computers of the 1950s and\r\nearly 1960s, but IBM used the term \"Initial Program Load\" with the IBM 7030 Stretch[11] and later used it for\r\ntheir mainframe lines, starting with the System/360 in 1964.\r\nInitial program load punched card for the IBM 1130 (1965)\r\nThe IBM 701 computer (1952–1956) had a \"Load\" button that initiated reading of the first 36-bit word into main\r\nmemory from a punched card in a card reader, a magnetic tape in a tape drive, or a magnetic drum unit, depending\r\non the position of the Load Selector switch. The left 18-bit half-word was then executed as an instruction, which\r\nusually read additional words into memory.\r\n[12][13]\r\n The loaded boot program was then executed, which, in turn,\r\nloaded a larger program from that medium into memory without further help from the human operator. The IBM\r\n704,\r\n[14]\r\n IBM 7090,\r\n[15]\r\n and IBM 7094[16] had similar mechanisms, but with different load buttons for different\r\ndevices. The term \"boot\" has been used in this sense since at least 1958.[17]\r\nIBM System/3 console from the 1970s. Program load selector switch is lower left; Program load\r\nswitch is lower right.\r\nOther IBM computers of that era had similar features. For example, the IBM 1401 system (1959) used a card\r\nreader to load a program from a punched card. The 80 characters stored in the punched card were read into\r\nmemory locations 001 to 080, then the computer would branch to memory location 001 to read its first stored\r\ninstruction. This instruction was always the same: move the information in these first 80 memory locations to an\r\nassembly area where the information in punched cards 2, 3, 4, and so on, could be combined to form the stored\r\nprogram. Once this information was moved to the assembly area, the machine would branch to an instruction in\r\nlocation 080 (read a card) and the next card would be read and its information processed.\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 3 of 25\n\nAnother example was the IBM 650 (1953), a decimal machine, which had a group of ten 10-position switches on\r\nits operator panel that were addressable as a memory word (address 8000) and could be executed as an instruction.\r\nThus, setting the switches to 7004000400 and pressing the appropriate button would read the first card in the card\r\nreader into memory (op code 70), starting at address 400 and then jump to 400 to begin executing the program on\r\nthat card.[18] The IBM 7040 and 7044 have a similar mechanism, in which the Load button causes the instruction\r\nset up in the entry keys on the front panel is executed, and the channel that instruction sets up is given a command\r\nto transfer data to memory starting at address 00100; when that transfer finishes, the CPU jumps to address 00101.\r\n[19]\r\nIBM's competitors also offered single-button program load.\r\nThe CDC 6600 (c. 1964) had a dead start panel with 144 toggle switches; the dead start switch entered 12\r\n12-bit words from the toggle switches to the memory of peripheral processor (PP) 0 and initiated the load\r\nsequence by causing PP 0 to execute the code loaded into memory.\r\n[20]\r\n PP 0 loaded the necessary code into\r\nits own memory and then initialized the other PPs.\r\nThe GE 645 (c. 1965) had a \"SYSTEM BOOTLOAD\" button that, when pressed, caused one of the I/O\r\ncontrollers to load a 64-word program into memory from a diode read-only memory and deliver an\r\ninterrupt to cause that program to start running.[21]\r\nThe first model of the PDP-10 had a \"READ IN\" button that, when pressed, reset the processor and started\r\nan I/O operation on a device specified by switches on the control panel, reading in a 36-bit word giving a\r\ntarget address and count for subsequent word reads; when the read completed, the processor started\r\nexecuting the code read in by jumping to the last word read in.[22]\r\nA noteworthy variation of this is found on the Burroughs B1700, where there is neither a boot ROM nor a\r\nhardwired IPL operation. Instead, after the system is reset, it reads and executes microinstructions sequentially\r\nfrom a cassette tape drive mounted on the front panel; this sets up a boot loader in RAM, which is then executed.\r\n[23]\r\n However, since this makes few assumptions about the system it can equally well be used to load diagnostic\r\n(Maintenance Test Routine) tapes which display an intelligible code on the front panel even in cases of gross CPU\r\nfailure.[23]\r\nIBM System/360 and successors\r\n[edit]\r\nIn the IBM System/360 and its successors, including the current z/Architecture machines, the boot process is\r\nknown as Initial Program Load (IPL).\r\nIBM coined this term for the 7030 (Stretch),\r\n[11]\r\n revived it for the design of the System/360, and continues to use it\r\nin those environments today.\r\n[24]\r\n In the System/360 processors, an IPL is initiated by the computer operator by\r\nselecting the three hexadecimal digit device address (CUU; C=I/O Channel address, UU=Control unit and Device\r\naddress[nb 3]) followed by pressing the LOAD button. On the high end System/360 models, most[nb 4] System/370\r\nand some later systems, the functions of the switches and the LOAD button are simulated using selectable areas\r\non the screen of a graphics console, often[nb 5] an IBM 2250-like device or an IBM 3270-like device. For\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 4 of 25\n\nexample, on the System/370 Model 158, the keyboard sequence 0-7-X (zero, seven and X, in that order) results in\r\nan IPL from the device address that was keyed into the input area. The Amdahl 470V/6 and related CPUs\r\nsupported four hexadecimal digits on those CPUs that had the optional second channel unit installed, for a total of\r\n32 channels. Later, IBM would also support more than 16 channels.\r\nThe IPL function in the System/360 and its successors prior to IBM Z, and its compatibles, such as Amdahl's,\r\nreads 24 bytes from an operator-specified device into main storage starting at real address zero. The second and\r\nthird groups of eight bytes are treated as Channel Command Words (CCWs) to continue loading the startup\r\nprogram (the first CCW is always simulated by the CPU and consists of a Read IPL command, 02h, with\r\ncommand chaining and suppress incorrect length indication being enforced). When the I/O channel commands are\r\ncomplete, the first group of eight bytes is then loaded into the processor's Program Status Word (PSW) and the\r\nstartup program begins execution at the location designated by that PSW.\r\n[24]\r\n The IPL device is usually a disk\r\ndrive, hence the special significance of the 02h read-type command, but exactly the same procedure is also used to\r\nIPL from other input-type devices, such as tape drives, or even card readers, in a device-independent manner,\r\nallowing, for example, the installation of an operating system on a brand-new computer from an OS initial\r\ndistribution magnetic tape. For disk controllers, the 02h command also causes the selected device to seek to\r\ncylinder 0000h, head 0000h, simulating a Seek cylinder and head command, 07h, and to search for record 01h,\r\nsimulating a Search ID Equal command, 31h; seeks and searches are not simulated by tape and card controllers, as\r\nfor these device classes a Read IPL command is simply a sequential read command.\r\nThe disk, tape or card deck must contain a special program to load the actual operating system or standalone\r\nutility into main storage, and for this specific purpose, \"IPL Text\" is placed on the disk by the stand-alone DASDI\r\n(Direct Access Storage Device Initialization) program or an equivalent program running under an operating\r\nsystem, e.g., ICKDSF, but IPL-able tapes and card decks are usually distributed with this \"IPL Text\" already\r\npresent.\r\nIBM introduced some evolutionary changes in the IPL process, changing some details for System/370 Extended\r\nArchitecture (S/370-XA) and later, and adding a new type of IPL for z/Architecture.\r\nPDP-8/E front panel showing the switches used to load the bootstrap program\r\nMinicomputers, starting with the Digital Equipment Corporation (DEC) PDP-5 and PDP-8 (1965) simplified\r\ndesign by using the CPU to assist input and output operations. This saved cost but made booting more\r\ncomplicated than pressing a single button. Minicomputers typically had some way to toggle in short programs by\r\nmanipulating an array of switches on the front panel. Since the early minicomputers used magnetic-core memory,\r\nwhich did not lose its information when power was off, these bootstrap loaders would remain in place unless they\r\nwere erased. Erasure sometimes happened accidentally when a program bug caused a loop that overwrote all of\r\nmemory.\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 5 of 25\n\nOther minicomputers with such simple form of booting include Hewlett-Packard's HP 2100 series (mid-1960s),\r\nthe original Data General Nova (1969), and DEC's PDP-4 (1962) and PDP-11 (1970).\r\nAs the I/O operations needed to cause a read operation on a minicomputer I/O device were typically different for\r\ndifferent device controllers, different bootstrap programs were needed for different devices.\r\nDEC later added, in 1971, an optional diode matrix read-only memory for the PDP-11 that stored a bootstrap\r\nprogram of up to 32 words (64 bytes). It consisted of a printed circuit card, the M792, that plugged into the\r\nUnibus and held a 32 by 16 array of semiconductor diodes. With all 512 diodes in place, the memory contained all\r\n\"one\" bits; the card was programmed by cutting off each diode whose bit was to be \"zero\". DEC also sold versions\r\nof the card, the BM792-Yx series, pre-programmed for many standard input devices by simply omitting the\r\nunneeded diodes.[25][26]\r\nFollowing the older approach, the earlier PDP-1 has a hardware loader, such that an operator needs only push the\r\nload switch to instruct the paper tape reader to load a program directly into core memory. The PDP-7,\r\n[27]\r\n PDP-9,\r\n[28]\r\n and PDP-15[29] successors to the PDP-4 have an added Read-In button to read a program in from paper tape\r\nand jump to it. The Data General Supernova used front panel switches to cause the computer to automatically load\r\ninstructions into memory from a device specified by the front panel's data switches, and then jump to loaded code.\r\n[30]\r\nEarly minicomputer boot loader examples\r\n[edit]\r\nIn a minicomputer with a paper tape reader, the first program to run in the boot process, the boot loader, would\r\nread into core memory either the second-stage boot loader (often called a Binary Loader) that could read paper\r\ntape with checksum or the operating system from an outside storage medium. Pseudocode for the boot loader\r\nmight be as simple as the following eight instructions:\r\n1. Set the P register to 9\r\n2. Check paper tape reader ready\r\n3. If not ready, jump to 2\r\n4. Read a byte from paper tape reader to accumulator\r\n5. Store accumulator to address in P register\r\n6. If end of tape, jump to 9\r\n7. Increment the P register\r\n8. Jump to 2\r\nA related example is based on a loader for a Nicolet Instrument Corporation minicomputer of the 1970s, using the\r\npaper tape reader-punch unit on a Teletype Model 33 ASR teleprinter. The bytes of its second-stage loader are read\r\nfrom paper tape in reverse order.\r\n1. Set the P register to 106\r\n2. Check paper tape reader ready\r\n3. If not ready, jump to 2\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 6 of 25\n\n4. Read a byte from paper tape reader to accumulator\r\n5. Store accumulator to address in P register\r\n6. Decrement the P register\r\n7. Jump to 2\r\nThe length of the second stage loader is such that the final byte overwrites location 7. After the instruction in\r\nlocation 6 executes, location 7 starts the second stage loader executing. The second stage loader then waits for the\r\nmuch longer tape containing the operating system to be placed in the tape reader. The difference between the boot\r\nloader and second stage loader is the addition of checking code to trap paper tape read errors, a frequent\r\noccurrence with relatively low-cost, \"part-time-duty\" hardware, such as the Teletype Model 33 ASR. (Friden\r\nFlexowriters were far more reliable, but also comparatively costly.)\r\nBooting the first microcomputers\r\n[edit]\r\nThe earliest microcomputers, such as the Altair 8800 (released first in 1975) and an even earlier, similar machine\r\n(based on the Intel 8008 CPU) had no bootstrapping hardware as such.[31] When powered up, the CPU would see\r\nmemory that would contain random data. The front panels of these machines carried toggle switches for entering\r\naddresses and data, one switch per bit of the computer memory word and address bus. Simple additions to the\r\nhardware permitted one memory location at a time to be loaded from those switches to store bootstrap code.\r\nMeanwhile, the CPU was kept from attempting to execute memory content. Once correctly loaded, the CPU was\r\nenabled to execute the bootstrapping code. This process, similar to that used for several earlier minicomputers,\r\nwas tedious and had to be error-free.[32]\r\nIntegrated circuit read-only memory era\r\n[edit]\r\nAn Intel 2708 EPROM \"chip\" on a circuit board\r\nThe introduction of integrated circuit read-only memory (ROM), with its many variants, including mask-programmed ROMs, programmable ROMs (PROM), erasable programmable ROMs (EPROM), and flash\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 7 of 25\n\nmemory, reduced the physical size and cost of ROM. This allowed firmware boot programs to be included as part\r\nof the computer.\r\nThe Data General Nova 1200 (1970) and Nova 800 (1971) had a program load switch that, in combination with\r\noptions that provided two ROM chips, loaded a program into main memory from those ROM chips and jumped to\r\nit.[30] Digital Equipment Corporation introduced the integrated-circuit-ROM-based BM873 (1974),[33] M9301\r\n(1977),[34] M9312 (1978),[35] REV11-A and REV11-C,[36] MRV11-C,[37] and MRV11-D[38] ROM memories, all\r\nusable as bootstrap ROMs. The PDP-11/34 (1976),[39] PDP-11/60 (1977),[40] PDP-11/24 (1979),[41] and most\r\nlater models include boot ROM modules.\r\nAn Italian telephone switching computer, called \"Gruppi Speciali\", patented in 1975 by Alberto Ciaramella, a\r\nresearcher at CSELT,\r\n[42]\r\n included an (external) ROM. Gruppi Speciali was, starting from 1975, a fully single-button machine booting into the operating system from a ROM memory composed of semiconductors, not ferrite\r\ncores. Although the ROM device was not natively embedded in the computer of Gruppi Speciali, due to the design\r\nof the machine, it also allowed the single-button ROM booting in machines not designed for that (therefore, this\r\n\"bootstrap device\" was architecture-independent), e.g., the PDP-11. Storing the state of the machine after the\r\nswitch-off was also in place, which was another critical feature in the telephone switching contest.[43]\r\nSome minicomputers and superminicomputers include a separate console processor that bootstraps the main\r\nprocessor. The PDP-11/44 had an Intel 8085 as a console processor;[44] the VAX-11/780, the first member of\r\nDigital's VAX line of 32-bit superminicomputers, had an LSI-11-based console processor,\r\n[45]\r\n and the VAX-11/730\r\nhad an 8085-based console processor.\r\n[46]\r\n These console processors could boot the main processor from various\r\nstorage devices.\r\nSome other superminicomputers, such as the VAX-11/750, implement console functions, including the first stage\r\nof booting, in CPU microcode.[47]\r\nMicroprocessors and microcomputers\r\n[edit]\r\nTypically, a microprocessor will, after a reset or power-on condition, perform a start-up process that usually takes\r\nthe form of \"begin execution of the code that is found starting at a specific address\" or \"look for a multibyte code\r\nat a specific address and jump to the indicated location to begin execution\". A system built using that\r\nmicroprocessor will have the permanent ROM occupying these special locations so that the system always begins\r\noperating without operator assistance. For example, Intel x86 processors always start by running the instructions\r\nbeginning at F000:FFF0,[48][49] while for the MOS 6502 processor, initialization begins by reading a two-byte\r\nvector address at $FFFD (MS byte) and $FFFC (LS byte) and jumping to that location to run the bootstrap code.\r\n[50]\r\nApple Computer's first computer, the Apple 1, introduced in 1976, featured PROM chips that eliminated the need\r\nfor a front panel for the boot process (as was the case with the Altair 8800) in a commercial computer. According\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 8 of 25\n\nto Apple's ad announcing it, \"No More Switches, No More Lights ... the firmware in PROMS enables you to enter,\r\ndisplay and debug programs (all in hex) from the keyboard.\"[51]\r\nDue to the expense of read-only memory at the time, the Apple II booted its disk operating systems using a series\r\nof very small incremental steps, each passing control onward to the next phase of the gradually more complex\r\nboot process. (See Apple DOS: Boot loader). Because so little of the disk operating system relied on ROM, the\r\nhardware was also extremely flexible and supported a wide range of customized disk copy protection\r\nmechanisms. (See Software Cracking: History.)\r\nSome operating systems, most notably pre-1995 Macintosh systems from Apple, are so closely interwoven with\r\ntheir hardware that it is impossible to natively boot an operating system other than the standard one. This is the\r\nopposite extreme of the scenario using switches mentioned above; it is highly inflexible but relatively error-proof\r\nand foolproof as long as all hardware is working normally. A common solution in such situations is to design a\r\nboot loader that works as a program belonging to the standard OS that hijacks the system and loads the alternative\r\nOS. This technique was used by Apple for its A/UX Unix implementation and copied by various freeware\r\noperating systems and BeOS Personal Edition 5.\r\nSome machines, like the Atari ST microcomputer, were \"instant-on\", with the operating system executing from a\r\nROM. Retrieval of the OS from secondary or tertiary store was thus eliminated as one of the characteristic\r\noperations for bootstrapping. To allow system customizations, accessories, and other support software to be loaded\r\nautomatically, the Atari's floppy drive was read for additional components during the boot process. There was a\r\ntimeout delay that provided time to manually insert a floppy as the system searched for the extra components. This\r\ncould be avoided by inserting a blank disk. The Atari ST hardware was also designed so the cartridge slot could\r\nprovide native program execution for gaming purposes as a holdover from Atari's legacy making electronic\r\ngames; by inserting the Spectre GCR cartridge with the Macintosh system ROM in the game slot and turning the\r\nAtari on, it could \"natively boot\" the Macintosh operating system rather than Atari's own TOS.\r\nThe IBM Personal Computer included ROM-based firmware called the BIOS; one of the functions of that\r\nfirmware was to perform a power-on self test when the machine was powered up, and then to read software from a\r\nboot device and execute it. Firmware compatible with the BIOS on the IBM Personal Computer is used in IBM\r\nPC compatible computers. The UEFI was developed by Intel, originally for Itanium-based machines, and later\r\nalso used as an alternative to the BIOS in x86-based machines, including Apple Macs using Intel processors.\r\nUnix workstations originally had vendor-specific ROM-based firmware. Sun Microsystems later developed\r\nOpenBoot, later known as Open Firmware, which incorporated a Forth interpreter, with much of the firmware\r\nbeing written in Forth. It was standardized by the IEEE as IEEE standard 1275-1994; firmware that implements\r\nthat standard was used in PowerPC-based Macs and some other PowerPC-based machines, as well as Sun's own\r\nSPARC-based computers. The Advanced RISC Computing specification defined another firmware standard,\r\nwhich was implemented on some MIPS-based and Alpha-based machines and the SGI Visual Workstation x86-\r\nbased workstations.\r\nModern boot loaders\r\n[edit]\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 9 of 25\n\nWhen a computer is turned off, its software‍—\r\nincluding operating systems, application code, and data‍—remains\r\nstored on non-volatile memory. When the computer is powered on, it typically does not have an operating system\r\nor its loader in random-access memory (RAM). The computer first executes a relatively small program stored in\r\nread-only memory (ROM, and later EEPROM, NOR flash) which support execute in place, to initialize CPU and\r\nmotherboard, to initialize the memory (especially on x86 systems), to initialize and access the storage (usually a\r\nblock-addressed device, e.g. hard disk drive, NAND flash, solid-state drive) from which the operating system\r\nprograms and data can be loaded into RAM, and to initialize other I/O devices.\r\nThe small program that starts this sequence is known as a bootstrap loader, bootstrap or boot loader. Often,\r\nmultiple-stage boot loaders are used, during which several programs of increasing complexity load one after the\r\nother in a process of chain loading.\r\nSome earlier computer systems, upon receiving a boot signal from a human operator or a peripheral device, may\r\nload a very small number of fixed instructions into memory at a specific location, initialize at least one CPU, and\r\nthen point the CPU to the instructions and start their execution. These instructions typically start an input\r\noperation from some peripheral device (which may be switch-selectable by the operator). Other systems may send\r\nhardware commands directly to peripheral devices or I/O controllers that cause an extremely simple input\r\noperation (such as \"read sector zero of the system device into memory starting at location 1000\") to be carried out,\r\neffectively loading a small number of boot loader instructions into memory; a completion signal from the I/O\r\ndevice may then be used to start execution of the instructions by the CPU.\r\nSmaller computers often use less flexible but more automatic boot loader mechanisms to ensure that the computer\r\nstarts quickly and with a predetermined software configuration. In many desktop computers, for example, the\r\nbootstrapping process begins with the CPU executing software contained in ROM (for example, the BIOS of an\r\nIBM PC) at a predefined address (some CPUs, including the Intel x86 series are designed to execute this software\r\nafter reset without outside help). This software contains rudimentary functionality to search for devices eligible to\r\nparticipate in booting, and load a small program from a special section (most commonly the boot sector) of the\r\nmost promising device, typically starting at a fixed entry point such as the start of the sector.\r\nBoot loaders may face peculiar constraints, especially in size; for instance, on the IBM PC and compatibles, the\r\nboot code must fit in the Master Boot Record (MBR) and the Partition Boot Record (PBR), which in turn are\r\nlimited to a single sector; on the IBM System/360, the size is limited by the IPL medium, e.g., card size, track\r\nsize.\r\nOn systems with those constraints, the first program loaded into RAM may not be sufficiently large to load the\r\noperating system and, instead, must load another, larger program. The first program loaded into RAM is called a\r\nfirst-stage boot loader, and the program it loads is called a second-stage boot loader. On many embedded CPUs,\r\nthe CPU built-in boot ROM, sometimes called the zero-stage boot loader,\r\n[52]\r\n can find and load first-stage boot\r\nloaders.\r\nFirst-stage boot loaders\r\n[edit]\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 10 of 25\n\nExamples of first-stage (hardware initialization stage) boot loaders include BIOS, UEFI, coreboot, Libreboot and\r\nDas U-Boot. On the IBM PC, the boot loader in the Master Boot Record (MBR) and the Partition Boot Record\r\n(PBR) was coded to require at least 32 KB[53][54] (later expanded to 64 KB[55]) of system memory and only use\r\ninstructions supported by the original 8088/8086 processors.\r\nSecond-stage boot loaders\r\n[edit]\r\nSecond-stage (OS initialization stage) boot loaders, such as shim,[56] GNU GRUB, rEFInd, BOOTMGR,\r\nSyslinux, and NTLDR, are not themselves operating systems, but are able to load an operating system properly\r\nand transfer execution to it; the operating system subsequently initializes itself and may load extra device drivers.\r\nThe second-stage boot loader does not need drivers for its own operation, but may instead use generic storage\r\naccess methods provided by system firmware such as the BIOS, UEFI or Open Firmware, though typically with\r\nrestricted hardware functionality and lower performance.[57]\r\nMany boot loaders (like GNU GRUB, rEFInd, Windows's BOOTMGR, Syslinux, and Windows NT/2000/XP's\r\nNTLDR) can be configured to give the user multiple booting choices. These choices can include different\r\noperating systems (for dual or multi-booting from different partitions or drives), different versions of the same\r\noperating system (in case a new version has unexpected problems), different operating system loading options\r\n(e.g., booting into a rescue or safe mode), and some standalone programs that can function without an operating\r\nsystem, such as memory testers (e.g., memtest86+), a basic shell (as in GNU GRUB), or even games (see List of\r\nPC Booter games).[58] Some boot loaders can also load other boot loaders; for example, GRUB loads BOOTMGR\r\ninstead of loading Windows directly. Usually, a default choice is preselected with a time delay during which a user\r\ncan press a key to change the choice; after this delay, the default choice is automatically run so normal booting can\r\noccur without interaction.\r\nThe boot process can be considered complete when the computer is ready to interact with the user, or the\r\noperating system is capable of running system programs or application programs.\r\nFirst and second stages boot loaders\r\n[edit]\r\nSome boot loaders, such as Das U-Boot and iBoot, include both first- and second-stage boot functions.\r\nEmbedded and multi-stage boot loaders\r\n[edit]\r\nMany embedded systems must boot immediately. For example, waiting a minute for a digital television or a GPS\r\nnavigation device to start is generally unacceptable. Therefore, such devices have software systems in ROM or\r\nflash memory so the device can begin functioning immediately; little or no loading is necessary, because the\r\nloading can be precomputed and stored on the ROM when the device is made.[citation needed]\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 11 of 25\n\nLarge and complex systems may have boot procedures that proceed in multiple phases until finally the operating\r\nsystem and other programs are loaded and ready to execute. Because operating systems are designed as if they\r\nnever start or stop, a boot loader might load the operating system, configure itself as a mere process within that\r\nsystem, and then irrevocably transfer control to the operating system. The boot loader then terminates normally as\r\nany other process would.\r\nMost computers are also capable of booting over a computer network. In this scenario, the operating system is\r\nstored on the disk of a server, and certain parts of it are transferred to the client using a simple protocol such as the\r\nTrivial File Transfer Protocol (TFTP). After these parts have been transferred, the operating system takes over\r\ncontrol of the booting process.\r\nAs with the second-stage boot loader, network booting begins by using generic network access methods provided\r\nby the network interface's boot ROM, which typically contains a Preboot Execution Environment (PXE) image.\r\nNo drivers are required, but the system functionality is limited until the operating system kernel and drivers are\r\ntransferred and started. As a result, once the ROM-based booting has completed it is entirely possible to network\r\nboot into an operating system that itself does not have the ability to use the network interface.\r\nIBM-compatible personal computers (PC)\r\n[edit]\r\nWindows To Go bootable flash drive, a Live USB example\r\nThe boot device is the storage device from which the operating system is loaded. A modern PC's UEFI or BIOS\r\nfirmware supports booting from various devices, typically a local solid-state drive or hard disk drive via the GPT\r\nor Master Boot Record (MBR) on such a drive or disk, an optical disc drive (using El Torito), a USB mass storage\r\ndevice (USB flash drive, memory card reader, USB hard disk drive, USB optical disc drive, USB solid-state drive,\r\netc.), or a network interface card (using PXE). Older, less common BIOS-bootable devices include floppy disk\r\ndrives, Zip drives, and LS-120 drives. IBM-compatible PCs are examples that use horizontal integrated hardware\r\nand UEFI/BIOS firmware.\r\nTypically, the system firmware (UEFI or BIOS) will allow the user to configure a boot order. If the boot order is\r\nset to \"first, the DVD drive; second, the hard disk drive\", then the firmware will try to boot from the DVD drive,\r\nand if this fails (e.g., because there is no DVD in the drive), it will try to boot from the local hard disk drive.\r\nFor example, on a PC with Windows installed on the hard drive, the user could set the boot order to the one given\r\nabove, and then insert a Linux Live CD in order to try out Linux without having to install an operating system\r\nonto the hard drive. This is an example of dual booting, in which the user chooses which operating system to start\r\nafter the computer has performed its power-on self-test (POST). In this example of dual booting, the user chooses\r\nby inserting or removing the DVD from the computer, but it is more common to choose which operating system to\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 12 of 25\n\nboot by selecting from a boot manager menu on the selected device, by using the computer keyboard to select\r\nfrom a BIOS or UEFI boot menu, or both; the boot menu is typically entered by pressing F8 or F12 keys during\r\nthe POST; the BIOS setup is typically entered by pressing F2 or DEL keys during the POST.\r\n[59][60]\r\nSeveral devices are available that enable the user to quick-boot into what is usually a variant of Linux for various\r\nsimple tasks such as Internet access; examples are Splashtop and Latitude ON.\r\n[61][62][63]\r\nA hex dump of FreeBSD's boot0 MBR\r\nAward Software BIOS from 2000 during booting\r\nUpon starting, an IBM-compatible personal computer's x86 CPU, executes in real mode, the instruction located at\r\nreset vector (the physical memory address FFFF0h on 16-bit x86 processors[64] and FFFFFFF0h on 32-bit and 64-\r\nbit x86 processors[65][66]), usually pointing to the firmware (UEFI or BIOS) entry point inside the ROM. This\r\nmemory location typically contains a jump instruction that transfers execution to the location of the firmware\r\n(UEFI or BIOS) start-up program. This program runs a power-on self-test (POST) to check and initialize required\r\ndevices such as main memory (DRAM), the PCI bus and the PCI devices (including running embedded option\r\nROMs). One of the most involved steps is setting up DRAM over SPD, further complicated by the fact that, at this\r\npoint, memory is very limited.\r\nAfter initializing required hardware, the firmware (UEFI or BIOS) goes through a pre-configured list of non-volatile storage devices (\"boot device sequence\") until it finds one that is bootable.\r\nOnce the BIOS has found a bootable device it loads the boot sector to linear address 7C00h (usually\r\nsegment:offset 0000h:7C00h,\r\n[53][55]: 29 \r\n but some BIOSes erroneously use 07C0h:0000h[citation needed]) and\r\ntransfers execution to the boot code. In the case of a hard disk, this is referred to as the Master Boot Record\r\n(MBR). The conventional MBR code checks the MBR's partition table for a partition set as bootable[nb 6] (the one\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 13 of 25\n\nwith active flag set). If an active partition is found, the MBR code loads the boot sector code from that partition,\r\nknown as Volume Boot Record (VBR), and executes it. The MBR boot code is often operating-system specific.\r\nA bootable MBR device is defined as one that can be read from, and where the last two bytes of the first sector\r\ncontain the little-endian word AA55h,\r\n[nb 7]\r\n found as byte sequence 55h, AAh on disk (also known as the MBR\r\nboot signature), or where it is otherwise established that the code inside the sector is executable on x86 PCs.\r\nThe boot sector code is the first-stage boot loader. It is located on fixed disks and removable drives, and must fit\r\ninto the first 446 bytes of the Master Boot Record in order to leave room for the default 64-byte partition table\r\nwith four partition entries and the two-byte boot signature, which the BIOS requires for a proper boot loader — or\r\neven less, when additional features like more than four partition entries (up to 16 with 16 bytes each), a disk\r\nsignature (6 bytes), a disk timestamp (6 bytes), an Advanced Active Partition (18 bytes) or special multi-boot\r\nloaders have to be supported as well in some environments. In floppy and superfloppy Volume Boot Records, up\r\nto 59 bytes are occupied for the Extended BIOS Parameter Block on FAT12 and FAT16 volumes since DOS 4.0,\r\nwhereas the FAT32 EBPB introduced with DOS 7.1 requires even 87 bytes, leaving only 423 bytes for the boot\r\nloader when assuming a sector size of 512 bytes. Microsoft boot sectors therefore traditionally imposed certain\r\nrestrictions on the boot process, for example, the boot file had to be located at a fixed position in the root directory\r\nof the file system and stored as consecutive sectors,[67][68] conditions taken care of by the SYS command and\r\nslightly relaxed in later versions of DOS.[68][nb 8] The boot loader was then able to load the first three sectors of\r\nthe file into memory, which happened to contain another embedded boot loader able to load the remainder of the\r\nfile into memory.\r\n[68]\r\n When Microsoft added LBA and FAT32 support, they even switched to a boot loader\r\nreaching over two physical sectors and using 386 instructions for size reasons. At the same time, other vendors\r\nmanaged to squeeze much more functionality into a single boot sector without relaxing the original constraints on\r\nonly minimal available memory (32 KB) and processor support (8088/8086).[nb 9] For example, DR-DOS boot\r\nsectors are able to locate the boot file in the FAT12, FAT16 and FAT32 file system, and load it into memory as a\r\nwhole via CHS or LBA, even if the file is not stored in a fixed location and in consecutive sectors.[69][53][70][71]\r\n[72][nb 10][nb 9]\r\nThe VBR is often OS-specific; however, its main function is to load and execute the operating system boot loader\r\nfile (such as bootmgr or ntldr ), which is the second-stage boot loader, from an active partition. Then the boot\r\nloader loads the OS kernel from the storage device.\r\nIf there is no active partition, or the active partition's boot sector is invalid, the MBR may load a secondary boot\r\nloader which will select a partition (often via user input) and load its boot sector, which usually loads the\r\ncorresponding operating system kernel. In some cases, the MBR may also attempt to load secondary boot loaders\r\nbefore trying to boot the active partition. If all else fails, it should issue an INT 18h[55][53] BIOS interrupt call\r\n(followed by an INT 19h just in case INT 18h would return) in order to give back control to the BIOS, which\r\nwould then attempt to boot off other devices, attempt a remote boot via network.[53]\r\nMany modern systems (Intel Macs and newer PCs) use UEFI.\r\n[73][74]\r\nUnlike BIOS, UEFI (not Legacy boot via CSM) does not rely on boot sectors, UEFI system loads the boot loader\r\n(EFI application file in USB disk or in the EFI System Partition) directly,\r\n[75]\r\n and the OS kernel is loaded by the\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 14 of 25\n\nboot loader.\r\nSoCs, embedded systems, microcontrollers, and FPGAs\r\n[edit]\r\nAn unlocked bootloader of an Android device, showing additional available options\r\nMany modern CPUs, SoCs and microcontrollers (for example, TI OMAP) or sometimes even digital signal\r\nprocessors (DSPs) may have a boot ROM integrated directly into their silicon, so such a processor can perform a\r\nsimple boot sequence on its own and load boot programs (firmware or software) from boot sources such as NAND\r\nflash or eMMC. It is difficult to hardwire all the required logic for handling such devices, so an integrated boot\r\nROM is used instead in such scenarios. Also, a boot ROM may be able to load a boot loader or diagnostic program\r\nvia serial interfaces like UART, SPI, USB and so on. This feature is often used for system recovery purposes, or it\r\ncould also be used for initial non-volatile memory programming when there is no software available in the non-volatile memory yet. Many modern microcontrollers (e.g., flash memory controller on USB flash drives) have\r\nfirmware ROM integrated directly into their silicon.\r\nSome embedded system designs may also include an intermediary boot sequence step. For example, Das U-Boot\r\nmay be split into two stages: the platform would load a small SPL (Secondary Program Loader), which is a\r\nstripped-down version of U-Boot, and the SPL would do some initial hardware configuration (e.g. DRAM\r\ninitialization using CPU cache as RAM) and load the larger, fully featured version of U-Boot.[76] Such embedded\r\nsystems may used highly customized and vertical integrated hardware and software, and their boot programs may\r\nbe simpler.\r\n[77]\r\n Some CPUs and SoCs may not use CPU cache as RAM on boot process, they use an integrated\r\nboot processor to do some hardware configuration to reduce cost.[78]\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 15 of 25\n\nIt is also possible to take control of a system by using a hardware debug interface such as JTAG. Such an interface\r\nmay be used to write the boot loader program into bootable non-volatile memory (e.g. flash) by instructing the\r\nprocessor core to perform the necessary actions to program non-volatile memory. Alternatively, the debug\r\ninterface may be used to upload some diagnostic or boot code into RAM, and then to start the processor core and\r\ninstruct it to execute the uploaded code. This allows, for example, the recovery of embedded systems where no\r\nsoftware remains on any supported boot device, and where the processor does not have any integrated boot ROM.\r\nJTAG is a standard and popular interface; many CPUs, microcontrollers and other devices are manufactured with\r\nJTAG interfaces (as of 2009).[citation needed]\r\nSome microcontrollers provide special hardware interfaces that cannot be used to take arbitrary control of a\r\nsystem or directly run code, but instead allow the insertion of boot code into bootable non-volatile memory (like\r\nflash memory) via simple protocols. Then, at the manufacturing phase, such interfaces are used to inject boot code\r\n(and possibly other code) into non-volatile memory. After system reset, the microcontroller begins to execute code\r\nprogrammed into its non-volatile memory, just like usual processors use ROMs for booting. Most notably, this\r\ntechnique is used by Atmel AVR microcontrollers, and by others as well. In many cases, such interfaces are\r\nimplemented by hardwired logic. In other cases, such interfaces could be created by software running in integrated\r\non-chip boot ROM from GPIO pins.\r\nMost DSPs have a serial mode boot and a parallel mode boot, such as the host port interface (HPI boot).\r\nIn the case of DSPs, there is often a second microprocessor or microcontroller present in the system design, and\r\nthis is responsible for overall system behavior, interrupt handling, dealing with external events, user interface, etc.,\r\nwhile the DSP is dedicated to signal processing tasks only. In such systems, the DSP could be booted by another\r\nprocessor, which is sometimes referred as the host processor (giving name to a Host Port). Such a processor is\r\nalso sometimes referred to as the master, since it usually boots first from its own memories and then controls\r\noverall system behavior, including booting of the DSP, and then further controls the DSP's behavior. The DSP\r\noften lacks its own boot memories and relies on the host processor to supply the required code instead. The most\r\nnotable systems with such a design are cell phones, modems, audio and video players and so on, where a DSP and\r\na CPU/microcontroller coexist.\r\nMany FPGA chips load their configuration from an external configuration ROM, typically a serial EEPROM, on\r\npower-up.\r\nVarious measures have been implemented that enhance the security of the booting process. Some of them are\r\nmade mandatory, others can be disabled or enabled by the end user. Traditionally, booting did not involve the use\r\nof cryptography. The security can be bypassed by unlocking the boot loader, which might or might not be\r\napproved by the manufacturer. Modern boot loaders make use of concurrency, meaning they can run multiple\r\nprocessor cores and threads at the same time, which adds extra layers of complexity to secure booting.\r\nMatthew Garrett argued that booting security serves a legitimate goal, but in doing so chooses defaults that are\r\nhostile to users.[79]\r\nUEFI secure boot[80]\r\nAndroid Verified boot\r\nSamsung Knox\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 16 of 25\n\nMeasured boot with the Trusted Platform Module, also known as \"trusted boot\".\r\nIntel BootGuard\r\nDisk encryption\r\nFirmware passwords\r\nUART console of a TP-Link router with OpenWrt that is stuck in a bootloop\r\nWhen debugging a concurrent and distributed system of systems, a bootloop (also written boot loop or boot-loop) is a diagnostic condition of an erroneous state that occurs on computing devices; when those devices\r\nrepeatedly fail to complete the booting process and restart before a boot sequence is finished, a restart might\r\nprevent a user from accessing the regular interface.\r\nAs the complexity of today's products increases, single projects, single departments or even single\r\ncompanies can no longer develop total products, causing concurrent and distributed development.\r\nToday and worldwide, industries are facing complex product development and its vast array of\r\nassociated problems, relating to project organization, project control and product quality. Many\r\nprocesses will become distributed as well. The defect detection process, so important for measuring and\r\neventually achieving product quality, is typically one of the first to experience problems caused by the\r\ndistributed nature of the project. The distribution of defect detection activities over several parties\r\nintroduces risks like the inadequate review of work products, occurrence of \"blind spots\" with respect to\r\ntest coverage or over-testing of components. Lifecycle-wide coordination of defect detection is\r\ntherefore needed to ensure effectiveness and efficiency of defect detection activities. —J.J.M.\r\nTrienekens; R.J. Kusters. (2004)[81]\r\nDetection of an erroneous state\r\n[edit]\r\nThe system might exhibit its erroneous state in, for example, an explicit bootloop or a blue screen of death, before\r\nrecovery is indicated.[82] Detection of an erroneous state may require a distributed event store and stream-processing platform for real-time operation of a distributed system.\r\nRecovery from an erroneous state\r\n[edit]\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 17 of 25\n\nAn erroneous state can trigger bootloops; this state can be caused by misconfiguration from previously known-good operations. Recovery attempts from that erroneous state then enter a reboot, in an attempt to return to a\r\nknown-good state. In Windows OS operations, for example, the recovery procedure was to reboot three times, the\r\nreboots needed to return to a usable menu.[83][84][82]\r\nRecovery might be specified via Security Assertion Markup Language (SAML), which can also implement Single\r\nsign-on (SSO) for some applications; in the zero trust security model, identification, authorization, and\r\nauthentication are separable concerns in an SSO session. When recovery of a site is indicated (viz., a blue screen\r\nof death is displayed on an airport terminal screen)[a] personal site visits might be required to remediate the\r\nsituation.[81]\r\nWindows NT 4.0[85]\r\nWindows 2000[86]\r\nWindows Server[87]\r\nWindows 10[88]\r\nThe Nexus 5X[89]\r\nAndroid 10: when setting a specific image as wallpaper, the luminance value exceeded the maximum of\r\n255, which happened due to a rounding error during conversion from sRGB to RGB. This then crashed the\r\nSystemUI component on every boot.[90][91]\r\nGoogle Nest hub[92]\r\nLG smartphone bootloop issues\r\nOn 19 July 2024, an update of CrowdStrike's Falcon software caused the 2024 CrowdStrike incident\r\nresulting in Microsoft Windows systems worldwide stuck in bootloops or recovery mode.\r\n[a]\r\nLook up bootup in Wiktionary, the free dictionary.\r\nBootstrapping § Computing\r\nMulti-booting\r\nBoot disk\r\nBootkit\r\nComparison of boot loaders\r\nLinux startup process\r\nMacintosh startup\r\nMicroreboot\r\nMulti boot\r\nNetwork booting\r\nRedBoot\r\nSelf-booting disk\r\nWindows startup process\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 18 of 25\n\n1. ^ Jump up to: a\r\n \r\nb\r\n CrowdStrike reverted the content update at 05:27 UTC,[93]\r\n This left machines stuck in a\r\nboot loop or in recovery mode.\r\n[94]\r\n and devices booted after the revert were not affected.[84][95]\r\n1. ^ E.g., System/360 through IBM Z, RS/6000 and System/38 through IBM Power Systems\r\n2. ^ Including daemons.\r\n3. ^ UU was often of the form Uu, U=Control unit address, u=Device address, but some control units\r\nattached only 8 devices; some attached more than 16. Indeed, the 3830 DASD controller offered 32-drive-addressing as an option.\r\n4. ^ Excluding the 370/145 and 370/155, which used a 3210 or 3215 console typewriter.\r\n5. ^ Only the S/360 used the 2250; the 360/85, 370/165 and 370/168 used a keyboard/display device\r\ncompatible with nothing else.\r\n6. ^ The active partition may contain a Second-stage boot loader, e.g., OS/2 Boot Manager, rather than an OS.\r\n7. ^ The signature at offset +1FEh in boot sectors is 55h AAh , that is 55h at offset +1FEh and AAh at\r\noffset +1FFh . Since little-endian representation must be assumed in the context of IBM PC compatible\r\nmachines, this can be written as 16-bit word AA55h in programs for x86 processors (note the swapped\r\norder), whereas it would have to be written as 55AAh in programs for other CPU architectures using a big-endian representation. Since this has been mixed up numerous times in books and even in original\r\nMicrosoft reference documents, this article uses the offset-based byte-wise on-disk representation to avoid\r\nany possible misinterpretation.\r\n8. ^ The PC DOS 5.0 manual incorrectly states that the system files no longer need to be contiguous.\r\nHowever, for the boot process to work the system files still need to occupy the first two directory entries\r\nand the first three sectors of IBMBIO.COM still need to be stored contiguously. SYS continues to take care\r\nof these requirements.\r\n9. ^ Jump up to: a\r\n \r\nb\r\n As an example, while the extended functionality of DR-DOS MBRs and boot sectors\r\ncompared to their MS-DOS/PC DOS counterparts could still be achieved utilizing conventional code\r\noptimization techniques in assembly language up to 7.05, for the addition of LBA, FAT32 and LOADER\r\nsupport the 7.07 sectors had to resort to self-modifying code, opcode-level programming in machine\r\nlanguage, controlled utilization of (documented) side effects, multi-level data/code overlapping and\r\nalgorithmic folding techniques to squeeze everything into a single physical sector, as it was a requirement\r\nfor backward- and cross-compatibility with other operating systems in multi-boot and chain load scenarios.\r\n10. ^ There is one exception to the rule that DR-DOS VBRs will load the whole IBMBIO.COM file into\r\nmemory: If the IBMBIO.COM file is larger than some 29 KB, trying to load the whole file into memory\r\nwould result in the boot loader to overwrite the stack and relocated Disk Parameter Table (DPT/FDPB).[A]\r\nTherefore, a DR-DOS 7.07 VBR would only load the first 29 KB of the file into memory, relying on\r\nanother loader embedded into the first part of IBMBIO.COM to check for this condition and load the\r\nremainder of the file into memory by itself if necessary. This does not cause compatibility problems, as\r\nIBMBIO.COM's size never exceeded this limit in previous versions without this loader.\r\n[A]\r\n Combined with\r\na dual entry structure this also allows the system to be loaded by a PC DOS VBR, which would load only\r\nthe first three sectors of the file into memory.\r\n1. ^ \"boot-strap\". Oxford English Dictionary. Vol. II (2nd ed.). Oxford: Clarendon Press. p. 407. “1953. A\r\ntechnique sometimes called the 'bootstrap technique'...”\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 19 of 25\n\n2. ^ \"bootstrap\". Computer Dictionary of Information Technology. Archived from the original on 2019-08-05.\r\nRetrieved 2019-08-05.\r\n3. ^ \"Bootstrap\". The Free Dictionary. Archived from the original on 2006-08-27. Retrieved 2008-08-27.\r\n4. ^ \"Pull oneself up by bootstraps\". Idioms by The Free Dictionary. Archived from the original on 2018-10-\r\n05. Retrieved 2019-10-07.\r\n5. ^ \"Bootstrap Definition\". Tech Terms. Archived from the original on 2020-05-10. Retrieved 2019-10-02.\r\n6. ^ \"Pull yourself up by your bootstraps\". The Phrase Finder. Archived from the original on 2012-04-17.\r\nRetrieved 2010-07-15.\r\n7. ^ \"boot\". Oxford English Dictionary. Vol. II (2nd ed.). Oxford: Clarendon Press. p. 405. “1975...The boot\r\noverlay code will overlay the first two instructions of the loader.”\r\n8. ^ Campbell-Kelly, Martin (1980). \"Programming the EDSAC\". IEEE Annals of the History of Computing.\r\n2 (1): 7–36. doi:10.1109/mahc.1980.10009.\r\n9. ^ Wilkes, Maurice V.; Wheeler, David J.; Gill, Stanley (1951). The Preparation of Programs for an\r\nElectronic Digital Computer. Addison-Wesley. Archived from the original on 2023-02-20. Retrieved 2020-\r\n09-25.\r\n10. ^ Buchholz, Werner (1953). \"The System Design of the IBM Type 701 Computer\" (PDF). Proceedings of\r\nthe I.R.E. 41 (10): 1273. Archived (PDF) from the original on 2022-10-09.\r\n11. ^ Jump up to: a\r\n \r\nb\r\n \"IBM 7619 Exchange\". Reference Manual 7030 Data Processing System (PDF). IBM.\r\nAugust 1961. pp. 125–127. A22-6530-2. Archived (PDF) from the original on 2022-10-09.\r\n12. ^ Principles of Operation Type 701 And Associated Equipment (PDF). IBM. 1953. p. 26. Archived (PDF)\r\nfrom the original on 2022-10-09. Retrieved 2012-11-09.\r\n13. ^ Jeremy M. Norman (2005). From Gutenberg to the Internet. Norman. p. 436. ISBN 0-930405-87-0.\r\n14. ^ 704 Electronic Data-Processing Machine Manual of Operation (PDF). IBM. pp. 14–15. Archived (PDF)\r\nfrom the original on 2022-10-09.\r\n15. ^ Operator's Guide for IBM 7090 Data Processing System (PDF). IBM. p. 34. Archived (PDF) from the\r\noriginal on 2022-10-09.\r\n16. ^ IBM 7094 Principles of Operation (PDF). IBM. p. 146. Archived (PDF) from the original on 2022-10-\r\n09.\r\n17. ^ Oxford English Dictionary. Oxford University. 1939.\r\n18. ^ 650 magnetic drum data-processing machine manual of operation (PDF). IBM. 1955. pp. 49, 53–54.\r\nArchived (PDF) from the original on 2022-10-09.\r\n19. ^ Operator's Guide for IBM 7040-7044 Systems (PDF). IBM. p. 10. A22-6741-1. Archived (PDF) from the\r\noriginal on 2022-10-09.\r\n20. ^ CONTROL DATA 6600 Computer System Reference Manual (PDF) (Second ed.). Control Data\r\nCorporation. August 1963. p. 53. Archived (PDF) from the original on 2022-10-09.\r\n21. ^ GE-645 System Manual (PDF). General Electric. January 1968. Archived (PDF) from the original on\r\n2022-10-09. Retrieved 2019-10-30.\r\n22. ^ PDP-10 System Reference Manual, Part 1 (PDF). Digital Equipment Corporation. 1969. pp. 2–72.\r\nArchived (PDF) from the original on 2022-10-09. Retrieved 2012-11-09.\r\n23. ^ Jump up to: a\r\n \r\nb\r\n Burroughs B 1700 Systems Reference Manual (PDF). Burroughs Corporation. November\r\n1973. p. 1-14. Archived (PDF) from the original on 2022-10-09.\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 20 of 25\n\n24. ^ Jump up to: a\r\n \r\nb\r\n z/Architecture Principles of Operation (PDF). IBM. September 2005. pp. Chapter 17.\r\nArchived (PDF) from the original on 2022-10-09. Retrieved 2007-04-14.\r\n25. ^ BM792 read-only-memory and MR11~DB bootstrap loader (PDF). Digital Equipment Corporation.\r\nJanuary 1974. DEC-II-HBMAA-E-D. Archived (PDF) from the original on 2022-10-09.\r\n26. ^ PDP-11 Peripherals Handbook (PDF). Digital Equipment Corporation. 1976. p. 4-25. Archived (PDF)\r\nfrom the original on 2022-10-09.\r\n27. ^ Programmed Data Processor-7 Users Handbook (PDF). Digital Equipment Corporation. 1965. p. 143.\r\nArchived (PDF) from the original on 2022-10-09.\r\n28. ^ PDP-9 User Handbook (PDF). Digital Equipment Corporation. January 1968. p. 10-3. Archived (PDF)\r\nfrom the original on 2022-10-09.\r\n29. ^ PDP-15 Systems Reference Manual (PDF). Digital Equipment Corporation. August 1969. p. 10-3.\r\nArchived (PDF) from the original on 2022-10-09.\r\n30. ^ Jump up to: a\r\n \r\nb\r\n How To Use The Nova Computers (PDF). Data General. April 1971. p. 2-30. Archived\r\n(PDF) from the original on 2022-10-09.\r\n31. ^ \"Oldcomputers: Altair 8800b\". Archived from the original on 2020-01-03. Retrieved 2019-12-10.\r\n32. ^ Holmer, Glenn. Altair 8800 loads 4K BASIC from paper tape. Archived from the original on 2019-07-30.\r\nRetrieved 2016-05-02.\r\n33. ^ BM873 restart/loader (PDF). Digital Equipment Corporation. April 1974. DEC-11-H873A-B-D.\r\nArchived (PDF) from the original on 2022-10-09.\r\n34. ^ M9301 bootstrap/terminator module maintenance and operator's manual (PDF). Digital Equipment\r\nCorporation. June 1977. EK-M9301-TM-OO1. Archived (PDF) from the original on 2022-10-09.\r\n35. ^ M9312 bootstrap/terminator module technical manual (PDF). Digital Equipment Corporation. March\r\n1981. EK-M9312-TM-OO3. Archived (PDF) from the original on 2022-10-09.\r\n36. ^ Microcomputer Interfaces Handbook (PDF). Digital Equipment Corporation. 1981. p. 17. Archived\r\n(PDF) from the original on 2022-10-09.\r\n37. ^ \"10 MRV11-C Read-Only Memory Module\". Microcomputer Products Handbook (PDF). Digital\r\nEquipment Corporation. 1985. Archived (PDF) from the original on 2022-10-24. Retrieved 2022-06-12.\r\n38. ^ \"11 MRVll·D Universal Programmable Read.Only Memory\". Microcomputer Products Handbook (PDF).\r\nDigital Equipment Corporation. 1985. Archived (PDF) from the original on 2022-10-24. Retrieved 2022-\r\n06-12.\r\n39. ^ PDP-11/34 system user's manual (PDF). Digital Equipment Corporation. July 1977. pp. 1–5, 2-1 – 2-12.\r\nEK-11034-UG-001. Archived (PDF) from the original on 2022-10-09.\r\n40. ^ PDP-11/60 installation and operation manual (PDF). Digital Equipment Corporation. February 1979.\r\npp. 1–10, 2-29 – 2-34, 3-1 – 3-6. EK-11060-OP-003. Archived (PDF) from the original on 2022-10-09.\r\n41. ^ PDP-11/24 System Technical Manual (PDF). Digital Equipment Corporation. June 1981. p. 1-6. EK-11024-TM-001. Archived (PDF) from the original on 2022-10-09.\r\n42. ^ Ciaramella, Alberto. Device for automatically loading the central memory of electronic processors U.S.\r\nPatent No. 4,117,974. 1978-10-03. (submitted in 1975)\r\n43. ^ Alberto Ciaramella racconta il brevetto del boostrap dei computer concepito in CSELT [Alberto\r\nCiaramella discusses the patent for bootstrapping computers conceived at CSELT] (in Italian). Archived\r\nfrom the original on 2021-11-13.\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 21 of 25\n\n44. ^ PDP-11/44 System Technical Manual (PDF). Digital Equipment Corporation. February 1979. p. 6-57.\r\nEK-KD11Z-TM-001. Archived (PDF) from the original on 2022-10-09.\r\n45. ^ VAX-11/780 Hardware User's Guide (PDF). Digital Equipment Corporation. February 1979. 2.3\r\nBOOTSTRAPPING and 3.6.1 Boot Command (B). EK-11780-UG-001. Archived (PDF) from the original\r\non 2022-10-09.\r\n46. ^ VAX-11/730 Central Processing Unit Technical Description (PDF). Digital Equipment Corporation. May\r\n1982. p. 1-9. EK-KA730-TD-001. Archived (PDF) from the original on 2022-10-09.\r\n47. ^ VAX-11/750 Software Installation Guide (PDF). Digital Equipment Corporation. December 1982. pp. 1-\r\n2 – 1-4, B-1 – B-8, C-1 – C-2. AA-K410C-TE. Archived (PDF) from the original on 2022-10-09.\r\n48. ^ Osborne, Adam; Kane, Gerry (1981). Osborne 16-Bit Microprocessor Handbook (PDF).\r\nOSBORNE/McGraw-Hill. pp. 5–27. ISBN 0-931988-43-8. Archived (PDF) from the original on 2022-10-\r\n09. Retrieved 2019-08-23.\r\n49. ^ Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3 (3A, 3B, 3C \u0026 3D): System\r\nProgramming Guide (PDF). Archived (PDF) from the original on 2022-10-09.\r\n50. ^ Osborne, Adam; Kane, Gerry (1981). Osborne 4\u00268-Bit Microprocessor Handbook. Osborne/McGraw-Hill. pp. 10–20. ISBN 0-931988-42-X.\r\n51. ^ Apple Ad, Interface Age, October 1976\r\n52. ^ \"An Introduction to RISC-V Boot flow\" (PDF). Retrieved 2024-09-04.\r\n53. ^ Jump up to: a\r\n \r\nb\r\n \r\nc\r\n \r\nd\r\n \r\ne\r\n Paul, Matthias R. (1997-10-02) [1997-09-29]. \"Caldera OpenDOS 7.01/7.02 Update\r\nAlpha 3 IBMBIO.COM - README.TXT and BOOT.TXT - A short description of how OpenDOS is booted\".\r\nArchived from the original on 2003-10-04. Retrieved 2009-03-29. [1]\r\n54. ^ Sakamoto, Masahiko (2010-05-13). \"Why BIOS loads MBR into 7C00h in x86?\". Glamenv-Septzen.net.\r\nArchived from the original on 2017-08-24. Retrieved 2012-08-22.\r\n55. ^ Jump up to: a\r\n \r\nb\r\n \r\nc\r\n Compaq Computer Corporation; Phoenix Technologies Ltd; Intel Corporation (1996-\r\n01-11). \"BIOS Boot Specification 1.01\" (PDF). Archived (PDF) from the original on 2022-10-09. Retrieved\r\n2017-12-21.\r\n56. ^ Red Hat Bootloader Team. \"UEFI shim loader\". GitHub. Retrieved 2023-10-28.\r\n57. ^ \"Chapter 6 - Troubleshooting Startup and Disk Problems\". Windows NT Server Resource Kit. Microsoft.\r\nArchived from the original on 2007-05-15.\r\n58. ^ \"Tint\". coreboot. Archived from the original on 2010-12-28. Retrieved 2010-11-20.\r\n59. ^ \"List of PC brands with their corresponding hot-keys\". www.disk-image.com. Archived from the original\r\non 2020-11-11. Retrieved 2020-09-26.\r\n60. ^ \"How to Enter the BIOS on Any PC: Access Keys by Manufacturer | Tom's Hardware\".\r\nwww.tomshardware.com. Archived from the original on 2023-02-20. Retrieved 2020-09-26.\r\n61. ^ Brown, Eric (2008-10-02). \"MontaVista Linux drives Dell's quick-boot feature\". The LinuxDevices\r\nArchive. linuxdevices.com. Retrieved 2010-11-20.\r\n62. ^ Larabel, Michael (2008-06-14). \"SplashTop Linux On HP, Dell Notebooks?\". Phoronix. Archived from\r\nthe original on 2016-10-05. Retrieved 2010-11-20.\r\n63. ^ \"Voodoo Envy's Instant-On IOS (powered by Splashtop)\". YouTube. 2008-07-16. Archived from the\r\noriginal on 2021-11-13. Retrieved 2010-11-20.\r\n64. ^ \"iAPX 286 Programmer's Reference Manual\" (PDF). Intel. 1983. Section 5.3 SYSTEM\r\nINITIALIZATION, p. 5-7. Archived (PDF) from the original on 2022-10-09. Retrieved 2019-08-23. “Since\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 22 of 25\n\nthe CS register contains F000 (thus specifying a code segment starting at physical address F0000) and the\r\ninstruction pointer contains FFF0, the processor will execute its first instruction at physical address\r\nFFFF0H.”\r\n65. ^ \"80386 Programmer's Reference Manual\" (PDF). Intel. 1986. Section 10.2.3 First Instructions, p. 10-3.\r\nArchived (PDF) from the original on 2022-10-09. Retrieved 2013-11-03. “After RESET, address lines A31–\r\n20 are automatically asserted for instruction fetches. This fact, together with the initial values of CS:IP,\r\ncauses instruction execution to begin at physical address FFFFFFF0H.”\r\n66. ^ \"Intel 64 and IA-32 Architectures Software Developer's Manual\" (PDF). Intel Corporation. May 2012.\r\nSection 9.1.4 First Instruction Executed, p. 2611. Archived (PDF) from the original on 2022-10-09.\r\nRetrieved 2012-08-23. “The first instruction that is fetched and executed following a hardware reset is\r\nlocated at physical address FFFFFFF0h. This address is 16 bytes below the processor's uppermost\r\nphysical address. The EPROM containing the software-initialization code must be located at this address.”\r\n67. ^ Zbikowski, Mark; Allen, Paul; Ballmer, Steve; Borman, Reuben; Borman, Rob; Butler, John; Carroll,\r\nChuck; Chamberlain, Mark; Chell, David; Colee, Mike; Courtney, Mike; Dryfoos, Mike; Duncan, Rachel;\r\nEckhardt, Kurt; Evans, Eric; Farmer, Rick; Gates, Bill; Geary, Michael; Griffin, Bob; Hogarth, Doug;\r\nJohnson, James W.; Kermaani, Kaamel; King, Adrian; Koch, Reed; Landowski, James; Larson, Chris;\r\nLennon, Thomas; Lipkie, Dan; McDonald, Marc; McKinney, Bruce; Martin, Pascal; Mathers, Estelle;\r\nMatthews, Bob; Melin, David; Mergentime, Charles; Nevin, Randy; Newell, Dan; Newell, Tani; Norris,\r\nDavid; O'Leary, Mike; O'Rear, Bob; Olsson, Mike; Osterman, Larry; Ostling, Ridge; Pai, Sunil; Paterson,\r\nTim; Perez, Gary; Peters, Chris; Petzold, Charles; Pollock, John; Reynolds, Aaron; Rubin, Darryl; Ryan,\r\nRalph; Schulmeisters, Karl; Shah, Rajen; Shaw, Barry; Short, Anthony; Slivka, Ben; Smirl, Jon; Stillmaker,\r\nBetty; Stoddard, John; Tillman, Dennis; Whitten, Greg; Yount, Natalie; Zeck, Steve (1988). \"Technical\r\nadvisors\". The MS-DOS Encyclopedia: versions 1.0 through 3.2. By Duncan, Ray; Bostwick, Steve;\r\nBurgoyne, Keith; Byers, Robert A.; Hogan, Thom; Kyle, Jim; Letwin, Gordon; Petzold, Charles;\r\nRabinowitz, Chip; Tomlin, Jim; Wilton, Richard; Wolverton, Van; Wong, William; Woodcock, JoAnne\r\n(Completely reworked ed.). Redmond, Washington, USA: Microsoft Press. ISBN 1-55615-049-0. LCCN 87-\r\n21452. OCLC 16581341. (xix+1570 pages; 26 cm) (NB. This edition was published in 1988 after extensive\r\nrework of the withdrawn 1986 first edition by a different team of authors: \"The MS-DOS Encyclopedia\r\n(1988)\". PCjs Machines. Archived from the original on 2018-10-14.)\r\n68. ^ Jump up to: a\r\n \r\nb\r\n \r\nc\r\n Chappell, Geoff (January 1994). \"Chapter 2: The System Footprint\". In Schulman,\r\nAndrew; Pedersen, Amorette (eds.). DOS Internals. The Andrew Schulman Programming Series (1st\r\nprinting, 1st ed.). Addison Wesley Publishing Company. ISBN 978-0-201-60835-9. (xxvi+738+iv pages,\r\n3.5\"-floppy [2][3]) Errata: [4][5][6]\r\n69. ^ Rosch, Winn L. (1991-02-12). \"DR DOS 5.0 - The better operating system?\". PC Magazine. Vol. 10,\r\nno. 3. p. 241–246, 257, 264, 266. Retrieved 2019-07-26. “[…] SYS has been improved under DR DOS 5.0\r\nso you don't have to worry about leaving the first cluster free on a disk that you want to make bootable.\r\nThe DR DOS system files can be located anywhere on the disk, so any disk with enough free space can be\r\nset to boot your system. […]” {{cite magazine}} : CS1 maint: deprecated archival service (link) (NB. The\r\nsource attributes this to the SYS utility while in fact this is a feature of the advanced bootstrap loader in the\r\nboot sector. SYS just plants this sector onto the disk.)\r\n70. ^ Paul, Matthias R. (2001-01-17). \"FAT32 in DR-DOS\". opendos@delorie. Archived from the original on\r\n2017-10-06. Retrieved 2017-10-06. “[…] The DR-DOS boot sector […] searches for the IBMBIO.COM\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 23 of 25\n\n(DRBIOS.SYS) file and then loads the *whole* file into memory before it passes control to it. […]”\r\n71. ^ Paul, Matthias R. (2002-02-20). \"Can't copy\". opendos@delorie. Archived from the original on 2017-10-\r\n06. Retrieved 2017-10-06. “[…] The DR-DOS boot sector loads the whole IBMBIO.COM file into memory\r\nbefore it executes it. It does not care at all about the IBMDOS.COM file, which is loaded by\r\nIBMBIO.COM. […] The DR-DOS boot sector […] will find the […] kernel files as long as they are\r\nlogically stored in the root directory. Their physical location on the disk, and if they are fragmented or not,\r\nis don't care for the DR-DOS boot sector. Hence, you can just copy the kernel files to the disk (even with a\r\nsimply COPY), and as soon as the boot sector is a DR-DOS sector, it will find and load them. Of course, it\r\nis difficult to put all this into just 512 bytes, the size of a single sector, but this is a major convenience\r\nimprovement if you have to set up a DR-DOS system, and it is also the key for the DR-DOS multi-OS\r\nLOADER utility to work. The MS-DOS kernel files must reside on specific locations, but the DR-DOS files\r\ncan be anywhere, so you don't have to physically swap them around each time you boot the other OS. Also,\r\nit allows to upgrade a DR-DOS system simply by copying the kernel files over the old ones, no need for\r\nSYS, no difficult setup procedures as required for MS-DOS/PC DOS. You can even have multiple DR-DOS\r\nkernel files under different file names stored on the same drive, and LOADER will switch between them\r\naccording to the file names listed in the BOOT.LST file. […]”\r\n72. ^ Paul, Matthias R. (2017-08-14) [2017-08-07]. \"The continuing saga of Windows 3.1 in enhanced mode\r\non OmniBook 300\". MoHPC - the Museum of HP Calculators. Archived from the original on 2017-10-06.\r\nRetrieved 2017-10-06. “[…] the DR-DOS FDISK does not only partition a disk, but can also format the\r\nfreshly created volumes and initialize their boot sectors in one go, so there's no risk to accidentally mess up\r\nthe wrong volume and no need for FORMAT /S or SYS. Afterwards, you could just copy over the remaining\r\nDR-DOS files, including the system files. It is important to know that, in contrast to MS-DOS/PC DOS,\r\nDR-DOS has \"smart\" boot sectors which will actually \"mount\" the file-system to search for and load the\r\nsystem files in the root directory instead of expecting them to be placed at a certain location. Physically,\r\nthe system files can be located anywhere and also can be fragmented. […]”\r\n73. ^ \"Intel Platform Innovation Framework for EFI\". Intel. Archived from the original on 2011-08-21.\r\nRetrieved 2008-01-07.\r\n74. ^ \"OpenBIOS - coreboot\". coreboot.org. Archived from the original on 2013-03-18. Retrieved 2013-03-20.\r\n75. ^ \"UEFI - OSDev Wiki\". wiki.osdev.org. Archived from the original on 2020-11-12. Retrieved 2020-09-26.\r\n76. ^ \"Overview – The four bootloader stages\". ti.com. Texas Instruments. 2013-12-05. Archived from the\r\noriginal on 2014-12-23. Retrieved 2015-01-25.\r\n77. ^ Nnamdi Ajah. \"BITE-SIZED BOOTING FOR ARM EMBEDDED SYSTEMS\". Gist. Retrieved 2025-09-\r\n03.\r\n78. ^ \"The boot process rxos 1.0rc1 documentation\". Retrieved 2015-10-25.\r\n79. ^ \"mjg59 | Boot Guard and PSB have user-hostile defaults\". mjg59.dreamwidth.org. Retrieved 2022-11-30.\r\n80. ^ \"Microsoft blocks UEFI bootloaders enabling Windows Secure Boot bypass\". BleepingComputer.\r\nRetrieved 2022-12-11.\r\n81. ^ Jump up to: a\r\n \r\nb\r\n J.J.M. Trienekens; R.J. Kusters (19–21 September 2003). Workshop: defect detection in\r\ndistributed software development. Eleventh Annual International Workshop on Software Technology and\r\nEngineering Practice. doi:10.1109/STEP.2003.40.\r\n82. ^ Jump up to: a\r\n \r\nb\r\n Tim Warren (2024-07-23). \"Inside the 78 minutes that took down millions of Windows\r\nmachines\". The Verge.\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 24 of 25\n\n83. ^ Joe Tidy (2024-07-20). \"CrowdStrike IT outage affected 8.5 million Windows devices, Microsoft says\".\r\nBBC News.\r\n84. ^ Jump up to: a\r\n \r\nb\r\n Piet Kerkhofs (2024-07-19). \"CrowdStrike Falcon and Microsoft blue screen issue\r\nupdates\". Eye Security. Retrieved 2024-07-19.\r\n85. ^ Ruley, John D.; David Methvin; Tom Henderson; Martin Heller (1997). Networking Windows NT 4.0:\r\nWorkstation and Server. Wiley. p. 257. ISBN 978-0-471-17502-5 – via Google Books.\r\n86. ^ Shultz, Gregory (February 2001). \"Disabling automatic reboot prevents possible reboot loop\". Windows\r\nProfessional. 6 (2). Element K Journals: 9. ProQuest 191083238.\r\n87. ^ \"New Windows Server updates cause DC boot loops, break Hyper-V\". BleepingComputer. Retrieved\r\n2022-05-17.\r\n88. ^ Paul Wagenseil (2021-01-21). \"Windows 10 update sending PCs into endless boot cycle: What to do\".\r\nTom's Guide. Retrieved 2022-05-20.\r\n89. ^ Hollister, Sean (2021-10-19). \"Google has tried everything but building the best phone\". The Verge.\r\nRetrieved 2022-05-17.\r\n90. ^ \"'It was unintentional,' says creator of 'cursed' Android wallpaper\". The Week. Retrieved 2022-05-19.\r\n91. ^ Hager, Ryne (2020-06-01). \"Google thinks it has solved the mystery of the cursed bootlooping\r\nwallpaper\". Android Police. Retrieved 2022-05-19.\r\n92. ^ Peckham, James (2022-03-29). \"Google Nest Hub gets a new UI that's so fresh it could bootloop your\r\nsmart display\". Android Police. Retrieved 2022-05-19.\r\n93. ^ \"Statement on Falcon Content Update for Windows Hosts\". crowdstrike.com. Retrieved 2024-07-19.\r\n94. ^ Baran, Guru (2024-07-19). \"CrowdStrike Update Pushing Windows Machines Into a BSOD Loop\".\r\nCyber Security News. Retrieved 2024-07-19.\r\n95. ^ \"Botched security update breaks Windows worldwide, causing BSOD and crashes\". Neowin. 2024-07-19.\r\nRetrieved 2024-07-19.\r\nSource: https://en.wikipedia.org/wiki/Booting\r\nhttps://en.wikipedia.org/wiki/Booting\r\nPage 25 of 25\n\n2. ^ \"bootstrap\". Retrieved Computer Dictionary 2019-08-05. of Information Technology. Archived from the original on 2019-08-05.\n3. ^ \"Bootstrap\". The Free Dictionary. Archived from the original on 2006-08-27. Retrieved 2008-08-27.\n4. ^ \"Pull oneself up by bootstraps\". Idioms by The Free Dictionary. Archived from the original on 2018-10-\n05. Retrieved 2019-10-07.     \n5. ^ \"Bootstrap Definition\". Tech Terms. Archived from the original on 2020-05-10. Retrieved 2019-10-02.\n6. ^ \"Pull yourself up by your bootstraps\". The Phrase Finder. Archived from the original on 2012-04-17.\nRetrieved 2010-07-15.     \n7. ^ \"boot\". Oxford English Dictionary. Vol. II (2nd ed.). Oxford: Clarendon Press. p. 405. “1975...The boot\noverlay code will overlay the first two instructions of the loader.”   \n8. ^ Campbell-Kelly, Martin (1980). \"Programming the EDSAC\". IEEE Annals of the History of Computing.\n2 (1): 7-36. doi:10.1109/mahc.1980.10009.     \n9. ^ Wilkes, Maurice V.; Wheeler, David J.; Gill, Stanley (1951). The Preparation of Programs for an\nElectronic Digital Computer. Addison-Wesley. Archived from the original on 2023-02-20. Retrieved 2020-\n09-25.      \n10. ^ Buchholz, Werner (1953). \"The System Design of the IBM Type 701 Computer\" (PDF). Proceedings of\nthe I.R.E. 41 (10): 1273. Archived (PDF) from the original on 2022-10-09.   \n11. ^ Jump up to: a b \"IBM 7619 Exchange\". Reference Manual 7030 Data Processing System (PDF). IBM.\nAugust 1961. pp. 125-127. A22-6530-2. Archived (PDF) from the original on 2022-10-09. \n12. ^ Principles of Operation Type 701 And Associated Equipment (PDF). IBM. 1953. p. 26. Archived (PDF)\nfrom the original on 2022-10-09. Retrieved 2012-11-09.    \n13. ^ Jeremy M. Norman (2005). From Gutenberg to the Internet. Norman. p. 436. ISBN 0-930405-87-0. \n14. ^ 704 Electronic Data-Processing Machine Manual of Operation (PDF). IBM. pp. 14-15. Archived (PDF)\nfrom the original on 2022-10-09.     \n15. ^ Operator's Guide for IBM 7090 Data Processing System (PDF). IBM. p. 34. Archived (PDF) from the\noriginal on 2022-10-09.     \n16. ^ IBM 7094 Principles of Operation (PDF). IBM. p. 146. Archived (PDF) from the original on 2022-10-\n09.      \n17. ^ Oxford English Dictionary. Oxford University. 1939.   \n18. ^ 650 magnetic drum data-processing machine manual of operation (PDF). IBM. 1955. pp. 49, 53-54.\nArchived (PDF) from the original on 2022-10-09.    \n19. ^ Operator's Guide for IBM 7040-7044 Systems (PDF). IBM. p. 10. A22-6741-1. Archived (PDF) from the\noriginal on 2022-10-09.     \n20. ^ CONTROL DATA 6600 Computer System Reference Manual (PDF) (Second ed.). Control Data\nCorporation. August 1963. p. 53. Archived (PDF) from the original on 2022-10-09.  \n21. ^ Ge-645 System Manual (PDF). General Electric. January 1968. Archived (PDF) from the original on\n2022-10-09. Retrieved 2019-10-30.     \n22. ^ PDP-10 System Reference Manual, Part 1 (PDF). Digital Equipment Corporation. 1969. pp. 2-72.\nArchived (PDF) from the original on 2022-10-09. Retrieved 2012-11-09.   \n23. ^ Jump up to: a b Burroughs B 1700 Systems Reference Manual (PDF). Burroughs Corporation. November\n1973. p. 1-14. Archived (PDF) from the original on 2022-10-09.   \n  Page 20 of 25   \n\ninstruction FFFF0H.” pointer contains FFF0, the processor will execute its first instruction at physical address\n65. ^ \"80386 Programmer's Reference Manual\" (PDF). Intel. 1986. Section 10.2.3 First Instructions, p. 10-3.\nArchived (PDF) from the original on 2022-10-09. Retrieved 2013-11-03. “After RESET, address lines A31-\n20 are automatically asserted for instruction fetches. This fact, together with the initial values of CS:IP,\ncauses instruction execution to begin at physical address FFFFFFF0H.”   \n66. ^ \"Intel 64 and IA-32 Architectures Software Developer's Manual\" (PDF). Intel Corporation. May 2012.\nSection 9.1.4 First Instruction Executed, p. 2611. Archived (PDF) from the original on 2022-10-09. \nRetrieved 2012-08-23. “The first instruction that is fetched and executed following a hardware reset is\nlocated at physical address FFFFFFF0h. This address is 16 bytes below the processor's uppermost \nphysical address. The EPROM containing the software-initialization code must be located at this address.”\n67. ^ Zbikowski, Mark; Allen, Paul; Ballmer, Steve; Borman, Reuben; Borman, Rob; Butler, John; Carroll,\nChuck; Chamberlain, Mark; Chell, David; Colee, Mike; Courtney, Mike; Dryfoos, Mike; Duncan, Rachel;\nEckhardt, Kurt; Evans, Eric; Farmer, Rick; Gates, Bill; Geary, Michael; Griffin, Bob; Hogarth, Doug;\nJohnson, James W.; Kermaani, Kaamel; King, Adrian; Koch, Reed; Landowski, James; Larson, Chris;\nLennon, Thomas; Lipkie, Dan; McDonald, Marc; McKinney, Bruce; Martin, Pascal; Mathers, Estelle;\nMatthews, Bob; Melin, David; Mergentime, Charles; Nevin, Randy; Newell, Dan; Newell, Tani; Norris,\nDavid; O'Leary, Mike; O'Rear, Bob; Olsson, Mike; Osterman, Larry; Ostling, Ridge; Pai, Sunil; Paterson,\nTim; Perez, Gary; Peters, Chris; Petzold, Charles; Pollock, John; Reynolds, Aaron; Rubin, Darryl; Ryan,\nRalph; Schulmeisters, Karl; Shah, Rajen; Shaw, Barry; Short, Anthony; Slivka, Ben; Smirl, Jon; Stillmaker,\nBetty; Stoddard, John; Tillman, Dennis; Whitten, Greg; Yount, Natalie; Zeck, Steve (1988). \"Technical\nadvisors\". The MS-DOS Encyclopedia: versions 1.0 through 3.2. By Duncan, Ray; Bostwick, Steve;\nBurgoyne, Keith; Byers, Robert A.; Hogan, Thom; Kyle, Jim; Letwin, Gordon; Petzold, Charles; \nRabinowitz, Chip; Tomlin, Jim; Wilton, Richard; Wolverton, Van; Wong, William; Woodcock, JoAnne\n(Completely reworked ed.). Redmond, Washington, USA: Microsoft Press. ISBN 1-55615-049-0. LCCN 87-\n21452. OCLC 16581341. (xix+1570 pages; 26 cm) (NB. This edition was published in 1988 after extensive\nrework of the withdrawn 1986 first edition by a different team of authors: \"The MS-DOS Encyclopedia \n(1988)\". PCjs Machines. Archived from the original on 2018-10-14.)   \n68. ^ Jump up to: a b c Chappell, Geoff (January 1994). \"Chapter 2: The System Footprint\". In Schulman, \nAndrew; Pedersen, Amorette (eds.). DOS Internals. The Andrew Schulman Programming Series (1st\nprinting, 1st ed.). Addison Wesley Publishing Company. ISBN 978-0-201-60835-9. (xxvi+738+iv pages,\n3.5\"-floppy [2][3]) Errata: [4][5][6]     \n69. ^ Rosch, Winn L. (1991-02-12). \"DR DOS 5.0-The better operating system?\". PC Magazine. Vol. 10,\nno. 3. p. 241-246, 257, 264, 266. Retrieved 2019-07-26. “[…] SYS has been improved under DR DOS 5.0\nso you don't have to worry about leaving the first cluster free on a disk that you want to make bootable.\nThe DR DOS system files can be located anywhere on the disk, so any disk with enough free space can be\nset to boot your system. […]” {{cite magazine}} : CS1 maint: deprecated archival service (link) (NB. The\nsource attributes this to the SYS utility while in fact this is a feature of the advanced bootstrap loader in the\nboot sector. SYS just plants this sector onto the disk.)   \n70. ^ Paul, Matthias R. (2001-01-17). \"FAT32 in DR-DOS\". opendos@delorie.  Archived from the original on\n2017-10-06. Retrieved 2017-10-06. “[…] The DR-DOS boot sector […] searches for the IBMBIO.COM \n   Page 23 of 25",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://en.wikipedia.org/wiki/Booting"
	],
	"report_names": [
		"Booting"
	],
	"threat_actors": [
		{
			"id": "9de1979b-40fc-44dc-855d-193edda4f3b8",
			"created_at": "2025-08-07T02:03:24.92723Z",
			"updated_at": "2026-04-10T02:00:03.755516Z",
			"deleted_at": null,
			"main_name": "GOLD LOCUST",
			"aliases": [
				"Anunak",
				"Carbanak",
				"Carbon Spider ",
				"FIN7 ",
				"Silicon "
			],
			"source_name": "Secureworks:GOLD LOCUST",
			"tools": [
				"Carbanak"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "cfdd35af-bd12-4c03-8737-08fca638346d",
			"created_at": "2022-10-25T16:07:24.165595Z",
			"updated_at": "2026-04-10T02:00:04.887031Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"Cosmic Wolf",
				"Marbled Dust",
				"Silicon",
				"Teal Kurma",
				"UNC1326"
			],
			"source_name": "ETDA:Sea Turtle",
			"tools": [
				"Drupalgeddon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "33ae2a40-02cd-4dba-8461-d0a50e75578b",
			"created_at": "2023-01-06T13:46:38.947314Z",
			"updated_at": "2026-04-10T02:00:03.155091Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"UNC1326",
				"COSMIC WOLF",
				"Marbled Dust",
				"SILICON",
				"Teal Kurma"
			],
			"source_name": "MISPGALAXY:Sea Turtle",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "62b1b01f-168d-42db-afa1-29d794abc25f",
			"created_at": "2025-04-23T02:00:55.22426Z",
			"updated_at": "2026-04-10T02:00:05.358041Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"Sea Turtle",
				"Teal Kurma",
				"Marbled Dust",
				"Cosmic Wolf",
				"SILICON"
			],
			"source_name": "MITRE:Sea Turtle",
			"tools": [
				"SnappyTCP"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434301,
	"ts_updated_at": 1775791946,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2ea47ee3caf45c7eea548e479295854aa201d78b.pdf",
		"text": "https://archive.orkl.eu/2ea47ee3caf45c7eea548e479295854aa201d78b.txt",
		"img": "https://archive.orkl.eu/2ea47ee3caf45c7eea548e479295854aa201d78b.jpg"
	}
}