Re: [coreboot] About Paging, Realmode and what is going on

[Zoran Stojsavljevic]

> 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  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.