Gigabyte is refusing to provide GPL source code for BMC firmware

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

colo

New Member
Aug 28, 2024
6
19
3
Hello everyone :)

I've decided to try taking matters in my own hands a while ago, and started a (private for now) fork of OpenBMC (see the official upstream Github project) to port it to the MC12-LE0's BMC. I've made some real progress, as sparsely documented on both the OpenBMC mailing lists and a German online forum [0], [1]), and have OpenBMC kernel and userland deployed on my "alpha" board.

In the weeks spent on working on it, I've gone through several rounds of bricking and unbricking the board in various ways already, and managed to get a few important features working: fan control, most sensors and iKVM are mostly working OK on my OpenBMC port. Several other very crucial things are not working, and I've asked Gigabyte if they were kind enough to provide their board's schematics to me, so that I can stop the silly reverse engineering exercise of any and each GPIO pin found on the BMC, and just re-implement established, known configuration instead.

Unfortunately, they politely denied my request for these schematics today. I figured that, maybe, someone of STH's regulars knows someone who knows someone who could have another word with Gigabyte staff who'd may be able and willing to provide that kind of documentation to a hobbyist still. I think that with it, I have a real shot at making the MC12-LE0 a supported machine for OpenBMC (if no other show-stopping difficulties of another kind arise).


Since the stock BMC firmware pre-dates DeviceTree, I don't know of a method to extract the de facto DTS/DTB equivalent that would also probably sufficiently describe the GPIO wiring that I need to get this work done. If anyone amongst you knows how to perform this feat (and I do know about /etc/devmaps/MC12/MC12-LE0-00.xml already, and no, it is unfortunately far from sufficient :)), I'd be all ears and very eager to learn.


Thanks for all your time and support! :)
 
Last edited:

nasbdh9

Active Member
Aug 4, 2019
249
166
43
GIGABYTE once told me in 2022 that they were developing OpenBMC internally to replace AMI MegaRAC, but it has not been released to the public yet. :rolleyes:
 

colo

New Member
Aug 28, 2024
6
19
3
I guess it would make sense for them to be able to cut out the middleman (MegaRAC probably isn't gratis), but if their initiative led nowhere tangible over the last two years, I doubt that my particular target board would be in their list of platform to support. Which is a shame, because I'd expect that with schematics, it should be doable in a few weeks. I've had ~ 0 prior experience with *embedded* Linux development and embedded hardware in general, and I've been making good progress when not clogged up with rather frustrating reverse engineering total guesswork :)

Funnily enough, AMI themselves seem to have rebased their BMC firmware development efforts on OpenBMC (they have a "MegaRAC OneTree Community Edition" on Github, which is an outdated OpenBMC fork with a few custom, AST2600EVB-specific additions sprinkled over, really nothing to write home about imo), which can only be good, because what I've seen on my travels through the stock image is quite horrible in some of its more derelict corners :')
 

Firebat

New Member
Jan 12, 2022
14
3
3
[...]

Unfortunately, they politely denied my request for these schematics today. I figured that, maybe, someone of STH's regulars knows someone who knows someone who could have another word with Gigabyte staff who'd may be able and willing to provide that kind of documentation to a hobbyist still. I think that with it, I have a real shot at making the MC12-LE0 a supported machine for OpenBMC (if no other show-stopping difficulties of another kind arise).

[...]

Thanks for all your time and support! :)
@Patrick maybe you could do a favour here?
 

colo

New Member
Aug 28, 2024
6
19
3
So I've started to look at stock-FW binaries a bit with radare2 (my reversing skills are actually far too underdeveloped for a task like this unfortunately), and I've gleaned some interesting insights and made a discovery as a consequence. I think AMI might already be complying, at least in their view, with the GPL and other licenses for their MegaRAC products. I've found this on Github:


That's more than 60GB of (very badly, imo :() organized code that seems to correspond to much of that I can see in in compiled form in the stock image on my MC12-LE0's BMC firmware. They even seem to update their code- and patch-dumps fairly regularly.

Unfortunately, everything is delivered in such bad shape and form (multiple copies of the AMI source and patch tree versions next to each other, and mostly in the form of literal `diff` output per-project they effectively fork internally... I have a hard time understanding why they're using git repos to provide this chaotic heap of content, instead of provising separate branches per-release, or something like that. Maybe because they can externalize hosting costs to Github that way? :D) that it's very hard to make use of it for me.

They seem to have several generations of their MegaRAC software stacks in service and development/maintenance in parallel, and when a product/mainboard has been released on version N, I think it will be "stuck" on that major version, no matter if there are subsequent releases that update the software stack in a major way. That's my interpretation of the fact that the latest MC12-LE0 BMC fw release from this year still boots "3.14.xx-ami", even though there are several repos available that include Linux 5.x kernel tarballs (they might be specific to more recent BMC hardware designs, such as the AST2600 - I did not check in detail yet).

Afaict, the content available in OSSW/RR11.7 at master · ami-megarac/OSSW should have most of the relevant custom AMI stuff that makes the MC12-LE0's stock BMC FW tick: It has things such as the custom driver for /dev/reset (OSSW/RR11.7/reset-src at master · ami-megarac/OSSW) as well as most/all the custom AMI drivers thast were needed when ootb support for various AST-devices wasn't there in Linus' tree.

Since my goal is to get OpenBMC ported to this BMC, the task ahead is now to find and understand the AMI-custom kernel and userspace code that implements feature X, and to identify the OpenBMC replacement/equivalent for that mechanism and configuration, and then port the mechanism over to the OpenBMC equivalent. I am not sure yet if that is doable (for me), but I sure will try. Reverse engineering the inner workings of the stock FW is certainly made easier by having most of its source and important patches available, but it's still *far* from easy.

I still think having schematics available would be a great (and maybe even necessary) boon for my little project.
 

colo

New Member
Aug 28, 2024
6
19
3
Quite far, actually. I successfully unbricked my board's BMC numerous times, and brought it back from various states of lifeless hopelessness ;) Most of these instances I have documented (in German) on the hardwareluxx forums - a list of my postings there is available at Suchergebnisse (not all related to unbricking/OpenBMC development work, but many).

I have a private fork of OpenBMC's upstream repository that has, afaict, close to 100% support for the board at the kernel/driver level. I did manage to fix and figure out the power control magic via GPIOs on my own in the end, schematics or no ;)

What I haven't done so far (and I've been stuck in this state for more than three months, but have not actively worked on the project during that time at all) is configuring all the OpenBMC userspace bits to support such things as sensible sensor representation/logging, proper SEL decoding, webUI-based firmware upgrades, etc. All the basic support is there, but it will take another significant effort (and a re-engagement on my part with OpenBMC's perceived quirks and oddities :)) to make the OpenBMC fork a plausible replacement for the stock firmware. Only time will tell when I can make that happen.
 

voltagex

New Member
Aug 5, 2020
27
3
3
I have a private fork of OpenBMC's upstream repository that has, afaict, close to 100% support for the board at the kernel/driver level. I did manage to fix and figure out the power control magic via GPIOs on my own in the end, schematics or no ;)
Although this board seems to be almost impossible to source, I think it would still be valuable to open source your work.
 
  • Like
Reactions: colo

colo

New Member
Aug 28, 2024
6
19
3
... so I finally mustered the courage to push the git branch that is my 100% amateur/hobbyist attempt at bringing OpenBMC onto the Gigabyte MC12-LE0 (https://www.gigabyte.com/Enterprise/Server-Motherboard/MC12-LE0-rev-1x) AM4 mainboard (that I had just bought last year as an end user): openbmc/README.gigabyte.md at gigabyte-mc12-le0 · jtru/openbmc

I ended up publishing it because a kind soul (another amateur/hobbyist that has no prior exposure to OpenBMC whatsoever) had noticed bb forum and mailing list activities across the 'Net that I had generated while working on it, and contacted me a few weeks ago, offering to brick his board by collaborating with me on the endeavor. So I guess it kind of makes sense to also let people in here at least know about its existence :)

Thanks for everyone's attention, and have a nice day! 8)
 

colo

New Member
Aug 28, 2024
6
19
3
I took some time to create an installer script that can deploy compatible OpenBMC images (which are still terribly broken and do not offer all the required functionality you would expect from a proper BMC, because my changes to adapt OpenBMC to the MC12-LE0 have not yet advanced far enough) you can build from my repo/fork onto the board, given its MegaRAC BMC firmware is old enough to provide SSH access: GitHub - jtru/openbmc_gigabyte_mc12-le0_installer: Tools for flashing OpenBMC images onto the Gigabyte MC12-LE0 rev1.x mainboard series

That should help testing this down the road when it's in a state more suitable for public consumption :)
 
  • Like
Reactions: nasbdh9