Announcement

Collapse
No announcement yet.

An Effort Making An Open-Source Radeon Video BIOS

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

  • #16
    Originally posted by mmstick View Post
    It does what firmware is suppose to do, which involves controlling all the components inside the GPU. If there were really such 'broken things' as you say there are, then why don't we see these 'broken things' on Windows? The very fact that BIOS updates are never given for GPUs is a testament that such things don't happen. The only 'broken things' I see on Linux are graphics drivers and proper OpenGL libraries.
    u-hu, riiight. if you haven't stepped into a shit yet, it doesn't mean that shit doesn't exist, Sherlock.
    as a man, who patched VBIOS'es in his cards for various reasons, including inadequate defaults, on his Windows-running PCs as long as 10 years ago, i can tell that you don't know what you blabbering about.

    PS: and "the very fact that BIOS updates are never given for GPUs is a testament that" VBIOS updates are easy to fuck up, not highly necessary to run the card at all (like with MB BIOS'es and their CPU support) and VBIOS faults are more easily worked-around with proprietary driver updates that override them.

    Originally posted by mmstick View Post
    All communications have to go through this BIOS, else there wouldn't be much point in making a BIOS
    no, they don't

    Originally posted by mmstick View Post
    Do you really think multibillion dollar companies would have their products running on dysfunctional BIOSs?
    and don't get me started on MB BIOS'es and firmwares on popular accessory devices. so... fuck-yes !
    Last edited by dfx.; 07-28-2013, 07:04 AM. Reason: fools don't shut up

    Comment


    • #17
      Originally posted by mmstick View Post
      What's the point?
      Opensource replacement to a propietary blob. No more reasons needed.

      Comment


      • #18
        I think that open source firmware for network cards is more desired, because could be more secure. If firmware is vulnerable then everybody could remotely get into PC. Quote from first link:
        I've finally found some time to study Loic Duflot's and Yves-Alexis Perez's recent presentation from the last month on remotely attacking network cards. You can get the slides here.

        In short, they're exploiting a buffer overflow in the network card's firmware by sending malicious packets to the card, and then they gain full control over the card's firmware, so they can e.g. issue DMA to/from the host memory, effectively fully controlling the host (that's another example of "Ring -3 rootkit" I would say). The buffer overflow is in some exotic management protocol (that I think is disabled by default, but that's irrelevant) implemented by the NIC's firmware (the NIC has its own RISC processor, and memory, and stack, which they overflow, etc.).

        Read more there:
        Article: "Remotely Attacking Network Cards (or why we do need VT-d and TXT)" Author: Joanna Rutkowska
        http://theinvisiblethings.blogspot.c...ds-or-why.html

        Presentation: "Can you still trust your network card?" Authors: Loc Duflot, Yves-Alexis Perez, Guillaume Valadon, Olivier Levillain.
        http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf
        Last edited by coastiron; 07-28-2013, 07:32 AM.

        Comment


        • #19
          Originally posted by mmstick View Post
          It does what firmware is suppose to do, which involves controlling all the components inside the GPU. If there were really such 'broken things' as you say there are, then why don't we see these 'broken things' on Windows? The very fact that BIOS updates are never given for GPUs is a testament that such things don't happen. The only 'broken things' I see on Linux are graphics drivers and proper OpenGL libraries.
          BIOS updates are given for GPUs. Google for it.

          Comment


          • #20
            Originally posted by mmstick View Post
            What's the point?
            In some cases, the only difference between the cheap card and the costly one is the bios locking out features. Combined with some other means of blocking the flashing of the unlocked firmware. Say, raising a read only flag after the flashing through the jTag connection.
            Still, even knowing this, it still seems like a waste of time to me. The price differences between such models is negligible considering the cost in man-hours of a person skilled enough to pull something like this off. A person this skilled in disassembling machine code could work on something like Nouveau where his contribution would matter to millions. Or maybe help bridging the gap between the open source AMD drivers and the closed source ones.

            Comment


            • #21
              Originally posted by c117152 View Post
              Still, even knowing this, it still seems like a waste of time to me. The price differences between such models is negligible considering the cost in man-hours of a person skilled enough to pull something like this off. A person this skilled in disassembling machine code could work on something like Nouveau where his contribution would matter to millions. Or maybe help bridging the gap between the open source AMD drivers and the closed source ones.
              Reasons to do it:
              Because I can do it.
              I have source code of video rom now.
              Fun.
              I can modify it now.
              ...

              Radeon driver is more complex then a option rom code. In radeon option rom the are "only" some calls to Atomtable. No acceleration, no Command processor programming and so on.

              Comment


              • #22
                Originally posted by oliver View Post
                If anybody could just 'hack it themselves' then it would have been long done. Look at your history, RadeonHD driver, where it was proposed to use the registers directly without Atombios. RadeonHD didn't evolve vast enough (much harder) and people didn't really care for it. But that's with a lot of things in life, Usually things that are 'better', be it technically or ethically, get little support. Sad, but true.
                That is quite wrong. RadeonHD evolved _very_ fast. But, ATIs bridgman was playing a double game and never giving us the information we asked for. He was constantly feeding the less morally acceptable fork playing divide and conquer, so that fglrx could remain the main linux strategy. The radeon driver did all the big statements, when something worked slightly or once on airlieds PC, it was a huge amount of noise. RadeonHD had to go thoroughly test stuff, and always, _always_ solved issues down to the core, making development seem slower. As soon as RadeonHD had found the issue, radeon took it over silently, and then went on to make big statements.

                In open source, technical or moral superiority loses against noisemaking all the time. And the radeon developers only motivation is the fact that SuSE was able to make noise while they weren't, and they were happy to go along with the devil and help keep ATIs fglrx, just so that they could be seen as the big open source heroes.

                Comment


                • #23
                  Originally posted by libv View Post
                  In open source, technical or moral superiority loses against noisemaking all the time.
                  Well, that reminds me of Wayland & Mir.
                  Guess you might have a point here...

                  Comment


                  • #24
                    LOL! If the NSA wanted to monitor your communications they wouldn't need to patch the firmware of your graphics card. They have access to technology that you have never ever heard about.

                    Comment


                    • #25
                      Originally posted by mmstick View Post
                      It is done.....you can simply hack an existing BIOS to change the clocks/voltages to be permanent in the firmware itself rather than using software to overclock after booting. Some enthusiast PC gamers do this sort of thing. RadeonHD driver? That obsolete open source Linux driver? Stupid? You mean your attitude which is the stupidest thing in this forum? Do you have any proof of your last statement whatsoever? You can't just 'reimplement a BIOS in software'. The BIOS is there to stay in the middle between the GPU and the driver. All communications have to go through this BIOS, else there wouldn't be much point in making a BIOS. Do you really think multibillion dollar companies would have their products running on dysfunctional BIOSs?
                      That's not true. A driver can be written that doesnt use any firmware at all. A BIOS isnt strictly required.

                      Comment


                      • #26
                        Originally posted by eisenhart View Post
                        Reasons to do it:
                        Because I can do it.
                        I have source code of video rom now.
                        Fun.
                        I can modify it now.
                        ...

                        Radeon driver is more complex then a option rom code. In radeon option rom the are "only" some calls to Atomtable. No acceleration, no Command processor programming and so on.
                        So... I take it that you are using Matthias Hopfs atombios disassembler for that. Did you turn it into an assembler?

                        But what are you doing about unpacking/packing this atombios bytecode into an option rom? How are you flashing this into the graphics card? This are the first steps one should solve here.

                        Comment


                        • #27

                          LOL! If the NSA wanted to monitor your communications they wouldn't need to patch the firmware of your graphics card. They have access to technology that you have never ever heard about.
                          And because of your rhetoric, still haven't heard of, and likely wont. But, I'm not an idiot, wont ask, and dont care for fanciful conjecture like that =D

                          Comment


                          • #28
                            Originally posted by mmstick View Post
                            You can't just 'reimplement a BIOS in software'.
                            Yes, you very definitely can. But the board specific bits would have to be done on a board specific basis, which is an endless amount of work.

                            Originally posted by mmstick View Post
                            The BIOS is there to stay in the middle between the GPU and the driver. All communications have to go through this BIOS, else there wouldn't be much point in making a BIOS.
                            AtomBIOS has the advantage of not being like an x86 BIOS. You can get its tables, get some info from the data tables. Have some constantly evolving interface to the function tables, and then run those function tables through some interpreter.

                            AtomBIOS severely disproves your statement here.

                            Originally posted by mmstick View Post
                            Do you really think multibillion dollar companies would have their products running on dysfunctional BIOSs?
                            Yes. And i have two years of rock hard experience with ATI on that one, with endless facts. What do you have to put against that?

                            Comment


                            • #29
                              Originally posted by libv View Post
                              That is quite wrong. RadeonHD evolved _very_ fast. But, ATIs bridgman was playing a double game and never giving us the information we asked for. He was constantly feeding the less morally acceptable fork playing divide and conquer, so that fglrx could remain the main linux strategy. The radeon driver did all the big statements, when something worked slightly or once on airlieds PC, it was a huge amount of noise. RadeonHD had to go thoroughly test stuff, and always, _always_ solved issues down to the core, making development seem slower. As soon as RadeonHD had found the issue, radeon took it over silently, and then went on to make big statements.

                              In open source, technical or moral superiority loses against noisemaking all the time. And the radeon developers only motivation is the fact that SuSE was able to make noise while they weren't, and they were happy to go along with the devil and help keep ATIs fglrx, just so that they could be seen as the big open source heroes.
                              I know you see things through jaded colored lenses, so please don't take this the wrong way.... But that is not what happened exactly. Radeonhd should never have been born in the first place. SuSe should never have been contracted to begin with.

                              Bridgman supported radeonhd as his recommendation for a long time even after it became irrelevant. I remember specifically several flamewars where he was supporting radeonhd when he clearly shouldnt have been

                              The fact is that whether you like it or not radeonhd was a waste of time and effort from the very beginning. Radeon outpaced it at every single step of the way. It worked better and faster AND was more stable and reliable. I can't begin to tell you how much GCC hated radeonhd. It was a bitch to compile, mostly because of the coding style was incorrect form. While you insisted on banging modesetting registers directly with radeonhd, radeon was already working and had moved on to acceleration. radeonhd was just a waste of time.
                              Last edited by duby229; 07-28-2013, 11:26 AM.

                              Comment


                              • #30
                                Originally posted by libv View Post
                                So... I take it that you are using Matthias Hopfs atombios disassembler for that. Did you turn it into an assembler?

                                But what are you doing about unpacking/packing this atombios bytecode into an option rom? How are you flashing this into the graphics card? This are the first steps one should solve here.
                                I dont interpret Atombios tables. I dump the tables simply to the c-structs and let execute the AMDs atom interpreter these (its still byte code) tables.

                                There is not only Atomtables in ROM. There is also int 10h and VBE code. In the end of build process you get a valid PCI option rom binary.

                                I could flash it to the card.

                                But its faster to test it using qemu:
                                qemu-system-x86_64 -cpu host -enable-kvm -vga none -device vfio-pci,x-vga=on,host=1:00.0,romfile=vgabios.rom -m 1024 -cdrom centos6.3.iso

                                Comment

                                Working...
                                X