summaryrefslogtreecommitdiff
path: root/util/fuzz-tests/description.md
diff options
context:
space:
mode:
authorAngel Pons <th3fanbus@gmail.com>2022-10-07 02:29:34 +0200
committerFelix Held <felix-coreboot@felixheld.de>2024-05-08 11:56:35 +0000
commitf5105313cf6933d283ce6e66429f5d1001cd66ff (patch)
tree439d8429e5ea3cfcdb180017be7b77eeb40fa48e /util/fuzz-tests/description.md
parentb816b186f094a117c5aed743176db5a92033b440 (diff)
mb/asrock/z97_extreme6: Add new mainboard
That's an ATX mainboard with a LGA1150 socket and four DDR3 DIMM slots. Porting was done using autoport and then doing a bunch of manual edits. This board has two socketed DIP-8 SPI flash chips and a physical switch to choose which one should the system boot from. As long as one of them contains a bootable firmware image, it is possible to reflash the other chip using the internal programmer by flipping the switch after booting to OS. Even if one somehow manages to flash unbootable firmware to both chips, they are socketed: one can carefully remove them from the socket and reflash them externally, which is a relatively safe procedure (when compared to in-circuit flashing, especially if the board isn't designed to safely be flashed in-circuit). In short, the board is hard to brick. Haswell MRC.bin cannot be used because it lacks support for the Z97 PCH found on this mainboard. Broadwell MRC.bin only works with Haswell CPUs so far, as raminit fails on Broadwell CPUs for an unknown reason. Maybe it's something about RcvEn, but it's unlikely it can easily be fixed. Working: - All four DIMM slots - Broadwell MRC.bin for raminit purposes - Serial port to emit spam - POST code display - S3 suspend/resume - All rear USB 3.0 ports - Internal USB 2.0 port - Audio output (green jack) - Integrated graphics (libgfxinit) - HDMI - VBT - Intel GbE (I218-V PHY and PCH MAC) - Realtek RTL8111E GbE - At least one SATA port - M2_1 slot (Gen3 x4, bifurcated from CPU) - Flashing internally with flashrom - SeaBIOS (current version) to boot Arch Linux - NCT6791D Super I/O software-based fan control tested using `sensors` and `pwmconfig`, all 6 fan tachometers and 5 PWM outputs work fine. Untested for now (i.e. should work, will eventually test): - DVI-I, DisplayPort - EHCI debug - Front USB 2.0 and 3.0 ports - The other audio jacks (as well as SPDIF) - The other PCIe and M.2 ports - Non-Linux OSes - PS/2 combo port (can only test with a keyboard) Untestable (i.e. cannot test due to unavailable hardware): - Thunderbolt AIC (Add-In Card) support Not working: - Broadwell CPUs, they require more magic to work (working on it). - Booting from ASM1062 SATA ports with SeaBIOS. Other payloads were not tested. It seems that the problem is with the controllers. - Super I/O automatic fan control: not yet implemented in coreboot. To control fans, use software fan control methods in the meantime. - Acer B247Y board driving a FHD panel of a Samsung S24E650 monitor, connected to the board's HDMI output says "Unsupported resolution" after libgfxinit configured the iGPU outputs in linear framebuffer mode. HDMI output works fine after Linux's i915 driver takes over. Not sure if it's specific to the monitor: the HDMI cable is beaten up, and it is hard to replace (need to relocate the logic board so that the ports are accessible). Change-Id: If1d22547725e59f435de36b973e1bf4f334269a9 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/68188 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Máté Kukri <kukri.mate@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Diffstat (limited to 'util/fuzz-tests/description.md')
0 files changed, 0 insertions, 0 deletions