> 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 <[email protected]> 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. > > -- > coreboot mailing list: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
