Zoran Stojsavljevic wrote:
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?
Correct.
So, what is this for the architecture? CSM? UEFI look alike?
Neither. There are no callbacks of any kind. Neither BIOS services nor UEFI runtime services (which are like BIOS services, but much more complicated for no reason other than inventor job security) are present here.
coreboot does export a "coreboot tables" data structure in RAM, e.g. with a memory map, and depending on build settings potentially also legacy tables such as ACPI, which may required by the operating system.
coreboot tables contain only data, no code.
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?
No. The MBR is irrelevant in the above scenario, it is never read. GRUB2 uses its own disk and filesystem drivers to locate and load the configured kernel and possibly initramfs files.
How the kernel and userland files got onto the disk drive is also irrelevant. Beyond a recognized partition table, GRUB configuration file and kernel files in the right directory on a supported filesystem, nothing else matters.
The same is true for FILO.
The payload directly reads the filesystem from disk, no boot sector is used.
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.
Again, it does not matter how Linux was installed, as long as GRUB2 can locate the kernel on the filesystem.
Any comments on what I wrote here? ;-)
coreboot with its payloads offers significant advantages over legacy BIOS and stillborn UEFI architectures.
//Peter
Peter Stuge wrote:
The MBR is irrelevant in the above scenario, it is never read.
..
The payload directly reads the filesystem from disk, no boot sector is used.
To clarify, I mean code here. No code is read/loaded/used from MBR.
The partition table is read, but I expect that GRUB2 supports both GPT and MBR partition tables, so MBR is not a requirement, and can likely be changed at will, without needing to modify coreboot or GRUB2 in boot flash, as long as the GRUB2 config file correctly reflects system configuration.
//Peter
Am Montag, den 04.09.2017, 20:15 +0000 schrieb Peter Stuge:
legacy tables such as ACPI
ACPI is a open standard, isn't it?
The payload directly reads the filesystem from disk, no boot sector is used.
Indeed. So a payload built for cb won't try to call BIOS. And if something after it tries it said payload should have implemented the calls.
coreboot with its payloads offers significant advantages over legacy BIOS and stillborn UEFI architectures.
C and open source is great. Though it frustrates me a bit that people did all this work – and here we are again, still implementing BIOS- Interrupts and all this old stuff. If it would compile on my machine I would prefer a tiny loader like FILO. The awkward thing about BIOS is that it was a second OS from the first day on – while the reasonable philosophy behind firmware should be: Start the board, load the OS and go back into your flash until reboot.
P.
On Mon, Sep 4, 2017 at 3:41 PM Philipp Stanner stanner@posteo.de wrote:
Start the board, load the OS and go back into your flash until reboot.
Just checking, but have you looked at the code to see what "start the board" really means? Hint: on x86 it's essentially one billion instructions before you can even think about using RAM, much less loading the payload.
I'm guessing, by what you are saying, that you are not familiar with what has to be done. Apologies if I am wrong :-)
And, that said, I'm back to the old original idea, which is to load linux from flash. It's working fine on UEFI today and I'm seeing what it takes to replace the coreboot ramstage with linux.
ron
The awkward thing about BIOS is that it was a second OS from the first day on – while the reasonable philosophy behind firmware should be: Start the board, load the OS and go back into your flash until reboot.
My history lessons may be failing me here, but IIRC the main reason for that was memory: DOS wasn't a full OS in the modern sense, it was pretty much just a shell and a collection of utility programs. All the actual device driving was done by the BIOS. So if you compare it with a modern GNU/Linux machine, the BIOS was equivalent to Linux and DOS to the GNU parts.
The original IBM PC had so little memory that they couldn't really afford to waste any of it on stuff like device drivers. So they put the drivers in flash where they could be executed in-place, which became the BIOS. Most of DOS itself (essentially the command.com shell) was just unloaded whenever you launched a program and re-loaded from disk afterwards, and while the program was running it mostly interacted with the BIOS directly.
So you're right that from our current point of view that having callbacks into firmware makes little sense, but back then they were working with what they had and it was pretty much the only way to get as much out of the machine as they needed. The BIOS was really the first OS on the platform, and all those later ones that implement their own drivers (Windows, Linux) are breaking with the intended paradigm.
-
Julius Werner -
Peter Stuge -
Philipp Stanner -
ron minnich