Announcement

Collapse
No announcement yet.

CoreBoot Gains Native VGA Text Mode

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Next stop: BIOS Modesetting

    Comment


    • #3
      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?

      Comment


      • #4
        Originally posted by Ant P. View Post
        Next stop: BIOS Modesetting
        If you had read the blog, you would know

        Comment


        • #5
          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.
          Test signature

          Comment


          • #6
            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


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

            Comment


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

              Comment


              • #8
                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


                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.

                Comment


                • #9
                  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.

                  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"
                  Test signature

                  Comment

                  Working...
                  X