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.