What is difference between U-Boot and BIOS ?
Are both these devices present on a particular CPU or once a single device can be present at a time?
It would be nice if someone provides examples.
Difference between U-Boot and BIOS
biosbootloadercpu
Related Solutions
- As we all know that BIOS is important part for accessing boot option. So now UEFI will do that? How?
BIOS boots by reading the first sector on a hard disk and executing it; this boot sector in turn locates and runs additional code. The BIOS system is very limiting because of space constraints and because BIOS runs 16-bit code, whereas modern computers use 32-bit or 64-bit CPUs. By contrast, EFI (or UEFI, which is just EFI 2.x) boots by loading EFI program files (with .efi filename extensions) from a partition on the hard disk, known as the EFI System Partition (ESP). These EFI boot loader programs can take advantage of EFI boot services for things like reading files from the hard disk.
As a practical matter, if you're using an OS like Linux that has complex BIOS-mode boot loaders, EFI-mode booting is likely to be similar to BIOS-mode booting, since GRUB 2 (the most popular BIOS-mode boot loader for Linux) has been ported to work under EFI, and many Linux distributions install GRUB 2 by default on EFI systems. OTOH, you can replace or supplement GRUB 2 with other EFI boot loaders. Indeed, the Linux kernel itself can be an EFI boot loader; code was added to do this with the 3.3.0 kernel. Used in this way, the EFI itself loads and runs the Linux kernel, or you can use a third-party boot manager like rEFInd or gummiboot to let you select which OS or kernel to boot.
- How would I know that I'm booting with UEFI not with BIOS?
As Root says, there are clues in the firmware's user interface; however, those are unreliable and vary from one computer to another. The only way to be sure is to check to see how the computer booted. In Linux, for instance, the presence of a directory called /sys/firmware/efi is diagnostic. If it's present, you've booted in EFI mode; if it's not present, you've probably booted in BIOS mode. (This directory can be absent on an EFI-mode boot under some circumstances, though.) dmesg output that refers to EFI is also diagnostic of an EFI-mode boot. In Windows, the partition table of the boot disk is diagnostic; if it's GPT, you booted in EFI mode, and if it's MBR, you booted in BIOS mode.
- So what is the real different in the "boot with BIOS" and "boot with UEFI"?
EFI can be faster, but that's not certain. The biggest speed difference is in hardware initialization early in the process. On my systems, this is a fraction of the total boot time, so a reduction in the hardware initialization time, while good, doesn't make all that much difference. It's not like I'm rebooting every ten minutes, after all.
UEFI supports a feature called Secure Boot that's intended, as the name suggests, to improve security. It does this by requiring a digital "signature" of boot loaders, which in turn should require signing of kernels, and so on up the chain. This should make it harder for malware authors to insert their code into the pre-boot process, thus improving security. This sounds good, but it also complicates dual-boot configurations, since code like GRUB and the Linux kernel must be signed. The major Linux distribution vendors are working on ways to make these requirements less of a burden for average Linux users, and they've got some preliminary stuff ready. At the moment, though, disabling Secure Boot is the easiest way to deal with it. This is a practical concern mainly for brand-new computers that ship with Windows 8, since Microsoft is requiring Secure Boot be enabled to get Windows 8 certification. Some people confuse UEFI and Secure Boot (the latter is just one feature of the former), but it deserves mention as a difference between BIOS and UEFI because it's causing some problems for new Windows 8 computers. If you've got an older system or are comfortable enough with firmware setup utilities to disable Secure Boot, this need not be a real problem.
Microsoft ties the boot disk's partition table type to the firmware type (MBR to BIOS; GPT to UEFI). Because MBR tops out at 2TiB (assuming standard sector sizes), this means that UEFI is a practical necessity to boot Windows on over-2TiB disks. You can still use such big disks as data disks under Windows, though, and you can boot some non-Microsoft OSes (such as Linux and FreeBSD) on big disks using GPT under BIOS.
As a practical matter if you're concerned about or interested in UEFI, the biggest issue is simply that UEFI is new enough that support for it is a bit spotty, particularly in some older and more exotic OSes. UEFI itself is new enough that most of its implementations are buggy, and those that aren't vary enough amongst themselves that it can be hard to describe things generally. Thus, using UEFI can be a challenge. OTOH, UEFI is the future. It's got some modest advantages, some of which will become more important in time (such as the 2TiB boot disk limit of Windows). Switching to a UEFI boot will change a few details of the boot process, but your overall computing experience won't change all that much once you overcome any boot issues you may encounter.
EDIT:
Could you expand on the OpRom settings (Option Rom). They seem to allow you choose between UEFI booting or "Legacy" booting and they apply to the Video card, Network card, and various other PCI devices.
Many plug-in cards provide firmware that interfaces with the firmware on the motherboard. The two types of firmware must be able to "talk" if the card's firmware is to do any good. This is necessary to use the card before an OS boots -- for instance, to display your firmware's options or a boot manager menu on a video card, to perform a network boot via a network card, or to boot from a hard disk connected to a disk controller card.
Just as with boot loaders, the code in a plug-in device's firmware is written to interface with either BIOS or EFI (although plug-in cards can support both, if I'm not mistaken). Some EFIs provide options to enable or disable this support on a fine-grained basis, as you've observed. In some cases, an EFI can use a card's BIOS-mode support to enable it to work in EFI mode, by "translating" the calls. (This is common with video cards, for instance; you can often plug in an old video card with nothing but BIOS support in its firmware and still use it to boot in EFI mode.)
I don't know precisely what each of the settings you note does. For instance, I don't know if "BIOS only" for one of these options would make the card work only in BIOS mode, "translate" so that the EFI can use the BIOS-mode calls in EFI mode, or something else. In fact, given the lack of standards in other EFI user interface areas, I would expect the details to differ from one EFI to another, so you may need to consult your computer's documentation or experiment if you need to know the details. I've seen some computers with very similar-sounding options in two different menus, which further complicates matters.
A superscalar processor is capable of executing multiple instructions within a single program in parallel. It does this by analyzing the instruction stream to determine which instructions do not depend on each other, and having multiple execution units within the processor to do the work simultaneously (e.g. multiple ALUs). Compiler support is generally not required to optimize code for superscalar processors as the functionality is typically implemented entirely in hardware.1
A vector processor contains instructions specifically designed to operate on whole groups of multiple data values at once (called arrays or vectors). Most modern high-performance processors contain some form of vector processing capability; for example; the SSE ADDPS instruction available in most x86 processors computes the sum of two vectors each containing four single-precision values. Compiler, developer, and operating system support are typically required to use vector instructions, and not every processor, even in current generations, support the most advanced vector instructions (e.g. Intel Celeron and Pentium processors, even as of Kaby Lake, do not support AVX).
More technical information about how today's processors achieve high performance is available in this answer.
1 An alternative, and rather unusual, design approach is to have multiple execution units but let the compiler determine what instructions to issue to each execution unit for each clock cycle. This is called very long instruction word and is typically only found on specialized processors.
Best Answer
There are numerous difference between U-Boot and a BIOS.
BTW these are both software, not "devices".
BIOS is essentially a PC concept, having appeared in CP/M personal computers and the original IBM PC.
U-Boot tries to live up to its name ("Universal Boot"), and has been ported to many architectures/platforms.
BIOS functions include basic system initialization after a reset or powerup, performing Power On Self Tests (aka POST), provide an interactive hardware configuration interface (aka BIOS setup) and bootstraping the PC. The use of the integrated device drivers of the original IBM PC's BIOS has been abandoned in favor of OS device drivers.
U-Boot functions include basic system initialization and bootstraping the system. The booting sequence can optionally be aborted to enter an interactive command-line session. Since U-Boot is extensible, any number of features can be configured in or added, such as POST and other diagnostics, filesystem maintenance utilities, network capabilities such as retrieving time-of-day (SNTP) or an IP address (DHCP client), and reading/writing/modifying memory locations. The actual features and capabilities of U-Boot will vary on system/installation to system.
BIOS handles the initial startup of the PC as first-stage bootloader. It typically executes in place (XIP) in the Flash memory that it resides in.
U-Boot is typically a second (or even third) stage bootloader. It could be the 1st-stage bootloader like a BIOS, since it can XIP, but I'm not aware if any platform has actually done that. Typically U-Boot is loaded from Flash memory and executed in main memory, e.g. SDRAM.
As a first-stage bootloader the BIOS is rather limited as it what it loads and executes, such as the Master Boot Record (MBR) from a hard disk. The BIOS does not typically load the actual OS image.
U-Boot, when it is provided the uImage file format, is aware of the OS it is loading, and can properly prepare memory buffers and parameters for proper OS initialization.
BIOS, since it is PC based, typically uses the video adapter and keyboard as operator I/O devices.
U-Boot typically uses a RS232 serial port as the operator I/O device.
The original IBM PC BIOS was published in the IBM PC technical documents as an x86 assembly language listing. Modern versions sold by AMI, Award and Phoenix are proprietary.
U-Boot is released under the GNU GPL.
Linux on PCs typically use Grub as the post-BIOS bootstrap program. I suppose U-Boot could be used in place of Grub, but I don't know the reasons for or against such an implementation.