mirror of
https://github.com/hirschmann/nbfc.git
synced 2026-04-26 00:56:01 +03:00
[GH-ISSUE #363] LifeBook E754 Findings #327
Labels
No labels
Stale
bug
config
discussion
duplicate
enhancement
experimental
feature
help-wanted
info
invalid
invalid
pull-request
question
up-for-grabs
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nbfc-hirschmann#327
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alienworker on GitHub (Oct 22, 2017).
Original GitHub issue: https://github.com/hirschmann/nbfc/issues/363
Hi to all,
I have Fujitsu-Simens LifeBook E754 with Intel i7-4702 MQ and I have the same issues like users from https://github.com/hirschmann/nbfc/issues/35. Firstly, I tried all configurations form https://github.com/hirschmann/nbfc/tree/master/Configs and they did not solve my problem. After that I followed the instructions from https://github.com/hirschmann/nbfc/wiki/How-to-create-a-NBFC-config. Unfortunately, I could not find any datasheets or configs of my model or of similar notebooks. Therefore, I analyze DSDT of my laptop. I understood the procedure but I could not modified your example so it could be applicable on my laptop. I would be very grateful if someone could help me to use my current findings in order to make XML config file for my laptop. You are my last chance guys. Probably the creator of this amazing software @hirschmann can lead me to make the config file based on my current findings.
Here are my findings:
I realized that the key part of DSDT export for my computer is probably this
…
Device (EC)
{
Name (_HID, EisaId ("PNP0C09"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0062, // Range Minimum
0x0062, // Range Maximum
0x01, // Alignment
0x01, // Length
)
IO (Decode16,
0x0066, // Range Minimum
0x0066, // Range Maximum
0x01, // Alignment
0x01, // Length
)
})
Name (_GPE, 0x17)
Scope ()
{
Name (ECOK, Zero)
}
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x03))
{
Store (Arg1, ECOK)
}
}
OperationRegion (SMB, EmbeddedControl, Zero, 0xFF)
Scope ()
{
Field (_SB.PCI0.LPCB.EC.SMB, ByteAcc, Lock, Preserve)
{
Offset (0x04),
ECCM, 8,
ECD1, 8,
ECD2, 8,
ECD3, 8,
Offset (0xE0),
ECBM, 8,
ECB1, 8,
ECB2, 8,
ECB3, 8,
ECB4, 8,
ECB5, 8,
ECB6, 8,
ECB7, 8,
ECB8, 8,
ECB9, 8,
ECBA, 8,
ECBB, 8,
ECBC, 8,
ECBD, 8,
ECBE, 8,
ECBF, 8,
ECBG, 8,
ECBH, 8,
ECBI, 8,
Offset (0xF8),
ECGM, 8,
ECG1, 8,
ECG2, 8,
ECG3, 8
}
}
}
….
Here is full file of DSDT export http://s000.tinyupload.com/?file_id=46882462029993614114
In your EC probing tool example is completely clear how to recognize the registers. I started prime95 software but from my output I could not find which registers I need to change. Here are my outputs from ec-probe.exe monitor –clearly
0x07:00,00,00,00,00,00,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80,80
Also here is the output from ec-probe.exe dump
00: 00 C0 00 00 00 00 00 80 00 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 FF
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0: 00 43 50 36 35 36 33 34 30 2D 30 31 30 30 31 33
F0: 31 35 53 00 00 00 00 00 00 03 9C 89 00 00 00 00
Do you have any tips for me?
@github-actions[bot] commented on GitHub (Dec 7, 2019):
This issue is stale because it has been open more than 180 days with no activity. If nobody comments within 7 days, this issue will be closed