https://wiki.archlinux.org/api.php?action=feedcontributions&user=Chroniclinux&feedformat=atomArchWiki - User contributions [en]2024-03-29T09:32:07ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=PulseAudio&diff=366288PulseAudio2015-03-20T13:55:53Z<p>Chroniclinux: Add package for KF5, kdemultimedia-kmix doesn't load into KF5, kmix package does.</p>
<hr />
<div>[[Category:Audio/Video]]<br />
[[Category:Sound]]<br />
[[cs:PulseAudio]]<br />
[[es:PulseAudio]]<br />
[[fr:PulseAudio]]<br />
[[it:PulseAudio]]<br />
[[ja:PulseAudio]]<br />
[[pt:PulseAudio]]<br />
[[ru:PulseAudio]]<br />
[[tr:PulseAudio]]<br />
[[zh-CN:PulseAudio]]<br />
{{Related articles start}}<br />
{{Related|PulseAudio/Examples}}<br />
{{Related|PulseAudio/Troubleshooting}}<br />
{{Related articles end}}<br />
[[Wikipedia:PulseAudio|PulseAudio]] is a sound server commonly used by desktop environments like [[GNOME]] or [[KDE]]. It serves as a proxy to sound applications using existing kernel sound components like [[ALSA]] or [[OSS]]. Since ALSA is included in Arch Linux by default, the most common deployment scenarios include PulseAudio with ALSA.<br />
<br />
== Installation ==<br />
<br />
* Required package: {{Pkg|pulseaudio}}<br />
* Optional GTK GUIs: {{Pkg|paprefs}} and {{Pkg|pavucontrol}}<br />
* Optional volume control via mapped keyboard keys: {{AUR|pulseaudio-ctl}}<br />
* Optional console (CLI) mixers: {{Pkg|ponymix}} and {{AUR|pamixer-git}}<br />
* Optional web volume control: [https://github.com/Siot/PaWebControl PaWebControl]<br />
* Optional system tray icon: {{AUR|pasystray-git}}<br />
* Optional KDE4 plasma applet: {{Pkg|kdemultimedia-kmix}} and {{AUR|kdeplasma-applets-veromix}} (If KMix/Veromix fail to connect to PulseAudio at boot you may need to edit {{ic|/etc/pulse/client.conf}} to include {{ic|autospawn &#61; yes}} instead of {{ic|autospawn &#61; no}}.)<br />
* Optional KF5 plasma applet: {{Pkg|kmix}}<br />
<br />
{{Note|Some confusion can be made between [[ALSA]] and PulseAudio. ALSA both includes a Linux kernel component with sound card drivers, and a userspace component, {{ic|libalsa}}. PulseAudio only builds on the kernel component, but offers compability with {{ic|libalsa}} through {{Pkg|pulseaudio-alsa}}.}}<br />
<br />
== Configuration ==<br />
<br />
=== Configuration files ===<br />
<br />
{{Merge|PulseAudio/Configuration|Configuration should stay in the main article, so the linked page should be merged here. Split [[#Troubleshooting]] instead if this page is found too long.|section=Abandoned draft}}<br />
By default, PulseAudio is configured to automatically detect all sound cards and manage them. It takes control of all detected ALSA devices and redirect all audio streams to itself, making the PulseAudio daemon the central configuration point. The daemon should work mostly out of the box, only requiring a few minor tweaks. <br />
<br />
PulseAudio will first look for configuration files in home directory {{ic|~/.config/pulse}}, then in system wide {{ic|/etc/pulse}}.<br />
<br />
PulseAudio runs as a server daemon that can run either system-wide or on per-user basis using a client/server architecture. The daemon by itself does nothing without its modules except to provide an API and host dynamically loaded modules. The audio routing and processing tasks are all handled by various modules. You find a detailed list of all available modules at [http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/ Pulseaudio Loadable Modules]. To enable them you can just add a line {{ic|load-module <module-name-from-list>}} to {{ic|~/.config/pulse/default.pa}}.<br />
<br />
{{Tip|<br />
* It is strongly suggested not to edit system wide configuration files, but rather edit user ones. Create the {{ic|~/.config/pulse}} directory, then copy the system configuration files in it and edit according to your need.<br />
* Make sure you keep user configuration in sync with changes to the packaged files in {{ic|/etc/pulse/}}. Otherwise, PulseAudio may refuse to start due to configuration errors.<br />
* There is no need to add user to audio group, as it uses [[udev]] and ''logind'' to dynamically give access to the currently "active" user}}<br />
<br />
==== daemon.conf ====<br />
<br />
Defines base settings like the default sample rates used by modules, resampling methods, realtime scheduling and various other settings related to the server process. These can not be changed at runtime without restarting the PulseAudio daemon. The defaults are sensible for most users.<br />
<br />
{| class="wikitable"<br />
|+ Notable configuration options<br />
! Option || Description<br />
|+<br />
| system-instance || Run the daemon as a system-wide instance. Highly discouraged as it can introduce security issues. Useful on (headless) systems that have no real local users. Defaults to {{ic|no}}.<br />
|+<br />
| resample-method || Which resampler to use when audio with incompatible sample rates needs to be passed between modules (e.g. playback of 96kHz audio on hardware which only supports 48kHz). The available resamplers can be listed with {{ic|$ pulseaudio --dump-resample-methods}}. Choose the best tradeoff between CPU usage and audio quality for the present use-case. {{Tip|In some cases PulseAudio will generate a high CPU load. This can happen when multiple streams are resampled (individually). If this is a common use-case in a workflow, it should be considered to create an additional sink at a matching sample rate which can then be fed into the main sink, resampling only once.}}<br />
|+<br />
| flat-volumes ||{{ic|flat-volumes}} scales the device-volume with the volume of the "loudest" application. For example, raising the VoIP call volume will raise the hardware volume and adjust the music-player volume so it stays where it was, without having to lower the volume of the music-player manually. Defaults to {{ic|yes}}. {{Warning|The default behavior can sometimes be confusing and some applications, unaware of this feature, can set their volume to 100% at startup, potentially blowing your speakers or your ears. To restore the classic (ALSA) behavior set this to {{ic|no}}.}}<br />
|+<br />
| default-fragments || Audio samples are split into multiple fragments of {{ic|default-fragment-size-msec}} each. The larger the buffer is, the less likely audio will skip when the system is overloaded. On the downside this will increase the overall latency. Increase this value if you have issues.<br />
|}<br />
<br />
==== default.pa ====<br />
<br />
This file is a startup script and is used to configure modules. It is actually parsed and read after the daemon has finished initializing and additionnal commands can be sent at runtime using {{ic|$ pactl}} or {{ic|$ pacmd}}. The startup script can also be provided on the command line by starting PulseAudio in a terminal using {{ic|$ pulseaudio -nC}}. This will make the daemon load the CLI module and will accept the configuration directly from the command line, and output resulting information or error messages on the same terminal. This can be useful when debugging the daemon or just to test various modules before setting them permanently on disk. The manual page is quite self explaining, please consult {{ic|man pulse-cli-syntax}} for the details of the syntax.<br />
<br />
{{tip|<br />
* Run {{ic|<nowiki>$ pacmd list-sinks|egrep -i 'index:|name:'</nowiki>}} to list available sinks. The present default sink is marked with an asterix.<br />
* Edit {{ic|~/.config/pulse/default.pa}} to insert/alter the set-default-sink command using the sink's name as the numbering cannot be guaranteed repeatable.<br />
}}<br />
<br />
==== {{ic|client.conf}} ====<br />
This is the configuration file read by every PulseAudio client applications. It is used to configure runtime options for individual clients. It can be used to set the configure the default sink and source statically as well as allowing (or disallowing) clients to automatically start the server if not currently running.<br />
<br />
=== Configuration command ===<br />
<br />
The main command to configure a server during runtime is {{ic|$ pacmd}}. Run {{ic|$ pacmd --help}} for a list options, or just run {{ic|$ pacmnd}} to enter the shell interactive mode and {{ic|Ctrl+d}} to exit. All modifications will immediately be applied.<br />
<br />
Once your new settings have been tested and meet your needs, edit the {{ic|default.pa}} accordingly to make the change persistent. See [[PulseAudio/Examples]] for some basic settings.<br />
<br />
{{Tip|leave the {{ic|load-module module-default-device-restore}} line in the {{ic|default.pa}} file untouched. It will allow you to restart the server in its default state, thus dismissing any wrong setting.}}<br />
<br />
It is important to understand that the "sources" and "sinks" accessible and selectable through PulseAudio depend upon the current hardware "Profile" selected. These "Profiles" are those ALSA "pcms" listed by the command {{ic|aplay -L}}, and more specifically by the command {{ic|pacmd list-cards}}, which will include a line "index:", a list beginning "profiles:", and a line "active profile: <...>" in the output, among other things.<br />
<br />
The "active profile" can be set with the command {{ic|pacmd set-card-profile INDEX PROFILE}}, with ''no'' comma separating INDEX and PROFILE, where INDEX is just the number on the line "index:" and a PROFILE name is everything shown from the beginning of any line under "profile:" to just ''before'' the colon and first space, as shown by the command {{ic|pacmd list-cards}}. For instance, {{ic|pacmd set-card-profile 0 output:analog-stereo+input:analog-stereo}}.<br />
<br />
It may be easier to select a "Profile" with a graphical tool like {{ic|pavucontrol}}, under the "Configuration" tab, or KDE System Settings, "Multimedia/Audio and Video Settings", under the "Audio Hardware Setup" tab. Each audio "Card", which are those devices listed by the command {{ic|aplay -l}}, or again by the command {{ic|pacmd list-cards}}, will have its own selectable "Profile". When a "Profile" has been selected, the then available "sources" and "sinks" can be seen by using the commands {{ic|pacmd list-sources}} and {{ic|pacmd list-sinks}}. Note that the "index" of the available sources and sinks will change each time a card profile is changed.<br />
<br />
The selected "Profile" can be an issue for some applications, especially the Adobe Flash players, typically {{ic|/usr/lib/mozilla/plugins/libflashplayer.so}} and {{ic|/usr/lib/PepperFlash/libpepflashplayer.so}}. Often, these Flash players will only work when one of the Stereo profiles is selected, and otherwise, will play video with no sound, or will simply "crash". When all else fails, you might try selecting a different profile.<br />
<br />
Of course, when configuring some variation of Surround Sound in PulseAudio, the appropriate Surround profile will have to be selected, before Surround Sound will work, or in order to do things like remap the speaker channels.<br />
<br />
== Running ==<br />
<br />
{{Note|Many [[desktop environments]] support [http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html Desktop Application Autostart Specification] and autostart programs based on [[Desktop entries|desktop files]] in the {{ic|/etc/xdg/autostart/}} directory. In this case, PulseAudio will be launched automatically regardless of the autospawn/socket activation described below.}}<br />
<br />
Since [http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/6.0/ version 6.0], PulseAudio relies on autospawn/socket activation.<br />
<br />
To use socket activation:<br />
<br />
$ systemctl --user enable pulseaudio.socket<br />
<br />
Alternatively, set {{ic|1=autospawn=yes}} in either {{ic|/etc/pulse/client.conf}} or {{ic|~/.pulse/client.conf}} in order to use autospawn activation.<br />
<br />
=== Starting manually ===<br />
<br />
PulseAudio can be manually started with:<br />
$ pulseaudio --start<br />
<br />
And stopped with:<br />
$ pulseaudio --kill<br />
<br />
=== Autostarting in unsupported desktop environments ===<br />
<br />
{{Deletion|[[systemd/User]] is enabled by default these days, autospawn yet another is a universal solution}}<br />
<br />
Check to see if PulseAudio is running:<br />
<br />
{{hc|<nowiki>$ pgrep -af pulseaudio</nowiki>|<br />
369 /usr/bin/pulseaudio<br />
}}<br />
<br />
If PulseAudio is not running and users are using X, the following will start PulseAudio with the needed the X11 plugins manually:<br />
<br />
$ start-pulseaudio-x11<br />
<br />
If you are running a DM or DE that doesn't support autostarting from {{ic|/etc/xdg/autostart/}}, then you can launch PulseAudio on login through {{ic|~/.xprofile}} (Some older DMs may require this to be placed in {{ic|~/.xinitrc}} instead):<br />
<br />
{{hc|~/.xprofile|<br />
/usr/bin/start-pulseaudio-x11 &<br />
}}<br />
<br />
== Back-end configuration ==<br />
<br />
=== ALSA ===<br />
<br />
Install {{Pkg|pulseaudio-alsa}} from the [[official repositories]]. This package contains the necessary {{ic|/etc/asound.conf}} for configuring ALSA to use PulseAudio.<br />
<br />
Also install {{Pkg|lib32-libpulse}} and {{Pkg|lib32-alsa-plugins}} if you run a x86_64 system and want to have sound for 32-bit [[multilib]] programs like Wine, Skype and Steam.<br />
<br />
To prevent applications from using ALSA's OSS emulation and bypassing PulseAudio (thereby preventing other applications from playing sound), make sure the module {{ic|snd_pcm_oss}} is not being loaded at boot. If it is currently loaded ({{ic|<nowiki>lsmod | grep oss</nowiki>}}), disable it by executing:<br />
# rmmod snd_pcm_oss<br />
<br />
==== ALSA/dmix without grabbing hardware device ====<br />
<br />
{{Note|This section describes alternative configuration, which is generally '''not''' recommended.}}<br />
<br />
You may want to use ALSA directly in most of your applications and to be able to use other applications, which constantly require PulseAudio at the same time. The following steps allow you to make PulseAudio use dmix instead of grabbing ALSA hardware device.<br />
<br />
* Remove package {{Pkg|pulseaudio-alsa}}, which provides compatibility layer between ALSA applications and PulseAudio. After this your ALSA apps will use ALSA directly without being hooked by Pulse.<br />
<br />
* Edit {{ic|/etc/pulse/default.pa}}.<br />
:Find and uncomment lines which load back-end drivers. Add '''device''' parameters as follows. Then find and comment lines which load autodetect modules.<br />
load-module module-alsa-sink '''device=dmix'''<br />
load-module module-alsa-source '''device=dsnoop'''<br />
# load-module module-udev-detect<br />
# load-module module-detect<br />
<br />
* ''Optional:'' If you use {{Pkg|kdemultimedia-kmix}} you may want to control ALSA volume instead of PulseAudio volume:<br />
$ echo export KMIX_PULSEAUDIO_DISABLE=1 > ~/.kde4/env/kmix_disable_pulse.sh<br />
$ chmod +x ~/.kde4/env/kmix_disable_pulse.sh<br />
<br />
* Now, reboot your computer and try running ALSA and PulseAudio applications at the same time. They both should produce sound simultaneously.<br />
:Use {{Pkg|pavucontrol}} to control PulseAudio volume if needed.<br />
<br />
=== Bluetooth Audio ===<br />
<br />
Install {{Pkg|pavucontrol}} to select the Output Device as well as direct the Playback app to the correct bluetooth audio device.<br />
<br />
=== OSS ===<br />
<br />
There are multiple ways of making OSS-only programs output to PulseAudio:<br />
<br />
==== ossp ====<br />
<br />
Install {{Pkg|ossp}} package and start {{ic|osspd.service}}.<br />
<br />
==== padsp wrapper ====<br />
<br />
Programs using OSS can work with PulseAudio by starting it with padsp (included with PulseAudio):<br />
<br />
$ padsp OSSprogram<br />
<br />
A few examples:<br />
<br />
$ padsp aumix<br />
$ padsp sox foo.wav -t ossdsp /dev/dsp<br />
<br />
You can also add a custom wrapper script like this: <br />
<br />
{{hc|/usr/local/bin/OSSProgram|<nowiki><br />
#!/bin/sh<br />
exec padsp /usr/bin/OSSprogram "$@"<br />
</nowiki>}}<br />
<br />
Make sure {{ic|/usr/local/bin}} comes before {{ic|/usr/bin}} in your '''PATH'''.<br />
<br />
=== GStreamer ===<br />
<br />
Install {{Pkg|gst-plugins-good}}, or {{Pkg|gstreamer0.10-good-plugins}} if your intended program has a legacy [[GStreamer]] implementation.<br />
<br />
=== OpenAL ===<br />
<br />
OpenAL Soft should use PulseAudio by default, but can be explicitly configured to do so: {{hc|/etc/openal/alsoft.conf|2=drivers=pulse,alsa}}<br />
<br />
=== libao ===<br />
<br />
Edit the libao configuration file:<br />
{{hc|/etc/libao.conf|2=default_driver=pulse}}<br />
Be sure to remove the {{ic|1=dev=default}} option of the alsa driver or adjust it to specify a specific Pulse sink name or number. <br />
<br />
{{Note|You could possibly also keep the libao standard of outputting to the ''alsa'' driver and its default device if you install {{pkg|pulseaudio-alsa}} since the ALSA default device then '''is''' PulseAudio.}}<br />
<br />
== Equalizer ==<br />
<br />
PulseAudio has an integrated 10-band equalizer system. In order to use the equalizer do the following:<br />
<br />
=== Load equalizer sink and dbus-protocol module ===<br />
<br />
$ pactl load-module module-equalizer-sink<br />
$ pactl load-module module-dbus-protocol<br />
<br />
=== Install and run the GUI front-end ===<br />
<br />
Install {{Pkg|python-pyqt4}} and execute:<br />
<br />
$ qpaeq<br />
<br />
{{Note|If qpaeq has no effect, install {{pkg|pavucontrol}} and change "ALSA Playback on" to "FFT based equalizer on ..." while the media player is running.}}<br />
<br />
=== Load equalizer and dbus module on every boot ===<br />
<br />
Edit the {{ic|/etc/pulse/default.pa}} or {{ic|~/.config/pulse/default.pa}} file with your favorite editor and append the following lines:<br />
<br />
### Load the integrated PulseAudio equalizer and D-Bus module<br />
load-module module-equalizer-sink<br />
load-module module-dbus-protocol<br />
<br />
== Applications ==<br />
<br />
=== QEMU ===<br />
<br />
{{Merge|QEMU|QEMU is the most complex of the "applications" described in this section, merging to the main article would provide better context.}}<br />
<br />
The audio driver used by QEMU is set with the {{ic|QEMU_AUDIO_DRV}} environment variable:<br />
<br />
$ export QEMU_AUDIO_DRV=pa<br />
<br />
Run the following command to get QEMU's configuration options related to PulseAudio:<br />
<br />
$ qemu-system-x86_64 -audio-help | awk '/Name: pa/' RS=<br />
<br />
The listed options can be exported as environment variables, for example:<br />
<br />
{{bc|1=<br />
$ export QEMU_PA_SINK=alsa_output.pci-0000_04_01.0.analog-stereo.monitor<br />
$ export QEMU_PA_SOURCE=input<br />
}}<br />
<br />
{{Style|The following is not specific to PulseAudio.}}<br />
<br />
To get list of the supported emulation audio drivers<br />
$ qemu-system-x86_64 -soundhw help<br />
<br />
To use e.g. {{ic|ac97}} driver for the guest use the {{ic|-soundhw ac97}} commnad with QEMU.<br />
<br />
{{Note|Video graphic card emulated drivers for the guest machine may also cause a problem with the sound quality. Test one by one to make it work. You can list possible options with {{ic|<nowiki>qemu-system-x86_64 -h | grep vga</nowiki>}}.}}<br />
<br />
=== AlsaMixer.app ===<br />
<br />
Make {{AUR|alsamixer.app}} dockapp for the {{Pkg|windowmaker}} use pulseaudio, e.g.<br />
$ AlsaMixer.app --device pulse<br />
<br />
Here is a two examples where the first one is for ALSA and the other one is for pulseaudio. You can run multiple instances of it. Use the {{ic|-w}} option to choose which of the control buttons to bind to the mouse wheel.<br />
# AlsaMixer.app -3 Mic -1 Master -2 PCM --card 0 -w 1<br />
# AlsaMixer.app --device pulse -1 Capture -2 Master -w 2<br />
<br />
{{Note|It can use only those output sinks that set as default.}}<br />
<br />
=== XMMS2 ===<br />
<br />
Make it switch to pulseaudio output<br />
$ nyxmms2 server config output.plugin pulse<br />
and to alsa<br />
$ nyxmms2 server config output.plugin alsa<br />
To make xmms2 use a different output sink, e.g.<br />
$ nyxmms2 server config pulse.sink alsa_output.pci-0000_04_01.0.analog-stereo.monitor<br />
<br />
See also the official guide [https://xmms2.org/wiki/Using_the_application].<br />
<br />
=== KDE Plasma Workspaces and Qt4 ===<br />
<br />
PulseAudio will automatically be used by KDE/Qt4 applications. It is supported by default in the KDE sound mixer. For more information see the [http://www.pulseaudio.org/wiki/KDE KDE page in the PulseAudio wiki]. One useful tidbit from that page is to add {{ic|load-module module-device-manager}} to {{ic|/etc/pulse/default.pa}}.<br />
<br />
If the phonon-gstreamer backend is used for Phonon, GStreamer should also be configured as described in [[#GStreamer]].<br />
<br />
=== Audacious ===<br />
<br />
[[Audacious]] natively supports PulseAudio. In order to use it, set Audacious Preferences -> Audio -> Current output plugin to 'PulseAudio Output Plugin'.<br />
<br />
=== Java/OpenJDK 6 ===<br />
<br />
Create a wrapper for the Java executable using padsp as seen on the [[Java#Java_sound_with_PulseAudio|Java sound with PulseAudio]] page.<br />
<br />
=== Music Player Daemon (MPD) ===<br />
<br />
[http://mpd.wikia.com/wiki/PulseAudio configure] [[MPD]] to use PulseAudio. See also [[MPD/Tips and Tricks#MPD and PulseAudio]].<br />
<br />
=== MPlayer ===<br />
<br />
[[MPlayer]] natively supports PulseAudio output with the {{ic|-ao pulse}} option. It can also be configured to default to PulseAudio output, in {{ic|~/.mplayer/config}} for per-user, or {{ic|/etc/mplayer/mplayer.conf}} for system-wide:<br />
{{hc|/etc/mplayer/mplayer.conf|2=ao=pulse}}<br />
<br />
=== guvcview ===<br />
<br />
{{Pkg|guvcview}} when using the PulseAudio input from a [[Webcam]] may have the audio input suspended resulting in no audio being recorded. You can check this by executing:<br />
<br />
$ pactl list sources<br />
<br />
If the audio source is "suspended" then modifying the following line in {{ic|/etc/pulse/default.pa}} and changing:<br />
<br />
load-module module-suspend-on-idle<br />
to<br />
#load-module module-suspend-on-idle<br />
<br />
And then either restarting PulseAudio or your computer will only idle the input source instead of suspending it. guvcview will then correctly record audio from the device.<br />
<br />
== Troubleshooting ==<br />
<br />
See [[PulseAudio/Troubleshooting]].<br />
<br />
== See also ==<br />
<br />
* [http://www.alsa-project.org/main/index.php/Asoundrc http://www.alsa-project.org/main/index.php/Asoundrc] - ALSA wiki on .asoundrc<br />
* [http://www.pulseaudio.org/ http://www.pulseaudio.org/] - PulseAudio official site<br />
* [http://www.pulseaudio.org/wiki/FAQ http://www.pulseaudio.org/wiki/FAQ] - PulseAudio FAQ</div>Chroniclinuxhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=160357Unified Extensible Firmware Interface2011-09-16T23:24:19Z<p>Chroniclinux: /* References */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
{{i18n|Unified Extensible Firmware Interface}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the Unified Extensible Firmware Interface.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GUID Partition Table}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short ) is a new type of firmware that was initially designed by Intel (as EFI) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 22 May 2010, UEFI Specification 2.3 is the most recent version.<br />
<br />
'''''Note: Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, the instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but includes features of both. This kind of firmware does not fall under any one UEFI version so it is not a standard EFI firmware.'''''<br />
<br />
== Booting an OS using BIOS ==<br />
<br />
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware are initialized and the POST operation is completed, the BIOS executes the first boot code in the first device in the device booting list. <br />
<br />
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.<br />
<br />
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.<br />
<br />
== Multi-booting using BIOS ==<br />
<br />
Since very little can be achieved by a program which fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like GRUB or LILO would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.<br />
<br />
== Booting an OS using UEFI ==<br />
<br />
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems. <br />
<br />
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to support Apple Partition Map also apart from MBR and GPT. Most of the UEFI firmwares have support for accessing FAT12 (floppy disks) , FAT16 and FAT32 filesystems in HDD and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called "EFI SYSTEM PARTITION" in which files required to be launched by the firmware is stored. Each vendor can store its files under <EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/ folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.<br />
<br />
Under UEFI, every program whether they are OS loaders or some utilities (like memory testing apps) or recovery tools outside the OS, should be a UEFI Application corresponding to the EFI firmware architecture. Most of the UEFI firmware in the market, including recent Apple Macs use x86_64 EFI firmware. Only some older macs use i386 EFI firmware while no non-Apple UEFI system is known to use i386 EFI firmware.<br />
<br />
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike the 64-bit Linux and Windows which include such support. Therefore the bootloader must be compiled for that architecture correctly.<br />
<br />
== Multi-booting using UEFI ==<br />
<br />
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without afffecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.<br />
<br />
== Multi-booting Linux on UEFI with Windows ==<br />
<br />
Windows Vista (SP1+) and 7 x64 versions support booting natively using UEFI firmware. But for this they need GPT partitioning of the HDD used for UEFI booting. Windows x64 versions support either UEFI-GPT booting or BIOS-MBR booting. Windows 32-bit versions support only BIOS-MBR booting. Follow the instructions provided in the forum link given in the references sections as to how to do this.<br />
<br />
This limitation does not exist in Linux as linux supports all 4 combinations of booting - UEFI-GPT, UEFI-MBR, BIOS-GPT, BIOS-MBR. If Linux and Windows are in the same HDD and boot using UEFI, then the linux bootloader must be configured to boot from GPT. This is a limitation of Windows, not Linux.<br />
<br />
== Linux Kernel Configuration for UEFI ==<br />
<br />
In case of linux, kernel support for EFI is very important. The required kernel configurations for UEFI systems are :<br />
<br />
Important UEFI related options -<br />
<br />
CONFIG_EFI=y<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
GUID Partition Table config option - very important for UEFI<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
UEFI Runtime Services Support - 'efivars' kernel module - optional but 'm' recommended since it can cause booting in some Sandy Bridge UEFI systems if compiled in the kernel image itself.<br />
<br />
CONFIG_EFI_VARS=m or y<br />
<br />
Retrieved from http://kernel.org/doc/Documentation/x86/x86_64/uefi.txt .<br />
<br />
Note 1: For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match. This is independent of the bootloader used and its compiled processor architecture.<br />
<br />
Note 2: If the UEFI Firmware arch and Linux Kernel arch are different, then the "'''noefi'''" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.<br />
<br />
Note 3: If you experience issues booting your UEFI system, such as rebooting or a black screen you may need to use Linux 3.0 or greater. Known systems this effects, all Dell laptops, all Apple after 2010, and some Lenovo, as well as some ASUS (E-350?). See 13 in references.<br />
<br />
== Linux Bootloaders for UEFI ==<br />
<br />
[[GRUB2]] - Follow instructions in the GRUB2 wiki page [https://wiki.archlinux.org/index.php/GRUB2#Bootloader_Installation_for_UEFI_systems link]. For bzr development version try AUR package - {{Package AUR|grub2-efi-bzr}}.<br />
<br />
[[GRUB-Legacy]] - Vanilla versions do not support UEFI, nor does Archlinux patched versions. Only Fedora's patched GRUB (efi-gpt patches from Intel) is known to support UEFI. [http://git.kernel.org/?p=boot/grub-fedora/grub-fedora.git;a=summary grub-fedora git repo]. AUR package - {{Package AUR|grub-legacy-efi-fedora}}.<br />
<br />
[http://sourceforge.net/projects/elilo/ ELILO] - LInux LOader for EFI - Still in development but at a slow pace. Config file similar to that of lilo. The only efi bootloader for Itaniun (IA64) systems. AUR package - {{Package AUR|elilo-git}}.<br />
<br />
[http://git.kernel.org/?p=boot/efilinux/efilinux.git;a=summary EFILINUX] - Reference Implementation of a x86_64 UEFI Linux Bootloader - Still in alpha phase. AUR package - {{Package AUR|efilinux-git}}.<br />
<br />
== Detecting UEFI Firmware Arch ==<br />
<br />
If you have a non-mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI 2.x firmware.<br />
<br />
Some of the known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio, Insyde H2O.<br />
<br />
Some of the known systems using these firmwares are Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, many Intel Server and Desktop motherboards<br />
<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.<br />
<br />
To find out the arch of the efi firmware in a Mac, boot into Mac OS X and type the following command<br />
<br />
<pre><br />
ioreg -l -p IODeviceTree | grep firmware-abi<br />
</pre><br />
<br />
If the command returns EFI32 the it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's efi implementation is not fully compliant with UEFI Specification.<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc. You can download a BSD licensed UEFI Shell from Intel's Tianocore EDK2 Sourceforge.net project.<br />
<br />
x86_64 UEFI Shell (Beta) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=ShellBinPkg/UefiShell/X64/Shell.efi;hb=HEAD<br />
<br />
x86_64 UEFI Shell (Old) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=EdkShellBinPkg/FullShell/X64/Shell_Full.efi;hb=HEAD<br />
<br />
i386 UEFI Shell (Beta) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=ShellBinPkg/UefiShell/Ia32/Shell.efi;hb=HEAD<br />
<br />
i386 UEFI Shell (Old) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi;hb=HEAD<br />
<br />
Use Beta Shell. If it does not work use Old shell. Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called '''''Launch EFI Shell from filesystem device''''' . For those motherboards, download the x86_64 UEFI Shell and copy it to you EFI SYSTEM PARTITION as '''''<EFI_SYSTEM_PARTITION>/shellx64.efi''''' (mostly '''/boot/efi/shellx64.efi''') .<br />
<br />
== Creating a EFI SYSTEM PARTITION in Linux ==<br />
<br />
'''''For MBR partitioned disks :'''''<br />
<br />
Create a 200 MB FAT32 partition using GNU Parted/GParted. Change the type code of that partition to 0xEF using fdisk, cfdisk or sfdisk.<br />
or<br />
Create a 200 MB partition using fdisk with partition type 0xEF and format it as FAT32 using '''mkfs.vfat -F32 /dev/<THAT_PARTITION>'''<br />
<br />
'''''For GPT partitioned disks :'''''<br />
<br />
Create a 200 MB FAT32 partition using GNU Parted/GParted. Set "boot" flag on for that partition.<br />
or<br />
Create a 200 MB partition using GPT fdisk (aka gdisk) with gdisk type code "EF00". Then format that partition as FAT32 using '''mkfs.vfat -F32 /dev/<THAT_PARTITION>'''<br />
<br />
'''Note 1:''' Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "EFI System Partition". <br />
<br />
'''Note 2:''' Do not use fdisk, cfdisk or sfdisk to change the type codes in a GPT disk. Do not use GPT fdisk on a MBR disk, it will be automatically converted to GPT (without data loss, but with boot failure).<br />
<br />
== References ==<br />
<br />
# Wikipedia's page on [http://en.wikipedia.org/wiki/UEFI UEFI]<br />
# Wikipedia's page on [http://en.wikipedia.org/wiki/EFI_System_partition EFI SYSTEM Partition]<br />
# Linux Kernel UEFI [http://kernel.org/doc/Documentation/x86/x86_64/uefi.txt Documentation]<br />
# [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
# [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
# [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
# [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
# [http://refit.sourceforge.net/ Homepage of rEFIt]<br />
# [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contains info on Windows UEFI booting also<br />
# [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
# [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
# [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
# [https://lkml.org/lkml/2011/6/8/322 EFI Boot problems on some newer machines(LKML)]</div>Chroniclinuxhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=160355Unified Extensible Firmware Interface2011-09-16T23:22:36Z<p>Chroniclinux: /* Linux Kernel Configuration for UEFI */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
{{i18n|Unified Extensible Firmware Interface}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the Unified Extensible Firmware Interface.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GUID Partition Table}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short ) is a new type of firmware that was initially designed by Intel (as EFI) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 22 May 2010, UEFI Specification 2.3 is the most recent version.<br />
<br />
'''''Note: Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, the instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but includes features of both. This kind of firmware does not fall under any one UEFI version so it is not a standard EFI firmware.'''''<br />
<br />
== Booting an OS using BIOS ==<br />
<br />
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware are initialized and the POST operation is completed, the BIOS executes the first boot code in the first device in the device booting list. <br />
<br />
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.<br />
<br />
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.<br />
<br />
== Multi-booting using BIOS ==<br />
<br />
Since very little can be achieved by a program which fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like GRUB or LILO would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.<br />
<br />
== Booting an OS using UEFI ==<br />
<br />
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems. <br />
<br />
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to support Apple Partition Map also apart from MBR and GPT. Most of the UEFI firmwares have support for accessing FAT12 (floppy disks) , FAT16 and FAT32 filesystems in HDD and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called "EFI SYSTEM PARTITION" in which files required to be launched by the firmware is stored. Each vendor can store its files under <EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/ folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.<br />
<br />
Under UEFI, every program whether they are OS loaders or some utilities (like memory testing apps) or recovery tools outside the OS, should be a UEFI Application corresponding to the EFI firmware architecture. Most of the UEFI firmware in the market, including recent Apple Macs use x86_64 EFI firmware. Only some older macs use i386 EFI firmware while no non-Apple UEFI system is known to use i386 EFI firmware.<br />
<br />
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike the 64-bit Linux and Windows which include such support. Therefore the bootloader must be compiled for that architecture correctly.<br />
<br />
== Multi-booting using UEFI ==<br />
<br />
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without afffecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.<br />
<br />
== Multi-booting Linux on UEFI with Windows ==<br />
<br />
Windows Vista (SP1+) and 7 x64 versions support booting natively using UEFI firmware. But for this they need GPT partitioning of the HDD used for UEFI booting. Windows x64 versions support either UEFI-GPT booting or BIOS-MBR booting. Windows 32-bit versions support only BIOS-MBR booting. Follow the instructions provided in the forum link given in the references sections as to how to do this.<br />
<br />
This limitation does not exist in Linux as linux supports all 4 combinations of booting - UEFI-GPT, UEFI-MBR, BIOS-GPT, BIOS-MBR. If Linux and Windows are in the same HDD and boot using UEFI, then the linux bootloader must be configured to boot from GPT. This is a limitation of Windows, not Linux.<br />
<br />
== Linux Kernel Configuration for UEFI ==<br />
<br />
In case of linux, kernel support for EFI is very important. The required kernel configurations for UEFI systems are :<br />
<br />
Important UEFI related options -<br />
<br />
CONFIG_EFI=y<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
GUID Partition Table config option - very important for UEFI<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
UEFI Runtime Services Support - 'efivars' kernel module - optional but 'm' recommended since it can cause booting in some Sandy Bridge UEFI systems if compiled in the kernel image itself.<br />
<br />
CONFIG_EFI_VARS=m or y<br />
<br />
Retrieved from http://kernel.org/doc/Documentation/x86/x86_64/uefi.txt .<br />
<br />
Note 1: For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match. This is independent of the bootloader used and its compiled processor architecture.<br />
<br />
Note 2: If the UEFI Firmware arch and Linux Kernel arch are different, then the "'''noefi'''" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.<br />
<br />
Note 3: If you experience issues booting your UEFI system, such as rebooting or a black screen you may need to use Linux 3.0 or greater. Known systems this effects, all Dell laptops, all Apple after 2010, and some Lenovo, as well as some ASUS (E-350?). See 13 in references.<br />
<br />
== Linux Bootloaders for UEFI ==<br />
<br />
[[GRUB2]] - Follow instructions in the GRUB2 wiki page [https://wiki.archlinux.org/index.php/GRUB2#Bootloader_Installation_for_UEFI_systems link]. For bzr development version try AUR package - {{Package AUR|grub2-efi-bzr}}.<br />
<br />
[[GRUB-Legacy]] - Vanilla versions do not support UEFI, nor does Archlinux patched versions. Only Fedora's patched GRUB (efi-gpt patches from Intel) is known to support UEFI. [http://git.kernel.org/?p=boot/grub-fedora/grub-fedora.git;a=summary grub-fedora git repo]. AUR package - {{Package AUR|grub-legacy-efi-fedora}}.<br />
<br />
[http://sourceforge.net/projects/elilo/ ELILO] - LInux LOader for EFI - Still in development but at a slow pace. Config file similar to that of lilo. The only efi bootloader for Itaniun (IA64) systems. AUR package - {{Package AUR|elilo-git}}.<br />
<br />
[http://git.kernel.org/?p=boot/efilinux/efilinux.git;a=summary EFILINUX] - Reference Implementation of a x86_64 UEFI Linux Bootloader - Still in alpha phase. AUR package - {{Package AUR|efilinux-git}}.<br />
<br />
== Detecting UEFI Firmware Arch ==<br />
<br />
If you have a non-mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI 2.x firmware.<br />
<br />
Some of the known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio, Insyde H2O.<br />
<br />
Some of the known systems using these firmwares are Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, many Intel Server and Desktop motherboards<br />
<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.<br />
<br />
To find out the arch of the efi firmware in a Mac, boot into Mac OS X and type the following command<br />
<br />
<pre><br />
ioreg -l -p IODeviceTree | grep firmware-abi<br />
</pre><br />
<br />
If the command returns EFI32 the it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's efi implementation is not fully compliant with UEFI Specification.<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc. You can download a BSD licensed UEFI Shell from Intel's Tianocore EDK2 Sourceforge.net project.<br />
<br />
x86_64 UEFI Shell (Beta) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=ShellBinPkg/UefiShell/X64/Shell.efi;hb=HEAD<br />
<br />
x86_64 UEFI Shell (Old) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=EdkShellBinPkg/FullShell/X64/Shell_Full.efi;hb=HEAD<br />
<br />
i386 UEFI Shell (Beta) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=ShellBinPkg/UefiShell/Ia32/Shell.efi;hb=HEAD<br />
<br />
i386 UEFI Shell (Old) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi;hb=HEAD<br />
<br />
Use Beta Shell. If it does not work use Old shell. Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called '''''Launch EFI Shell from filesystem device''''' . For those motherboards, download the x86_64 UEFI Shell and copy it to you EFI SYSTEM PARTITION as '''''<EFI_SYSTEM_PARTITION>/shellx64.efi''''' (mostly '''/boot/efi/shellx64.efi''') .<br />
<br />
== Creating a EFI SYSTEM PARTITION in Linux ==<br />
<br />
'''''For MBR partitioned disks :'''''<br />
<br />
Create a 200 MB FAT32 partition using GNU Parted/GParted. Change the type code of that partition to 0xEF using fdisk, cfdisk or sfdisk.<br />
or<br />
Create a 200 MB partition using fdisk with partition type 0xEF and format it as FAT32 using '''mkfs.vfat -F32 /dev/<THAT_PARTITION>'''<br />
<br />
'''''For GPT partitioned disks :'''''<br />
<br />
Create a 200 MB FAT32 partition using GNU Parted/GParted. Set "boot" flag on for that partition.<br />
or<br />
Create a 200 MB partition using GPT fdisk (aka gdisk) with gdisk type code "EF00". Then format that partition as FAT32 using '''mkfs.vfat -F32 /dev/<THAT_PARTITION>'''<br />
<br />
'''Note 1:''' Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "EFI System Partition". <br />
<br />
'''Note 2:''' Do not use fdisk, cfdisk or sfdisk to change the type codes in a GPT disk. Do not use GPT fdisk on a MBR disk, it will be automatically converted to GPT (without data loss, but with boot failure).<br />
<br />
== References ==<br />
<br />
# Wikipedia's page on [http://en.wikipedia.org/wiki/UEFI UEFI]<br />
# Wikipedia's page on [http://en.wikipedia.org/wiki/EFI_System_partition EFI SYSTEM Partition]<br />
# Linux Kernel UEFI [http://kernel.org/doc/Documentation/x86/x86_64/uefi.txt Documentation]<br />
# [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
# [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
# [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
# [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
# [http://refit.sourceforge.net/ Homepage of rEFIt]<br />
# [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contains info on Windows UEFI booting also<br />
# [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
# [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
# [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]</div>Chroniclinuxhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=160354Unified Extensible Firmware Interface2011-09-16T23:22:25Z<p>Chroniclinux: /* Linux Kernel Configuration for UEFI */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
{{i18n|Unified Extensible Firmware Interface}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the Unified Extensible Firmware Interface.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GUID Partition Table}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short ) is a new type of firmware that was initially designed by Intel (as EFI) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 22 May 2010, UEFI Specification 2.3 is the most recent version.<br />
<br />
'''''Note: Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, the instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but includes features of both. This kind of firmware does not fall under any one UEFI version so it is not a standard EFI firmware.'''''<br />
<br />
== Booting an OS using BIOS ==<br />
<br />
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware are initialized and the POST operation is completed, the BIOS executes the first boot code in the first device in the device booting list. <br />
<br />
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.<br />
<br />
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.<br />
<br />
== Multi-booting using BIOS ==<br />
<br />
Since very little can be achieved by a program which fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like GRUB or LILO would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.<br />
<br />
== Booting an OS using UEFI ==<br />
<br />
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems. <br />
<br />
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to support Apple Partition Map also apart from MBR and GPT. Most of the UEFI firmwares have support for accessing FAT12 (floppy disks) , FAT16 and FAT32 filesystems in HDD and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called "EFI SYSTEM PARTITION" in which files required to be launched by the firmware is stored. Each vendor can store its files under <EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/ folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.<br />
<br />
Under UEFI, every program whether they are OS loaders or some utilities (like memory testing apps) or recovery tools outside the OS, should be a UEFI Application corresponding to the EFI firmware architecture. Most of the UEFI firmware in the market, including recent Apple Macs use x86_64 EFI firmware. Only some older macs use i386 EFI firmware while no non-Apple UEFI system is known to use i386 EFI firmware.<br />
<br />
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike the 64-bit Linux and Windows which include such support. Therefore the bootloader must be compiled for that architecture correctly.<br />
<br />
== Multi-booting using UEFI ==<br />
<br />
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without afffecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.<br />
<br />
== Multi-booting Linux on UEFI with Windows ==<br />
<br />
Windows Vista (SP1+) and 7 x64 versions support booting natively using UEFI firmware. But for this they need GPT partitioning of the HDD used for UEFI booting. Windows x64 versions support either UEFI-GPT booting or BIOS-MBR booting. Windows 32-bit versions support only BIOS-MBR booting. Follow the instructions provided in the forum link given in the references sections as to how to do this.<br />
<br />
This limitation does not exist in Linux as linux supports all 4 combinations of booting - UEFI-GPT, UEFI-MBR, BIOS-GPT, BIOS-MBR. If Linux and Windows are in the same HDD and boot using UEFI, then the linux bootloader must be configured to boot from GPT. This is a limitation of Windows, not Linux.<br />
<br />
== Linux Kernel Configuration for UEFI ==<br />
<br />
In case of linux, kernel support for EFI is very important. The required kernel configurations for UEFI systems are :<br />
<br />
Important UEFI related options -<br />
<br />
CONFIG_EFI=y<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
GUID Partition Table config option - very important for UEFI<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
UEFI Runtime Services Support - 'efivars' kernel module - optional but 'm' recommended since it can cause booting in some Sandy Bridge UEFI systems if compiled in the kernel image itself.<br />
<br />
CONFIG_EFI_VARS=m or y<br />
<br />
Retrieved from http://kernel.org/doc/Documentation/x86/x86_64/uefi.txt .<br />
<br />
Note 1: For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match. This is independent of the bootloader used and its compiled processor architecture.<br />
<br />
Note 2: If the UEFI Firmware arch and Linux Kernel arch are different, then the "'''noefi'''" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.<br />
<br />
NOte 3: If you experience issues booting your UEFI system, such as rebooting or a black screen you may need to use Linux 3.0 or greater. Known systems this effects, all Dell laptops, all Apple after 2010, and some Lenovo, as well as some ASUS (E-350?). See 13 in references.<br />
<br />
== Linux Bootloaders for UEFI ==<br />
<br />
[[GRUB2]] - Follow instructions in the GRUB2 wiki page [https://wiki.archlinux.org/index.php/GRUB2#Bootloader_Installation_for_UEFI_systems link]. For bzr development version try AUR package - {{Package AUR|grub2-efi-bzr}}.<br />
<br />
[[GRUB-Legacy]] - Vanilla versions do not support UEFI, nor does Archlinux patched versions. Only Fedora's patched GRUB (efi-gpt patches from Intel) is known to support UEFI. [http://git.kernel.org/?p=boot/grub-fedora/grub-fedora.git;a=summary grub-fedora git repo]. AUR package - {{Package AUR|grub-legacy-efi-fedora}}.<br />
<br />
[http://sourceforge.net/projects/elilo/ ELILO] - LInux LOader for EFI - Still in development but at a slow pace. Config file similar to that of lilo. The only efi bootloader for Itaniun (IA64) systems. AUR package - {{Package AUR|elilo-git}}.<br />
<br />
[http://git.kernel.org/?p=boot/efilinux/efilinux.git;a=summary EFILINUX] - Reference Implementation of a x86_64 UEFI Linux Bootloader - Still in alpha phase. AUR package - {{Package AUR|efilinux-git}}.<br />
<br />
== Detecting UEFI Firmware Arch ==<br />
<br />
If you have a non-mac UEFI system, then you have a x86_64 (aka 64-bit) UEFI 2.x firmware.<br />
<br />
Some of the known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio, Insyde H2O.<br />
<br />
Some of the known systems using these firmwares are Asus EZ Mode BIOS (in Sandy Bridge P67 and H67 motherboards), MSI ClickBIOS, HP EliteBooks, Sony Vaio Z series, many Intel Server and Desktop motherboards<br />
<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.<br />
<br />
To find out the arch of the efi firmware in a Mac, boot into Mac OS X and type the following command<br />
<br />
<pre><br />
ioreg -l -p IODeviceTree | grep firmware-abi<br />
</pre><br />
<br />
If the command returns EFI32 the it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's efi implementation is not fully compliant with UEFI Specification.<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc. You can download a BSD licensed UEFI Shell from Intel's Tianocore EDK2 Sourceforge.net project.<br />
<br />
x86_64 UEFI Shell (Beta) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=ShellBinPkg/UefiShell/X64/Shell.efi;hb=HEAD<br />
<br />
x86_64 UEFI Shell (Old) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=EdkShellBinPkg/FullShell/X64/Shell_Full.efi;hb=HEAD<br />
<br />
i386 UEFI Shell (Beta) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=ShellBinPkg/UefiShell/Ia32/Shell.efi;hb=HEAD<br />
<br />
i386 UEFI Shell (Old) - http://tianocore.git.sourceforge.net/git/gitweb.cgi?p=tianocore/edk2;a=blob_plain;f=EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi;hb=HEAD<br />
<br />
Use Beta Shell. If it does not work use Old shell. Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called '''''Launch EFI Shell from filesystem device''''' . For those motherboards, download the x86_64 UEFI Shell and copy it to you EFI SYSTEM PARTITION as '''''<EFI_SYSTEM_PARTITION>/shellx64.efi''''' (mostly '''/boot/efi/shellx64.efi''') .<br />
<br />
== Creating a EFI SYSTEM PARTITION in Linux ==<br />
<br />
'''''For MBR partitioned disks :'''''<br />
<br />
Create a 200 MB FAT32 partition using GNU Parted/GParted. Change the type code of that partition to 0xEF using fdisk, cfdisk or sfdisk.<br />
or<br />
Create a 200 MB partition using fdisk with partition type 0xEF and format it as FAT32 using '''mkfs.vfat -F32 /dev/<THAT_PARTITION>'''<br />
<br />
'''''For GPT partitioned disks :'''''<br />
<br />
Create a 200 MB FAT32 partition using GNU Parted/GParted. Set "boot" flag on for that partition.<br />
or<br />
Create a 200 MB partition using GPT fdisk (aka gdisk) with gdisk type code "EF00". Then format that partition as FAT32 using '''mkfs.vfat -F32 /dev/<THAT_PARTITION>'''<br />
<br />
'''Note 1:''' Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "EFI System Partition". <br />
<br />
'''Note 2:''' Do not use fdisk, cfdisk or sfdisk to change the type codes in a GPT disk. Do not use GPT fdisk on a MBR disk, it will be automatically converted to GPT (without data loss, but with boot failure).<br />
<br />
== References ==<br />
<br />
# Wikipedia's page on [http://en.wikipedia.org/wiki/UEFI UEFI]<br />
# Wikipedia's page on [http://en.wikipedia.org/wiki/EFI_System_partition EFI SYSTEM Partition]<br />
# Linux Kernel UEFI [http://kernel.org/doc/Documentation/x86/x86_64/uefi.txt Documentation]<br />
# [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
# [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
# [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
# [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
# [http://refit.sourceforge.net/ Homepage of rEFIt]<br />
# [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contains info on Windows UEFI booting also<br />
# [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
# [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
# [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]</div>Chroniclinux