For some time Fedora releases have supported UEFI (more commonly known as EFI) booting on X86-64 platforms. Having some experience of using EFI on IA64 platforms over the years, I decided to test out EFI booting Fedora 12 on one of my systems has built-in support for UEFI booting. This post details my experience.
|
|
|||||||||||||||||||||||
    |
UEFI is a follow on to the original EFI specification developed by Intel in the late 1990s. Until recently, UEFI was restricted to high-end servers but is now becoming more commonplace on commodity servers and desktops. Fedora 12 can be booted using UEFI. In this post, I describe how to access and list the UEFI globally defined variables that Fedora 12 is aware of. The aim of the Plymouth project is to answer the oft-stated user requirement that their computer startup be flicker-free, seamless, shiny and logged. In this post I examine the current state of the project and show you how to customize your startup and shutdown experience. IA-PC HPET (High Precision Event Timer) is a specification which was jointly developed by Intel and Microsoft in the early part of this decade.. The latest version is dated October 2004. It’s stated purpose is to initially supplement and eventually replace the legacy 8254 Programmable Interval Timer and the Real Time Clock Periodic Interrupt generation functions that are currently used as the ‘de-facto’ timer hardware for IA-PCs. The HPET architecture defines a set of timers that can be used by the operating system. A timer block is a combination of a single counter and up to 32 comparators and match registers. The comparator compares the contents of the match register against the value of a free running monotonic up-counter. When the output of the up-counter equals the value in the match register an interrupt is generated. Each of the comparators can output an interrupt. A maximum of 8 timer blocks are supported for a total of 256 timers. Each timer block can have different clocking attributes. Specific implementations may include only a subset of these timers. A minimum of three timers is required. The specification contains the following block diagram of the HPET architecture. Some of the timers may be enabled to generate a periodic interrupt. If a timer is set to be periodic, its period is added to the match register each time a match occurs, thus computing the next time for this timer to generate an interrupt.. An up-counter is usually 64 bits wide but 32-bit implementations are permitted by the specification and 64-bit up-counters can also be driven in 32-bit mode. Up-counters run at a minimum of 10 MHz. which is much faster than the older RTC (Real Time Clock) and can thus produce periodic interrupts at a much higher resolution. The registers associated with these timers are mapped to memory space. The BIOS uses ACPI ( Advanced Configuration and Power Interface) functionality to inform the operating system of the location of the HPET memory-mapped register space. Here is an example of a disassembled ACPI HPET table from an Intel DX48BT2 (AKA BoneTrail) motherboard. $ cat /sys/firmware/acpi/tables/HPET > /var/tmp/hpet.out $ iasl -d /var/tmp/hpet.out $ cat /var/tmp/hpet.dsl /* * Intel ACPI Component Architecture * AML Disassembler version 20090123 * * Disassembly of /var/tmp/hpet.out, Sun Jul 5 19:34:47 2009 * * ACPI Data Table [HPET] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h I am experimenting with XAM (eXtensible Access Method), which is a storage standard developed by SNIA (Storage Networking Industry Association and have developed a first prototype of a VIM (Vendor Interface Module) for the ext4 file system based on adding another namespace to the current extended file attributes support. Since other Linux developers might be interested in how to add an extended attributes namespace to a file system, I decided to publish this post as a guide. Extended file attributes (EA) are extensions to the normal attributes which are associated with inodes in a file system. They are simply name:value pairs associated with files and directories and whose purpose is to provide additional functionality which is either defined by the operating system or a user application. An EA may be defined or undefined. If an EA is defined, its value may be empty or non-empty. Most of the initial work to support EAs in Linux was done by Andreas Gruenbacher in the 2001 to 2004 timeframe and is based on work done in the SGI XFS file system. EAs are stored directly in inodes and on additional disk blocks if necessary. Currently all EAs associated with a file must fit in an inode and one additional block. Blocks that contain the identical set of EAs may be shared among several inodes. EAs in inodes and on blocks have a different header followed by multiple entry descriptors. Entry descriptors are sorted in disk blocks but are left unsorted in inodes. EA names are zero-terminated strings and are always specified using a fully qualified namespace.attribute e.g. system.posix_acl_access or security.selinux. Namespaces are used to define different classes of EAs. Different EA classes are required because the permissions and capabilities required for manipulating EAs in one namespace may differ from one to another. Currently Linux supports EA namespaces for SELinux (security.), system (system.), trusted (trusted.) and user (user.). Fedora 11 comes with EA support in the Linux kernel and hence it is the kernel which must be modified in order to add another EA namespace. In my case I wanted to add an EA namespace called snia in order to support XAM XSet metadata (see below). Here is the patch file for the Fedora 11 2.6.29.4-167.fc11 kernel which implements the snia namespace. It should work for both 32-bit and 64-bit kernels but I have only tested it on a 64-bit kernel. diff |
||||||||||||||||||||||
|
Copyright © 2005-2012 Finnbarr P. Murphy. All Rights Reserved. |
|||||||||||||||||||||||