The rate at which the complexity of the amd64 boot process is increasing is quite alarming.
UEFI is an overcomplicated, buggy monstrosity, but that's just the tail end of the "boot process". Nowadays, to get an x86 CPU to execute a single opcode, you need to have a Management Engine (or Platform Security Processor, in AMD-speak) firmware blob resident in the firmware flash chip. More modern CPUs, for Intel, say, oblige you to use Intel-provided "memory reference code" and other "firmware support package" blobs just to initialize the CPU in the early stage. AFAIK, Intel isn't even bothering to document the details of its CPU and chipset initialization sequences anymore, in favour of just making people use unexplained blobs. These are just some of the issues the coreboot project is having to deal with. It really feels like at least in the world of x86, the window is rapidly closing on projects like coreboot being able to accomplish anything useful, although there are at least some major users like Chromebooks.
And then of course we have things like SMM, and the way in which secure firmware updates are facilitated (which relies on things like flash write protect functionality)...
It's correct that these blobs are loaded way before GRUB or a Linux kernel gets booted. To be precise they are part of the firmware image; UEFI refers to a boot protocol specification. So for example with coreboot, you can select one of many "payloads". Payloads include UEFI boot, MBR boot, etc. So it's probably best to distinguish between the boot protocol and the firmware package as a whole.
The ME firmware is loaded by the CPU itself before anything begins executing; there's a header in the firmware image stored on the CPU to let the CPU find it. These are cryptographically signed, so all projects like Coreboot can do is incorporate the binaries provided by Intel.
The MRC/FSP blobs are executed by the x86 firmware, they're x86 code which runs very early. Theoretically projects like Coreboot could replace these blobs with their own code, but it would require reverse engineering these blobs to figure out what they're doing. The fact that this would be a major effort is a testiment to the complexity of the initialization routines implemented in these blobs.
The order is basically something along the lines of:
1. CPU loads ME firmware, verifies signature, starts it running on the ME coprocessor.
2. First x86 opcode is executed; this is part of the 3rd party firmware (Coreboot, AMI, etc.)
3. The 3rd party firmware will probably start by executing the Intel MRC/FSP blob. (Possibly this blob even expects to be the reset vector now, wouldn't surprise me; I'm not an expert on this.)
4. The memory controllers/chipset/etc. are now setup. The 3rd party firmware can do what it likes at this point.
5. Typically, firmware will implement a standard boot protocol like MBR boot or UEFI boot. Coreboot executes a payload at this stage.
I should add that microcode is another (signed, encrypted) blob. Modern x86 CPUs are so buggy out of the factory that they're often unable to even boot an OS unless a microcode upgrade is applied, so 3rd party firmware often performs a microcode upgrade before booting. Historically I don't believe it was uncommon for the OS kernel to perform a microcode upgrade, if configured to do so because a newer microcode was available than was incorporated in the firmware; Linux has functionality to do this. However I seem to recall that late (kernel boot or later) microcode application is being phased out; recent x86 CPUs want microcode updates to be completed very early, before kernel boot.
UEFI is an overcomplicated, buggy monstrosity, but that's just the tail end of the "boot process". Nowadays, to get an x86 CPU to execute a single opcode, you need to have a Management Engine (or Platform Security Processor, in AMD-speak) firmware blob resident in the firmware flash chip. More modern CPUs, for Intel, say, oblige you to use Intel-provided "memory reference code" and other "firmware support package" blobs just to initialize the CPU in the early stage. AFAIK, Intel isn't even bothering to document the details of its CPU and chipset initialization sequences anymore, in favour of just making people use unexplained blobs. These are just some of the issues the coreboot project is having to deal with. It really feels like at least in the world of x86, the window is rapidly closing on projects like coreboot being able to accomplish anything useful, although there are at least some major users like Chromebooks.
And then of course we have things like SMM, and the way in which secure firmware updates are facilitated (which relies on things like flash write protect functionality)...