I'm building something and I'm wondering if anyone connect this PCIe Backplane to normal ATX power supply direct ?
Gigabyte MJ11-EC1 EPYC 3151 Mystery
- Thread starter BMacD
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
I've managed to get myself quite locked out of my machine. My server running password manager had some trouble yesterday and as a result I lost my IPMI password and access to the host OS (TrueNAS).
I can still SSH to BMC. Is there any way to reset the IPMI interface password from there? Or is there any way to reset BMC to defaults on this board?
My only other option available seems to be to get VGA cable and adapter so that I can get video output from the VGA port, reset the TrueNAS password that way and then reset IPMI password through ipmitool inside TrueNAS.
E1: ... And the VGA does not work on my board. This is not a good situation.
E2: Phew, had one SSH Public key sent to server. Got access again!
I can still SSH to BMC. Is there any way to reset the IPMI interface password from there? Or is there any way to reset BMC to defaults on this board?
My only other option available seems to be to get VGA cable and adapter so that I can get video output from the VGA port, reset the TrueNAS password that way and then reset IPMI password through ipmitool inside TrueNAS.
E1: ... And the VGA does not work on my board. This is not a good situation.
E2: Phew, had one SSH Public key sent to server. Got access again!
Last edited:
I got the full box with the 10x pcie and have been losing my mind on why it won't even one GPU. Any ideas?
- tried in F09 and F02
- Tried enabling SL_SAS to pcie, and change the different pcie modes
- updated BMC (pcie inventory shows no pcie devices)
-Booted windows and the Device manager didn't show anything, although it shows many pcie bridges
- power is connected to the board
- 3 psus are plugged, 1 orange (also tried with just 1 or just 2 psu)
- tried with both SMT, AER enabled and disabled
- tried a P40, a 2080ti, a 1060 and a sata controller
Getting desperate as I spent 300 on this apparent 4U paperweight
Thanks
- tried in F09 and F02
- Tried enabling SL_SAS to pcie, and change the different pcie modes
- updated BMC (pcie inventory shows no pcie devices)
-Booted windows and the Device manager didn't show anything, although it shows many pcie bridges
- power is connected to the board
- 3 psus are plugged, 1 orange (also tried with just 1 or just 2 psu)
- tried with both SMT, AER enabled and disabled
- tried a P40, a 2080ti, a 1060 and a sata controller
Getting desperate as I spent 300 on this apparent 4U paperweight
Thanks
A bit late for the party but for reference, a workaround would be to use easy2boot to manually boot from the drive. Not elegant but good for emergencies
Hey all, have been trying to update to the latest BMC firmware (12.61.17 -> 12.61.39) from the BMC itself and it keeps failing verification constantly. I reckon it needs an intermediate set of versions. Anyone done this successfully or am I looking at having to use a different method?
Might be late, and not answering your question, I apologise for which. But imho it's rarely a good idea to update bios or bmc firmware unless there's a new feature you want to take advantage of, or something is genuinely not working. In my expirience it's more of a headache to upgrade, also the chance of something breaking is too high.
Maybe there is something going wrong with the extraction, or the file itself is corrupt. Also could try to Restore Factory Defaults your bmc and try the update then. But make sure you have a backup as well, you never know.
Anyway you shouldn't need any intermediate versions. this fimware should work:
MC12-LE0 (rev. 1.x) | Workstation Motherboard - GIGABYTE Germany
Single AMD Ryzen™ 5000/4000/3000 Series ProcessorsDual Channel UDIMM DDR4, 4 DIMMs2 x 1Gb/s LAN ports via Intel® I210-AT6 x SATA 6Gb/s ports1 x M.2 slot with PCIe Gen3 x1 inter...
You could also try to do it under linux, or windows I guess, should return more usefull logs.
EDIT: spelling
Last edited:
Reporting happily that this setting works for me. Running 4x32G SK Hynix HMA84GR7MFR4N-UH (dual rank) without ECC errors.
Besides, i had to set the pcie_aspm=off as a bootable flag.
Can anyone point me to the german forum? I can't find it and i'd like to know as much as possible about this board.
Cheers!
Gigabyte MJ11-EC1 NAS Server
Bei Ram-König werden gerade ITX Mainboard's mit AMD EPYC 3151 für 69€ Verschleudert. Das Mainboard kommt Inkl. dem ATX Adapter versandkostenfrei. Leider hat das Mainboard keinen PCI-e Slot dafür. Jedoch einen M2 Slot und bis zu 16 SATA Laufwerke passen an das Mainboard. Als Speicher wird u.a...
www.hardwareluxx.de
Why are you setting pcie_aspm=off ? Did you already disabled both onboard Intel NICs?
Gigabyte MJ11-EC1 NAS Server
Bei Ram-König werden gerade ITX Mainboard's mit AMD EPYC 3151 für 69€ Verschleudert. Das Mainboard kommt Inkl. dem ATX Adapter versandkostenfrei. Leider hat das Mainboard keinen PCI-e Slot dafür. Jedoch einen M2 Slot und bis zu 16 SATA Laufwerke passen an das Mainboard. Als Speicher wird u.a...
I got these BadDLLP warnings (Correctable PCIe Bus Error) flooding my logs.
Disabling the onboard Intel NICs is something i will try out soon. Thanks for the suggestion!
Hi all, thanks for all the great info about this board!
I’ve gotten 3 of those and of course they did not behave the same from the beginning! To begin with, two of the boards did not POST with neither 1 nor 2 Samsung M393A4K40BB1 - CRC4Q 32GB RDIMMS in the blue slots. The third one POST without issues with 4 of those without having to change anything in BIOS.
What solved the 2 other boards issue, was to clear CMOS. After clearing it, the board POST directly with 4 DIMMS installed. I then adjusted ONLY the clock speed to 1067MHz just to be on the safe side.
I ran MemTest86 on all boards and no errors have been detected.
I have also updated the BMC to the latest 12.61.39 FW and everything kept working. I have shut the boards down for a couple of days now, so I wonder if they will POST directly or if I’ll have to do some magic there again.
question I have, do any of you see any downside in not setting the other values as suggested in the posts before?
AMD CBS -> UMC Common Options -> DDR4 Common Options -> Data Bus Configuration:
RTTnom 7
RTTwr Dynamic ODT off
RTTpark 2
~ >DRAM Timing Configuration:
Memory Clock Speed 1067MHz
Trcdrd 10h
Trcdwr 10h
Trp 10h
ProcODT 48 Ohm
Like I mentioned, the only change I did was to the Clock Speed to 1067MHz.
Thanks again and let’s hope I manage to make this board stable with 128gb memory and a 10gbps NIC!
I’ve gotten 3 of those and of course they did not behave the same from the beginning! To begin with, two of the boards did not POST with neither 1 nor 2 Samsung M393A4K40BB1 - CRC4Q 32GB RDIMMS in the blue slots. The third one POST without issues with 4 of those without having to change anything in BIOS.
What solved the 2 other boards issue, was to clear CMOS. After clearing it, the board POST directly with 4 DIMMS installed. I then adjusted ONLY the clock speed to 1067MHz just to be on the safe side.
I ran MemTest86 on all boards and no errors have been detected.
I have also updated the BMC to the latest 12.61.39 FW and everything kept working. I have shut the boards down for a couple of days now, so I wonder if they will POST directly or if I’ll have to do some magic there again.
question I have, do any of you see any downside in not setting the other values as suggested in the posts before?
AMD CBS -> UMC Common Options -> DDR4 Common Options -> Data Bus Configuration:
RTTnom 7
RTTwr Dynamic ODT off
RTTpark 2
~ >DRAM Timing Configuration:
Memory Clock Speed 1067MHz
Trcdrd 10h
Trcdwr 10h
Trp 10h
ProcODT 48 Ohm
Like I mentioned, the only change I did was to the Clock Speed to 1067MHz.
Thanks again and let’s hope I manage to make this board stable with 128gb memory and a 10gbps NIC!
Got SYS_FAN working on BMC firmware v12.61.39 yesterday, without SSH access.
Newer firmware versions disable BMC SSH completely, so running bmcprog directly on the BMC, as discussed earlier in this thread, was no longer an option. JTAG was not something I felt comfortable attempting at the time either.
Fortunately, I had a spare board available, which allowed me to work through and validate the entire process before touching the main system. It turns out that bmcprog is simply an ARM binary contained in the firmware root filesystem. You can extract it from a full gigaflash -dump image, run it under qemu-arm in a disposable VM, and use it to compile a valid SKU.BIN without requiring BMC shell access.
I tested the complete procedure on the spare board first and then applied it successfully to the production system.
I documented the full process here, in case it is useful to anyone else:
GitHub - Gizmo-Ger/sys-fan-mj11-g431mm0: SYS_FAN sensor unlock + custom fan curves for Gigabyte MJ11-EC1/G431-MM0 BMC boards
This was honestly a project I had been putting off for quite some time. I had known about both the SSH-based method and the JTAG approach for a while, but never found the time or motivation to work through it properly. A failed USB-TTL adapter and a rainy Sunday afternoon finally pushed me to investigate an alternative approach. AI also helped me structure and polish the documentation, which is what finally got the project over the line.
The method worked cleanly on both of my boards, but please verify every step yourself before attempting it on your own hardware.
The result is a noticeably quieter system now that the case fans are properly detected and controllable instead of running at full speed.
One additional finding while digging through the BMC config partition:
On the locked firmware, the sysadmin account does not appear to be disabled at the account level. Instead, ssh_server_config simply contains:
DenyUsers sysadmin
The account itself still has a valid password hash and UID 0.
I have not yet tested whether gigaflash -restore also restores this file. According to the documentation, -restore does restore user-related settings, while deliberately leaving FRU/SKU identity data untouched. It is therefore possible that removing the DenyUsers sysadmin line from a config backup and restoring it may re-enable SSH without requiring the full repack-and-write procedure used for the SKU fix.
If -restore does not touch this file, the same extraction, repacking, and flashing approach may be required.
Anyone who still has a board with working BMC SSH access could test this much more quickly than I can on a locked board.
Newer firmware versions disable BMC SSH completely, so running bmcprog directly on the BMC, as discussed earlier in this thread, was no longer an option. JTAG was not something I felt comfortable attempting at the time either.
Fortunately, I had a spare board available, which allowed me to work through and validate the entire process before touching the main system. It turns out that bmcprog is simply an ARM binary contained in the firmware root filesystem. You can extract it from a full gigaflash -dump image, run it under qemu-arm in a disposable VM, and use it to compile a valid SKU.BIN without requiring BMC shell access.
I tested the complete procedure on the spare board first and then applied it successfully to the production system.
I documented the full process here, in case it is useful to anyone else:
GitHub - Gizmo-Ger/sys-fan-mj11-g431mm0: SYS_FAN sensor unlock + custom fan curves for Gigabyte MJ11-EC1/G431-MM0 BMC boards
This was honestly a project I had been putting off for quite some time. I had known about both the SSH-based method and the JTAG approach for a while, but never found the time or motivation to work through it properly. A failed USB-TTL adapter and a rainy Sunday afternoon finally pushed me to investigate an alternative approach. AI also helped me structure and polish the documentation, which is what finally got the project over the line.
The method worked cleanly on both of my boards, but please verify every step yourself before attempting it on your own hardware.
The result is a noticeably quieter system now that the case fans are properly detected and controllable instead of running at full speed.
One additional finding while digging through the BMC config partition:
On the locked firmware, the sysadmin account does not appear to be disabled at the account level. Instead, ssh_server_config simply contains:
DenyUsers sysadmin
The account itself still has a valid password hash and UID 0.
I have not yet tested whether gigaflash -restore also restores this file. According to the documentation, -restore does restore user-related settings, while deliberately leaving FRU/SKU identity data untouched. It is therefore possible that removing the DenyUsers sysadmin line from a config backup and restoring it may re-enable SSH without requiring the full repack-and-write procedure used for the SKU fix.
If -restore does not touch this file, the same extraction, repacking, and flashing approach may be required.
Anyone who still has a board with working BMC SSH access could test this much more quickly than I can on a locked board.
Last edited:
Awesome work!
I don't believe Gigabyte is blocking rolling back the BMC firmware on this board? Couldn't you just flash SKU.BIN from an old firmware version via SSH?
Fair point, and honestly, I never tested that myself. It is worth separating two different scenarios, though.
PeterF’s finding about signature verification specifically concerned a manually modified firmware image being rejected. Flashing an official, still-signed older Gigabyte release with the vendor’s own bmc_fw_update tool is a different question entirely. I genuinely do not know whether this board enforces anti-rollback protection or version fusing. Many OEM boards do not.
If rollback is allowed, then you are right: that would be a much simpler solution. Downgrade to a firmware release that still allows sysadmin SSH access, run bmcprog directly on the BMC as described in Path A of the write-up, and you are done.
The whole qemu-arm and bmcprog extraction route only exists because I assumed that downgrading would be blocked, without actually verifying it first.
One caveat for anyone considering this: a full BMC firmware reflash has a much larger blast radius than the config-partition-only changes described in my write-up. If an older firmware image is not fully compatible with a partition layout or configuration change introduced in a later release — unlikely, but not impossible — the resulting failure mode could be considerably worse than anything involved in my approach.
So, if possible, test it on a spare board first.
I will try to verify this myself and report back. If a downgrade works cleanly, it would make the entire qemu-arm and bmcprog extraction process unnecessary for anyone whose main goal is simply to regain SSH access.
Nice find that you can update the SKU with the gigaflash utility!
What I remember is that it is possible to construct the SKU.bin file manually. It is a gziped SKU.xml inserted in a file with som pointers and checksums. The first ones I did manually . But you first needs a starting point that is based on your board as there are serial numbers and Mac addresses inside.
While investigating the system and trying out different ways to change the model the access via the jtag and serial console was very useful, the log messages from the bmc bootup process gave a good knowledge of how the system works. I also completly dissassembled the BMC flash file, recreating the filesystems inside. I also introduced some hacks (telnet, nc, user and password files) and reassembled a modified BMC file, but never found out how to go around the signing of the file so could never flash it. It is probable that an raw unsigned file can be flashed from the uboot prompt. I never tested this as I only have one board.
My system has run continually for 2,5 years now! I really like it! I never bothered to update the BMC to never versions so have still ssh access.
It is good to see that someone continues to work on it and have done a good job where I and others stopped!
BR
Peter
Thanks for the detail — really useful, and matches what we independently ran into. Folded the key points into the repo's SYS_FAN_HOWTO.md: your SKU.BIN construction (gzip'd SKU.xml + pointers/checksums) lines up exactly with what build_sku_bin.sh does now, and it's good confirmation that starting from your own board's dump is a hard requirement, not just caution, given the serials/MACs baked in.
The u-boot theory is the one I want to chase. Turns out I actually have two of these boards, so I can risk one testing whether a raw unsigned image really does flash from the u-boot prompt without hitting the signature check. If it works, it'd solve both your full-firmware-mod dead end and an open question on our end — whether there's a gigaflash write mode that accepts a full JFFS2 partition image, which we'd need for a persistent SSH fix instead of the current manual per-boot edit.
Before I try it — anything you remember about the u-boot prompt itself on these boards (how to break into it, command syntax available, whether it's stock AMI/AST2500 u-boot or Gigabyte-modified)? Want to go in with as much as I can from your side before risking the spare.
Also glad to hear 2.5 years uptime — good sign the fan profile approach holds up long-term.
Thanks again for writing this up — genuinely helpful.
This may help you probe the u-boot environment and figure out what's possible: Introduction — Depthcharge 0.6.0 documentation
I stumbled across this a few months when I was tinkering with cross-flashing some EnGenius switches between model families.
Thanks for the lead. I will dig into it. Much appreciated. Finally found the time to dig into - it´s a goldmine ;-) @Dave Corder can´t thank you enough
Last edited:
Hi, has anyone tried connecting a SXM2 adapter board to this motherboard?
This adapterboard should work with just a cable SXM adapter board single, but I guess this dual board needs another SlimSAS i8 to work : SXM adapter board dual.
This adapterboard should work with just a cable SXM adapter board single, but I guess this dual board needs another SlimSAS i8 to work : SXM adapter board dual.