Where is the bootloader stored - in ROM, RAM, or elsewhere?
Solution 1:
ROM is a separate chip from the RAM. It does not require power to retain its contents, and originally could not be modified by any means, but came hard wired from the factory. Later PROM, or Programmable Read Only Memory replaced true ROM. These chips came blank from the factory, and could be written to once using a special procedure that essentially burned out bits of the chip causing their state to change. This was then replaced with EPROM, or Eraseable Programmable Memory. These chips had a little window on them and if you shined ultraviolet light into them, could be erased, allowing them to be programmed again. These were then replaced with EEPROM, or Electrically Erasable Programmable Memory. These chips have a special software procedure to erase them so they can be reprogrammed. ROM generally is still used to refer to all of these types generically.
The motherboard has some type of ROM chip that holds the firmware, which in PC parlance is usually called the BIOS, or Basic Input Output System, though it is being replaced these days with EFI firmware. This is the software that the CPU first starts executing at power on. All firmware performs initialization of the hardware, typically provides some diagnostic output, and provides a way for the user to configure the hardware, then locates and loads the boot loader, which in turn locates and loads the OS.
With PC BIOS, it simply loads and executes the first sector off the disk it decides to boot from, which typically is the first hard disk detected. By convention the first sector of a hard disk, called the Master Boot Record, contains a DOS partition table listing the locations of the partitions on the disk, and and leaves some space for the boot loader. Ubuntu uses the GRUB boot loader, which places enough code in the MBR to load and execute /boot/grub/core.img. Normally a copy of this file is placed in the sectors following the MBR, but before the first partition, and that is actually what the MBR loads, since finding the location of /boot/grub/core.img is too difficult to do properly in the very limited space available in the MBR.
The grub core image contains the base grub code, plus any modules needed to access /boot/grub so that it can load additional modules there, and the grub config file that describes what operating systems can be booted, and where they can be found.
The EFI firmware used on Intel Macs and becoming available as a replacement to BIOS on most recent PC motherboards requires a dedicated partition that holds boot loader files, and the firmware is smart enough to find those files and load one instead of just loading and executing whatever is in the first sector of the disk.
Solution 2:
ROM is not in Main memory:
ROM isn't a part of Main memory. It is a separate chip, which is most of the time built-in in a bigger IC. More example, Your PC can consists of several ROM. Those are built in your mother board.
Generally :
- ROM are very small in memory size. These memory is non-volatile, in the sense, the program stored in ROM don't get erased with power shut down.
- ROM are used to store permanent programs, which are very essential your hardware to perform correctly.
- A typical example of ROM is BIOS chip. Where the program of very low level booting and initializing hardware are stored
You mentioned that, You read an article where author said, "ROM is a part of Main memory". This is confusing, because typically Main Memory refers to the memory of kinds which are volatile, such as RAM. But yes, If you use Main Memory term for the entire memory space of a PC, then ROM is a part of that memory space. You should note that, generally Main Memory exclude memory of kinds as ROM.
Where is Bootloader stored:
Modern system use two stage boot loading. In the first step a tiny program is loaded from a sector (called boot-sector more often) of Hard disk. This tiny program in turn load a program from some where in the disk, which is called bootloader. And finally bootloader loads the OS.
In term of Ubuntu system, the process is as following:
After you turn on your PC, BIOS (which is stored in ROM) automatically runs and initializes various parts of PC hardware. Then it checks for a specific sector in the defined first Boot device (typically Hard disk). This sector is boot-sector, which is 512 bytes in size.
The program in the boot-sector is loaded in memory (1st stage). This tiny program has information which programs should it load into memory next and where that program is located in Disk or Boot device. It loads that program. In Ubuntu, it is
/boot/grub/core.img.In the 2nd stage, The OS-Loader, GRUB, loads Ubuntu by loading the kernel and initial ram disk into the memory and hands-over control to the kernel. Then the kernel runs and loads all of the necessary programs such as display manager, Gui's etc.
So, we can clearly say, that the bootloader is neither stored in ROM, nor in RAM, It is actually stored on Hard disk (or other Boot device, such as bootable CDROM, USB drives etc) , precisely speaking the first sector of the hard disk, which is of size 512 bytes and often referred to as the boot-sector. And this bootloader loads the OS-loader (in Ubuntu, it is grub) which also resides in the hard disk (i.e /boot/grub/ folder), and it's task is loading the OS (say, Ubuntu).
As a test, Remove the hard disk (and all other boot device) and try to boot. You can go up to the BIOS step, but after that step, you can't boot anything. Most probably the BIOS will say, "No Boot device Found" or "No Operating System found" or something similar.
Hope this answer will help.
For more information, you may want to visit these links:
- http://en.wikipedia.org/wiki/Read-only_memory
- http://en.wikipedia.org/wiki/Random-access_memory
Solution 3:
An x86-compatible processor always starts in so-called "real" mode, which is a 16-bit mode with 1 megabyte of addressable memory available. From that address space, 640K are available for programs, and addresses above that are mapped to different devices.
For example, addresses starting from 0xA000:0x0000 are mapped to the video RAM, so, writing data there would actually write data to the video adapter's memory displaying pixels on the screen.
Similarly, BIOS ROM starts from 0xF000:0000 so the CPU, when powered on, simply starts executing instructions one by one starting from that pre-defined address. The BIOS ROM contains the initial program which starts by performing a "power-on self test", or POST. From Wikipedia:
The BIOS software is built into the PC, and is the first code run by a PC when powered on ('boot firmware'). When the PC starts up, the first job for the BIOS is the power-on self-test, which initializes and identifies system devices such as the CPU, RAM, video display card, keyboard and mouse, hard disk drive, optical disc drive and other hardware. The BIOS then locates boot loader software held on a peripheral device (designated as a 'boot device'), such as a hard disk or a CD/DVD, and loads and executes that software, giving it control of the PC.2 This process is known as booting, or booting up, which is short for bootstrapping.
The BIOS firmware is responsible for reading the first sector from the disk into memory and passing the control to a small program which is, again, located at a specific address there. The MBR bootloader may then start loading the OS directly (as was the case with MS-DOS) or to load "second stage", which is not limited to the confines of a single disk sector.
Bootloaders which use the multi-stage approach can be quite complex with text or graphical interface which allows user to select from which disk or partition to load an operating system.
So if, as Uri suggests, you're interested whether the Windows bootloader and GRUB can co exist together, the answer is: the actual MBR can only contain a single first-stage bootloader (come on, the whole sector is just 512 bytes), but the second stage of a bootloader may be able to "chain-load" operating systems from different partitions. Windows bootloader is only able to recognize and load Windows, while GRUB is able to load Linux or pass control to another bootloader stored in a volume boot record of one of the partitions, which allows to boot Windows or other OS. The latter process is called chain-loading.
When you install Ubuntu on a computer which has Windows on it, GRUB will be installed into MBR and you'll be able to boot both Ubuntu and Windows.
However, if Windows is installed after Ubuntu, GRUB will be replaced with Windows bootloader and you'll need to re-install GRUB to be able to boot Ubuntu again.
Solution 4:
The conflict between what you say about the bootloader being in ROM and it being in the MBR is perhaps due to bootloader being used for any code that works out how to do the minimum to load in code to make the computer do something useful, including each state in a multi-stage boot.
So, the starting state is to have a computer, which is a programmable device, but doesn't know how to load software to run because it doesn't have any software loaded. (And hence boot from pull itself up from its bootstraps).
Historically, there were a few different solutions to this problem, but these days we start with some code in ROM (mostly likely strictly EEPROM), which is enough to get it to look at different devices and try them in turn until it finds one that's bootable.
(This is why many systems will boot off a CD or DVD if you put an OS installer disk in and from the hard-drive otherwise, the BIOS [the code on the ROM, including the code we're talking about and some other low-level stuff that get things started] is set to look at the CD/DVD drive first, then at a hard-drive if it doesn't find anything, tweakers often set it to ignore the CD/DVD drive unless manually requested so it doesn't waste time spinning up a non-bootable disk that was left in the drive).
This code in the ROM is sometimes called a bootloader.
When it knows what drive to look at, it will then look at the MBR, which contains information about primary partions - how could you later look at / or /boot or C:/ (on a Windows system) if you didn't even know what part of the disk was which partition, never mind how each partition was mounted? - and some code with further instructions to execute. (Incidentally, this explains why some OSes - like Windows - can only be installed on a primary partition, the details of those partitions are in the MBR and that's the only partition information their bootloader has read, and it doesn't load the EBR to learn about the logical partitions, as far as it's concerned those partitions don't even exist yet).
That executable code, is also called a bootloader. When we care to distinguish between this and what comes next, it's called a primary boot loader (because unless we're making our own BIOS we ignore the ROM bit as out of our control).
That code will be very small as there's only around 400 bytes for it to fit in, so to do anything real, it will load some more code, that can be larger as it doesn't have to deal with this constraint.
This code, is also known as a bootloader. When we care to distinguish between this and what came before, it's called a secondary boot loader.
That code could perhaps be the final stage in the process. It would if you've only one OS, or if all the OSs on your system use compatible boot-loaders (e.g. two Linux installs that both use GRUB, so whichever GRUB was updated last can offer to boot into either of them) then it presents menus (if desired) loads in a kernel, and passes control over the the operating system.
In the case where you've an OS that isn't compatible with that bootloader, it may chainload. E.g. if you have Windows and Linux on the same machine, the GRUB option for loading Windows will in fact load yet another bootloader that only knows about the Windows installation(s), and pass over to it. While this was a tertiary stage in the process, it's still called a secondary boot loader, because it neither knows nor cares that there was another secondary boot loader running before it. This would also be the case with a Linux install that used a different type of secondary bootloader.
Mostly when we talk about the bootloader in terms of Linux, we generally don't mean the ROM code (it's not part of Linux, or changed by installing Linux). When we do update-grub we're changing the secondary bootloader, which is typically in /boot of a particular installation. When we do install-grub we're changing it and also the primary bootloader in the MBR so that it has enough code to know where /boot is (perhaps starting a software RAID as it goes) and will load and execute that when it, itself is executed.
So, in summary you were incorrect when you said ROM was part of main memory* because it's separate. (Indeed, RAM is taken as antonymous to ROM). You were correct both in saying there was a bootloader there and in the MBR, because they're two steps of the process and both are sometimes called by that name. And the answer to "Do different OS store their bootloader in different places?" is "mostly", because if you incompatible secondary bootloaders will either hide other bootloaders (if you install Windows after installing Linux) or chainload into the other one if requested (if you fix that situation, or install Linux after Windows), but an OS can share a secondary bootloader if they are compatible (if you install Linux after another Linux that uses the same type of secondary boot loader, and it can see the other Linux [sometimes software RAID confuses things and makes chainloading necessary).
*In days where one would programatically make use of both ROM and RAM this was different. On a ZX Spectrum for example, the ROM would be 16kiB and include a BASIC interpreter, so as well as giving you the starting point for loading something into its 48kiB or 128KiB (paged) or RAM, (in which case, it's essentially booting into that BASIC interpreter and then using that to boot into what was on the tape), there was a whole bunch of functions from the BASIC interpreter that programs in RAM could use (why write a trig function when the computer already has one at a known position? especially when you've only 48kiB for all your own code to run in). This ROM was also visible in the same way as the RAM, just at different addresses. In such a case the ROM was as much a part of main memory as the RAM, but not writable. These days you pretty much ignore the ROM once you're past the first stage of booting.