[coreboot] passing EFI-console-like info to payloads

[Jordan Crouse]

On 07/04/08 17:54 -0400, Jeremy Jackson wrote:
> 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)

Taking the Linux kernel as an example, you have to understand that any
"early debug" you get now is not because of anything the BIOS is doing,
but because the Linux kernel understands VGA very early during boot. 
If you wanted some other video interface to be available, then the Linux
kernel would have to understand _that_ interface as well.  Clearly, this
is not a priority for the kernel folks since only VGA is supported for
early video display (mainly for legacy purposes), and all other systems
without VGA is relegated to using serial or some other debug mechanism.

So you have two problems - 1) getting the loader to initialize the video
(which doesn't happen today, not even on traditional BIOS), and 2)
teaching the kernel how to talk to it, which is difficult without a 
standard interface (like VGA has).  The 'efifb' that you mentioned before
is a framebuffer driver and comes up relatively late during the kernel
boot - it is not a replacement for VGA and early printk debugging messages.

> 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 at 60Hz?  A flatpanel monitor won't always display that, and
> there's not hotplugging/interrupts in firmware.

Which is further reason why coreboot should not be involved at all in 
display management - we should let more intelligent payloads handle that.
You can take this up with an individual payload developer,  but as
far as core coreboot development is concerned, its a non-starter.

> 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.

Yes, but note that only a few platforms do that - thats certainly
not a feature that was added to coreboot by design.

Above all other things, we want to keep coreboot light and fast - that
means we don't bring up entities that are only going to be reinitialized
later by a payload.  Of those entities, the two prime examples are 
NIC and video - both are easily handled by the Linux kernel and other
payloads, so thats where that support should be.  

The platform specific code has to be _somewhere_ - today its hidden
behind the INT10 interface and later it might be somewhere else.
I prefer to have my platform specific code where it will do me
the most good - and it does me the most good in a place where
my payload can take full advantage of the hardware - the EFI 
interface doesn't offer us any of that, and it abstracts control
of the video engine away from the entity that could use it most,
the kernel.

> > > 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.

But it doesn't actually solve that problem, at least not today in the
Linux kernel. 

Jordan

> -- 
> Jeremy Jackson
> Coplanar Networks
> (519)489-4903
> http://www.coplanar.net
> jerj at coplanar.net
> 
> 

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.