Hi Jordan,
Thanks for the feedback.
I think you might be mis-interpreting my intentions; I'm not trying to emulate BIOS or EFI, but rather allow early debug output to a video monitor from Linuxbios payloads, *without* using legacy ISA VGA ioports/memory. (which aren't available on some platforms, I might add)
Comments below...
A furthur idea, is storing video timings in CMOS... finally a use for that tiny storage space! Why not do DDC each boot/resume? well, it's slow, and if nothing is connected at boot/resume, then what, 640x480@60Hz? A flatpanel monitor won't always display that, and there's not hotplugging/interrupts in firmware.
maybe a key sequence for re-read DDC and update CMOS, for emergency video enable.
On Mon, 2008-04-07 at 14:31 -0600, Jordan Crouse wrote:
On 07/04/08 15:37 -0400, Jeremy Jackson wrote:
I've been eyeing legacy ISA io/mem range removal, in particular VGA, for some time. Concerning early debug output, it seems that EFI has done this by exporting basic framebuffer info, and Linux has an efifb which uses it. (framebuffer base address + size, stride, pixel format)
EFI does this by first bringing up the video hardware (in other words, adding a full video module for the hardware into the EFI system), or by acting as a proxy for VGA (i.e - bringing up the video console with VESA) and then passing the information to the kernel.
In Linuxbios there is the RageXL driver, which is basic chip init, I don't think it's a full video module. It can't output anything, it has no fonts, etc.
Linuxbios currently passes serial console info. Idea: pass key framebuffer info to payloads, so they can use a video/VGA console for early debug output (Linux "earlyprintk").
To emulate this behavior, coreboot would have to understand how to drive a myriad of video controllers itself. And it still wouldn't help with what
It would have to initialize them at least, that's true. For onboard chips I think that's reasonable, eg RageXL. I haven't thought about add-on boards.
you want to do because earlyprintk comes and goes before the kernel framebuffers are initialized. You are far better off using the native
Yes, this is the motivation for passing the framebuffer info, so earlyprintk can provide output before framebuffers are initialized, if they are at all.
framebuffer driver for your hardware (because then you can change modes and do other things that efifb cannot).
Changing modes might not be a requirement, only early debug output.
There is a thread "[coreboot] libpayload: Geode video console support" from a few days ago, which I think is related.
That is not at all related - that is a patch for a payload library that emulates video output for the local payload but nothing else. That code does not live in coreboot.
I'm suggesting it *could* be related, by being a generic framebuffer driver, using infos passed from Linuxbios/coreboot (sorry for using old name).
With the libpayload video console support framework, presumably all gfx chips could have their drivers written, yet again. There's a headstart in Linuxbios for initializing RageXL and a couple others, that could be enhanced to print output also.
Is this necessary, or unnecessary code duplication? Could the chip-specific init code be left in Linuxbios, and only a generic video console (ie font + generic rendering to framebuffer code) be provided in libpayload (and/or Linux)?
As far as I am concerned, coreboot should have nothing to do with graphics - initializing graphics is up to the individual payloads. If it is the kernel, then it should be a framebuffer. if it is something else (say, a libpayload based payload) then that "something else" needs to handle it. Yeah, this isn't at all like how a traditional BIOS does it, but we're not designing coreboot to be a drop-in replacement for a traditional BIOS.
I'm only referring to EFI console, because it's an example of something that solves the legacy ISA VGA removal problem, but still allows early debug output.