Where is the bootloader stored - in ROM, RAM, or elsewhere?
up vote
30
down vote
favorite
According to the wikipedia entry, a bootloader is a small program stored in ROM(a part of the main memory(RAM), isn't it??) which can only be read and not erased. I am a little puzzled here. Does this mean that every RAM we buy has a bootloader installed by default?
And also, I read from a book which says that there is typically an area called the MBR (Master Boot Record) on the hard drive which includes a bootloader...
So where exactly is this bootloader located? Do different Operating Systems store their bootloader in different places?
boot bootloader
add a comment |
up vote
30
down vote
favorite
According to the wikipedia entry, a bootloader is a small program stored in ROM(a part of the main memory(RAM), isn't it??) which can only be read and not erased. I am a little puzzled here. Does this mean that every RAM we buy has a bootloader installed by default?
And also, I read from a book which says that there is typically an area called the MBR (Master Boot Record) on the hard drive which includes a bootloader...
So where exactly is this bootloader located? Do different Operating Systems store their bootloader in different places?
boot bootloader
add a comment |
up vote
30
down vote
favorite
up vote
30
down vote
favorite
According to the wikipedia entry, a bootloader is a small program stored in ROM(a part of the main memory(RAM), isn't it??) which can only be read and not erased. I am a little puzzled here. Does this mean that every RAM we buy has a bootloader installed by default?
And also, I read from a book which says that there is typically an area called the MBR (Master Boot Record) on the hard drive which includes a bootloader...
So where exactly is this bootloader located? Do different Operating Systems store their bootloader in different places?
boot bootloader
According to the wikipedia entry, a bootloader is a small program stored in ROM(a part of the main memory(RAM), isn't it??) which can only be read and not erased. I am a little puzzled here. Does this mean that every RAM we buy has a bootloader installed by default?
And also, I read from a book which says that there is typically an area called the MBR (Master Boot Record) on the hard drive which includes a bootloader...
So where exactly is this bootloader located? Do different Operating Systems store their bootloader in different places?
boot bootloader
boot bootloader
edited Aug 10 '12 at 5:48
Eliah Kagan
81.1k20227364
81.1k20227364
asked Aug 8 '12 at 3:27
xczzhh
82541317
82541317
add a comment |
add a comment |
7 Answers
7
active
oldest
votes
up vote
41
down vote
accepted
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.
Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An OverviewA small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)
According to him. The main memory is made up of two parts, RAM and ROM. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory... @Sergey
– xczzhh
Aug 8 '12 at 5:17
@xczzhh - yes BIOS is stored in ROM , which detects the Bootloader present in Partitions . Upon installing any OS , it creates a entry kind of flag in BIOS to detect the respective BOOTLOADER.
– atenz
Aug 8 '12 at 6:19
1
@xczzhh, no, the boot loader is on the hard drive or some other disk. It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes.
– psusi
Aug 8 '12 at 14:37
EFI uses EFI applications instead.It loads the EFI application in the NVRAM
– Suici Doga
May 7 '16 at 2:07
@SuiciDoga, no, EFI applications ( which are basically limited to a few firmware upgrade utilities and boot loaders ) are stored in the EFI system partition of the hard disk. NVRAM is where EFI stores some configuration variables, such as boot order.
– psusi
May 7 '16 at 13:24
add a comment |
up vote
22
down vote
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
2
ROM hasn't been faster than RAM for about a decade now. In fact, one of the first things a modern BIOS does is copy itself into RAM because the RAM is so much faster.
– David Schwartz
Aug 8 '12 at 12:38
1
@DavidSchwartz, It's been more than a decade now. Every PC BIOS I used in the mid '90s had an option to shadow the bios in RAM for speed.
– psusi
Aug 8 '12 at 14:43
@Anwar, the link to Main Memory is dead.
– The Matt
Dec 1 at 16:48
add a comment |
up vote
15
down vote
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.
I suppose he wants to know whether the Windows bootloader and GRUB can co exist together, or not. UEFI ,GPT disks don't use MBR how does this effect them?.
– Uri Herrera
Aug 8 '12 at 3:51
The BIOS ROM is located in the F000: segment, which is just below 1 MB. The 640k is from the segments below A000:, which are available for the real mode OS and programs to use.
– psusi
Aug 8 '12 at 4:00
@psusi: you're right, I re-phrased that part
– Sergey
Aug 8 '12 at 4:42
Thank you for the answer. Do you mean that there are multiple bootloaders(one within the BIOS, and another in MBR?) involved to boot an operating system? It's new to me... :)
– xczzhh
Aug 8 '12 at 5:22
@xczzhh Well, ok, the code in BIOS is not called "bootloader", the one stored on disk does. I updated my answer to make this clear.
– Sergey
Aug 8 '12 at 6:10
|
show 2 more comments
up vote
4
down vote
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.
add a comment |
up vote
0
down vote
Make a minimal working example and run it on an emulator to understand those concepts:
printf '364%509s125252' > main.img
qemu-system-x86_64 -hda main.img
This is a super simple "bootloader" that does a single hlt
instruction. More info at: https://stackoverflow.com/a/32483545/895245
You can then run it on real hardware with:
sudo dd if=main.img of=/dev/sdX
and plugging the USB on your computer, and booting from it.
When you do this, it becomes clear that the bootloader is something that lives on a permanent storage disk like USBs or hard disks.
What lives on ROM is the code that starts up the bootloader for us, called firmware (or less precisely BIOS).
add a comment |
up vote
0
down vote
In days of old, the boot program resided on punched paper tape similar to those used by telegraph machines or punched card media ('don't see both of them around anymore). the process used to be called IPL, short for Initial Program Load. Sometimes if a paper tape or card reader was not available one would need to enter the binary IPL code directly into the processor via a console on the front panel. whew!
Nowadays the IPL code reside in pROMs which when executed in turn load and execute any secondary boot loaders tailored to load (bootup) the desired operating system. the secondary loader could be on any medium on any part of the setup known to or addressable by the IPL code.
add a comment |
up vote
-1
down vote
The boot loader usually is in the first sector of the hard drive, usually called the Master Boot Record.
Cheers
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f173248%2fwhere-is-the-bootloader-stored-in-rom-ram-or-elsewhere%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
41
down vote
accepted
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.
Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An OverviewA small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)
According to him. The main memory is made up of two parts, RAM and ROM. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory... @Sergey
– xczzhh
Aug 8 '12 at 5:17
@xczzhh - yes BIOS is stored in ROM , which detects the Bootloader present in Partitions . Upon installing any OS , it creates a entry kind of flag in BIOS to detect the respective BOOTLOADER.
– atenz
Aug 8 '12 at 6:19
1
@xczzhh, no, the boot loader is on the hard drive or some other disk. It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes.
– psusi
Aug 8 '12 at 14:37
EFI uses EFI applications instead.It loads the EFI application in the NVRAM
– Suici Doga
May 7 '16 at 2:07
@SuiciDoga, no, EFI applications ( which are basically limited to a few firmware upgrade utilities and boot loaders ) are stored in the EFI system partition of the hard disk. NVRAM is where EFI stores some configuration variables, such as boot order.
– psusi
May 7 '16 at 13:24
add a comment |
up vote
41
down vote
accepted
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.
Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An OverviewA small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)
According to him. The main memory is made up of two parts, RAM and ROM. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory... @Sergey
– xczzhh
Aug 8 '12 at 5:17
@xczzhh - yes BIOS is stored in ROM , which detects the Bootloader present in Partitions . Upon installing any OS , it creates a entry kind of flag in BIOS to detect the respective BOOTLOADER.
– atenz
Aug 8 '12 at 6:19
1
@xczzhh, no, the boot loader is on the hard drive or some other disk. It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes.
– psusi
Aug 8 '12 at 14:37
EFI uses EFI applications instead.It loads the EFI application in the NVRAM
– Suici Doga
May 7 '16 at 2:07
@SuiciDoga, no, EFI applications ( which are basically limited to a few firmware upgrade utilities and boot loaders ) are stored in the EFI system partition of the hard disk. NVRAM is where EFI stores some configuration variables, such as boot order.
– psusi
May 7 '16 at 13:24
add a comment |
up vote
41
down vote
accepted
up vote
41
down vote
accepted
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.
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.
edited Jun 18 '17 at 14:54
Faheem Mitha
5,99411013
5,99411013
answered Aug 8 '12 at 4:21
psusi
30.9k14986
30.9k14986
Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An OverviewA small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)
According to him. The main memory is made up of two parts, RAM and ROM. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory... @Sergey
– xczzhh
Aug 8 '12 at 5:17
@xczzhh - yes BIOS is stored in ROM , which detects the Bootloader present in Partitions . Upon installing any OS , it creates a entry kind of flag in BIOS to detect the respective BOOTLOADER.
– atenz
Aug 8 '12 at 6:19
1
@xczzhh, no, the boot loader is on the hard drive or some other disk. It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes.
– psusi
Aug 8 '12 at 14:37
EFI uses EFI applications instead.It loads the EFI application in the NVRAM
– Suici Doga
May 7 '16 at 2:07
@SuiciDoga, no, EFI applications ( which are basically limited to a few firmware upgrade utilities and boot loaders ) are stored in the EFI system partition of the hard disk. NVRAM is where EFI stores some configuration variables, such as boot order.
– psusi
May 7 '16 at 13:24
add a comment |
Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An OverviewA small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)
According to him. The main memory is made up of two parts, RAM and ROM. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory... @Sergey
– xczzhh
Aug 8 '12 at 5:17
@xczzhh - yes BIOS is stored in ROM , which detects the Bootloader present in Partitions . Upon installing any OS , it creates a entry kind of flag in BIOS to detect the respective BOOTLOADER.
– atenz
Aug 8 '12 at 6:19
1
@xczzhh, no, the boot loader is on the hard drive or some other disk. It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes.
– psusi
Aug 8 '12 at 14:37
EFI uses EFI applications instead.It loads the EFI application in the NVRAM
– Suici Doga
May 7 '16 at 2:07
@SuiciDoga, no, EFI applications ( which are basically limited to a few firmware upgrade utilities and boot loaders ) are stored in the EFI system partition of the hard disk. NVRAM is where EFI stores some configuration variables, such as boot order.
– psusi
May 7 '16 at 13:24
Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An Overview
A small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)
According to him. The main memory is made up of two parts, RAM and ROM. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory... @Sergey– xczzhh
Aug 8 '12 at 5:17
Here is a paragraph excerpted from Glenn Brookshear's Computer Science, An Overview
A small portion of a computer's main memory where the CPU expects to find its initial program is constructed from special nonvolatile memory cells. Such memory is known as read-only memory(ROM)
According to him. The main memory is made up of two parts, RAM and ROM. I just want to know whether the so-called bootloader is installed on the ROM part of the main memory... @Sergey– xczzhh
Aug 8 '12 at 5:17
@xczzhh - yes BIOS is stored in ROM , which detects the Bootloader present in Partitions . Upon installing any OS , it creates a entry kind of flag in BIOS to detect the respective BOOTLOADER.
– atenz
Aug 8 '12 at 6:19
@xczzhh - yes BIOS is stored in ROM , which detects the Bootloader present in Partitions . Upon installing any OS , it creates a entry kind of flag in BIOS to detect the respective BOOTLOADER.
– atenz
Aug 8 '12 at 6:19
1
1
@xczzhh, no, the boot loader is on the hard drive or some other disk. It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes.
– psusi
Aug 8 '12 at 14:37
@xczzhh, no, the boot loader is on the hard drive or some other disk. It is installed along with the OS. Unless you download and install an update from your motherboard maker, the ROM never changes.
– psusi
Aug 8 '12 at 14:37
EFI uses EFI applications instead.It loads the EFI application in the NVRAM
– Suici Doga
May 7 '16 at 2:07
EFI uses EFI applications instead.It loads the EFI application in the NVRAM
– Suici Doga
May 7 '16 at 2:07
@SuiciDoga, no, EFI applications ( which are basically limited to a few firmware upgrade utilities and boot loaders ) are stored in the EFI system partition of the hard disk. NVRAM is where EFI stores some configuration variables, such as boot order.
– psusi
May 7 '16 at 13:24
@SuiciDoga, no, EFI applications ( which are basically limited to a few firmware upgrade utilities and boot loaders ) are stored in the EFI system partition of the hard disk. NVRAM is where EFI stores some configuration variables, such as boot order.
– psusi
May 7 '16 at 13:24
add a comment |
up vote
22
down vote
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
2
ROM hasn't been faster than RAM for about a decade now. In fact, one of the first things a modern BIOS does is copy itself into RAM because the RAM is so much faster.
– David Schwartz
Aug 8 '12 at 12:38
1
@DavidSchwartz, It's been more than a decade now. Every PC BIOS I used in the mid '90s had an option to shadow the bios in RAM for speed.
– psusi
Aug 8 '12 at 14:43
@Anwar, the link to Main Memory is dead.
– The Matt
Dec 1 at 16:48
add a comment |
up vote
22
down vote
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
2
ROM hasn't been faster than RAM for about a decade now. In fact, one of the first things a modern BIOS does is copy itself into RAM because the RAM is so much faster.
– David Schwartz
Aug 8 '12 at 12:38
1
@DavidSchwartz, It's been more than a decade now. Every PC BIOS I used in the mid '90s had an option to shadow the bios in RAM for speed.
– psusi
Aug 8 '12 at 14:43
@Anwar, the link to Main Memory is dead.
– The Matt
Dec 1 at 16:48
add a comment |
up vote
22
down vote
up vote
22
down vote
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
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
edited Dec 1 at 20:12
The Matt
1135
1135
answered Aug 8 '12 at 6:28
Anwar
55.6k22143252
55.6k22143252
2
ROM hasn't been faster than RAM for about a decade now. In fact, one of the first things a modern BIOS does is copy itself into RAM because the RAM is so much faster.
– David Schwartz
Aug 8 '12 at 12:38
1
@DavidSchwartz, It's been more than a decade now. Every PC BIOS I used in the mid '90s had an option to shadow the bios in RAM for speed.
– psusi
Aug 8 '12 at 14:43
@Anwar, the link to Main Memory is dead.
– The Matt
Dec 1 at 16:48
add a comment |
2
ROM hasn't been faster than RAM for about a decade now. In fact, one of the first things a modern BIOS does is copy itself into RAM because the RAM is so much faster.
– David Schwartz
Aug 8 '12 at 12:38
1
@DavidSchwartz, It's been more than a decade now. Every PC BIOS I used in the mid '90s had an option to shadow the bios in RAM for speed.
– psusi
Aug 8 '12 at 14:43
@Anwar, the link to Main Memory is dead.
– The Matt
Dec 1 at 16:48
2
2
ROM hasn't been faster than RAM for about a decade now. In fact, one of the first things a modern BIOS does is copy itself into RAM because the RAM is so much faster.
– David Schwartz
Aug 8 '12 at 12:38
ROM hasn't been faster than RAM for about a decade now. In fact, one of the first things a modern BIOS does is copy itself into RAM because the RAM is so much faster.
– David Schwartz
Aug 8 '12 at 12:38
1
1
@DavidSchwartz, It's been more than a decade now. Every PC BIOS I used in the mid '90s had an option to shadow the bios in RAM for speed.
– psusi
Aug 8 '12 at 14:43
@DavidSchwartz, It's been more than a decade now. Every PC BIOS I used in the mid '90s had an option to shadow the bios in RAM for speed.
– psusi
Aug 8 '12 at 14:43
@Anwar, the link to Main Memory is dead.
– The Matt
Dec 1 at 16:48
@Anwar, the link to Main Memory is dead.
– The Matt
Dec 1 at 16:48
add a comment |
up vote
15
down vote
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.
I suppose he wants to know whether the Windows bootloader and GRUB can co exist together, or not. UEFI ,GPT disks don't use MBR how does this effect them?.
– Uri Herrera
Aug 8 '12 at 3:51
The BIOS ROM is located in the F000: segment, which is just below 1 MB. The 640k is from the segments below A000:, which are available for the real mode OS and programs to use.
– psusi
Aug 8 '12 at 4:00
@psusi: you're right, I re-phrased that part
– Sergey
Aug 8 '12 at 4:42
Thank you for the answer. Do you mean that there are multiple bootloaders(one within the BIOS, and another in MBR?) involved to boot an operating system? It's new to me... :)
– xczzhh
Aug 8 '12 at 5:22
@xczzhh Well, ok, the code in BIOS is not called "bootloader", the one stored on disk does. I updated my answer to make this clear.
– Sergey
Aug 8 '12 at 6:10
|
show 2 more comments
up vote
15
down vote
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.
I suppose he wants to know whether the Windows bootloader and GRUB can co exist together, or not. UEFI ,GPT disks don't use MBR how does this effect them?.
– Uri Herrera
Aug 8 '12 at 3:51
The BIOS ROM is located in the F000: segment, which is just below 1 MB. The 640k is from the segments below A000:, which are available for the real mode OS and programs to use.
– psusi
Aug 8 '12 at 4:00
@psusi: you're right, I re-phrased that part
– Sergey
Aug 8 '12 at 4:42
Thank you for the answer. Do you mean that there are multiple bootloaders(one within the BIOS, and another in MBR?) involved to boot an operating system? It's new to me... :)
– xczzhh
Aug 8 '12 at 5:22
@xczzhh Well, ok, the code in BIOS is not called "bootloader", the one stored on disk does. I updated my answer to make this clear.
– Sergey
Aug 8 '12 at 6:10
|
show 2 more comments
up vote
15
down vote
up vote
15
down vote
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.
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.
edited Aug 8 '12 at 21:19
answered Aug 8 '12 at 3:48
Sergey
36k98799
36k98799
I suppose he wants to know whether the Windows bootloader and GRUB can co exist together, or not. UEFI ,GPT disks don't use MBR how does this effect them?.
– Uri Herrera
Aug 8 '12 at 3:51
The BIOS ROM is located in the F000: segment, which is just below 1 MB. The 640k is from the segments below A000:, which are available for the real mode OS and programs to use.
– psusi
Aug 8 '12 at 4:00
@psusi: you're right, I re-phrased that part
– Sergey
Aug 8 '12 at 4:42
Thank you for the answer. Do you mean that there are multiple bootloaders(one within the BIOS, and another in MBR?) involved to boot an operating system? It's new to me... :)
– xczzhh
Aug 8 '12 at 5:22
@xczzhh Well, ok, the code in BIOS is not called "bootloader", the one stored on disk does. I updated my answer to make this clear.
– Sergey
Aug 8 '12 at 6:10
|
show 2 more comments
I suppose he wants to know whether the Windows bootloader and GRUB can co exist together, or not. UEFI ,GPT disks don't use MBR how does this effect them?.
– Uri Herrera
Aug 8 '12 at 3:51
The BIOS ROM is located in the F000: segment, which is just below 1 MB. The 640k is from the segments below A000:, which are available for the real mode OS and programs to use.
– psusi
Aug 8 '12 at 4:00
@psusi: you're right, I re-phrased that part
– Sergey
Aug 8 '12 at 4:42
Thank you for the answer. Do you mean that there are multiple bootloaders(one within the BIOS, and another in MBR?) involved to boot an operating system? It's new to me... :)
– xczzhh
Aug 8 '12 at 5:22
@xczzhh Well, ok, the code in BIOS is not called "bootloader", the one stored on disk does. I updated my answer to make this clear.
– Sergey
Aug 8 '12 at 6:10
I suppose he wants to know whether the Windows bootloader and GRUB can co exist together, or not. UEFI ,GPT disks don't use MBR how does this effect them?.
– Uri Herrera
Aug 8 '12 at 3:51
I suppose he wants to know whether the Windows bootloader and GRUB can co exist together, or not. UEFI ,GPT disks don't use MBR how does this effect them?.
– Uri Herrera
Aug 8 '12 at 3:51
The BIOS ROM is located in the F000: segment, which is just below 1 MB. The 640k is from the segments below A000:, which are available for the real mode OS and programs to use.
– psusi
Aug 8 '12 at 4:00
The BIOS ROM is located in the F000: segment, which is just below 1 MB. The 640k is from the segments below A000:, which are available for the real mode OS and programs to use.
– psusi
Aug 8 '12 at 4:00
@psusi: you're right, I re-phrased that part
– Sergey
Aug 8 '12 at 4:42
@psusi: you're right, I re-phrased that part
– Sergey
Aug 8 '12 at 4:42
Thank you for the answer. Do you mean that there are multiple bootloaders(one within the BIOS, and another in MBR?) involved to boot an operating system? It's new to me... :)
– xczzhh
Aug 8 '12 at 5:22
Thank you for the answer. Do you mean that there are multiple bootloaders(one within the BIOS, and another in MBR?) involved to boot an operating system? It's new to me... :)
– xczzhh
Aug 8 '12 at 5:22
@xczzhh Well, ok, the code in BIOS is not called "bootloader", the one stored on disk does. I updated my answer to make this clear.
– Sergey
Aug 8 '12 at 6:10
@xczzhh Well, ok, the code in BIOS is not called "bootloader", the one stored on disk does. I updated my answer to make this clear.
– Sergey
Aug 8 '12 at 6:10
|
show 2 more comments
up vote
4
down vote
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.
add a comment |
up vote
4
down vote
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.
add a comment |
up vote
4
down vote
up vote
4
down vote
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.
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.
edited Aug 8 '12 at 13:59
answered Aug 8 '12 at 12:55
Jon Hanna
708615
708615
add a comment |
add a comment |
up vote
0
down vote
Make a minimal working example and run it on an emulator to understand those concepts:
printf '364%509s125252' > main.img
qemu-system-x86_64 -hda main.img
This is a super simple "bootloader" that does a single hlt
instruction. More info at: https://stackoverflow.com/a/32483545/895245
You can then run it on real hardware with:
sudo dd if=main.img of=/dev/sdX
and plugging the USB on your computer, and booting from it.
When you do this, it becomes clear that the bootloader is something that lives on a permanent storage disk like USBs or hard disks.
What lives on ROM is the code that starts up the bootloader for us, called firmware (or less precisely BIOS).
add a comment |
up vote
0
down vote
Make a minimal working example and run it on an emulator to understand those concepts:
printf '364%509s125252' > main.img
qemu-system-x86_64 -hda main.img
This is a super simple "bootloader" that does a single hlt
instruction. More info at: https://stackoverflow.com/a/32483545/895245
You can then run it on real hardware with:
sudo dd if=main.img of=/dev/sdX
and plugging the USB on your computer, and booting from it.
When you do this, it becomes clear that the bootloader is something that lives on a permanent storage disk like USBs or hard disks.
What lives on ROM is the code that starts up the bootloader for us, called firmware (or less precisely BIOS).
add a comment |
up vote
0
down vote
up vote
0
down vote
Make a minimal working example and run it on an emulator to understand those concepts:
printf '364%509s125252' > main.img
qemu-system-x86_64 -hda main.img
This is a super simple "bootloader" that does a single hlt
instruction. More info at: https://stackoverflow.com/a/32483545/895245
You can then run it on real hardware with:
sudo dd if=main.img of=/dev/sdX
and plugging the USB on your computer, and booting from it.
When you do this, it becomes clear that the bootloader is something that lives on a permanent storage disk like USBs or hard disks.
What lives on ROM is the code that starts up the bootloader for us, called firmware (or less precisely BIOS).
Make a minimal working example and run it on an emulator to understand those concepts:
printf '364%509s125252' > main.img
qemu-system-x86_64 -hda main.img
This is a super simple "bootloader" that does a single hlt
instruction. More info at: https://stackoverflow.com/a/32483545/895245
You can then run it on real hardware with:
sudo dd if=main.img of=/dev/sdX
and plugging the USB on your computer, and booting from it.
When you do this, it becomes clear that the bootloader is something that lives on a permanent storage disk like USBs or hard disks.
What lives on ROM is the code that starts up the bootloader for us, called firmware (or less precisely BIOS).
edited May 23 '17 at 12:39
Community♦
1
1
answered Oct 4 '15 at 19:18
Ciro Santilli 新疆改造中心 六四事件 法轮功
9,08444246
9,08444246
add a comment |
add a comment |
up vote
0
down vote
In days of old, the boot program resided on punched paper tape similar to those used by telegraph machines or punched card media ('don't see both of them around anymore). the process used to be called IPL, short for Initial Program Load. Sometimes if a paper tape or card reader was not available one would need to enter the binary IPL code directly into the processor via a console on the front panel. whew!
Nowadays the IPL code reside in pROMs which when executed in turn load and execute any secondary boot loaders tailored to load (bootup) the desired operating system. the secondary loader could be on any medium on any part of the setup known to or addressable by the IPL code.
add a comment |
up vote
0
down vote
In days of old, the boot program resided on punched paper tape similar to those used by telegraph machines or punched card media ('don't see both of them around anymore). the process used to be called IPL, short for Initial Program Load. Sometimes if a paper tape or card reader was not available one would need to enter the binary IPL code directly into the processor via a console on the front panel. whew!
Nowadays the IPL code reside in pROMs which when executed in turn load and execute any secondary boot loaders tailored to load (bootup) the desired operating system. the secondary loader could be on any medium on any part of the setup known to or addressable by the IPL code.
add a comment |
up vote
0
down vote
up vote
0
down vote
In days of old, the boot program resided on punched paper tape similar to those used by telegraph machines or punched card media ('don't see both of them around anymore). the process used to be called IPL, short for Initial Program Load. Sometimes if a paper tape or card reader was not available one would need to enter the binary IPL code directly into the processor via a console on the front panel. whew!
Nowadays the IPL code reside in pROMs which when executed in turn load and execute any secondary boot loaders tailored to load (bootup) the desired operating system. the secondary loader could be on any medium on any part of the setup known to or addressable by the IPL code.
In days of old, the boot program resided on punched paper tape similar to those used by telegraph machines or punched card media ('don't see both of them around anymore). the process used to be called IPL, short for Initial Program Load. Sometimes if a paper tape or card reader was not available one would need to enter the binary IPL code directly into the processor via a console on the front panel. whew!
Nowadays the IPL code reside in pROMs which when executed in turn load and execute any secondary boot loaders tailored to load (bootup) the desired operating system. the secondary loader could be on any medium on any part of the setup known to or addressable by the IPL code.
answered Dec 8 '17 at 6:02
Loi
1
1
add a comment |
add a comment |
up vote
-1
down vote
The boot loader usually is in the first sector of the hard drive, usually called the Master Boot Record.
Cheers
add a comment |
up vote
-1
down vote
The boot loader usually is in the first sector of the hard drive, usually called the Master Boot Record.
Cheers
add a comment |
up vote
-1
down vote
up vote
-1
down vote
The boot loader usually is in the first sector of the hard drive, usually called the Master Boot Record.
Cheers
The boot loader usually is in the first sector of the hard drive, usually called the Master Boot Record.
Cheers
answered Aug 8 '12 at 8:11
j0N45
1746
1746
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f173248%2fwhere-is-the-bootloader-stored-in-rom-ram-or-elsewhere%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown