Zoran Stojsavljevic wrote:
But a bootloader built as a payload could also be built to use BIOS interfaces. GRUB is one example of this.
Let us assume the following configuration: FSP -> Coreboot -> Payload: GRUB2 -> Linux
No legacy interrupts, correct?
Correct.
So, what is this for the architecture? CSM? UEFI look alike?
Neither. There are no callbacks of any kind. Neither BIOS services nor UEFI runtime services (which are like BIOS services, but much more complicated for no reason other than inventor job security) are present here.
coreboot does export a "coreboot tables" data structure in RAM, e.g. with a memory map, and depending on build settings potentially also legacy tables such as ACPI, which may required by the operating system.
coreboot tables contain only data, no code.
I assume, the Linux image on the HDD/SSD was installed far before as CSM, so there is already existing MBR, and some CSM implemented legacy services (INTs) already exist, am I correct?
No. The MBR is irrelevant in the above scenario, it is never read. GRUB2 uses its own disk and filesystem drivers to locate and load the configured kernel and possibly initramfs files.
How the kernel and userland files got onto the disk drive is also irrelevant. Beyond a recognized partition table, GRUB configuration file and kernel files in the right directory on a supported filesystem, nothing else matters.
The same is true for FILO.
The payload directly reads the filesystem from disk, no boot sector is used.
I assume UEFI installed Linux would NOT run, since GRUB2 will be not able to find MBR... I assume GRUB2 as payload to Coreboot assumes MBR/Legacy (by default) implementation.
Again, it does not matter how Linux was installed, as long as GRUB2 can locate the kernel on the filesystem.
Any comments on what I wrote here? ;-)
coreboot with its payloads offers significant advantages over legacy BIOS and stillborn UEFI architectures.
//Peter