Hi all,
problem solved... there is another register in DMI PFS space at 0x2740, that needs to have the same value as the LGMR register in PCI cfg space. However, since FSP locks down the DMI PSF space, that register has to be written before FSP-S.
Kind regards Michael / c0d3z3r0
On Fri, 2021-01-15 at 00:40 +0100, Michael Niewöhner wrote:
Hi all,
I'm currently trying to get EC to host memory mapping (H2RAM-HLPC) working on a Clevo L141CU. This will be used by ACPI for the EC ram OpRegion. The EC is an ITE IT5570E. If you don't have access to the datasheet, look for IT8528 or similiar, which is mostly identical irt. memory mapping registers (and many others, too).
On vendor firmware, I can access the two EC ram regions at addresses 0xfe700100, 0xfe700380 via /dev/mem (using dd or memtool md 0xfe700100+0x100 for example). The PCH LGMR register has the value 0xfe700001. The address is within the PCH reserved range (0xfc800000-0xfe7fffff).
Possible addresses are 0xf[ef]XX_X000, according to the datasheet. Free/unused ranges on CNP should be 0xFE036000-0xFE0AFFFF, 0xFE0D0000-0xFE0FFFFF, 0xFE400000-0xFE5FFFFF and 0xFE600000-0xFE7FFFFF (temp address range for FSP), so there shouldn't be any conflict.
EC/superio registers are set as follows:
EC: HCTRL2R (0x1036) = 0x80 -> HBREN = 1 -> "1: The host memory cycle is decoded" HRAMWC (0x105A) = 0x03 -> H2RAM memory cycles, H2RAM window 0 and 1 enabled HRAMW0BA (0x105B) = 0x10 -> window 0 starts at 0x100 HRAMW0BA (0x105C) = 0x38 -> window 1 starts at 0x380 HRAMW0AAS (0x105D) = 0x04 -> window 0: no read/write lock, size = 256 bytes HRAMW1AAS (0x105E) = 0x03 -> window 1: no read/write lock, size = 128 bytes
SIO LDN 0x0f: 0xF5 = 0x00 -> HLPCRAMBA[15:12] = 0x00 0xF6 = 0x70 -> HLPCRAMBA[23:16] = 0x70 0xFC = 0x00 -> HLPCRAMBA[32:24] = 0xFE -> LGMR address is 0xfe700000
The EC registers are initialized by the EC firmware. No change was needed. The superio registers hand to be configured after enabling the logical device.
Unfortunately, mapping doesn't work with coreboot for unknown reasons. Dumping the region only returns 0xff's.
I tested both, reading in coreboot and on Linux, just to be sure there's no OS ressource issue. I also tried to change the mapping address. While I successfully tested changing the address to various values on vendor fw by changing LGMR and the SIO registers (0xfe0b0000, 0xfe701000, 0xfe701000, 0xfE600000, ...), I had no success with coreboot.
I was able to dump the EC ram windows through the I2EC data/index programming on both vendor fw and coreboot, so I am sure, the ram windows are initialized and filled with sensible data.
Any ideas, what could be wrong here?
Kind regards Michael / c0d3z3r0