Hi all,
I ported coreboot to an HP Pavilion dm4-3099se (board 1793, Intel Sandy Bridge
/ HM67), a consumer laptop that previously had no coreboot support.
This is my first coreboot port, so feedback and review are very welcome.
The source tree is available here:
https://github.com/cl45h/coreboot-hp-pavilion-dm4
The port boots successfully and the following hardware is working:
native raminit (no MRC blob)
libgfxinit with LVDS 1600x900 panel and backlight control
IDT audio
keyboard
touchpad
lid switch
Fn keys
CPU temperature sensors
battery and AC adapter detection
SeaBIOS payload
legacy MBR dual boot with Windows untouched
S3 suspend/resume has not been tested yet.
SPI protection bypass
One interesting part of this board is that HP protects the boot block using PR0:
0x3a1000 - 0x3fffff
which overlaps with coreboot's bootblock location. Normally this would require
an external programmer.
I was able to work around this in software.
The stock firmware applies PR0 and FLOCKDN after replaying the S3 boot script.
The script contains 903 entries, including 25 DISPATCH opcodes. 24 of them
point to:
0xACEBC260
which is DRAM marked as Reserved but still writable from the OS.
I instrumented the resume path by redirecting the first and last DISPATCH
entries to 45-byte stubs that read HSFS and PR0, then jump back to the original
routine.
The observed values were:
first DISPATCH last DISPATCH runtime
HSFS 0x6008 0x6008 0xe008
PR0 0x00000000 0x00000000 0x83ff03a1
This gives a short window where the SPI protections are not active.
Clearing PR0 alone is not enough because the firmware rewrites it later.
However, FLOCKDN is write-once, so setting it while PR0 is still clear prevents
the later firmware write from taking effect.
After that, flashrom reports the BIOS region as writable and the PR0 warning
disappears.
This is a known bug class (Wojtczuk & Kallenberg, 2015), so there is nothing
fundamentally new here; it is just an unpatched instance on EOL hardware with a
working PoC.
It may affect other HP consumer InsydeH2O platforms from the same generation,
but I only tested this machine.
Autoport issues
These two issues caused most of the debugging time and may be useful
documentation for future ports.
1. Wrong panel type
autoport configures the panel as eDP, but this machine uses LVDS.
The symptom is simply a black screen.
The missing option was:
select GFX_GMA_PANEL_1_ON_LVDS
as used by boards such as the X220 and some Dell Latitude models.
2. Missing LGMR programming
LGMR (LPC configuration register 0x98) is not programmed by autoport.
It enables decoding of the EC memory window:
0xFE802000
where battery information is exposed.
Without it, the window reads as 0xff and the battery appears absent. The ASL
looks incorrect, but the actual issue is missing hardware initialization.
LGMR does not appear in the usual autoport output:
inteltool
lspci
acpidump
Both issues are documented in the repository, along with flashing quirks.
With FLOCKDN enabled early, the SPI opcode menu becomes frozen, so flashrom
falls back to hardware sequencing and passing -c causes failures.
Intel ME status
The Intel ME was left untouched and remains active.
The descriptor denies the host both read and write access to the ME region, so
me_cleaner would require an external programmer.
I would be happy to clean up the tree and submit it to Gerrit if there is
interest.
I know the per-file attribution comments would need to be removed, and the EC
dump replay generated by autoport probably needs trimming.
Thanks,
cl45h
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
