> 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? So, what is this for the architecture? CSM? UEFI look alike?

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?

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.

Any comments on what I wrote here? ;-)

Zoran

On Mon, Sep 4, 2017 at 12:01 PM, Philipp Stanner <stanner@posteo.de> wrote:
Thanks so far. Very interesting.

Am Montag, den 04.09.2017, 07:28 +0000 schrieb Peter Stuge:
>
> coreboot itself can only start one payload, but SeaBIOS allows the
> user to choose which of those payloads to start, in which case a
> payload *does* have interrupt services available.
>
> Just to let you know that this is possible.
>

> There is no "32-bit instruction set". The instruction set is the
> same,
> there is no difference in what opcodes could be used (well except
> maybe
> gdt and idt stuff) but *addressing* is obviously different in 32-bit
> mode,
> and using 32-bit addressing makes everything a lot easier.
>

If there is no difference according the instruction set and as coreboot
itself doesn't provide BIOS-services: Why don't we just switch the CPU
to flat protected mode, do our duty and jump into the payload (SeaBIOS
mainly) which then switches back to real mode if necessary, change the
GDT or do whatever it needs to do?
Switching back to Real Mode, using 32-Bit-addresses (what sounds like a
hack to me. I can't imagine Intel intended this) is much more
complicated than staying in PM, isn't it?

x86 is pain. Sometimes I wonder why it even works at all. Let's hope
there will be RISC-V-Boards one day.

P.