On 04/01/2017 05:24 AM, Nico Huber wrote:
On 01.04.2017 00:49, Todd Weaver wrote:
On a related topic, but not related to vbios gfx; I met with Matthew Garrett while at LibrePlanet, and he mentioned that we needn't worry about graphics within coreboot or the vbios, but could just deliver Linux kernel and use the graphics stack from there.
Can we bypass the vbios/graphics within coreboot and deliver the Linux kernel payload and use its graphics?
Yes, that would work. (In the case of Intel hardware) the Linux grap- phics driver does a superset of the things the VBIOS does. Actually, its default case is to ignore what the VBIOS did and start all over again. (One technical detail: You'd still have to put the Video BIOS Table, VBT into coreboot.)
OK, we will research that.
However, you'd have no display before the kernel boots. That's a nit, if you use the Linux kernel as payload but that comes with other impli- cations. Currently, that would kill what I'd call the "legacy boot experience". Without a payload like SeaBIOS, you can't just plug a USB drive with a random OS on it and expect the system to boot from it.
Yes, skipping "legacy boot experience" while a benefit (to avoid vbios) has the disadvantage of user control of replacing an OS with ease. So the next question is can we offer something similar after linux kernel payload? such as even a console based menu of boot options on esc? There may be existing projects I am unaware of that already look at linux kernel driven usb boot options.
Again, feel free to throw things at the coreboot mailing list.
I am sending this there now. Thanks for your help!
Todd.
Annnnnnnd with the linux payload we're back to linuxbios :-)
For a payload chooser and such I can offer two options: 1) petitboot has a boot menu type thing 2) u-root (u-root.tk) is going to have a boot menu type thing, as we've been asked to do one.
Overall I like the idea of the linux payload, of course :-)
If you're going to do that, however, I strongly recommend going with a 16 M flash part. 8 will work for now but you're going to have issues long term. Linux is not getting smaller over time ...
I'm actually working on this now so would like to help if possible.
with linux 4, and the new kexec "just load this file and boot it please" support, it's very easy to use linux as a bootloader, far easier than it used to be. We even have a kexec command written in Go in u-root. My general experience is that linux is by far the best bootstrap out there, as its drivers tend to be much more hardened than most bootloaders.
ron
On Sat, Apr 1, 2017 at 7:14 AM Todd Weaver todd@puri.sm wrote:
On 04/01/2017 05:24 AM, Nico Huber wrote:
On 01.04.2017 00:49, Todd Weaver wrote:
On a related topic, but not related to vbios gfx; I met with Matthew Garrett while at LibrePlanet, and he mentioned that we needn't worry about graphics within coreboot or the vbios, but could just deliver Linux kernel and use the graphics stack from there.
Can we bypass the vbios/graphics within coreboot and deliver the Linux kernel payload and use its graphics?
Yes, that would work. (In the case of Intel hardware) the Linux grap- phics driver does a superset of the things the VBIOS does. Actually, its default case is to ignore what the VBIOS did and start all over again. (One technical detail: You'd still have to put the Video BIOS Table, VBT into coreboot.)
OK, we will research that.
However, you'd have no display before the kernel boots. That's a nit, if you use the Linux kernel as payload but that comes with other impli- cations. Currently, that would kill what I'd call the "legacy boot experience". Without a payload like SeaBIOS, you can't just plug a USB drive with a random OS on it and expect the system to boot from it.
Yes, skipping "legacy boot experience" while a benefit (to avoid vbios) has the disadvantage of user control of replacing an OS with ease. So the next question is can we offer something similar after linux kernel payload? such as even a console based menu of boot options on esc? There may be existing projects I am unaware of that already look at linux kernel driven usb boot options.
Again, feel free to throw things at the coreboot mailing list.
I am sending this there now. Thanks for your help!
Todd.
Can we bypass the vbios/graphics within Coreboot and deliver the Linux kernel payload and use its graphics?
Yes, that would work. (In the case of Intel hardware) the Linux grap- phics driver does a superset of the things the VBIOS does. Actually, its default case is to ignore what the VBIOS did and start all over again. (One technical detail: You'd still have to put the Video BIOS Table, VBT into coreboot.)
As my very modest knowledge about vBIOS and Legacy BIOS is (I am, as we speak, trying to understand much more in-depth about differences between UEFI and Legacy), I think that, if you tend to bring Legacy based Coreboot, there is NO chance to avoid VBT (Video BIOS Table), which should/must be passed to Linux kernel, so Linux should/must reuse it for its own GFX (with much richer super set of functionality).
In contrary, if you use UEFI based context, then, instead of VBT you'll use so called GOP driver (The Graphics Output Protocol (GOP) is enabled by UEFI driver to support graphic console output in the pre-OS phase).
The ultimate goal of GOP is to replace legacy VGA BIOS and eliminate VGA HW functionality. Once you bring OS, it will NOT inherit GOP, rather use its own GFX from scratch (sans VBT).
My two cent to this thread, Zoran
-
ron minnich -
Todd Weaver -
Zoran Stojsavljevic