No announcement yet.

The Binary Blobs Making Up Coreboot

  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Wow. Already?

    That is amazing.

    In 2012 Carl-Daniel Hailfinger and I were on the barricades for including the binary blobs into the main repository.

    Congrats to Peter Stuge and google's Ron Minnich for _finally_ seeing the light.

    Edit: Oops, it seems that they did do that initially, but people got lax along the way.
    Last edited by libv; 02 March 2015, 04:33 PM.


    • #12
      Originally posted by curaga View Post
      This seems like a fairly easy task to start with. You don't have to know assembler to be able to translate between syntaxes, and you can likely expect a byte-identical result too once finished. The usual disclaimers, everything pulled out of ass, etc etc.
      There are some awful things* you can do with assembly macros, and sometimes for bare metal stuff you end up with things at weird alignments/positions that can be difficult to get set up right. But for the most part, yeah.

      *(I implemented an assembler for a virtual machine that runs on a microcontroller, using assembly macros. If that ain't twisted, I don't know what is. It actually works well except for having no way to print line numbers in response to errors. It makes mixing native assembly and the VM assembly easy though.)


      • #13
        IMO there is zero point in worrying about the microcode blob when you are already executing microcode on reset.


        • #14
          Originally posted by libv View Post
          In 2012 ...
          Oh really, that's a bit late, given that some of the files that were now moved originally appeared in the repository in 2009:


          • #15
            Originally posted by yuhong View Post
            IMO there is zero point in worrying about the microcode blob when you are already executing microcode on reset.
            As you can discern from one of the comments from Dec 14, 2013 on, the main reason is to make life easier for the libreboot team that feels strongly about the issue, and easier for us coreboot developers by reducing the volume of the libreboot complaints.


            • #16
              Also, those two are not comparable.

              CPU/GPU/APU manufacturer has much more to lose if it gets discovered that his micorcode was doing intentionally nasty stuff. Chip development costs big $$$.

              In contrast, binary blobs that get used to patch a chip after it is already on the market are much less exposed to such risk.

              You can never know who exactly made it, has it been tweaked with and even if you discover the scam, big deal, source will just have to try elsewhere and at some later time.


              • #17
                Do any of these blobs contain x86 executable code or is it all code that gets downloaded to various chips to make them run?