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

[Peter Stuge]

Philipp Stanner wrote:
> Once coreboot jumped into SeaBIOS-code the latter is responsible for
> providing the right interface for interrupt services.

Sure, coreboot does not provide interrupt services. I did not mean to
claim that it does. Sorry if there was confusion.


> I guess it doesn't matter very much in the end who switches the CPU
> to Real Mode.

One point I tried to make is that the CPU can very well be switched
back and forth several times before the actual OS kernel is running.


> My point is that coreboot's bios calls can't be called because they
> don't exist ^^

Sure, that's accurate, but having coreboot doesn't mean that there
are never BIOS interrupt services.


> > That depends. A *payload* can not assume interrupt services, but a
> > bootloader (e.g. in MBR) can very well assume interrupt services, 
> > especially since MBR is a BIOS paradigm.
> 
> Every payload built for and with coreboot won't try to call interrupts.

No payload is built with coreboot. Programs built as payloads will
indeed not call interrupt services, because they expect none.

But a bootloader built as a payload could also be built to use BIOS
interfaces. GRUB is one example of this.

And it is technically possible to put multiple payloads into CBFS.

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.


> > > And you can't use the 32-Bit-Instructionset anymore, can you?
> > 
> > That's orthogonal. You can use 32-bit instructions in 16-bit mode and
> > vice versa. The 0x66 and 0x67 opcode prefixes can be used to set an
> > instruction mode for a single instruction.
> 
> But in the beginning of this thread on 02 Aug Ron Minnich wrote
> that coreboot switches to PM, because: 
> 
> "And we want the 32-bit instruction set."

Maybe he didn't consider the prefix, or maybe he was thinking about
how GCC+binutils are pretty poor at dealing with the different modes
and swapping between them.

On the instruction level it's not a big deal to explicitly set the
"other" mode, but the toolchain is not very strong when it comes to
16-bit, making it more difficult to do so when writing C code. It was
created for the operating system environment and it shows, but that's
perfectly fine.

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.


//Peter