A tiny bootstrap loader program is situated in –

Concept — When power is applied, the CPU immediately begins fetching instructions from a fixed reset address, at a moment when no software has yet run. The very first program it executes must therefore already be present in memory that is non-volatile (it keeps its contents while the machine is switched off) and that the processor can address directly, with no driver, no controller and no file system in place. Read-only memory is the class of memory built to satisfy both conditions.

Application — The bootstrap loader is exactly that first program: a very small routine written permanently into the firmware chip on the motherboard, so the reset vector points straight at it. Its whole job is to bring up enough of the machine to fetch the real operating system:

1. Power-on: the CPU starts executing at the reset vector, which lies inside the read-only memory address range.

2. The loader initialises the minimum hardware needed to talk to a boot device (chipset, memory controller, storage controller).

3. It copies the first sector — the operating-system loader — from that device into RAM.

4. It jumps to the code it just copied, and the operating system takes over the machine.

Cross-check — Step 2 is what makes a disk readable in the first place, so the loader cannot itself be fetched from a disk; that would require the loader to already be running. And BIOS (or UEFI) is the name of the firmware program set that contains this routine — it answers "which software", not "written into which memory". That firmware, bootstrap loader included, is physically held in the read-only memory chip.

Result: a tiny bootstrap loader program is situated in ROM.