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).
Every other T7200 tested so far has worked without microcode updates.
Based on information supplied by Charles Devereaux. Look into this. The following are the files that he gave me, and what he said:
failsafes to allow people to experiment with few risks.The memdisk tries to load a grub.cfg from each partition, failing that from the CBFS, and failing that prepares the serial port and shows a simple menu reminding the user that this is the memdisk (beeps are also played) and some simple options (ex: call directly a linux kernel).
The grub.cfg from the CBFS tries to load a working grub.cfg from a thumbdrive, and failing that shows a menu offering to boot on seabios (for CD boot)
This makes it possible to say remove the HD and still have a booting machine (using a thumbdrive) - which may be an interesting option to offer to your users (a "rescue/reinstall" thumbdrive, or a simple failsafe in case the user wants to reinstall from a CD into a brand new HD)
It's also hacker friendly:
Just some simple if logic, but it does the job.
Besides that, if you want to experiment with fast booting, my systemd
configure script follows. Just boot your kernel with
init=/lib/systemd/systemd. You also need to add at the botton of the
resulting /lib/udev/rules.d/99-systemd.rules the following to make network
configuration automatic:
SUBSYSTEM=="net", KERNEL!="lo", TAG+="systemd",
ENV{SYSTEMD_ALIAS}+="/sys/subsystem/net/devices/$name"
ENV{SYSTEMD_WANTS}="ifup@%k.service"
It will put the systemd stuff in /lib/systemd instead of /usr/lib/systemd (on debian), allowing a peacefull coexistence, and won't use any of the old /etc/init.d stuff (major cause of slowdown).
This is the exact systemd configuration I used to get a system up in 0.6s as reported on the mailing list.
Further optimizations of the boot-time requires to optimize the kernel configuration even more. Here is my current .config (everything is built-in, slowly removing modules (ex: yenta, firewire) one by one to see where I can gain speed.
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.
check if intel_bios_reader from intel-gpu-tools reports the same value (BIOS has a hardcoded value) for PWM modulation frequency. This file can read the VBIOS (64K dump).
Check other tools in intel-gpu-tools aswell, compare outputs. Possibly add more information to intel-regs.py output (submit changes to mtjm). Do oprom trace / replay (http://www.coreboot.org/User:GNUtoo#How_to_get_rid_of_the_vbios_of_the_x60_.5BNew_Version.5D)
Study how EDID works and how gma.c handles it.
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 (from review.coreboot.org) 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)
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
The change is also included in libreboot 6.
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 changeset (review.coreboot.org), but should work on the current version. it is included in libreboot 6
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.
See #lcd_i945_incompatibility.
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.
intel_bios_dumper (use man) in intel-gpu-tools seems interesting.
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.