Or go back to main document index.
These logs are usually obtained when testing changes related to graphics on i945 (X60 and T60).
TODO: T60: find (for rare buggy CPU's that are unstable without microcode updates) if there is a workaround (patched kernel, special parameter, etc) So far, only 1 processor has been found to have issues. See microcode errata sheets http://download.intel.com/design/mobile/SPECUPDT/31407918.pdf and http://download.intel.com/design/mobile/SPECUPDT/30922214.pdf and then look at the debugging results collected in t7200q directory (q means quirk).
Fix X60 Tablet issues (see incompatible panels listed at ../index.html#supported_x60t_list).
Fix T60 issues (see incompatible panels listed at ../index.html#supported_t60_list).
Run that tool (resources/utilities/i945gpu/intel-regs.py) as root on machines with the offending panels in:
This shows values in devicetree.cb and src/northbridge/intel/i945/gma.c, the idea is that you run it on factory bios or vbios and that it will (might) show different values: then you try those in the native graphics (in libreboot).
Other values/registers might also need to be added to the script for these tests.
Original getregs.py script can be found at http://hg.mtjm.eu/scripts/file/tip/intel-regs.py written by Michał Masłowski.
Older kernels could init GPU on an X60 without a vbios or native graphics. I have to do a git bisect to find out when that was broken.
Note: "memory_corruption_check=0 i915.lvds_channel_mode=2" kernel parameters were once used successfully for linux-libre 3.10 on a ThinkPad T60 (distribution: Parabola) to get graphics working.
Also check #5320_kernel312fix (to fix 3D on kernel 3.12/higher)
The fix below was done on 5320/6 but should work just fine on later versions of 5320.
Native gpu init + backlight controls! (Fn keys). Also confirmed on X60 Tablet (1024x768) and X60 Tablet (1400x1050)
Checkout http://review.coreboot.org/#/c/5320 on top of a coreboot git clone.
Add backlight controls: in src/mainboard/lenovo/x60/devicetree.cb, change gpu_backlight to 0x879F879E
That's all! This has also been backported into libreboot 5th release (line 1233 in src/mainboard/lenovo/x60/i915io.c). GNUtoo (Denis Carikli)
told me about the register BLC_PWM_CTL and that you could set it to control backlight. I read that address using devmem2 while running the VBIOS:
# devmem2 0xe4361254 w
When doing this, it gave back that value. The same trick was used to get backlight controls for T60 (see #t60_native_notes).
Reading 0xe4361254 (address) in Lenovo BIOS always yields FFFFFFFF, even when writing to it (and writing to it doesn't affect brightness controls). 'mtjm' on IRC found that the buttons (Fn keys) control /sys/class/backlight/acpi_video0 which has no affect on 61254 (BLC_PWM_CTL). He says intel_backlight has different values and uses the register. devmem2 works, needs checking lspci -vv for where the memory is mapped, which is different than on coreboot; mtjm found that it was 0xec061254 on his machine (X60 Tablet), and the register value is different too. This is relevant, because we still don't know how backlight controls are actually handled. We got it working by accident. We need to know more..
Intel-gpu-tools may prove useful for further debugging: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
mtjm says 0xe4300000 is an MMIO region of the gpu (lspci -vv shows it), 0x61254 (BLC_PWM_CTL) is a documented register. Searching the kernel driver for backlight shows that in intel_panel.c this register is used (there is an XXX comment about finding the right value, where recent kernels get it from.
What we want to do is calculate a good value, instead of setting it in devicetree.cb. mtjm says about backlight physics: it has a light source , uses pulse width modulation (PWM) to turn it on/off, dimming is done by spending less time on. Note: this may not be correct; he says his understanding is based on how the Lenote yeeloong works.
mtjm goes on to say, that the register specifies the frequency used for PWM in its depending on the GPU core frequency, so it might be possible to calculate it without hardcoded laptop-specific values. Therefore, I am supposed to find out the 'display core frequency' (mtjm says there might be a register for it; also, it might be in 5320 or the replay code) and the PWM modulation frequency. https://en.wikipedia.org/wiki/Backlight#Flicker_due_to_backlight_dimming
phcoder (Vladimir Serbinenko) who is author of 5320 (review.coreboot.org) talks about 'duty cycle limit' and 'flickering frequency'.
Also check #5320_kernel312fix (to fix 3D on kernel 3.12/higher)
The fix below was done on an earlier version of 5345, but should work on the current version.
Native gpu init + backlight controls! (Fn keys). Working on all panels except for 14" XGA (1024x768) and 15" XGA (1024x768)!
Checkout http://review.coreboot.org/#/c/5320 and then cherry-pick http://review.coreboot.org/#/c/5345 on top of a coreboot git clone.
Add backlight controls: in src/mainboard/lenovo/t60/devicetree.cb, change gpu_backlight to 0x58BF58BE
Hold on! Check ../index.html#get_edid_panelname to know what LCD panel you have. This is important for the next step!
../index.html#supported_t60_list.
Note to self: Run oprom trace for phcoder (T60 w/ 5320+5345 + oprom + grub) for phcoder. This (among other things) might help to get all panels supported, without modification.
This needs to be rewritten (or better organized, or deleted?). This is also now included in libreboot 6 (using the proper way, not the 7c0000 method which was a hack)
This was done on 5320/6 so far. The fix below is for 5320/6 which is now obsolete. This needs to be re-done for the latest version of 5320. The fix below is (in practise) only for reference, therefore.
See #x60_cb5927_testing for the original (and current) fix, for the replay code. Now we want to implement that on top of http://review.coreboot.org/#/c/5320 which is the current code for native graphics initialization on i945.
src/northbridge/intel/i945/gma.c (using the 7c0000 hack) on 5320: 5320_7c0000_gma.c (rename it to gma.c, replacing the current one).
The above is a hack (as is the original). A better (more correct) method is implemented in later versions of 5927, so that should also be adapted for 5320. For now, you can use the above fix.
The correct way to do it is to set gtt address to (end of stolen memory - gtt size), which is what later versions of 5927 do (successfully).
Here is some debugging output using intel_gpu_tools v1.2-1 (from trisquel repositories) using tool "intel_gtt":
The latest version as-is (5927/11) has not been tested by me yet. Always boot with 'drm.debug=0x06' kernel parameter when testing this.
This is the fix for 3D on kernel 3.12 and higher on i945 (ThinkPad X60 in this case). This is for the replay code. Libreboot 5th release has a version of this backported already (based on 5927/3 using the '7c0000' hack).
The replay code is obsolete (see 5320 changeset on review.coreboot.org for better version which supports more machines/screens, and then 5345 for T60). Information here for reference since that is where the fix was first applied.
Read the information on http://review.coreboot.org/#/c/5927/.
For historical purposes, here is a collection of IRC logs that once existed on this page, related to the issue: kernel312_irc.
PGETBL_CTL differs between VBIOS (-) and native graphics init (+).
- PGETBL_CTL: 0x3ffc0001
+ PGETBL_CTL: 0x3f800001
GTT (graphics translation table) size is PGETBL_save, max 256 KiB. BSM (Base of Stolen Memory) is given by the bios.
Use 'drm.debug=0x06' kernel parameter when booting in grub! Make sure to use kernel 3.14.4 as before (or any recent kernel).
Before each test run, boot a live USB and delete the old logs in /var/log (kernel log, xorg log, dmesg and so on).
Use latest 5927/5320/5345 on X60/T60 (with GTT/3D/kernel3.12 fix) with native graphics initialization. Load (from the ROM) the runningvga.bin for each LCD panel on each machine; do not execute it, only load it! Rename the ROM appropriately, based on the machine name and the panel name. coreboot_nativegfx_5868_plusrunningvga_t60_14_LTD141ECMB.rom, for instance. Keep a copy for later use.
It is (theoretically) supposed to:
You are supposed to:
With each boot, make notes about what you see and get logs using the standard test. You will need the files from #intelvbttool_results for each machine.
Results (# means untested):The VBIOS on i945 (intel gpu) platforms is self-modifying; that is, it's contents change when you run it. intelvbttool takes a dump of the currently running vbios, and parses it.
The idea is that we can extract the VBT tables using this knowledge, on the X60, X60 Tablet and T60 (Intel GPU).
Here is an example of how VBT was implemented on the ThinkPad X230: http://review.coreboot.org/#/c/5396.
Use this kernel: http://samnoble.org/thinkpad/kernel/linux-image-3.14.4-gnuowen_2_i386.deb
You'll need to build a T60 ROM with SeaBIOS and the VGA ROM (for Intel GPU). An X60 ROM is also needed (same configuration, using the VGA ROM for X60).
T60 has DVI on it's dock, make sure that the dock is attached when getting this output.
Get intelvbttool here: http://review.coreboot.org/#/c/5842 (util/intelvbttool).
Now dump a copy of the running VGA BIOS:
$ sudo dd if=/dev/mem bs=64k of=runningvga.bin skip=12 count=1
Then do (and record the output):
$ ./intelvbttool runningvga.bin > intelvbttool_out
Backup both files (runningvga.bin and intelvbttool_out), renaming them to match the machine and LCD panel used. ../index.html#get_edid_panelname will show you how to get the name (model) of the LCD panel used.
When idle, the X60 and T60 make a high pitched whining sound. With a recorder, find out where it originates from. 'processor.max_cstate=2' or 'idle=halt' kernel parameters can be used in GRUB to remove it. Alternatively (and for better battery life), another method is to use 'powertop' (see docs/index.html in libreboot release archives).
funfunctor in IRC says: "sounds like the gain is set to high, AGC of a ADC is not setup correctl probably".
damo22 in IRC says: "damo22: it seems like the T60 (happens on X60 aswell) does not support certain cpu C-states but is being forced to use them and this causes a noise. i believe it's because it doesnt let the cpu go into low power state.".
CareBear\ in IRC says: "it has to do with the CPU and chipset switching power states differently with coreboot than with the factory BIOS and as a result the power supply circuitry on the mainboard emits that noise. the whine is quite clearly directly related to the CPU switching between power states "
Another comment (mailing list):
If this noise doesn't occur with
the vendor firmware, has anybody checked if coreboot uses the same
power management timing settings? (e.g. C4-TIMING_CNT, see [1], there
might be more such settings not mentioned in the public datasheet)
[1] Intel I/O Controller Hub 7 (ICH7) Family Datasheet Document Number: 307013-003
Look into this later. This isn't necessarily a bug, just a part of the code which someone noticed that seems odd.
funfuctor: fchmmr: what is 'eventc' exactly in the devicetree of your board? Is that meant to be programed sequentially somehow?
fchmmr: looks like something with EC
fchmmr: src/ec/lenovo/h8/chip.h: u8 eventc_enable;
fchmmr: src/ec/lenovo/h8/h8.c: ec_write(0x1c, conf->eventc_enable);
funfuctor: fchmmr: yes, better ask phcoder-screen why eventc is defined twice
funfuctor: and which value is correct
fchmmr: looks like 0x3c is incorrect
fchmmr: just a guess
fchmmr: in devicetree.cb it goes event2 then 3 4 5 6 7 c 8 9 then a b c d
fchmmr: but i don't know what 'event c' is
funfuctor: fchmmr: interesting, well in that case you could prob figure it out yourself..
funfuctor: fchmmr: the order should not matter. basically devicetree is syntax for fill in a C struct
funfuctor: fchmmr: look closely at build/mainboard/lenovo/t60/static.c
fchmmr: funfunctor: it was sven schnelle who wrote that (I used 'git blame')
fchmmr: I think "eventc" has something to do with battery
fchmmr: commit 95ebe66f7f5fef64d363cb48e5a441ad505353d1
fchmmr: Author: Sven Schnelle <svens@stackframe.org>
fchmmr: Date: Thu Apr 28 09:29:06 2011 +0000
fchmmr: that's the commit that added those lines.
fchmmr: funfunctor:
fchmmr: "" // C: OEM information
fchmmr: src/ec/lenovo/h8/acpi/battery.asl
funfuctor: fchmmr: i'll leave you with the issue of fixing the devicetree duplicate value
funfuctor: fchmmr: you need to read the datasheet to figure out what register 0x3C is
funfuctor: sorry *0x1C rather
funfuctor: grep eventc src/ec/lenovo/h8/h8.c
funfuctor: ec_write(0x1c, conf->eventc_enable);
Also look in src/ec/lenovo/h8/h8.c and src/ec/lenovo/h8/chip.h and src/mainboard/lenovo/x60/devicetree.cb
Do a 'git blame' and a 'git log path/to/file' etc. ask sven, even.
funfunctor: shadow compiling means you run both compilers (context: GCC and Clang/LLVM) at the same time. If one compiler misses a problem the other compiler hopefully finds it
funfunctor: fchmmr: blow your mind (compiler security and reprodicible builds) - http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/
Copyright © 2014 Francis Rowe, All Rights Reserved.
See ../license.html for license conditions.