Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
Hello
My mistake, after carefully checking, it's just the pen that's not giving
anything at all ; however I am getting the exact same 5E and 5F for the
screen rotation - but no ACPI event.
For the pen, I'm not getting any event at all - even with the modified
kernel with the original DSDT that previously gave me such events. Unless
something weird happened, my best guess is that the pen detection switch is
not correctly plugged. I'll have to check that later.
Now about these tablet rotation, thinkpad-acpi expects a MHKG field in the
dsdt to report them to the input layer (cf tpacpi_input_send_tabletsw)
In the original DSDT, MHKG is:
Method (MHKG, 0, NotSerialized)
{
Store (Zero, Local0)
ShiftLeft (\_SB.PCI0.LPC.EC.HTAB, 0x03, Local0)
Return (Local0)
}
So basically it's only reading the TMOD field from the EC, but in
src/ec/lenovo/h8/acpi/ec.asl, I see MKHP, but no MKHG
A simple fix will be to add MKHG
Meanwhile, commenting out send_acpi_ev=false from hotkey_notify_usrevent
seems in thinkpad-acpi.c enough. Then acpi_listen will then see the
following events:
ibm/hotkey IBM0068:00 0080 5009
ibm/hotkey IBM0068:00 0080 500a
(which can be mapped to screen rotation scripts)
For the raw EC events:
Dec 9 15:36:44 thinkpad kernel: [115080.081227] ACPI : EC: = TASK =
Dec 9 15:36:44 thinkpad kernel: [115080.081232] ACPI : EC: --- status =
0x28
Dec 9 15:36:44 thinkpad kernel: [115080.081235] ACPI : EC: --- command =
0x84
Dec 9 15:36:44 thinkpad kernel: [115080.081276] ACPI : EC: = IRQ =
Dec 9 15:36:44 thinkpad kernel: [115080.081280] ACPI : EC: --- status =
0x09
Dec 9 15:36:44 thinkpad kernel: [115080.081284] ACPI : EC: --- data = 0x5e
Dec 9 15:36:44 thinkpad kernel: [115080.081290] ACPI : EC: --- status =
0x08
Dec 9 15:36:44 thinkpad kernel: [115080.082262] ACPI : EC: push query
execution (0x5e) on queue
Dec 9 15:36:47 thinkpad kernel: [115082.603688] ACPI : EC: = TASK =
Dec 9 15:36:47 thinkpad kernel: [115082.603692] ACPI : EC: --- status =
0x28
Dec 9 15:36:47 thinkpad kernel: [115082.603695] ACPI : EC: --- command =
0x84
Dec 9 15:36:47 thinkpad kernel: [115082.603734] ACPI : EC: = IRQ =
Dec 9 15:36:47 thinkpad kernel: [115082.603739] ACPI : EC: --- status =
0x09
Dec 9 15:36:47 thinkpad kernel: [115082.603743] ACPI : EC: --- data = 0x5f
Dec 9 15:36:47 thinkpad kernel: [115082.603749] ACPI : EC: --- status =
0x08
Dec 9 15:36:47 thinkpad kernel: [115082.604711] ACPI : EC: push query
execution (0x5f) on queue
On Fri, Dec 5, 2014 at 7:37 AM, Charles Devereaux coreb...@guylhem.net
wrote:
Hello
For your information, this patch does not gives me any of these ACPI
events on the x60 tablet, so the patch may be specific to the X220t
To correct the events value, I tried to replicate your events output with :
enable CONFIG_DYNAMIC_DEBUG
echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
I still can't get logs similar to yours.
I would love to make that work. Please let me know how I can report the
correct values.
Thanks
Charles
On Mon, Aug 25, 2014 at 5:02 PM, Vladimir 'φ-coder/phcoder' Serbinenko
phco...@gmail.com wrote:
On 25.08.2014 22:53, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Ideally, the DSDT should be fixed within coreboot, but this goes
beyond
my present abilities.
Not true. Just do the same changes to the corresponding *.asl files in
coreboot repo and send the patch to gerrit. Other than a layer of
preprocessing, it's exactly the same code as you got from disassembly.
Sorry, I misread you. I thought that you extracted coreboot DSDT from
running system then patched it and used as custom DSDT. I'm going to
make few experiments on my x220t.
This may interest you:
On X220t
stylus removal:
[17424.931729] ACPI : EC: = TASK =
[17424.931747] ACPI : EC: --- status = 0x28
[17424.931755] ACPI : EC: --- command = 0x84
[17424.931852] ACPI : EC: = IRQ =
[17424.931865] ACPI : EC: --- status = 0x09
[17424.931874] ACPI : EC: --- data = 0x5d
[17424.931885] ACPI : EC: --- status = 0x08
So it's _Q5D
Stylus reinsert:
[17493.249126] ACPI : EC: push gpe query to the queue
[17493.249198] ACPI : EC: = TASK =
[17493.249207] ACPI : EC: --- status = 0x28
[17493.249213] ACPI : EC: --- command = 0x84
[17493.249293] ACPI : EC: = IRQ =
[17493.249306] ACPI : EC: --- status = 0x09
[17493.249316] ACPI : EC: --- data = 0x5c
[17493.249329] ACPI : EC: --- status = 0x08
So it's _Q5C
Turning LID around:
[17582.701907] ACPI : EC: push gpe query to the queue
[17582.701979] ACPI : EC: = TASK =
[17582.701987] ACPI : EC: --- status = 0x28
[17582.701994] ACPI : EC: --- command = 0x84
[17582.702075] ACPI : EC: = IRQ =
[17582.702092] ACPI : EC: --- status = 0x09
[17582.702096] ACPI :
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
Le 09/12/2014 à 23h08, Charles Devereaux a écrit : So basically it's only reading the TMOD field from the EC, but in src/ec/lenovo/h8/acpi/ec.asl, I see MKHP, but no MKHG A simple fix will be to add MKHG Meanwhile, commenting out send_acpi_ev=false from hotkey_notify_usrevent seems in thinkpad-acpi.c enough. Then acpi_listen will then see the following events: ibm/hotkey IBM0068:00 0080 5009 ibm/hotkey IBM0068:00 0080 500a (which can be mapped to screen rotation scripts) Oh wait, sorry if I only get the thread here and I lost the beginning, but, does that mean you found how to make screen position (tablet or laptop mode) finally detectable through ACPI? ’cos I still didn’t understand why it didn’t. If it’s the case, how much time it could take to have needed changes arriving to Debian testing? is there any way not implying to recompile the whole kernel to have them before? Correct me if I misinterpreted. signature.asc Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
Hello
On Tue, Dec 9, 2014 at 5:29 PM, Garreau, Alexandre galex-...@galex-713.eu
wrote:
Oh wait, sorry if I only get the thread here and I lost the beginning,
but, does that mean you found how to make screen position (tablet or
laptop mode) finally detectable through ACPI? ’cos I still didn’t
understand why it didn’t.
Yes, I did. Never give up, never surrender.
It's hackish but it works. It didn't before, because there is a missing
entry in the DSDT : MKHG, which thinkpad-acpi test if it exists before
reporting the screen position event.
Many such entries are missing (ex: GBDC to control bluetooth from within
thinkpad-acpi) but now there are ways around most of them - cf the rfkill
message.
However, that doesn't mean the DSDT is clean, as Windows still can't be
booted. It's a good test because it's picky about DSDTs. It will be a good
milestone to reach. FYI, the x201 can boot windows from coreboot according
to the wiki.
If you want screen position ACPI events, I suggest you flash the latest
libreboot (it includes φcoder original patch), and edit the thinkpad-acpi
file from the kernel as suggested to comment this one line. It is a module
in debian, so you only need to recompile it, not the whole kernel.
There are various kernel compilation guide for debian that can help you
recompile the modules after editing the source file - it's very
straightforward. If you are member of a LUG, they can help you too.
If you are confortable editing grub config file to deploy a new bzImage, I
can send you my kernel binaries and modules (I use 3.14.25), but I believe
that would be more complex. I would not recommand that.
If it’s the case, how much time it could take to have needed changes
arriving to Debian testing? is there any way not implying to recompile
the whole kernel to have them before?
Debian uses standard OS components, and I'm sure such an ugly patch would
never be accepted. Most people don't use coreboot and don't want spare ACPI
events.
Like most of things I do, it's just a hack, an experiment, to test an
hypothesis about the cause of the problem, and see if it can be made to
work.
The proper way to support that would be to add the MKHG field to coreboot
DSDT, it would be instantaneous when you reboot after having flashed this
new version.
I believe the following should be enough:
Method (MHKG, 0, NotSerialized)
{
Store (Zero, Local0)
ShiftLeft (TMOD, 0x03, Local0)
Return (Local0)
}
Unfortunately, I won't be able to do more test until the end of next week.
Maybe someone else will want to try that and, if it works, submit a patch.
Charles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #95: Run coreboot in VirtualBox
#95: Run coreboot in VirtualBox --+- Reporter: uwe| Owner: somebody Type: enhancement|Status: closed Priority: minor | Milestone: Component: misc |Resolution: invalid Keywords: | Dependencies: Patch Status: there is no patch | --+- Comment (by Intika): this idea look nice :) i ll have a look in it when i have time... seems to be easy to implement https://www.virtualbox.org/ticket/1929 -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/95#comment:6 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #95: Run coreboot in VirtualBox
#95: Run coreboot in VirtualBox --+- Reporter: uwe| Owner: somebody Type: enhancement|Status: closed Priority: minor | Milestone: Component: misc |Resolution: invalid Keywords: | Dependencies: Patch Status: there is no patch | --+- Comment (by Intika): you should reopen the issue -- Ticket URL: https://tracker.coreboot.org/trac/coreboot/ticket/95#comment:7 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Memory corruption on Resume from S3 Baytrail
Hi, In coreboot developer manual memory map section ( http://www.coreboot.org/Developer_Manual/Memory_map) there is specific mention of low memory. *0x0 - 0x9*: Low 640kB. Should not be clobbered on S3 suspend/resume (exceptions?) How do I tell Linux not to use this memory? I tried linux kernel argument memap=640K@0x0 to reserve the space but my kernel does not boot with that. What changes are expected in Linux kernel configuration for S3 suspend/resume to work smoothly with coreboot? On Sun, Nov 23, 2014 at 12:54 PM, Stefan Reinauer stefan.reina...@coreboot.org wrote: On 11/19/14 11:36 AM, Gailu Singh wrote: Hi Experts, I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume from Linux (kernel 3.10). I can suspend with pm-suspend and resume with power button; however after resuming I get following logs in Linux Corrupted low memory at c0001004 (1004 phys) = 0008eaea Corrupted low memory at c0001008 (1008 phys) = b0606600 ... Corrupted low memory at c00018fc (18fc phys) = 08ea This seems to be caused by coreboot as I do not see these logs if I use BIOS instead of coreboot. Is it true that during resume coreboot uses RAM portion already mapped by Linux and thus corrupting it. How to I avoid the RAM conflict? Looks like coreboot (or FSP) is overwriting this memory with some trampoline code. One (ugly) way to fix this would be to just reserve the space in the memory table. The better way would be to track down where this is actually happening and fix it there. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] problem with: vendorcode/amd/agesa/fam15: Build as a static library
While trying to get abuild working from Windows I found a coreboot makefile problem. File src/vendorcode/amd/agesa/f15/Makefile.inc is be processed twice. While this doesn't break a Linux build, it does break the Windows build. The Windows problem is because the ar command line contains each object file twice, and the Windows 32KB command line length is exceeded. As a temporary work around, I bracket the contents if Makefile.inc with: ifeq ($(F15_MAKE_INCLUDED),) export F15_MAKE_INCLUDED=y ... endif What is the correct solution? Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
