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 > > _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
