coreboot

Walter Sonius wrote:

What to do next to get this "compaq_pro_6300_sff" variant officially supported?

*Supply more logs/info?
*Fill a bug for the ECC not working or first get this variant supported as is?
*Fill a bug that VGA doesn't work in SeaBIOS?
*Fill a bug/ticket on the flashrom support list for the difference in parameters needed pre/post flash?

https://support.hp.com/us-en/drivers/hp-compaq-pro-6300-small-form-factor-pc/model/5232884
https://support.hp.com/in-en/drivers/hp-compaq-elite-8300-small-form-factor-pc/model/5232855

Walter Sonius

If I read your report right, you got an unmodified coreboot for compaq_8300_elite_sff variant to boot and achieved partial but useful functionality. Great!

Usually to get support added for a new variant you would actually submit a patch via gerrit (see Documentation/ for details). However, if you would like someone else do it, please bundle up all the logs generated by autoport, one set while running vendor firmware (hope you got a backup) and another while running coreboot, and post them somewhere. With those I may be able to spin something up, as changes should be minimal, but timelines are not guaranteed, as most of us who work on ivybridge boards do it for free.

Keith Hui wrote in #note-1:
...

If I read your report right, you got an unmodified coreboot for compaq_8300_elite_sff variant to boot and achieved partial but useful functionality. Great!

Correct, almost everything works except the 4th black sata port and haven't tested the blue Audio jack line-in on the back. Will try the 4th sata port on OEM 3.08 firmware and report back.

Usually to get support added for a new variant you would actually submit a patch via gerrit (see Documentation/ for details). However, if you would like someone else do it, please bundle up all the logs generated by autoport, one set while running vendor firmware (hope you got a backup) and another while running coreboot, and post them somewhere. With those I may be able to spin something up, as changes should be minimal, but timelines are not guaranteed, as most of us who work on ivybridge boards do it for free.

Thank you for letting me know that gerrit is the preferred way of uploading/discussing new board support instead of the ticket. If you would see fit to spin up this variant, I can test the gerrit branch/pull request and will report back.

Note on the confusing naming of this particular model. This HP device comes with 3 stickers on the device, 2 of them note the wording order "pro_6300_sff" and 1 the "6300_pro_sff". Also autoports detects it as hp_compaq_pro_6300_sff compared to the hp_compaq_8300_elite_sff.

Therefor I think that "hp_compaq_pro_6300_sff" with "pro" preceding the model number vs "elite" trailing after the model number would be the right variant name?

Patch up: https://review.coreboot.org/c/coreboot/+/86869

Until you can set yourself up there, I'll also check this issue for reports.

• For the VGA port, you may want to try commenting "select GFX_GMA_ANALOG_I2C_HDMI_B" in Kconfig. See if removing it makes the VGA port work in SeaBIOS.
• The black SATA port is eSATA; you'll need the right cable. I made the sata_port_map change in the patch. Please test.
• Check your coreboot log that "early_usb_init: USB00: USBIR_TXRX_GAIN_MOBILE_LOW is an invalid setting for desktop!" no longer appears.
• WOL and iGPU+dGPU has been a long standing chipset issue that does need to be addressed, but they're bigger issue than just one board.
• Please also test edk2 payload. If you aren't set up for UEFI booting, try a live Linux distro.

Just confirming that SeaBIOS (version rel-1.16.3-0-ga6ed6b70) is also working with VGA output if "select GFX_GMA_ANALOG_I2C_HDMI_B" in Kconfig is removed just like the EDK2 tianocore UEFI results.

Also retested all PS2 ports (keyboard & mouse) and PCI and PCIe devices again including a PCIe 3.0 8x HP p420 HBA which was correctly detected as 8Gt 8x length.

However during testing of the SATA ports, there might be a regression since the 1st blue port also doesn't work anymore... only the white ones 2 and 3. That might be because of the 0xf to 0x6 port map change? Is 3 ports better than 2 instead of 4?

Just a few notes to correct and summarize the upcoming "compaq_pro_6300_series.md":
https://review.coreboot.org/c/coreboot/+/86869/3/Documentation/mainboard/hp/compaq_pro_6300_series.md
*The 6.8.0-52 kernel tested was part of KDE neon(ubuntu 24.04) not Fedora.
*The SuperIO only works with serial and ps2 ports not HWM fan nor voltage monitoring.
*VGA output both SeaBIOS / EDK2 and OS can be removed from known issues
*4 motherboard jc42 temperature sensors compared to 2
*suspend s3 and wake from power button works
*LEDs power and hdd work as expected

Apart from the SATA ports, this board seems kinda complete is 2 SATA ports enough to finish your pull?

Mmmm very interesting... Wake On LAN its working for onboard ethernet 82579LM currently. However note that the PCI slot is occupied with a RTL8169 (no cable), the PCIe J32 1x slot has a 82574L (no cable) and the lowest PCIe 1x slot has a RTL8125 (no cable) all doing nothing...

I also didn't have to disable the fake wake events in /proc/acpi/wakeup, maybe because the machine was on for a longer time and fell asleep itself instead of me forcing it?

Other connections alive are, USB 2.0 connections back(lower for USB keyboard upper for 8GB flashdrive KDE NEON live) lowest USB 3 port in back with USB 2.0 mouse, serial port, VGA port.

My guess is that these other PCI(e) devices doing nothing keep on some bus/power states during sleep which allows to wakeup up via the onboard ethernet? Will measure the Watt usage during 2nd sleep wake on lan event and let you know, previously without all the PCI(e) devices it was around 15Watt idle and 0Watt sleep.

Confirmed, its standby power in suspend is around ~3watt with Wake On Lan compared to ~0/1watt without working Wake On Lan. Will try again with only one PCIe ethernet adapter inserted (82579LM) in the system.

More interesting, wake on lan is now functioning while there is not a single extra PCI(e) card inserted and suspend power usage is around 0/1 watt. Its the SeaBIOS build btw that I'm running with KDE Neon Live from USB. The last thing I will try is boot with Displayport compared to VGA and see if the machine will wake, otherwise I have no idea why it didn't work with Wake On Lan in first place...

Even with Displayport instead of VGA and without a serial cable connected Wake On Lan is still working. Will try EDK2 tianocore UEFI again tomorrow to verify Wake On Lan is working 100%.

Walter Sonius wrote in #note-10:

Just confirming that SeaBIOS (version rel-1.16.3-0-ga6ed6b70) is also working with VGA output if "select GFX_GMA_ANALOG_I2C_HDMI_B" in Kconfig is removed just like the EDK2 tianocore UEFI results.

Also retested all PS2 ports (keyboard & mouse) and PCI and PCIe devices again including a PCIe 3.0 8x HP p420 HBA which was correctly detected as 8Gt 8x length.

However during testing of the SATA ports, there might be a regression since the 1st blue port also doesn't work anymore... only the white ones 2 and 3. That might be because of the 0xf to 0x6 port map change? Is 3 ports better than 2 instead of 4?

Great news about VGA port! The patch has been updated with this and SATA regression fixed. ESATA only differs in the connector shape; the protocol is same - actually SATA itself is supposed to be hotplug compatible if I understand right.

Just a few notes to correct and summarize the upcoming "compaq_pro_6300_series.md":
https://review.coreboot.org/c/coreboot/+/86869/3/Documentation/mainboard/hp/compaq_pro_6300_series.md
*The 6.8.0-52 kernel tested was part of KDE neon(ubuntu 24.04) not Fedora.
*The SuperIO only works with serial and ps2 ports not HWM fan nor voltage monitoring.
*VGA output both SeaBIOS / EDK2 and OS can be removed from known issues
*4 motherboard jc42 temperature sensors compared to 2
*suspend s3 and wake from power button works
*LEDs power and hdd work as expected

Apart from the SATA ports, this board seems kinda complete is 2 SATA ports enough to finish your pull?

We can work towards a solution later, but with VGA and blue SATA port fixed I think it's good enough for merging.

This will really finish it ;-)

4th Black SATA port Fixed by using portmap "0x3f" hinted from "z220_cmt_workstation" instead of "0xf". Portmap "0x10" only made the 4th black port working and broke all three others...

https://review.coreboot.org/c/coreboot/+/35829

Angel Pons did start this particular pro_6300 port more than 5 years ago but I haven't noticed it in the WIP(can be closed). At that time the port had issues with CPU FAN to loud continuously but as of today with your current template it behaves silent just as the OEM firmware.

First, thank you for your thorough testing.

Walter Sonius wrote in #note-14:

4th Black SATA port Fixed by using portmap "0x3f" hinted from "z220_cmt_workstation" instead of "0xf". Portmap "0x10" only made the 4th black port working and broke all three others...

What about 0x1f, which would be 0001 1111 (binary)? This would still hint, that there are five and not five ports. You could test the other iterations, and check if all other three ports keep working.

Walter Sonius wrote in #note-14:

This will really finish it ;-)

4th Black SATA port Fixed by using portmap "0x3f" hinted from "z220_cmt_workstation" instead of "0xf". Portmap "0x10" only made the 4th black port working and broke all three others...

Great news! Patch has been updated with 0x3f (see below).

Paul Menzel wrote in #note-15:

First, thank you for your thorough testing.

What about 0x1f, which would be 0001 1111 (binary)? This would still hint, that there are five and not five ports. You could test the other iterations, and check if all other three ports keep working.

This is the "ports implemented" map, and 0x3f enables all 6 SATA ports 7-series PCHs could ever have. Boards are supposed to zero the bits for ports that aren't actually on the board, but based on what Walter said, one of the ports between ports 0-3 is also not implemented - this board only has 4 SATA ports. To get at the correct value all six bits (ie. 0x01-0x20) will need to be tested to find out which port is which - and we now know port 4 (or the fifth) is black, port 0 is blue (for it supports 6Gbps and with its Q75 PCH it must be port 0) and port 5 is not implemented because that bit being 0 didn't break any physical port. But I'll wait for Walter's report before finalizing this value.

Walter Sonius wrote in #note-13:

The Wake On Lan feature is working perfectly with S3 suspend to RAM both on SeaBIOS and EDK2(mcb 2408) it doesn't need to disable false wake events mentioned earlier for the previous 8300_elite_sff based attempt. Wak On Lan even works now on (warm) boots (system shutdown before) not sure if that is called S5 or some special S4 mode(did not hibernate) but it just consumes around ~0-1 Watt!
Suspend to ram S3, can also be woken from USB keyboard (not mouse) and offcourse Power Button.
The Power LED also blinks in Suspend compared to continues on in normal operating mode.
The only thing blocking S3 suspend to RAM as in instantly waking after sleep is having a PS2 keyboard connected!

Sweet. These can be left for later, and WOL actually works.

All testing has been done with a non updated but active and normal functioning ME/TXE firmware version 8.1.31.1351 (generation 2) from the OEM firmware, see earlier coreboot logs and new log with ME disabled!

Just tried corna me_cleaner with option -S on the current running whole firmware file, reflashed and cold(first) boot seems a little bit slower with first a instant powerdown after poweron but than it continues itself powering on and booting. The operating systems just complaines about "mei_me" issues but that is expected and when waking from suspend the system notices that the mei pci device is not there. I'm aware that also during coreboot build there is an option to do the ME neutering, but since that is not default it may not be needed to test?

There is a config option to hide the ME if it fails. Turn it on if you neuter ME and all should be well.

For ECC RAM I will fill a separate bug if this pro_6300_sff/mt variant is officially merged.

All manuals only mention non-ECC memory, and knowing that with an i3 CPU you won't get ECC, and I have a feeling the ECC lines may not even be wired. I am 95% confident ECC is not supported on this model at all.

Still would recommend a note in the "compaq_pro_6300_series.md" about using flashrom while on coreboot firmware, both needed for -r read and -w write. Will continue that as a seperate issue in the flashrom tracker soon, but coreboot/flashrom new enthusiasts might panic if they cannot reflash again with simple syntax so this is the fix:
flashrom -p internal:boardmismatch=force,ich_spi_mode=hwseq -w test.rom -c "Opaque flash chip"

At this point coreboot is by geeks for geeks, although more layman-friendly documentation is always a good thing.

Thanks Keith, Martin and the Mr Jenkins ;-) for completing this pull request, you earn all the credits to the code and don't need to mention me.

Mr. Jenkins is a QC bot. ;-)

One more thing Walter.

In mainboard/hp/snb_ivb_desktops/devicetree.cb, can you try changing

register "gen1_dec" = "0x00fc0601" to
register "gen1_dec" = "0x00fc0a01"

and report back if HWM and fan would work?

It's a hint from https://review.coreboot.org/c/coreboot/+/79745

Paul Menzel wrote in #note-15:

What about 0x1f, which would be 0001 1111 (binary)? This would still hint, that there are five and not five ports. You could test the other iterations, and check if all other three ports keep working.

Also patched 0x3f to 0x1f and all 4 sata ports are still functioning would this be preferred like the WIP 8300_cmt variant, or do all other values need to be tested 0x3 0x7 0x10-0x20?

Keith Hui wrote in #note-17:

One more thing Walter.

In mainboard/hp/snb_ivb_desktops/devicetree.cb, can you try changing

register "gen1_dec" = "0x00fc0601" to
register "gen1_dec" = "0x00fc0a01"

Changed this from "6>a" but didn't notice any difference in "lm-sensors" output nor sensors-detect. Do I have to do some foo modprobe a certain module since nct6775 force_id=0x0b00 or 1c11 won't do anything or patch certain gpio.c as in the 8300 cmt variant? The superiotool from the coreboot/util just fails at the beginning with a false ASPEED detected.

sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +31.0°C  (high = +85.0°C, crit = +105.0°C)
Core 0:        +30.0°C  (high = +85.0°C, crit = +105.0°C)
Core 1:        +21.0°C  (high = +85.0°C, crit = +105.0°C)
Core 2:        +20.0°C  (high = +85.0°C, crit = +105.0°C)
Core 3:        +28.0°C  (high = +85.0°C, crit = +105.0°C)

jc42-i2c-0-1a
Adapter: SMBus I801 adapter at 0400
temp1:        +25.2°C  (low  =  +0.0°C)                  ALARM (HIGH, CRIT)
                       (high =  +0.0°C, hyst =  +0.0°C)
                       (crit =  +0.0°C, hyst =  +0.0°C)

jc42-i2c-0-18
Adapter: SMBus I801 adapter at 0400
temp1:        +26.5°C  (low  =  +0.0°C)                  ALARM (HIGH, CRIT)
                       (high =  +0.0°C, hyst =  +0.0°C)
                       (crit =  +0.0°C, hyst =  +0.0°C)

jc42-i2c-0-1b
Adapter: SMBus I801 adapter at 0400
temp1:        +22.0°C  (low  =  +0.0°C)                  ALARM (HIGH, CRIT)
                       (high =  +0.0°C, hyst =  +0.0°C)
                       (crit =  +0.0°C, hyst =  +0.0°C)

jc42-i2c-0-19
Adapter: SMBus I801 adapter at 0400
temp1:        +24.2°C  (low  =  +0.0°C)                  ALARM (HIGH, CRIT)
                       (high =  +0.0°C, hyst =  +0.0°C)
                       (crit =  +0.0°C, hyst =  +0.0°C)

Perhaps Riku Viitanen could clarify what - Super I/O: fan speeds stay in control means?

There is a config option to hide the ME if it fails. Turn it on if you neuter ME and all should be well.

Can confirm that both the ME neutering option and the hide MEI device on error option selected in make menuconfig also work as expected, ME disabled and no more dmesg errors.

Walter Sonius wrote in #note-18:

Paul Menzel wrote in #note-15:

What about 0x1f, which would be 0001 1111 (binary)? This would still hint, that there are five and not five ports. You could test the other iterations, and check if all other three ports keep working.

Also patched 0x3f to 0x1f and all 4 sata ports are still functioning would this be preferred like the WIP 8300_cmt variant, or do all other values need to be tested 0x3 0x7 0x10-0x20?

Only three values remain to be tested: 0x1d, 0x17, 0x1b. Test them in this order. If my understanding is correct, one of them will leave all SATA ports working, which will be the final value we need. My bet is on 0x1d, but I don't know for sure.

Keith Hui wrote in #note-17:

One more thing Walter.

In mainboard/hp/snb_ivb_desktops/devicetree.cb, can you try changing

register "gen1_dec" = "0x00fc0601" to
register "gen1_dec" = "0x00fc0a01"

Changed this from "6>a" but didn't notice any difference in "lm-sensors" output nor sensors-detect. Do I have to do some foo modprobe a certain module since nct6775 force_id=0x0b00 or 1c11 won't do anything or patch certain gpio.c as in the 8300 cmt variant? The superiotool from the coreboot/util just fails at the beginning with a false ASPEED detected.

Perhaps Riku Viitanen could clarify what `- Super I/O: fan speeds stay in control` means? 

These LPC bus port decodes are from your logs. But the output here says the temp sensors are on the SMBus, meaning the ports aren't doing anything.

I have a patch that modifies superiotool to be able to dump NPCD378:
https://review.coreboot.org/c/coreboot/+/82627

Will be interesting to see if it can get some info out of an NPCD379. Just patch, build, and run - under vendor firmware please. You may have to hack it further to force its hands.

Keith Hui wrote in #note-19:

Only three values remain to be tested: 0x1d, 0x17, 0x1b. Test them in this order. If my understanding is correct, one of them will leave all SATA ports working, which will be the final value we need. My bet is on 0x1d, but I don't know for sure.

Will test these remaining three values and report.

Perhaps Riku Viitanen could clarify what - Super I/O: fan speeds stay in control means?

https://review.coreboot.org/c/coreboot/+/26050
I might understand what Riku meant, on the Libreboot website I found notice on the "8200_elite_sff" referring to psu_fan_lvl=3 which can be set by nvram variable. I checked the current hp/snb_ivb_desktops code and all is already there for all other variants as well. However its missing the build option to enable nvram.

sudo nvramtool -a
nvramtool: CMOS option table not found in coreboot table.  Apparently, the coreboot installed on this system was built without selecting CONFIG_USE_OPTION_TABLE.

Where do I enable this during coreboot compile since it isn't mentioned under general "CONFIG_USE_OPTION_TABLE" or is it the new radio button "Option backend to use (Use CMOS for configuration values)"?

These LPC bus port decodes are from your logs. But the output here says the temp sensors are on the SMBus, meaning the ports aren't doing anything.
I have a patch that modifies superiotool to be able to dump NPCD378:
https://review.coreboot.org/c/coreboot/+/82627

Will be interesting to see if it can get some info out of an NPCD379. Just patch, build, and run - under vendor firmware please. You may have to hack it further to force its hands.

Will rerun autoport but with this updated superiotool code on OEM firmware.

Might as well get the autoport data for the "8200_elite_sff" and the "8300_elite_sff" runing OEM firmware this Thursday or Friday night if that might improve the overall code (cannot flash these models since there in use)?

Walter Sonius wrote in #note-20:

Perhaps Riku Viitanen could clarify what - Super I/O: fan speeds stay in control means?

https://review.coreboot.org/c/coreboot/+/26050
I might understand what Riku meant, on the Libreboot website I found notice on the "8200_elite_sff" referring to psu_fan_lvl=3 which can be set by nvram variable. I checked the current hp/snb_ivb_desktops code and all is already there for all other variants as well. However its missing the build option to enable nvram.

sudo nvramtool -a
nvramtool: CMOS option table not found in coreboot table.  Apparently, the coreboot installed on this system was built without selecting CONFIG_USE_OPTION_TABLE.

Where do I enable this during coreboot compile since it isn't mentioned under general "CONFIG_USE_OPTION_TABLE" or is it the new radio button "Option backend to use (Use CMOS for configuration values)"?

That is it. You can double check .config afterwards that it is indeed enabled.

These LPC bus port decodes are from your logs. But the output here says the temp sensors are on the SMBus, meaning the ports aren't doing anything.
I have a patch that modifies superiotool to be able to dump NPCD378:
https://review.coreboot.org/c/coreboot/+/82627

Will be interesting to see if it can get some info out of an NPCD379. Just patch, build, and run - under vendor firmware please. You may have to hack it further to force its hands.

Will rerun autoport but with this updated superiotool code on OEM firmware.

A reminder: Run the patched superiotool on its own first and make sure it produces useful outputs.

Might as well get the autoport data for the "8200_elite_sff" and the "8300_elite_sff" runing OEM firmware this Thursday or Friday night if that might improve the overall code

Yes please! Looking forward to your logs.

Another favour to ask: Can you check the markings on your system boards (63, 82 and 83s) if they say "Edison" on the board?

Walter Sonius wrote in #note-23:

Board names:
8300_elite_sff is indeed "EDISON REV A" and has NPCD379HAKFX
8200_elite_sff is "BACH REV.A" and has NPCD378HAKFX

Got the logs. Thanks. It also prompts me to revert the LPC decode change - vendor places the I/O ports at 0xa??, coreboot uses 0x6??, but all the configs are otherwise present.

Patch updated with SATA map as 0x17. (pounds gavel :) )
Ports Implemented register of SATA controller reads 0x05. Vendor BIOS apparently check all ports for connected drives and disable ports not occupied. If you feel like it, can you connect something to all SATA ports and see if this value change?

# Bad value -> gfx_uma_size = 0x7 <----------------

It's the cmos.layout. It does not have value 0x7. Of course it would complain.
Try adding that value and test. You can copy from mainboard/asus/p8x7x-series/variants/p8z77-m/cmos.layout, which has all possible values.

If it works, we'll send out a separate patch, since that file is shared by all variants.

Not mentioned earlier because default but all previous display output testing for this 'pro_6300_sff' was done with libgfxinit in case of SeaBIOS it was txt mode and for EDK2 UEFI it was framebuffer.

Success HP Z220 SFF 1.87 K51 firmware flashed onto this "pro_6300_sff", used the original OEM 3.08 16MB raw rom dump and used ifdtool -i to replace the 'bios' and the 'me' region with the Z220 ones. Now looking for a way to enable ECC...

Except for the ME staying in "MANUFACTURING MODE" the "pro_6300_sff" works kinda okay with this Z220 BIOS. It will show more BIOS features, like RAID and PS2 mouse sleep wake but sadly nothing related to ECC. Even used the hprepsetup tool to list all the BIOS features but nothing related to ECC RAM memory. Tried multiple types and combinations of ECC RAM, but it never leads to a working ie31200_edac device. If the 8300_elite_sff becomes available I might check with this Z220 modded BIOS or coreboot if ECC will work on that machine.