PC Construction

"Copy" doesn't really fit. I agree "configure" works, but I'm trying to dissect the brain of the twit that wrote "conp".

Here's a quote from another article on UEFI:
https://phoenixts.com/blog/uefi-vs-legacy-bios/ said:
The next improvement implemented by UEFI has to do with the type of code it uses. UEFI uses C-language. This form of coding is much more simplistic than assembler, which is the type of language that legacy systems require.
Click to expand...

That author needs to look up what "simplistic" means.
 
https://phoenixts.com/blog/uefi-vs-legacy-bios/ said:
The next improvement implemented by UEFI has to do with the type of code it uses. UEFI uses C-language. This form of coding is much more simplistic than assembler, which is the type of language that legacy systems require.
Click to expand...
:disagree: In my opinion the quote as a whole is BS. The code might be easier to maintain because it is written in C. No system requires assembler. It requires some form of machine code. That machine code could be obtained by assembling and linking an assembler source or compiling and linking a suitable higher level language (eg. C) providing you can access low level devices. What's the betting that the C source has to be linked against assembler written device routines?
 
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ said:
You’ve probably read a lot of stuff on the internet about UEFI. Here is something important you should understand: 95% of it was probably garbage. If you think you know about UEFI, and you derived your knowledge anywhere other than the UEFI specifications, mjg59’s blog or one of a few other vaguely reliable locations/people – Rod Smith, or Peter Jones, or Chris Murphy, or the documentation of the relatively few OSes whose developers actually know what the hell they’re doing with UEFI – what you think you know is likely a toxic mix of misunderstandings, misconceptions, half-truths, propaganda and downright lies. So you should probably forget it all.
Click to expand...
 
The blog post quoted above is a very readable intro to the technicalities, and I count myself lucky* to have stumbled across it. Recommended for anyone interested in UEFI.

https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/

https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ said:
Most of the unhappiness about Secure Boot is not really about Secure Boot the mechanism – whether the people expressing that unhappiness think it is or not – but about specific implementations of Secure Boot in the real world.

The only one we really care about is Secure Boot as it’s implemented on PCs shipped with Microsoft Windows 8 or higher pre-installed...

Computers complying with the requirements must:
  • Ship with Secure Boot turned on (except for servers)
  • Have Microsoft’s key in the list of keys they trust
  • Disable BIOS compatibility mode when Secure Boot is enabled (actually the UEFI spec requires this too, if I read it correctly)
  • Support signature blacklisting
x86 computers complying with the requirements must additionally:
  • Allow a physically present person to disable Secure Boot
  • Allow a physically present person to enable Custom Mode, and modify the list of keys the firmware trusts
ARM computers complying with the requirements must additionally:
  • NOT allow a physically present person to disable Secure Boot
  • NOT allow a physically present person to enable Custom Mode, and modify the list of keys the firmware trusts
Yes. You read that correctly. The Microsoft certification requirements, for x86 machines, explicitly require implementers to give a physically present user complete control over Secure Boot – turn it off, or completely control the list of keys it trusts...

Now, for ARM machines, the requirements are significantly more evil: they state exactly the opposite, that it must not be possible to disable Secure Boot and it must not be possible for the system owner to change the trusted keys. This is bad and wrong. It makes Microsoft-certified ARM systems into a closed shop. But it’s worth noting it’s no more bad or wrong than most other major ARM platforms. Apple locks down the bootloader on all iDevices, and most Android devices also ship with locked bootloaders.

If you’re planning to buy a Microsoft-certified ARM device, be aware of this, and be aware that you will not be in control of what you can boot on it.
Click to expand...

* Update: not any more. This lead me down too many blind alleys, although I have learned a lot as a result.
 
Last edited:
Hmm... tyranny of choice.

Do I struggle and become an "expert" on UEFI, or do I take the pragmatic approach of "down-grading" to legacy boot?

At least (with legacy boot) I would be certain which device I'm booting from! I am annoyed that the boot order is not hard-and-fast user-defined in UEFI and gets updated whenever it feels inclined (by some install process - or even the boot process itself - writing to the boot config file).
 
Yes, I'm pissed off with that as well BH. Although I am talking Windows, I used to be able to have two bootable SSDs hung off it and able to select which one to boot from in the BIOS. However, I can't find an easy wau of doing this under UEFI as the only option that I get is "Windows boot manager". The boot drive is obviously set within that, but I haven't yet found a way of altering it. The second bootable drive is a backup boot drive in case of primary failure and cloning primary to backup now and again was the insurance policy. ATM, I can achieve what I want by opening the case and swapping the drives (The backup is not now permanently connected as it was under BIOS)
 
Trev said:
ATM, I can achieve what I want by opening the case and swapping the drives
Click to expand...
That's the approach I have taken the last couple of days - disconnect the SATA to the drive I don't want to boot! Forcing a live Linux DVD to boot in the optical drive involves entering the BIOS (sorry - UEFI firmware) at boot and specifically selecting to boot it from the boot override menu.
 
What I don't understand is whether the Windows boot options accessed via the W10 OS are then in the UEFI or on the boot disk as it appears to be the disk that is modified. But I suppose this must be written to the UEFI or how the hell does it know whether to boot to drive A (main) or drive B(backup) and how do you switch the boot to drive B if drive A has failed?
Suppose I had better disconnect drive A and see what happens.
 
Trev said:
What I don't understand is whether the Windows boot options accessed via the W10 OS are then in the UEFI or on the boot disk
Click to expand...
My brief reading of the reference above indicates the UEFI motherboard firmware passes control to the first device it finds with a valid boot configuration file on an EFI partition. What happens after that is entirely dependent on what the script in the configuration file says.
 
I read the same article as well BH. But I still could not sort the answer.
OK, I'm going to have a play now. I'll be back (If ever my computer works again.
 
As suspected.
In turn:
Both A and B connected = Boots to A
Only B connected = Boots to B (as suspected it would)
Both A and B connected = Boots to B (last boot drive)
Only A connected = Boots to A
So. I'll just leave B disconnected until either I need it or for cloning onto purposes and not bother trying to establish the innermost workings of UEFI
 
FWIW, being a bit lot nerdy about publishing (and having time on my hands), I have edited up a "print friendly" version of the UEFI article from post 286 (compete with selected highlights from all four pages of the ensuing discussion) and uploaded it as a PDF to my dropbox.

If printing it out, I recommend only printing the first 16 pages, and setting the print options to "shrink to printable area" (that's because I used the iPad's ability to convert web pages directly to PDF).

 
Explanatory Glossary to the Above

As is normal for technical articles, the author expects a degree of prior knowledge and not to have to explain technical terms. The aim here is to reduce the level of prior knowledge required by at least explaining the acronyms.

ARM
Advanced Research Machines - the (British) company which developed the computer processor architecture now known as just "ARM". The ARM architecture is a competitor to x86, and software for one cannot run on the other (except via an emulation layer, which is naturally slower than running native software directly). ARM is RISC (Reduced Instruction Set Computing), which means it uses simple operations which execute very fast (and complex instructions have to be compiled into a series of simple instructions).​
​
ARM processors (or derivatives) are almost universal in the manufacture of smart phones and tablets, and modern Macs. See also "x86".​

BIOS
Basic Input/Output System - firmware provided on a (IBM-style, legacy) PC motherboard to interface the hardware peripherals with higher level software (ie operating system) via an abstraction layer. This was so that the hardware was free to vary in implementation but still present a uniform interface to the software (compensated for in the BIOS firmware). However, as the PC evolved, the hardware implementation converged on one or a few solutions, and execution via the BIOS abstraction layer became a bottleneck, so more recent OSes bypass the BIOS layer and access the hardware directly with their own high-performance device drivers.​
​
Nonetheless, the BIOS is the only code which can execute at power up, because everything else has to be loaded from some storage device or other, into memory, before execution can be transferred to it. Consequently, despite the OS having little (or no) use for it once the OS is running, the BIOS is responsible for POST (power-on self test), orchestrating the boot process, and accessing hardware during the boot process, and despite the BIOS providing a (redundant) abstraction layer to the hardware it has become known only for its role in the boot process.​
​
Because PCs evolved from the original IBM design, with other manufacturers producing similar (but not identical) copies so as to cash in on the software being produced for the IBM PC architecture, and the original IBM BIOS being proprietary, other manufacturers had to come up with their own versions of BIOS without definitive knowledge of the IBM specification (if there ever was a formal specification). Consequently, although they all do similar things (including the boot process), they are not necessarily identical (ie standardised) in the fine detail.​
​
Despite UEFI replacing the BIOS boot process, motherboards with UEFI firmware still have some kind of BIOS, because it is still necessary to run POST and it is still necessary for UEFI to access the hardware in the process of booting (without the aid of software loaded later in the boot process).​

CD
Compact Disc, but used to refer to any optical media or optical drive, such as DVD-ROM or Blu-ray MDisc.​

CSM
Compatibility Support Module - the section of a UEFI implementation used to support the legacy BIOS method of booting a PC.​

EFI
Extensible Firmware Interface, originally developed by Intel and standardised as UEFI.​
​
ESP
EFI System Partition - the partition on a HDD (or other storage media) dedicated to holding boot information for UEFI.​

FAT, FAT12, FAT16, FAT32
File Allocation Table - the file system implemented by the original MS-DOS and Microsoft Windows. The particular type of FAT (12, 16, or 32) is characterised by the number of binary bits allocated to storing the indexes to file system resources; small HDDs only need a few bits and storing more than necessary occupies too great a percentage of the available resources.​
​
However, even FAT32 is limited to 4GiB files, so alternatives include NTFS (Microsoft) and Ext (Linux/UNIX).​
​
FAT is specified for the ESP.​

GiB, TiB
Gigabytes, Terabytes (measures of file size or storage capacity). The traditional GB and TB are ambiguous: computer scientists regard 1 GB as 2^30 = 1,073,741,824 bytes and 1 TB as 2^40 = 1,099,511,627,776 bytes, whereas in other spheres "Giga" means x 10^9 and "Tera" means x 10^12. HDD manufacturers have exploited this ambiguity by (for example) advertising drives of 1,000,000,000,000 bytes capacity as "1TB", which is 10% smaller than a computer-science 1TB.​
​
To avoid this ambiguity, KiB (Kibibyte), MiB (Mebibyte), GiB (Gibibyte), and TiB (Tebibyte) have been coined to unambiguously mean 2^10, 2^20, 2^30, and 2^40 bytes respectively.​

GPG
GNU Privacy Guard - an open-source replacement for the popular (and proprietary) PGP encryption and cryptographic signature software.​

GPT
GUID Partition Table - a method for declaring the logical structure of HDDs (or other storage media), as an alternative to MBR (and without the 2TiB limitation of MBR). GPT may include an MBR to support the legacy BIOS boot process, but alternative boot processes (notably UEFI) do not need a MBR and instead use the GPT indexing to refer to a disk partition for the boot loader (thus avoiding the size constraints on an MBR boot loader). See also "MBR", "UEFI".​

GUID
Globally Unique Identifier - a scheme intended to provide a unique numerical indentifier for every resource on the planet. Also UUID (Universally Unique Identifier).​

HDD
Hard Disk Drive​

IBM
International Business Machines, the originators of the desktop personal computer which became the ubiquitous PC.​

Mac
Short for "Apple Macintosh", a personal computer with an alternative architecture and software to the IBM PC, made by Apple. IBM PC operating systems and software are not (directly) compatible with Macs, and vice versa.​

MBR
Master Boot Record. Under the MBR scheme the first few sectors (storage locations) of an HDD are defined as containing a boot loader and a partition table. The boot loader is software which the BIOS boot process transfers control to, and which (unlike the BIOS boot process) can be set up to suit the OS when the OS is installed. The boot loader is then responsible for continuing the boot process, ultimately passing control to the OS. The partition table is used to index the logical structure of the physical HDD, subdividing it into up to 4 partitions and declaring their properties (including the ability to subdivide partitions into logical partitions). However, because of the limitations of the MBR partitioning scheme, MBR can only cope with drives up to 2TiB - so the capacity of modern HDDs has outgrown the capability of MBR. See also "GPT".​

MS-DOS
Microsoft Disc Operating System. This was the first OS for the original IBM PC (as PC-DOS), supported by the BIOS and the MBR to boot it up. Consequently, because MS-DOS was contingent on the MBR scheme, "MS-DOS format" or "DOS format" is frequently (incorrectly) used as a synonym for "MBR".​

NVRAM
Non-Volatile Random Access Memory - the storage medium for BIOS and boot code on a PC motherboard, with configuration options accessible through a dedicated user interface by interrupting the boot process at power-up. The whole NVRAM contents can usually only be updated by a specific motherboard firmware update process, also accessible from the dedicated user interface. Some OS utilities and OS installation processes might also have access to the configuration options.​

OS
Operating System - the layer of software which provides the user interface to application software, and handles all the nitty-gritty of file systems, networking, printing, etc etc so that the application software can ignore all that and concentrate on what it is supposed to do. Examples of modern OSes include:​
Fedora (a version of Linux)​
openSUSE (a version of Linux)​
Microsoft Windows​
MacOS (a version of Unix for Macs)​

PC
Personal Computer, usually referring specifically to the IBM PC (and compatibles) as opposed to an Apple Mac or any other type of personal computer not using the x86 IBM PC architecture.​

PXE
Pre-boot eXecution Environment ("pixie"). This enables the boot process to refer to resources over a network, and thus boot a computer without installing an OS locally or use the boot process to install a local OS from networked resources.​

TiB
See "GiB".​

UEFI
Universal Extensible Firmware Interface - a set of formal standards for handling the hand-over from the motherboard hardware/firmware boot process to a boot loader, and the subject of the article. The standards include the ability to use the de facto MBR method, but also provide a framework for alternatives not limited by the constraints on MBR. MBR limitations resulted in many proprietary work-arounds, without any standardisation.​

UI
User Interface.​

x86, x86-32, x86-64
"x86" is a general reference to the range of microprocessors pioneered by Intel with the 8086, and chosen by IBM for the original PC. Consequently, MS-DOS and Microsoft Windows (and a vast quantity of application software) was written specifically for the x86 instruction set, and subsequent PCs with faster processors had to be compatible with that same instruction set. The 8086 was developed into the 80186, then 80286 and 80386 etc. Intel also make processors with other architectures, but the x86 architecture remains the core of the PC.​
​
The x86 architecture is a competitor to ARM, and software for one cannot run on the other (except via an emulation layer, which is naturally slower than running native software directly). x86 is CISC (Complex Instruction Set Computing), which means it implements complex operations directly, slower than individual instructions in a RISC (Reduced Instruction Set Computing) processor but having to execute fewer of them for the same effect.​
​
The original 8086 used 16-bit data registers. x86-32 and x86-64 refer to processors with 32-bit and 64-bit registers respectively. A processor with 32-bit registers has to break calculations down into more steps by only being able to handle 32 bits at a time, than would a 64-bit processor able to handle 64 bits at a time, so a x86-64 is faster than x86-32 but an x86-32 is cheaper to make than an x86-64. However, software has to be tweaked to take advantage of 64 bits, which is why there are different versions of Windows for x86-32 and x86-64.​
 
Last edited:
I bloody give up. The SSD won't boot unless I've given it a fresh install - any kind of fiddling kills it and then the system only boots the HDD (with my target build on it). What's needed is an independent boot manager such as XOSL instead of the behind-the-scenes manipulations the Linux install makes.

I don't need multiboot though, what I need is to transfer the installation I already have on the HDD onto the SSD. That would be easy with MBR, but UEFI is creating major obstacles... and I can't go back to MBR without corrupting my existing installation (which I am trying to preserve).

My next attempt will be to build a fresh installation on the SSD, then work out what needs changing so it works like the HDD installation.
 
prpr said:
Yay!
Click to expand...
Yeah, but the synonymous usage occurs so frequently, it's pissing in the wind to stop it or keep complaining about it - same as AdamW's dislike of "UEFI BIOS".

That said, I have little sympathy for AdamW: he seems to have forgotten that even UEFI needs some kind of "basic input output system" (in other words: a minimal set of device drivers) in order to function (the UEFI spec - available here: https://uefi.org/sites/default/files/resources/2_4_Errata_A.pdf - refers to this as Boot Services), and even specifies that building in "Legacy Operating System Support" is not precluded... ie BIOS calls (anyone who remembers coding for MS-DOS will remember BIOS calls).

Neither have I spotted any mention of POST. A manufacturer setting up a UEFI-compliant firmware for their motherboard has to include a BIOS layer underneath it (whether AdamW likes it called BIOS or not).
 
Coreboot sounds interesting, but you would have to have a motherboard for which there was an available image.
 
You must log in or register to reply here.
Back
Top