Re: [coreboot] More Fn+key on X60T
Le 03/11/2014 à 05h29, Charles Devereaux a écrit :
Hello
On Sun, Nov 2, 2014 at 8:26 AM, Garreau, Alexandre galex-...@galex-713.eu
wrote:
Where do come from the numbers used in the two scripts you showed? I
suppose there’s a code for each XFree86 keysym, right?
IIRC, it's just a linear function of the keysym: there is a difference by
about 80
Ok… any example anywhere? like a wiki page?
Talking about /sys/devices/platform/thinkpad_acpi: do you have the file
“hotkey_tablet_mode”? I need it to detect when the screen is turned in
tablet mode so that I can automatically rotate the screen. Do it need to
be implemented in coreboot too?
No, this is due to missing DSDT entries in coreboot that thinkpad-acpi uses:
2058 static int hotkey_get_tablet_mode(int *status)
2059 {
2060 int s;
2061
2062 if (!acpi_evalf(hkey_handle, s, MHKG, d))
2063 return -EIO;
2064
2065 *status = ((s TP_HOTKEY_TABLET_MASK) != 0);
2066 return 0;
2067 }
However, with the latest patch from φcoder, you should have the ACPI events
directly
Ok, so just upgrade should fix it right?
Fn+F6 and F8 show up in cat /dev/input/event4,
Not here.
More problematic, Fn+F10, Fn+insert, Fn+delete are dead as can be -
regardless of the /sys/devices/platform/thinkpad_acpi/hotkey_mask
Yeah, that’s the problem.
According to
http://www.thinkwiki.org/wiki/How_to_get_special_keys_to_work#Triggering_key_events:
By disassembling and editing the DSDT, more events can be added. HKEY
events are triggered by calls to the MKHQ function, e.g.
\_SB.PCI0.LPC.EC.HKEY.MHKQ(0×1007) will trigger ibm/hotkey HKEY 0080
1007. Most of these can be found in _Qxx methods within the DSDT,
which are executed on embedded controller events, e.g. _Q10 is triggered by
pressing Fn-F7. You can add a call to MKHQ into an existing _Qxx method to
get it recognized by thinkpad-acpi as well as creating new _Qxx methods,
which if you're lucky will correspond to an EC event that IBM never used
(e.g. A 770 will send Fn-Home/End/PgUp/PgDn to thinkpad-acpi if hacked in
this fashion). For example, this is a modified block of DSDT for a G40
http://www.wormnet.eu/ibm-g40/morebuttons.dsl.
My best idea at the moment is that the EC gives different Q codes than
those in the DSDT for the keys that do not generate ACPI events.
What’s a DSDT? I’m not sure of what’s HKEY, and I’m sure I don’t
understand what’s MKHQ, _Qxx, Q code, EC and G40.
Yet in src/ec/lenovo/h8/acpi/ec.asl, I do see Fn+10, Fn+Insert, Fn+Delete
and also Fn+Backspace, ie everything has been added, but thinkpad-acpi
shows nothing in /dev/input/event4
Am I missing something?
Even Fn+Insert and Delete? :D /me’s wondering if maybe the trick
Fn+numpad would be possible with some hack…
PS: Do you have a PGP key?
I do, but for public communication (ex: mailing list) I don't use it.
Even for signature?
pgpMHaySMaFlm.pgp
Description: PGP signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS F2A85-M questions
On Fri Oct 31 03:25:55 CET 2014, Patrick 'P. J.' McDermott wrote: Hi, Hi, I'm interested in running coreboot on the ASUS F2A85-M, and I have a few questions. The wiki page for the board says that hardware virtualization is untested. Has anyone tested this since the page was created in 2012? Or could someone with this board please test this? KVM works very well for me. How reliable is the hack for supporting Richland CPUs? No problems with this. I always use it without problems :) Are other variants of the F2A85-M (e.g. F2A85-M2) supported? I don't know. Probably need make a patch for this. -- Best regards, HacKurx -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
With the changed TXE/descriptor, it moved ahead but now toggling between POST codes 0x66 and 0x07. I checked ./src/include/console/post_codes.h and these POST codes are not defined there so I doubt that these are coming from coreboot code. Are these post codes coming from FSP code? If yes, How do I interpret them? Do I need to ask Intel? Any pointers please? On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil seanmcne...@gmail.com wrote: You mentioned just copying the .fd file, so I assumed it was being used directly in your coreboot image. FSP needs to be incorporated into flash, yes. It should, however, be patched with the BCT program as what is provided in the .fd is usually not patched with the a configuration that you desire. Thus you should run bct and configure/patch the .fd and generate a .bin to include into coreboot. I am a little confused by your email below. You state that you are not using the .fd directly then contradict yourself in the next sentence. Bottom line is I would not include any .fd file from the FSP archive directly. Use BCT to patch it and do not name it .fd. This avoids any confusion regarding whether you are including a patched FSP or not. Just because there is a bsf file included in the GOLD release doesn't mean that the .fd was patched with those settings and that it is valid. Best of luck to you. There are many issues you will have to resolve dealing with new hardware. I've gone through the process with a lot of support from Intel and it is not that easy. Especially when certain components found on the CRB are not provided on custom hardware. Cheers, Sean On 11/02/2014 08:01 PM, Gailu Singh wrote: Hi Sean, 1. This is not for a real project and we are trying to understand FSP interaction with coreboot to look at feasibility for considering coreboot in our future projects. Unfortunately I do not have board documentation so was not able to determine which one is serial port 0 though I know that port 0 is specified in coreboot config. That was the reason I was trying on all 3 available ports. 2. I am not using .fd directly. I believe that FSP need to be included in bootloader (coreboot in this case) and we are providing path to coreboot so that it can be included in coreboot. In my original post I only said that I copied .fd to a path expected by coreboot configuration. May I know how did you conclude that I am using it directly? May be that can give me some pointer. 3. I had checked the bsf file in the FSP kit with BCT tool and it is configured for non-ECC RAM, so I believe that no change is required in .fd. Am I wrong? 4. Yes, I agree that there is no documentation available on how to create entire 8MB binary with Firmware Description, TXE, coreboot etc so for safe route I only touched upper 2 MB as recommended in one of the initial commit for baytrail FSP integration and some posts related to similar discussion. On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil seanmcne...@gmail.com wrote: Coreboot and FSP are not as easy to understand as you can see. I also would suggest that you seek assistance from either Sage (who has good experience that I understand serves the USA and Europe markets and contributed the current Coreboot+FSP code) or perhaps a company in Asia such as Zien Solutions (of Vietnam). There are a number of issues that you are failing to understand: 1) As stated, the first serial port is actually connected to a USB-Serial converter and delivered out of the microUSB connector on the CRB. 2) You need to configure the FSP with Intels program to create a ROMable image and not use the .fd file directly. 3) BayleyBay needs to be configured for non-ECC RAM whereas Bakersport needs to be configured for ECC. 4) You don't necessarily need the TXE security module, but you could very well cause problems if it is partially overwritten. Best is to create a correct 8MB image to flash that has the proper Intel Firmware Description block at the beginning. Regards, Sean On 11/02/2014 02:25 AM, Gaumless via coreboot wrote: First, the serial ports: The serial console is on the first serial port on the micro-USB connection. The 0x on the post code display means that it's not actually starting to boot - it's probably hanging in the TXE. There are known issues with upgrading to coreboot from some of the bayleybay roms. I thought Intel was going to document that, but I don't know if they did. The Gold 2 FSP doesn't support D0 parts, so if you have a D0, you need the Gold 3. Also, the FSP is targeted at the embedded sku Baytrail-I. It might work with M/D parts, I haven't tested that. Assuming all that is ok, you probably need to start from a different rom. It might be failing because of the TXE security. You'll probably need to talk to your Intel contact to get that update. Finally, if this is not a personal project, you might be interested in contacting Sage and look at purchasing a
Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
Hi. Now you have coreboot running. coreboot searches for FSP, finds it and executes the first call into it. FSP returns with an error and what you see is this (taken from src/drivers/intel/fsp/cache_as_ram.inc): /* * Failures for postcode 0xBB - failed in the FSP: * * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully. * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid. * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the microcode region. * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met. * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked */ So what you actually see is error code 0x07 from FSP. This can mean that your CPU is not supported by this FSP version. If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if you have in advance a D0 stepping installed on your board, than you have to use GOLD3 FSP release as it was already mentioned. I had the same issue and it was due to missing D0-Support in GOLD1 release. So, I would suggest to try the right FSP-release from Intel. Bye Werner Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot: With the changed TXE/descriptor, it moved ahead but now toggling between POST codes 0x66 and 0x07. I checked ./src/include/console/post_codes.h and these POST codes are not defined there so I doubt that these are coming from coreboot code. Are these post codes coming from FSP code? If yes, How do I interpret them? Do I need to ask Intel? Any pointers please? On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil seanmcne...@gmail.com mailto:seanmcne...@gmail.com wrote: You mentioned just copying the .fd file, so I assumed it was being used directly in your coreboot image. FSP needs to be incorporated into flash, yes. It should, however, be patched with the BCT program as what is provided in the .fd is usually not patched with the a configuration that you desire. Thus you should run bct and configure/patch the .fd and generate a .bin to include into coreboot. I am a little confused by your email below. You state that you are not using the .fd directly then contradict yourself in the next sentence. Bottom line is I would not include any .fd file from the FSP archive directly. Use BCT to patch it and do not name it .fd. This avoids any confusion regarding whether you are including a patched FSP or not. Just because there is a bsf file included in the GOLD release doesn't mean that the .fd was patched with those settings and that it is valid. Best of luck to you. There are many issues you will have to resolve dealing with new hardware. I've gone through the process with a lot of support from Intel and it is not that easy. Especially when certain components found on the CRB are not provided on custom hardware. Cheers, Sean On 11/02/2014 08:01 PM, Gailu Singh wrote: Hi Sean, 1. This is not for a real project and we are trying to understand FSP interaction with coreboot to look at feasibility for considering coreboot in our future projects. Unfortunately I do not have board documentation so was not able to determine which one is serial port 0 though I know that port 0 is specified in coreboot config. That was the reason I was trying on all 3 available ports. 2. I am not using .fd directly. I believe that FSP need to be included in bootloader (coreboot in this case) and we are providing path to coreboot so that it can be included in coreboot. In my original post I only said that I copied .fd to a path expected by coreboot configuration. May I know how did you conclude that I am using it directly? May be that can give me some pointer. 3. I had checked the bsf file in the FSP kit with BCT tool and it is configured for non-ECC RAM, so I believe that no change is required in .fd. Am I wrong? 4. Yes, I agree that there is no documentation available on how to create entire 8MB binary with Firmware Description, TXE, coreboot etc so for safe route I only touched upper 2 MB as recommended in one of the initial commit for baytrail FSP integration and some posts related to similar discussion. On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil seanmcne...@gmail.com mailto:seanmcne...@gmail.com wrote: Coreboot and FSP are not as easy to understand as you can see. I also would suggest that you seek assistance from either Sage (who has good experience that I understand serves the USA and Europe markets and contributed the current Coreboot+FSP code) or perhaps a company in Asia such as Zien Solutions (of Vietnam). There are a number of issues that you are failing to understand: 1) As stated, the first serial port is actually connected to a
Re: [coreboot] More Fn+key on X60T
Hello On Mon, Nov 3, 2014 at 4:58 AM, Garreau, Alexandre galex-...@galex-713.eu wrote: Ok… any example anywhere? like a wiki page? No, I was just speaking from memory. Try some increasing numbers and see what you get in xev. Ok, so just upgrade should fix it right? This is http://review.coreboot.org/6765, it depends on the version you use. What’s a DSDT? I’m not sure of what’s HKEY, and I’m sure I don’t understand what’s MKHQ, _Qxx, Q code, EC and G40. Basically, this means this stuff is handled within coreboot, and should use certain ways that thinkpad-acpi will recognize. I hoped other persons would be interested by the discrepancies we both noticed, but nope. Too bad. This means the bug (as there seem to be one) will not be fixed anytime soon. Even Fn+Insert and Delete? :D /me’s wondering if maybe the trick Fn+numpad would be possible with some hack… Fn+PrintSc, Fn+ScrLk, Fn+Pause all work for me in xev. I don't think they are handled as the others, so you won't be able to remap them (unless you say that keycode 107 is not Sys_Req but your key, etc - IMHO a bad idea) PS: Do you have a PGP key? I do, but for public communication (ex: mailing list) I don't use it. Even for signature? As nobody tried to impersonate me yet, no :-) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Fwd: [Intel-gfx] i915.fastboot bug report - not working on coreboot
Hello
The issues with i915.fastboot have been explained by Jesse Barnes,
unfortunately I do not think I can help any further with that.
Could someone from the list help him pinpoint why coreboot is using a
different mode?
This would make native video init compatible with i915.fastboot=1, to
further reduce bootime. I guesstimate about 0.8 seconds could be shaved,
which would be quite significant.
My reply was:
(IIRC, there is no VBT or INT 10H support yet in coreboot native video
init)
Regarding EDID, it's handled from intel_gma_init in
coreboot/src/northbridge/
intel/i945/gma.c.
The only thing I see that could be linked to a preferred mode is in
decode_edid from coreboot/src/lib/edid.c :
if (edid[0x18] 0x02) {
printk(BIOS_SPEW, First detailed timing is
preferred timing\n);
has_preferred_timing = 1;
}
(...)
/* detailed timings */
printk(BIOS_SPEW, Detailed timings\n);
has_valid_detailed_blocks = detailed_block(out, edid +
0x36, 0);
if (has_preferred_timing !did_detailed_timing)
has_preferred_timing = 0; /* not really accurate...
*/
Maybe disabling has_preferred_timing if there are no did_detailed_timing
is wrong?
-- Forwarded message --
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Thu, Oct 30, 2014 at 5:34 PM
Subject: Re: [Intel-gfx] i915.fastboot bug report - not working on coreboot
To: Charles Devereaux intel...@guylhem.net
Cc: intel-...@lists.freedesktop.org, Paul Menzel
paulepan...@users.sourceforge.net
On Thu, 23 Oct 2014 16:44:26 -0400
Charles Devereaux intel...@guylhem.net wrote:
[0.529733] [drm:intel_set_config_compute_mode_changes], modes are
different, full mode set
[0.529736] [drm:drm_mode_debug_printmodeline], Modeline 0: 0 54167
1024 1048 1184 1344 768 771 777 806 0x0 0xa
[0.529740] [drm:drm_mode_debug_printmodeline], Modeline 11:1024x768
60 65000 1024 1048 1184 1344 768 771 777 806 0x48 0xa
This looks like the issue. The BIOS programs a slightly different
1024x768 mode than what the kernel tries to apply. Looks like reduced
vs non-reduced blanking approximately.
We could adjust the fastboot code to handle that, or change coreboot to
use the preferred mode from the EDID of the display or make the VBT
match, which is presumably what the kernel is using.
--
Jesse Barnes, Intel Open Source Technology Center
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: [Intel-gfx] i915.fastboot bug report - not working on coreboot
Charles Devereaux via coreboot wrote: Could someone from the list help him pinpoint why coreboot is using a different mode? I will not. The answer to this is already well known - the coreboot code is doing something different, probably because it doesn't know better, probably because the programmer has not written correct code. This would make native video init compatible While I appreciate that there are many users who would like all kinds of things to work without them being able to fix it themselves, the reality is that things will work when someone fixes them. All these things are well-known problems. Correct patches would be great. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] IMB-A180 Real Time Clock is 20-30% slow (coreboot only, not original AMI BIOS)
We are working with both vanilla Coreboot and Sage's BSP version of Coreboot, and we stumbled upon the fact that the system clock is running 20-30% slow. This does not occur when booting from the original AMI BIOS. We are running both CentOS 6.4 and Ubuntu 14.04 versions of Linux. To reproduce, run sleep 10 and time it with a stopwatch. Our timings indicate about 12.2 seconds when booting from either vanilla or Sage BSP Coreboot. I've searched the Coreboot mailing list archives (and google), but I don't see anything. Does anyone know anything about this? I'll start looking at the code, but any help will be greatly appreciated. Best regards, Mark Mason Engineering Design Team -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] disable from: rewrite?
Rudolf Marek via coreboot wrote: Is there a mailman option on our ml to stop rewriting the From header of the email? Please disable it site-wide, unless there is a per-user option. It is quite retarded... Yes, I agree. But the big email providers do not value mailing lists, so here we are. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] disable from: rewrite?
Hello! I agree. I had to fish this one out of the spam bucket, because Google Mail insists that some people do tag these message as such. They may have signed up and forgotten that they have done that. It would be interesting to see how many people have done so and receive their messages via Google Mail. - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. On Mon, Nov 3, 2014 at 7:30 PM, Peter Stuge via coreboot coreboot@coreboot.org wrote: Rudolf Marek via coreboot wrote: Is there a mailman option on our ml to stop rewriting the From header of the email? Please disable it site-wide, unless there is a per-user option. It is quite retarded... Yes, I agree. But the big email providers do not value mailing lists, so here we are. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: [Intel-gfx] i915.fastboot bug report - not working on coreboot
Let's not forget that in some cases it can also be that coreboot is doing something right/better, but it is not matching a bug the driver thinks it has to fix. It happens. ron On Mon, Nov 3, 2014 at 4:11 PM, Peter Stuge via coreboot coreboot@coreboot.org wrote: Charles Devereaux via coreboot wrote: Could someone from the list help him pinpoint why coreboot is using a different mode? I will not. The answer to this is already well known - the coreboot code is doing something different, probably because it doesn't know better, probably because the programmer has not written correct code. This would make native video init compatible While I appreciate that there are many users who would like all kinds of things to work without them being able to fix it themselves, the reality is that things will work when someone fixes them. All these things are well-known problems. Correct patches would be great. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: [Intel-gfx] i915.fastboot bug report - not working on coreboot
On Mon, Nov 3, 2014 at 7:11 PM, Peter Stuge via coreboot coreboot@coreboot.org wrote: The answer to this is already well known To you maybe, but I never saw that posted on the list or published on the x60 wiki or in other documentation. Please tell me more about it or point me to a link at least. If the problem is simple enought, I could tackle it. While I appreciate that there are many users who would like all kinds of things to work without them being able to fix it themselves, the reality is that things will work when someone fixes them. That's right, I would love some issues to be fixed, and yet at the moment many of them are too complex for me. (The DSDT issues however are something I might soon be able to fix, along with the Fn keyboard issues, first by checking whether the Qx codes obtained with ec-access do match the values hardcoded in ec.asl - I suspect they won't) However, I don't believe someone else can possibily fix issues that are not being properly documented, so I document precisely what is broken and how, to get a better idea of what to do, especially if there seem to be a common factor as in the DSDT case. Sorry if this disturbs you. There is only one thing I can't understand - the tone of your answers. If my questions disturb you so much, what about not answering at all instead? All these things are well-known problems. Correct patches would be great. Known to you maybe. Not to me. I'm discovering them. If you do have a exhaustive list of all these well known problems, could you please publish it somewhere? Here's a fun new one from today: turning off the whole radio subsystem with the hardware switch does *NOT* seem affect WWAN, even if the LED is turned off. (or I want to know why I can still send AT commands, get responses, NMEA coordinates from the integrated GPS, etc. Maybe the rfkill pin is badly soldered on the mini PCIe connector, which I wanted to check before announcing that, but it's troubling) I suppose you must know about this issue in great detail. Please enlighten me with your knowledge then. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
