Results 1 to 9 of 9

Thread: CoreBoot Gains Native VGA Text Mode

  1. #1
    Join Date
    Jan 2007
    Posts
    14,788

    Default CoreBoot Gains Native VGA Text Mode

    Phoronix: CoreBoot Gains Native VGA Text Mode

    While Luc Verhaegen (one of the original RadeonHD driver developers) has been out of work since right after FOSDEM when he was laid off by Novell due to cutbacks, he hasn't quit coding. While Luc hasn't been working on the RadeonHD driver, or any ATI driver for that matter, one of the projects that he has gotten involved with is CoreBoot, the project formerly known as LinuxBIOS. As part of this work over the past few months, Luc is announcing today that he has been successful in implementing a native VGA text-mode within CoreBoot...

    http://www.phoronix.com/vr.php?view=NzQwMQ

  2. #2
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

    Default

    Next stop: BIOS Modesetting

  3. #3
    Join Date
    May 2008
    Posts
    598

    Default

    Until now, if you wanted working graphics with coreboot, you were still tied to the PCI option rom of your graphics card. This code i just pushed out makes even this last vestige of non-free software disappear.
    I don't understand the difference. How can use have VGA without using the graphics card???

    Or is it that the API is the same on all GPU's/IGP's to get VGA?

  4. #4
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by Ant P. View Post
    Next stop: BIOS Modesetting
    If you had read the blog, you would know

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    There really is a need for both direct programming and BIOS-based modesetting. The benefit of BIOS-based modesetting is that maintenance is lower (letting devs spend more time on other pressing issues like 3D) and support for new GPUs can be faster, but direct programming has benefits too.

    Direct programming can insulate you from BIOS-related problems, give you a solution for cases where the BIOS is not accessible, and gives you a fallback that is likely to "always work" when all else fails. You need to be willing to spend the time to "get it right" for each platform, but Luc understands that and does put in the effort to get it right.

    VGA hardware is supposed to be common across GPUs (although "supposed to be" is not the same as "is") so this seems like an ideal application for direct programming.

  6. #6
    Join Date
    May 2008
    Posts
    598

    Default

    Impressive that so much is possible at such an early stage, and even with the very limited about space. I think CoreBoot with payload is limited to 4MiB?

    Given what BIOS is an acronym for
    http://en.wikipedia.org/wiki/BIOS

    Perhaps "basic" and "I/O" should be updated, as CoreBoot is more than just "basic I/O"

  7. #7
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

    Quote Originally Posted by bridgman View Post
    There really is a need for both direct programming and BIOS-based modesetting. The benefit of BIOS-based modesetting is that maintenance is lower (letting devs spend more time on other pressing issues like 3D) and support for new GPUs can be faster, but direct programming has benefits too.

    Direct programming can insulate you from BIOS-related problems, give you a solution for cases where the BIOS is not accessible, and gives you a fallback that is likely to "always work" when all else fails. You need to be willing to spend the time to "get it right" for each platform, but Luc understands that and does put in the effort to get it right.

    VGA hardware is supposed to be common across GPUs (although "supposed to be" is not the same as "is") so this seems like an ideal application for direct programming.
    John, remember all those times when you were blaming C based modesetting code for the 3D driver not materialising? How close to the truth do you think this really is, now that some parts of 3d driver bringup happened eventually, but it still far, far away from getting there, even though everybody has no other option but to use atombios today. How much did modesetting work really slow things down?

    In my opinion; much, much less than the scattering of resources.

    About my code here; VGA is to some extent a standard. I bring up the standard textmode, and set the hardware up just so that it can fully display this standard textmode. There is no further attempt to change the mode after this, as this requires more knowledge than just the vga standard and thus requires a proper driver. But... Pushing text into the vga framebuffer, and then moving the location of the framebuffer and the cursor, that is very much possible and very general and standard still. And this is exactly what linux later on does to display its console.

    This is the solution here, and it is the perfect solution for a very necessary usecase as well. Everything beyond this requires a proper driver.

    And John, this is not a BIOS based modeset. It is a GPLed C based modeset, for a stack of software intended to replace one part of what usually is BIOS functionality. It is definitely not legacy, and it never will be either.

  8. #8
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    323

    Default

    Quote Originally Posted by Louise View Post
    Impressive that so much is possible at such an early stage, and even with the very limited about space. I think CoreBoot with payload is limited to 4MiB?

    Given what BIOS is an acronym for
    http://en.wikipedia.org/wiki/BIOS

    Perhaps "basic" and "I/O" should be updated, as CoreBoot is more than just "basic I/O"
    Louise, just the coreboot part, including a full vga font (which is, in comparison; huge is this size, when compressed:
    "input/output = 127888/51194 = 2.498"

    This is from the coreboot compile log, using the old style compression method. Coreboot in less than 64kB.

    Then, to be able to get some useful functionality, SeaBIOS is added and this currently amounts to 70kB uncompressed.

    If both are moved into CBFS (coreboot fs) it would be using less than 128kB. For C code, not for handcrafted asm.

    But, really, coreboot is not limited by anything, just the size of the flash chip, which today is never less than 256kB, and sometimes boards are being shipped with 2MB. And there are even bigger SPI chips out there.

  9. #9
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,458

    Default

    Quote Originally Posted by libv View Post
    John, remember all those times when you were blaming C based modesetting code for the 3D driver not materialising? How close to the truth do you think this really is, now that some parts of 3d driver bringup happened eventually, but it still far, far away from getting there, even though everybody has no other option but to use atombios today. How much did modesetting work really slow things down?.
    It'll probably take a lot more beer before everyone agrees on a single number but my sense is that it cost us somewhere around five calendar months, between your time spent on coding / testing / figuring out what the HW did and our time spent researching display information which we hadn't planned to do until after acceleration hardware was documented and running.

    Quote Originally Posted by libv View Post
    And John, this is not a BIOS based modeset. It is a GPLed C based modeset, for a stack of software intended to replace one part of what usually is BIOS functionality. It is definitely not legacy, and it never will be either.
    Understood. I was trying to say nice things, work with me here

    I know calling the previous BIOS implementation (code written in x86 assembler rather than CPU-independent bytecodes) "legacy" doesn't sit well with you but in fairness the decision was made long before either of us were involved. Knowing what I do today I would probably have suggested "classic" rather than "legacy"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •