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.
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 <info@gluglug.org.uk>
This document is released under the Creative Commons Attribution-ShareAlike 4.0 International Public License and all future versions.
A copy of the license can be found at ../license.txt.
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See ../license.txt for more information.