coreboot

Wreg Yek wrote:

HP Elitebook 2170p is weird compared with many other Elitebooks supported by coreboot, for its keyboard scan codes under coreboot is different with those under oem firmware, regardless of the same set of EC firmware blobs are used.

The scan codes under oem firmware conform to the upstream 60-keyboard.hwdb, while after systemd v257-rc1, the KEYBOARD_KEY_66=pickup_phone within upstream 60-keyboard.hwdb starts to conflict with the scan codes of backspace key under coreboot, where it is 0x66.

Besides backspace, I have collected the scan codes of all Fn-keys under coreboot into the attached 61-2170p-kb.hwdb, which is adjusted to the default SMBIOS tables of coreboot for Elitebook 2170p, and could be used to walk around the scan code conflict.

Thanks for your report. Both the conflict issue and your key map are confirmed on my own HP Elitebook 2170p, and your key map works very well.

I guess the EC (extended from keyboard controller) of 2170p have two mode for keyboard scan codes: default mode and oem mode. Its oem firmware may send come commands to EC to switch it to oem mode, while no command is sent on the current coreboot, so the EC remains in the default mode.

We may have to confirm whether this phenomena of scan code switch is widespread among early Elitebook models (it seems not present on folio 9470m running coreboot, whose scan codes for Fn-keys seems to conform to the upstream 60-keyboard.hwdb) by asking those who own early Elitebooks for test, in order to determine whether to find and implement the commands to switch scan code, or ask systemd project to handle the default mode, as your key map works well.

The version of factory firmware of my 2170p is F.43.

The latest oem firmware update HP Notebook System BIOS Update F.72 Rev.A could be downloaded from https://support.hp.com/us-en/drivers/hp-elitebook-2170p-notebook-pc/5245427 by selecting "Windows 10 (64-bit)".

$ sha512sum sp96088.exe 
940e533b6a276c13a6e46a93795ca84b19877b05e82c0c1795b7fea9cbea63c28e606ef994352fc77c4fdfb2e0c31c5edeefa98b989e1990364dfc6417b25460  sp96088.exe

This sp96088.exe contains an MS cabinet archive, and could be extracted with cabextract(1) to obtain another cabinet archive Rom.CAB, which can be extracted to obtain a 5MB Rom.bin, with the same size as the BIOS region of the factory firmware.

As hinted by ver.txt within Rom.CAB, a 256kB volume with type NVRAM (recognized by UEFITool NE) at 0x3e0000 of the BIOS region of the factory firmware could be extracted and overwritten (via UEFITool old engine, as UEFITool NE has not been capable of modification yet) onto the volume at the same offset of the Rom.bin. This modified Rom.bin could be insert back into the factory firmware as its BIOS region via ifdtool, and the latest oem firmware (F.72 Rev.A) is obtained.

Oem firmwares (either factory or latest) of SandyBridge/IvyBridge Elitebooks is notorious for refusing to boot from GPT-paritioned hdd via either MBR or EFI, though manually booting from EFI file does work.

The scan codes under the oem firmware (either factory or latest) do conform to the upstream 60-keyboard.hwdb. More importantly, the scan code of backspace (in oem mode defined earlier) is 0x0e:

# evtest /dev/input/by-path/platform-i8042-serio-0-event-kbd 
Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab83
Input device name: "AT Translated Set 2 keyboard"
...
Event: time 1732504394.297639, type 4 (EV_MSC), code 4 (MSC_SCAN), value 0e
Event: time 1732504394.297639, type 1 (EV_KEY), code 14 (KEY_BACKSPACE), value 1
Event: time 1732504394.297639, -------------- SYN_REPORT ------------
Event: time 1732504394.368779, type 4 (EV_MSC), code 4 (MSC_SCAN), value 0e
Event: time 1732504394.368779, type 1 (EV_KEY), code 14 (KEY_BACKSPACE), value 0
Event: time 1732504394.368779, -------------- SYN_REPORT ------------

kbc1126_ec_dump could extract EC blobs from Rom.bin (version 63.1C from F.72 Rev.A):

$ sha512sum Rom.bin.fw*
44a27359e8e2ecfae910a754617d5ee947d6bba976f2eb53114a97c71b64813da7ab4223749706c9bbcaf1e752c190834ee3b41c297c191b3cac200814e02938  Rom.bin.fw1
09c5b8bab6f258a0303ac502b4900cd4277bd6c43bfd2ef0030df6e918ef3300d04d2979373f8b05f77d1eae1c27ebd01856426b8eed6f215e1fcaed68e0977e  Rom.bin.fw2

The larger fw2 is different with the one extracted from the factory firmware (version 63.1A from F.43):

$ sha512sum flashregion_1_bios.bin.fw*
44a27359e8e2ecfae910a754617d5ee947d6bba976f2eb53114a97c71b64813da7ab4223749706c9bbcaf1e752c190834ee3b41c297c191b3cac200814e02938  flashregion_1_bios.bin.fw1
6fab77ad3844f0ed965df16d29167fbff4b50cb64a81e5ea234f043ab78f06018905c9075fc73980d5e61c4a7e3ac9d9aa1eecfd816dd9ff97e3776531c4ecb5  flashregion_1_bios.bin.fw2

Under a coreboot image with these EC blobs integrated (either 63.1A or 63.1C), the scan codes conform to Wreg Yek's 61-2170p-kb.hwdb, and the scan code of backspace (in default mode defined earlier) is 0x66:

Event: time 1732511777.265566, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time 1732511777.265566, type 1 (EV_KEY), code 14 (KEY_BACKSPACE), value 1
Event: time 1732511777.265566, -------------- SYN_REPORT ------------
Event: time 1732511777.370022, type 4 (EV_MSC), code 4 (MSC_SCAN), value 66
Event: time 1732511777.370022, type 1 (EV_KEY), code 14 (KEY_BACKSPACE), value 0
Event: time 1732511777.370022, -------------- SYN_REPORT ------------

Bill XIE wrote in #note-2:

This sp96088.exe contains an MS cabinet archive, and could be extracted with cabextract(1) to obtain another cabinet archive Rom.CAB, which can be extracted to obtain a 5MB Rom.bin, with the same size as the BIOS region of the factory firmware.

As hinted by ver.txt within Rom.CAB, a 256kB volume with type NVRAM (recognized by UEFITool NE) at 0x3e0000 of the BIOS region of the factory firmware could be extracted and overwritten (via UEFITool old engine, as UEFITool NE has not been capable of modification yet) onto the volume at the same offset of the Rom.bin. This modified Rom.bin could be insert back into the factory firmware as its BIOS region via ifdtool, and the latest oem firmware (F.72 Rev.A) is obtained.

Incredible. You even found a way to update the oem firmware without using the proprietary tools provided by HP, in the form of EFI executables.

I have never updated the oem firmware of my own 2170p before using coreboot on it, for I do not want to use those proprietary update tools.

Under a coreboot image with these EC blobs integrated (either 63.1A or 63.1C), the scan codes conform to Wreg Yek's 61-2170p-kb.hwdb, and the scan code of backspace (in default mode defined earlier) is 0x66:

It is regretful that the so-called scan code switch persists after upgrading the EC blobs.

On Elitebook 8460p, the scan codes under coreboot mostly conforms to the upstream 60-keyboard.hwdb, with KEYBOARD_KEY_0e=backspace, although KEYBOARD_KEY_b3=prog1 # Fn+F11 - Ambient Light Sensor button and KEYBOARD_KEY_df=sleep # Fn+F3 are only available under the oem firmware. Under coreboot Fn+F3 and Fn+F11 only generate scan codes for F3 and F11 respectively.

On Elitebook Folio 9470m, the scan codes under coreboot mostly conforms to the upstream 60-keyboard.hwdb, with KEYBOARD_KEY_0e=backspace, although KEYBOARD_KEY_df=sleep # Fn+F3 is only available under the oem firmware. Under coreboot Fn+F3 only generates scan code for F3.

So it seems that scan code switch is indeed "widespread among early Elitebooks", but the actual change on most models is not that large like 2170p.

I decide to forward this issue and the hwdb piece composed by you to systemd project as https://github.com/systemd/systemd/issues/35469 , as finding the command to switch the key map mode of HP Elitebook 2170p by reverse engineering the oem firmware is both hard and ineffective.

Bill XIE wrote in #note-5:

I decide to forward this issue and the hwdb piece composed by you to systemd project as https://github.com/systemd/systemd/issues/35469 , as finding the command to switch the key map mode of HP Elitebook 2170p by reverse engineering the oem firmware is both hard and ineffective.

Thanks for forwarding these for me, as github does allow me to open any issue. They guard against all users of my email provider as spammers.

The systemd project asked me to "submit this as a PR", which I did, and they soon accept this PR.