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)
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").
There is a thread "[coreboot] libpayload: Geode video console support" from a few days ago, which I think is related.
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)?
Keeping it in Linuxbios makes sense for onboard video chips, ie keep board-specific knowledge in the firmware, OTOH, for addin cards, maybe libpayload could have multiple drivers, and pick at runtime...
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.
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 you want to do because earlyprintk comes and goes before the kernel framebuffers are initialized. You are far better off using the native framebuffer driver for your hardware (because then you can change modes and do other things that efifb cannot).
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.
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.
Jordan
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.
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@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@coplanar.net
I see I should have investigated efifb first. Thanks for the discussion.
On Mon, 2008-04-07 at 16:42 -0600, Jordan Crouse wrote:
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.
On 07/04/08 19:26 -0400, Jeremy Jackson wrote:
I see I should have investigated efifb first. Thanks for the discussion.
Well, I only investigated efifb - there might be some other EFI magic that happens earlier. Also, its not likely that VGA is just going to disappear over night, so I'll bet that VGA gets involved in some sneaky way.
Jordan
Jordan Crouse wrote:
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.
Are you implying that we should move the x86emu / vm86 stuff out of coreboot and into libpayload?
That would bring us a couple of advantages like being able to use the same instance of code for int13h emulation to boot off SCSI drives via option rom.
Stefan
On 07/04/08 16:29 -0700, Stefan Reinauer wrote:
Jordan Crouse wrote:
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.
Are you implying that we should move the x86emu / vm86 stuff out of coreboot and into libpayload?
That would bring us a couple of advantages like being able to use the same instance of code for int13h emulation to boot off SCSI drives via option rom.
I'm not sure that SCSI will be a going concern for libpayload for some time. :)
Seriously, though - I think that optionROM handling should remain in coreboot, because I think thats the best place for it. Yes, an optionROM might start VGA, but that shouldn't mean we implicitly condone all graphics init in coreboot, just like we don't plan to spin up drives just because a RAID card optionROM is initialized.
On a slightly different topic, we want to be careful not to move much functionality from coreboot to libpayload, because libpayload won't be used in many situations - it won't be used in conjunction with grub2 for example, nor for LAB, nor for gPXE - so we don't want to limit behavior that other payloads may find useful. Libpayload is _not_ a payload to rule them all.
Jordan
Jordan Crouse wrote:
Seriously, though - I think that optionROM handling should remain in coreboot, because I think thats the best place for it. Yes, an optionROM might start VGA, but that shouldn't mean we implicitly condone all graphics init in coreboot, just like we don't plan to spin up drives just because a RAID card optionROM is initialized.
Handling all devices of a certain type in the same place in a similar manner does lead to a sane code flow.
I am not sure we really want to handle graphics init sequences in 3 different places, depending on whether we have open source drivers or not.
The libpayload stuff for geode is nice, but there is similar code for ATI cards in linuxbios, and there is option rom based init in another place. This is very scattered and I don't really see the reason for that, nor believe it makes sense.
On a slightly different topic, we want to be careful not to move much functionality from coreboot to libpayload, because libpayload won't be used in many situations - it won't be used in conjunction with grub2 for example, nor for LAB, nor for gPXE - so we don't want to limit behavior that other payloads may find useful. Libpayload is _not_ a payload to rule them all.
I agree. Though I believe grub2 will use libpayload, eventually. It is interesting to see how quick libpayload might run towards a critical mass.
Stefan
On 07/04/08 16:58 -0700, Stefan Reinauer wrote:
Jordan Crouse wrote:
Seriously, though - I think that optionROM handling should remain in coreboot, because I think thats the best place for it. Yes, an optionROM might start VGA, but that shouldn't mean we implicitly condone all graphics init in coreboot, just like we don't plan to spin up drives just because a RAID card optionROM is initialized.
Handling all devices of a certain type in the same place in a similar manner does lead to a sane code flow.
I am not sure we really want to handle graphics init sequences in 3 different places, depending on whether we have open source drivers or not.
The libpayload stuff for geode is nice, but there is similar code for ATI cards in linuxbios, and there is option rom based init in another place. This is very scattered and I don't really see the reason for that, nor believe it makes sense.
My opinion is - during PCI init, if you have an optionROM, you should run it. If we start deciding to run some optionROMs and not others, then we'll get confused fast.
My other opinion is that native graphics drivers should run in the payload, We should lose the ATI card stuff in coreboot. That consolidates the code by type - native code in the payload, optionROM in coreboot, and we can ignore what actual device either mechanism runs.
Jordan
On Mon, Apr 07, 2008 at 06:14:01PM -0600, Jordan Crouse wrote:
The libpayload stuff for geode is nice, but there is similar code for ATI cards in linuxbios, and there is option rom based init in another place. This is very scattered and I don't really see the reason for that, nor believe it makes sense.
My opinion is - during PCI init, if you have an optionROM, you should run it. If we start deciding to run some optionROMs and not others, then we'll get confused fast.
My opinion is that option ROMs should not be needed, and that we have code for basic init for all supported hardware in coreboot. (Set a graphics mode or init a SCSI controller, but not spin up disks.)
My other opinion is that native graphics drivers should run in the payload, We should lose the ATI card stuff in coreboot. That consolidates the code by type - native code in the payload, optionROM in coreboot, and we can ignore what actual device either mechanism runs.
Short term (a few years or so) I pretty much agree. Long term I think I would like to set a graphics mode in coreboot.
Typically that isn't practical right now, but I would like to keep the RageXL code in v3 too when the time comes. That will make us think about where that type of init code fits in.
//Peter
On 08/04/08 02:36 +0200, Peter Stuge wrote:
On Mon, Apr 07, 2008 at 06:14:01PM -0600, Jordan Crouse wrote:
The libpayload stuff for geode is nice, but there is similar code for ATI cards in linuxbios, and there is option rom based init in another place. This is very scattered and I don't really see the reason for that, nor believe it makes sense.
My opinion is - during PCI init, if you have an optionROM, you should run it. If we start deciding to run some optionROMs and not others, then we'll get confused fast.
My opinion is that option ROMs should not be needed, and that we have code for basic init for all supported hardware in coreboot. (Set a graphics mode or init a SCSI controller, but not spin up disks.)
Is it really worth supporting dozens upon dozens of cards when all those cards already come with their own code free of charge? I know that optionROMs are proprietary and closed and scary but they work.
My other opinion is that native graphics drivers should run in the payload, We should lose the ATI card stuff in coreboot. That consolidates the code by type - native code in the payload, optionROM in coreboot, and we can ignore what actual device either mechanism runs.
Short term (a few years or so) I pretty much agree. Long term I think I would like to set a graphics mode in coreboot.
What value would such a thing have, other then putting up a splashscreen? We won't have callbacks, so payloads couldn't use it. It would only be able to communicate the coreboot boot progress and if we play our cards right coreboot will boot so fast that we'll be in the payload before the screen even syncs. In the large collection of things that coreboot doesn't need, I think video and NIC cards are number one on the hit parade.
Jordan
On Mon, Apr 07, 2008 at 08:52:27PM -0600, Jordan Crouse wrote:
My opinion is that option ROMs should not be needed, and that we have code for basic init for all supported hardware in coreboot.
Is it really worth supporting dozens upon dozens of cards when all those cards already come with their own code free of charge?
Long term, yes I think so. The common open source driver rhetoric applies, vendors probably don't really like that code. Pushing it outside their organization should be beneficial both for them and users. (Though I expect the transition to be a little bumpy because of differing work environments, habits and standards.)
I know that optionROMs are proprietary and closed and scary but they work.
They are also machine specific and sometimes painfully slow.
We can work around the first part with x86emu, which is a cool trick, but not so elegant. :)
Long term I think I would like to set a graphics mode in coreboot.
What value would such a thing have, other then putting up a splashscreen? We won't have callbacks, so payloads couldn't use it.
They could use it if it was left in a defined state.
It would only be able to communicate the coreboot boot progress and if we play our cards right coreboot will boot so fast that we'll be in the payload before the screen even syncs. In the large collection of things that coreboot doesn't need, I think video and NIC cards are number one on the hit parade.
Agree for coreboot itself, but the point would be to do enough in order to make them usable.
The console is a little special since that is where the user is, and while coreboot should work without user intervention, payloads may not.
//Peter
On Mon, Apr 7, 2008 at 11:12 PM, Peter Stuge peter@stuge.se wrote:
On Mon, Apr 07, 2008 at 08:52:27PM -0600, Jordan Crouse wrote:
My opinion is that option ROMs should not be needed, and that we have code for basic init for all supported hardware in coreboot.
Is it really worth supporting dozens upon dozens of cards when all those cards already come with their own code free of charge?
Long term, yes I think so. The common open source driver rhetoric applies, vendors probably don't really like that code. Pushing it outside their organization should be beneficial both for them and users. (Though I expect the transition to be a little bumpy because of differing work environments, habits and standards.)
Ugh. Anyone want to wager a guess as to how many different PCI (not including AGP or PCI-E) video cards there are? I don't think we could fit hardware init for every PCI video card out there into 4Mb. Don't get me wrong, I love the idea, but I just don't think it's practical.
I know that optionROMs are proprietary and closed and scary but they work.
They are also machine specific and sometimes painfully slow.
We can work around the first part with x86emu, which is a cool trick, but not so elegant. :)
Long term I think I would like to set a graphics mode in coreboot.
What value would such a thing have, other then putting up a splashscreen? We won't have callbacks, so payloads couldn't use it.
They could use it if it was left in a defined state.
It would only be able to communicate the coreboot boot progress and if we play our cards right coreboot will boot so fast that we'll be in the payload before the screen even syncs. In the large collection of things that coreboot doesn't need, I think video and NIC cards are number one on the hit parade.
Agree for coreboot itself, but the point would be to do enough in order to make them usable.
The console is a little special since that is where the user is, and while coreboot should work without user intervention, payloads may not.
3 things I want to throw in: - why not have the monitor syncing while coreboot/payload are still running? Isn't one of the benefits of coreboot to have the (entire) system in a ready state ASAP? - coreboot always has/should have the option NOT to touch the video/pci roms, and not to include the emulator, so if the user wants to put it in the payload, they always have the option. - if the payload fails before or during video init for some reason, not every user has a null modem serial cable, or USB debug cable. The sooner video is up, theoretically at least, the less that can go wrong before it gets done, and hopefully it can provide something useful.
-Corey
On Mon, Apr 07, 2008 at 03:37:25PM -0400, Jeremy Jackson wrote:
With the libpayload video console support framework, presumably all gfx chips could have their drivers written, yet again.
Is this necessary, or unnecessary code duplication?
Neccessary. The code is duplicated between libpayload and Linux fb driver because they are mutually exclusive, and because coreboot does not want to try to abstract every aspect of hardware with some API. (This is the BIOS way, which we want to move away from.)
As Jordan mentioned, libpayload is intended for development of applications that become coreboot payloads. This is very awesome for embedded when an OS kernel isn't needed.
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)?
In theory, yes. But either there would be lots of callbacks for setting options (I can't use the 16 color mode, I need 16bpp) or the console would be fixed format and very limited. Neither is acceptable IMO.
//Peter
-
Corey Osgood -
Jeremy Jackson -
Jordan Crouse -
Peter Stuge -
Stefan Reinauer