More info from the edge. This weekend has been quite a bit of real experience with UEFI up close and personal using an HP Stream G2 netbook.
The BIOS defaults to booting Win10 from a GPT-EFI partition and runs Win10 from an NTFS partition. The NTFS partition is divided into two volumes on an eMMC - electronic mult-media memory chip embedded on the main/motherboard.
Unlike Chromebooks which have a stripped down and bare bones BIOS, the Stream book has full features for booting from an MBR or GPT partitioned style storage device, using an eMMC or a USB bus device connected to the main/motherboard.. but it cannot boot from a microSD storage device deven though it has an SD memory slot.
What that means is the BIOS will scan those two buses eMMC and USB for storage devices and then look into devices on them for MBR or GPT partitioned disks.
When it does any MBR or GPT partition device with either an "Actrive" or "EFI" marked parition will be listed in its selectable boot menu "esc-F9" and can be chosen to attempt an operating system boot.
MBR is a four Primary partition, and Logical parition mini-index format description system at the top of the drive for locating an "Active" boot partition within the first 2 TB of an LBA - logical block access drive..
Limited by either the sector size and/or the number of blocks that a 16 bit BIOS can access.
The MBR slots contain the actual position within those blocks where the first boot sector for an Active partition can be found. It automatically loads the first few blocks into memory and gives control over to them by setting the CPU program segment pointer to the first one and performs an execute.. generally its a tiny machine language program that "bootstraps" by loading the next few sectors which is a filesystem driver for accessing "that" partitions "specific" filesystem and scans for the second stage bootloader for the pre-loader for that operating system.. the "preloader" generally does things specific to the operating system like preloading device drivers the kernel will need in memory in order to access the rest of the storage device.
Then the preloader loads the kernel into memory and jumps to its startup routine. The operating system decompresses the kernel, performs inventory and additional hardware specific platform "parts or bus initialization", and any plug and play autodetect and addtional device driver loading and initialization and then begins to provide feedback to the end user via the default local console.. a serial port or vga monitor.. then turns over control to a windows "manager" and presents a logon screen.. those are the general steps of most "windows like" systems.. be they microsoft, apple or linux.
GPT has a multiply redundant, "fake" MBR partitioning system for use for storage devives larger than 2TB.
A fake MBR is created at the top of the drive for marking the drive with a serial number and to indicate to old style BIOS boot systems that the drive is in use and contains information it can't see.. or that it is at least not "blank" and indicates caution should be exercised if the BIOS cannot further scan the storage device.
GPT has multiple copies of its mini-Index system for listing partitions on the drive, at the Top, Middle and Bottom of the drive. If one becomes damaged the others can be used to detect the damage and also wage an election to determine a quorum or tribunal of which contains the accurate information without having to perform extensive bitwise parity reconstruction of the data. Like MBR the paritions can be marked with a partition "type" for MBR that is simply "active or not active", but for GPT its more extensive, more generally one parition will be marked as an EFI - ESP - Extensible Firmware Partition, with a "hexidecimal type code" which is also a FAT32 filesytem format partition intended to contain mini-32 bit programs the UEFI can load into memory and execute, be they "C" programs for performing diagnostics, maintenance or bootstraping an operating system.
Since they are 32 bit prorgams they can have longer and larger sector registers in memory to seek deeper into an LBA drive and aren't limited by the MBR-LBA limit of 2 TB on storage devices with 512, 2048 or 4096 byte sectors. Some later 16 BIOS could work with larger byte sector discs but not all.
More complex 32 bit programs than were possible with 16 bit programs in a bootsector are possible. While MBR could load overlay programs to do something similar, few hard drive manufacturers released the hardware specific details to make this possible and moving the ability into programs loaded by UEFI made it easier to be more broadly accepted.
.. to be continued
