| commit | eeb15e83cbef6a1b402e91cd1305dd352fb0cc06 | [log] [tgz] |
|---|---|---|
| author | Walter Sonius <walterav1984@gmail.com> | Sat Jul 12 16:11:23 2025 +0200 |
| committer | Angel Pons <th3fanbus@gmail.com> | Mon Jul 28 13:45:35 2025 +0000 |
| tree | b5bf32b4250c4822c400df14544601fae38dbcfe | |
| parent | 5537ce7c2f85584652b396840988364dd0f22439 [diff] |
mb/gigabyte: Add ga-h81m-d2w (ITE8620E superio)
This board came virtually rebranded from a specific German OEM called
Wortmann AG and was identified as "TERRA_PC/H81M-D2W" model: 1009381.
It however ships a GIGABYTE GA-H81M-D2W rev 1.0 branded motherboard
which is extremely similar to a Retail GIGABYTE GA-H81M-D2V rev 1.0.
The only obvious differences are the onboard video outputs, its serial
connectivity and total abscence of it on the GIGABYTE support website.
- GA-H81M-D2W
DVI-D + DVI-I + serial port header on motherboard
- GA-H81M-D2V
DVI-D + VGA + DB9 serial port connector on backplate
Mainboard: GIGABYTE GA-H81M-D2W rev 1.0
Pure autoport (initial commit) doesn't boot, second patch brings up
general Haswell fixes, vendor/product naming corrected, RAM SPD MAP
slot detection, PCIe fixes enabling onboard LAN and other PCIe slots
and some IT8625E superio code from a other coreboot port made most
ITE8620E superio related functions work, especially WDT otherwise this
board resets every couple of seconds! Autoport did log hda codec / pins
but it didn't include them in the hda_verb.c, so I added them manually
which also fixes pcspkr (beep codes, not soundcard connected).
Flash instructions:
Internal flashing using flashrom works on OEM and when running coreboot
using the following command: flashrom -p internal -c "MX25L6473F" -w ROM
An external flasher ch341a_spi (3.3v mod) used with a SOIC 8 pomona
probe to recover the MX25L6473F in situ also works without issues. Only
the power of the USB programmer was used, and the board's main PSU was
disconnected during external flash!
Tested:
- coreboot 25.06-77-g812d0e2f626d as base
- EDK2 (MrChromebox/2502)
- SeaBIOS 1.16.3
- Broadwell mrc.bin (tidus)
- Haswell mrc.bin (peppy used for all mrc.bin noted testing)
- Haswell NRI
- libgfxinit textmode (SeaBIOS) / framebuffer (EDK2)
- DVI-D & DVI-I (VGA) all work during POST, BOOT and OS
- Pentium G3220 / Xeon E3-1225 v3 / Xeon E3-1231 v3
- RAM single and dual slot 2GB/4GB/8GB mixed DDR3 DIMMS max 6, 8, 16GB
(NRI & mrc.bin)
0/2: 2GB DDR3-1333 - Kingston 99U5458-001.A00LF (2010-W29)
0&2: 4GB DDR3-1600 - Kingston 9905402-174.A00G (2015-W33)
0/2: 2GB DDR3-1600 - Micron 8JTF25664AZ-1G6M1 (2013-W37)
0/2: 4GB DDR3-1600 - Samsung M378B5173BH0-CK0 (2013-W30)
(NRI single DIMM won't mix with others)
0/2: 8GB DDR3-1600 - SK Hynix HMT41GU6MFR8C-PB (2023-W20)
(ECC UDIMM, mrc.bin only, see NRI note below)
0&2: 4GB DDR3-1600 ECC - Kingston 9965432-051.A00LF (2013-W19)
0&2: 8GB DDR3-1866 ECC - Micron 18JSF1G72AZ-1G9E1 (2013-W29)
- Fedora MATE 42 (Kernel 6.14)
- KDE NEON 6.4 (Kernel 6.11)
- MS Windows 10 / 11
- Audio Outputs both DVI > HDMI, Headphone, Line Out (left&right chan.)
- Audio Input Line In (back)
- pcspkr
- USB2/3 all Intel ports
- SATA 4 ports
- PCIe slots (16x 5GT/s & both 1x 5GT/s)
- iGPU (plus dGPU as in dual GPU work both with mrc.bin / Haswell NRI)
- dGPU (nVidia GeForce GT640-2GD3 2.5GT/s / Radeon HD7770-1GB 5GT/s)
- Realtek RTL8111F onboard Gb LAN
- Wake on LAN
- HWM shows both fan speeds and voltages
- PS/2 port (both Keyboard and Mouse with Y splitter cable)
- Serial port header (coreboot console & OS)
- PowerButton (Poweron/Poweroff/Wake)
- ResetButton
- LEDs HDD & POWER (off during suspend)
- Shutdown/Reboot/Suspend
- Strip down the Intel ME/TXE firmware (make menuconfig) see ME note!
- Disabling ME HECI (manually remove from devicetree.cb) see ME note!
- flashrom -p internal -c "MX25L6473F" #read & write
Not tested:
- Audio Inputs Front & Back Microphone Ports
- parallel port header
- USBDEBUG
- VBIOS
Not working:
- Disable Intel ME PCI interface (make menuconfig)
- USB2/3 all VIA VL805 backpanel ports
FD layout note:
The original OEM firmware ships a BIOS region that seem to use the
whole firmware:
00000000:00000fff fd
00000000:007fffff bios
00001000:001fffff me
Although coreboot works fine with this flash descriptor layout it is
mandatory to flash a complete image! Replacing only a specific region
like the BIOS region when relying on --ifd will confuse flashrom and
trash the flash chip's contents! As a temporary measure one can use
--layout to flash a specific region using the following layout:
00000000:00000fff fd
00001000:001fffff me
00200000:007fffff bios
Permanently changing the flash descriptor layout to look like this will
solve flashing specific regions and remains a valid option since it
cannot break GIGABYTE its DualBIOS feature since its absent.
NRI note:
EDK2 shows 0GB instead of the actual RAM amount installed. While using
Haswell mrc.bin EDK2 shows the correct amount of RAM. The earlier noted
RAM modules have also been tested using NRI in Memtest86+ v7.20 which
still correctly displays and test the total amount of RAM.
ECC UDIMMs currently do not work on this board because NRI does
not check whether the board / chipset support ECC. This results
in RCVET failures for the ECC bytelane (byte 8). Eventually this
will be fixed in NRI. Haswell mrc.bin works as expected.
ME note:
Neutering the ME will let the system still function correctly, unless
you include EFFS and FCRS partitions addressed by ME_CLEANER_ARGS:
"-S --whitelist EFFS,FCRS"
Failing to supply these ME partitions will cripple superio functions as
in serial output (breaks coreboot serial console) and HWM fan and
voltage info goes random nuts while the fan stays at normal speed.
VIA VL805 note:
Without firmware loading (which is still unknown) and enabling it in the
devicetree.cb will give DMAR IOMMU errors therefore disabled by default!
The data.vbt blob was extracted using debugfs from the OEM F5 firmware
which enables both video outputs DVI-D and DVI-I (VGA).
Since this board is not listed on the GIGABYTE website, but it works
with the Retail GA-H81M-D2V F6 firmware I listed that one instead in the
board_info.txt. However I cannot confirm that this coreboot port also
works for the GA-H81M-D2V, it is good practice to at least check its
gpio values matching this port!
Change-Id: I80dc414a92d115099ec8966841af0cf22d5b1d09
Signed-off-by: Walter Sonius <walterav1984@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88412
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
coreboot is a Free Software project aimed at replacing the proprietary firmware (BIOS/UEFI) found in most computers. coreboot performs the required hardware initialization to configure the system, then passes control to a different executable, referred to in coreboot as the payload. Most often, the primary function of the payload is to boot the operating system (OS).
With the separation of hardware initialization and later boot logic, coreboot is perfect for a wide variety of situations. It can be used for specialized applications that run directly in the firmware, running operating systems from flash, loading custom bootloaders, or implementing firmware standards, like PC BIOS services or UEFI. This flexibility allows coreboot systems to include only the features necessary in the target application, reducing the amount of code and flash space required.
All source code for coreboot is stored in git. It is downloaded with the command:
git clone https://review.coreboot.org/coreboot.git.
Code reviews are done in the project's Gerrit instance.
The code may be browsed via coreboot's Gitiles instance.
The coreboot project also maintains a mirror of the project on github. This is read-only, as coreboot does not accept github pull requests, but allows browsing and downloading the coreboot source.
After the basic initialization of the hardware has been performed, any desired “payload” can be started by coreboot.
See https://doc.coreboot.org/payloads.html for a list of some of coreboot's supported payloads.
The coreboot project supports a wide range of architectures, chipsets, devices, and mainboards. While not all of these are documented, you can find some information in the Architecture-specific documentation or the SOC-specific documentation.
For details about the specific mainboard devices that coreboot supports, please consult the Mainboard-specific documentation or the Board Status pages.
Releases are currently done by coreboot every quarter. The release archives contain the entire coreboot codebase from the time of the release, along with any external submodules. The submodules containing binaries are separated from the general release archives. All of the packages required to build the coreboot toolchains are also kept at coreboot.org in case the websites change, or those specific packages become unavailable in the future.
All releases are available on the coreboot download page.
Please note that the coreboot releases are best considered as snapshots of the codebase, and do not currently guarantee any sort of extra stability.
The coreboot build, associated utilities and payloads require many additional tools and packages to build. The actual coreboot binary is typically built using a coreboot-controlled toolchain to provide reproducibility across various platforms. It is also possible, though not recommended, to make it directly with your system toolchain. Operating systems and distributions come with an unknown variety of system tools and utilities installed. Because of this, it isn't reasonable to list all the required packages to do a build, but the documentation lists the requirements for a few different Linux distributions.
To see the list of tools and libraries, along with a list of instructions to get started building coreboot, go to the Starting from scratch tutorial page.
That same page goes through how to use QEMU to boot the build and see the output.
Further details on the project, as well as links to documentation and more can be found on the coreboot website:
You can contact us directly on the coreboot mailing list:
https://doc.coreboot.org/community/forums.html
There are many files in the coreboot tree that we feel are not copyrightable due to a lack of creative content.
“In order to qualify for copyright protection in the United States, a work must satisfy the originality requirement, which has two parts. The work must have “at least a modicum” of creativity, and it must be the independent creation of its author.”
https://guides.lib.umich.edu/copyrightbasics/copyrightability
Similar terms apply to other locations.
These uncopyrightable files include:
As non-creative content, these files are in the public domain by default. As such, the coreboot project excludes them from the project's general license even though they may be included in a final binary.
If there are questions or concerns about this policy, please get in touch with the coreboot project via the mailing list.
The copyright on coreboot is owned by quite a large number of individual developers and companies. A list of companies and individuals with known copyright claims is present at the top level of the coreboot source tree in the ‘AUTHORS’ file. Please check the git history of each of the source files for details.
Because of the way coreboot began, using a significant amount of source code from the Linux kernel, it's licensed the same way as the Linux Kernel, with GNU General Public License (GPL) Version 2. Individual files are licensed under various licenses, though all are compatible with GPLv2. The resulting coreboot image is licensed under the GPL, version 2. All source files should have an SPDX license identifier at the top for clarification.
Files under coreboot/Documentation/ are licensed under CC-BY 4.0 terms. As an exception, files under Documentation/ with a history older than 2017-05-24 might be under different licenses.
Files in the coreboot/src/commonlib/bsd directory are all licensed with the BSD-3-clause license. Many are also dual-licensed GPL-2.0-only or GPL-2.0-or-later. These files are intended to be shared with libpayload or other BSD licensed projects.
The libpayload project contained in coreboot/payloads/libpayload may be licensed as BSD or GPL, depending on the code pulled in during the build process. All GPL source code should be excluded unless the Kconfig option to include it is set.
Since 2017, coreboot has been a member of The Software Freedom Conservancy, a nonprofit organization devoted to ethical technology and driving initiatives to make technology more inclusive. The conservancy acts as coreboot's fiscal sponsor and legal advisor.