Announcement

Collapse
No announcement yet.

The Binary Blobs Making Up Coreboot

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

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

    Leave a comment:


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

    Leave a comment:


  • pgeorgi
    replied
    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 http://review.coreboot.org/#/c/4531/, 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.

    Leave a comment:


  • pgeorgi
    replied
    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: http://review.coreboot.org/gitweb?p=...c0970dbb12bd2a

    Leave a comment:


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

    Leave a comment:


  • BradN
    replied
    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.)

    Leave a comment:


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

    Leave a comment:


  • curaga
    replied
    Originally posted by Adarion View Post
    I still do have some Geode LX machines, but sadly I am not a hacker to freshen up and polish the Geode sources.
    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.

    Leave a comment:


  • maligor
    replied
    Originally posted by Brane215 View Post
    methinks AMD's AGESA and equivalent counterparts are also a problem.

    AFAIK AMD offfers AGESA as prepackaged module that initializes HW in right order so that rest of the BIOS can carry it from there.

    I understand that they use binary as a way to control environmnent, but there should be open sauce alternativ for those that want to invest some time in it.
    Since I happen to have a coreboot clone due to looking at the IMB180 at one point, the binaries seemed to be VGA, XHCI and IMC, which I assume are really optional for bootup. (But I imagine the fan controller, vga and usb 3.0 won't work)

    I'm not really sure what you expect of AGESA. The only binaries in the AGESA sources (aside from the device firmwares mentioned above) in coreboot I found from a quick look was some CPU microcode tables. (I don't know if these are optional or not). But as I said, a quick look, someone who's worked on the AMD platforms would probably know better.

    I've been meaning to try it out and play around with it, I even have a stack of bios chips for a board (and programming tools), but too little time, too many computer games.
    Last edited by maligor; 02 March 2015, 06:32 AM. Reason: typo in board model

    Leave a comment:


  • WorBlux
    replied
    Originally posted by andyprough View Post
    It's a version called BeagleBone Black:


    Description: "BeagleBone Black is a low-cost, community-supported development platform for developers and hobbyists. Boot Linux in under 10 seconds and get started on development in less than 5 minutes with just a single USB cable."
    Just my own SWAG (scientific wild A guess) is that rig may rely on the onboard PRU microcontrollers to mediate the flash process.


    On second guess... just looks like it's leverage the linux spi protocol off of those headers.
    Last edited by WorBlux; 01 March 2015, 11:16 PM.

    Leave a comment:

Working...
X