<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>libreboot tutorials</title>
<style type="text/css">
body {
font-family: sans-serif;
font-size: 1em;
background: #fff;
color: #000;
}
</style>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="author" content="glugman">
<meta name="description" content="tutorials for libreboot, the reboot library.">
<meta name="robots" content="all">
</head>
<body>
<header>
<h1 id="pagetop">Development notes</h1>
<aside>These are development notes, for future use. For old (obselete) notes, see <a href="old.html">old.html</a>.</aside>
</header>
<p>
Or go <a href="../">back to main document index</a>.
</p>
<hr/>
<h2>Contents</h2>
<ul>
<li><a href="#todo">TODO list</a></li>
<li><a href="#standard_test">Standard test</a></li>
<li><a href="#t60_cpu_microcode">T60 cpu microcode</a></li>
<li><a href="#fastboot">Fast boot</a></li>
<li><a href="#lcd_i945_incompatibility">LCD panels on i945 - fix incompatible panels</a></li>
<li><a href="#blind_x60">Blind X60 - kernel git bisect</a></li>
<li><a href="#i945_vbt">i945 X60/T60 VBT implementation (experimental: testing)</a></li>
<li><a href="#intelvbttool_results">IntelVbtTool results</a></li>
<li><a href="#cpu_cstates_buzzing">CPU c-states (X60/T60) buzzing sound on CPU idle</a></li>
<li><a href="#battery_eventc">Battery 'event c' on X60 (and T60?)</a></li>
</ul>
<hr/>
<h1 id="standard_test">standard test</h1>
<p>
These logs are usually obtained when testing changes related to graphics on i945 (X60 and T60).
</p>
<ul>
<li>
Make a copy of these files:
<ul>
<li>/var/log/dmesg</li>
<li>/var/log/kern.log</li>
<li>/var/log/Xorg.0.log</li>
<li>/proc/ioports</li>
<li>/proc/iomem</li>
<li>/sys/class/drm/card0/error</li>
</ul>
</li>
<li>
Record these outputs:
<ul>
<li>sudo intel_reg_dumper</li>
<li>uname -r</li>
<li>lspci -vvvvnnnnxxxx</li>
<li>sudo modprobe msr</li>
<li>sudo inteltool -a</li>
<li>sudo cbmem -c</li>
</ul>
</li>
<li>
Try some 3D games with latest kernel.
</li>
</ul>
<p><a href="#pagetop">Back to top of page.</a></p>
<hr/>
<h1 id="t60_cpu_microcode">T60 cpu microcode</h1>
<p>
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 <a href="../t7200q">t7200q</a> directory (q means quirk).
</p>
<p>
Every other T7200 tested so far has worked without microcode updates.
</p>
<p><a href="#pagetop">Back to top of page.</a></p>
<hr/>
<h1 id="fastboot">Fast boot</h1>
<p>
Based on information supplied by Charles Devereaux. Look into this. The following are the files
that he gave me, and what he said:
</p>
<ul>
<li><a href="fastboot/x60.config">x60.config</a></li>
<li><a href="fastboot/get-systemd.sh">get-systemd.sh</a></li>
<li><a href="fastboot/grub.cfg.memdisk">grub.cfg.memdisk</a></li>
<li><a href="fastboot/grub.cfg">grub.cfg</a></li>
</ul>
<p>
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).
</p>
<p>
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)
</p>
<p>
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)
</p>
<p>
It's also hacker friendly:
</p>
<ul>
<li>
the memdisk acts as a failsave in case the flash has had its grub.cfg removed or damanged
</li>
<li>
the flash grub.cfg is a failsafe in case the HD grub.cfg was damaged or removed
</li>
</ul>
<p>
Just some simple if logic, but it does the job.
</p>
<p>
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:<br/>
<b>
SUBSYSTEM=="net", KERNEL!="lo", TAG+="systemd",<br/>
ENV{SYSTEMD_ALIAS}+="/sys/subsystem/net/devices/$name"<br/>
ENV{SYSTEMD_WANTS}="ifup@%k.service"
</b>
</p>
<p>
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).
</p>
<p>
This is the exact systemd configuration I used to get a system up in 0.6s
as reported on the mailing list.
</p>
<p>
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.
</p>
<p><a href="#pagetop">Back to top of page.</a></p>
<hr/>
<h1 id="lcd_i945_incompatibility">LCD panels on i945 - fix incompatible panels</h1>
<p>
Fix T60 issues (see incompatible panels listed at <a href="../index.html#supported_t60_list">../index.html#supported_t60_list</a>).
</p>
<p>
Run that tool (resources/utilities/i945gpu/intel-regs.py) as root on machines with the offending panels in:
</p>
<ul>
<li>Coreboot (or libreboot, whatever) with VBIOS (disable native graphics also)</li>
<li>(Factory BIOS also?)</li>
</ul>
<p>
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).
</p>
<p>
Other values/registers might also need to be added to the script for these tests.
</p>
<p>
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).
</p>
<p>
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 (<a href="http://www.coreboot.org/User:GNUtoo#How_to_get_rid_of_the_vbios_of_the_x60_.5BNew_Version.5D">http://www.coreboot.org/User:GNUtoo#How_to_get_rid_of_the_vbios_of_the_x60_.5BNew_Version.5D</a>)
</p>
<p>
Study how EDID works and how gma.c handles it.
</p>
<p>
Original getregs.py script can be found at <a href="http://hg.mtjm.eu/scripts/file/tip/intel-regs.py">http://hg.mtjm.eu/scripts/file/tip/intel-regs.py</a>
written by Michał Masłowski.
</p>
<p><a href="#pagetop">Back to top of page.</a></p>
<hr/>
<h1 id="blind_x60">Blind X60 - kernel git bisect</h1>
<p>
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.
</p>
<ul>
<li>See <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613979#102">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613979#102</a></li>
<li><b>git help bisect</b> has an example of how to bisect</li>
<li>See <a href="http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search">http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search</a></li>
<li>
I have ccache. Read on how to compile kernel using ccache instead of regular gcc. (speeds up compiling). How I installed it:
<ul>
<li>sudo apt-get install ccache</li>
<li>echo 'export PATH="/usr/lib/ccache:$PATH"' | tee -a ~/.bashrc \ && source ~/.bashrc && echo $PATH</li>
</ul>
</li>
</ul>
<p>
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.
</p>
<p><a href="#pagetop">Back to top of page</a></p>
<hr/>
<h1 id="i945_vbt">i945 gfx: X60/T60 VBT implementation (experimental: testing)</h1>
<p>
intel_bios_dumper (use man) in intel-gpu-tools seems interesting.
</p>
<p>
<b>Use 'drm.debug=0x06' kernel parameter when booting in grub! Make sure to use kernel 3.14.4 as before (or any recent kernel).</b>
</p>
<p>
Before each test run, boot a live USB and delete the old logs in /var/log (kernel log, xorg log, dmesg and so on).
</p>
<p>
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.
</p>
<p>It is (theoretically) supposed to:</p>
<ul>
<li>Enable kernel to see VBT tables so that it can see the panel. (theoretically this will make T60 15" XGA/1024x768 work)</li>
</ul>
<p>You are supposed to:</p>
<ul>
<li>enable native graphics in menuconfig</li>
<li>include the self-modified VGA ROM (load, but not execute) - for reverse engineering the correct VBT tables.</li>
</ul>
<p>
With each boot, make notes about what you see and get logs using the <a href="#standard_test">standard test</a>.
You will need the files from <a href="#intelvbttool_results">#intelvbttool_results</a> for each machine.
</p>
Results (# means untested):
<ul>
<li>
<b>X60/X60s:</b>
<ul>
<li>TMD-Toshiba LTD121ECHB: #</li>
<li>CMO N121X5-L06: #</li>
<li>Samsung LTN121XJ-L07: #</li>
<li>BOE-Hydis HT121X01-101: #</li>
</ul>
</li>
<li>
<b>X60T XGA:</b>
<ul>
<li>BOE-Hydis HV121X03-100: #</li>
</ul>
</li>
<li>
<b>X60T SXGA+:</b>
<ul>
<li>BOE-Hydis HV121P01-100: #</li>
</ul>
</li>
<li>
<b>T60 14" XGA:</b>
<ul>
<li>Samsung LTN141XA-L01: #</li>
<li>CMO N141XC: #</li>
<li>BOE-Hydis HT14X14: #</li>
<li>TMD-Toshiba LTD141ECMB: #</li>
</ul>
</li>
<li>
<b>T60 14" SXGA+</b>
<ul>
<li>TMD-Toshiba LTD141EN9B: #</li>
<li>Samsung LTN141P4-L02: #</li>
<li>Boe-Hydis HT14P12: #</li>
</ul>
</li>
<li>
<b>T60 15" XGA</b>
<ul>
<li>Samsung LTN150XG-L08: #</li>
<li>LG-Philips LP150X09: #</li>
<li>13N7068 (IDtech): #</li>
<li>13N7069 (CMO): #</li>
</ul>
</li>
<li>
<b>T60 15" SXGA+</b>
<ul>
<li>LG-Philips LP150E05-A2K1: #</li>
<li>BOE-Hydis HV150P01-100: #</li>
</ul>
</li>
<li>
<b>T60 15" UXGA</b>
<ul>
<li>BOE-Hydis HV150UX1-100: #</li>
<li>IDTech N150U3-L01: #</li>
<li>BOE-Hydis HV150UX1-102: #</li>
</ul>
</li>
<li>
<b>T50 15" QXGA</b>
<ul>
<li>IDtech IAQX10N: #</li>
<li>IDtech IAQX10S: #</li>
</ul>
</li>
</ul>
<p><a href="#pagetop">Back to top of page</a></p>
<hr/>
<h1 id="intelvbttool_results">intelvbttool test results (VGA ROM's)</h1>
<p>
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.
</p>
<p>
The idea is that we can extract the VBT tables using this knowledge, on the X60, X60 Tablet and T60 (Intel GPU).
</p>
<p>
Here is an example of how VBT was implemented on the ThinkPad X230:
<a href="http://review.coreboot.org/#/c/5396" target="_blank">http://review.coreboot.org/#/c/5396</a>.
</p>
<p>
Use this kernel:
<a href="http://samnoble.org/thinkpad/kernel/linux-image-3.14.4-gnuowen_2_i386.deb">http://samnoble.org/thinkpad/kernel/linux-image-3.14.4-gnuowen_2_i386.deb</a>
</p>
<p>
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).
</p>
<p>
T60 has DVI on it's dock, make sure that the dock is attached when getting this output.
</p>
<p>
Get intelvbttool here: <a href="http://review.coreboot.org/#/c/5842">http://review.coreboot.org/#/c/5842</a> (util/intelvbttool).
</p>
<p>
Now dump a copy of the running VGA BIOS:
<b>$ sudo dd if=/dev/mem bs=64k of=runningvga.bin skip=12 count=1</b><br/>
Then do (and record the output):<br/>
<b>$ ./intelvbttool runningvga.bin > intelvbttool_out</b>
</p>
<p>
Backup both files (runningvga.bin and intelvbttool_out), renaming them to match the machine and LCD panel used.
<a href="../index.html#get_edid_panelname">../index.html#get_edid_panelname</a> will show you how to get the name (model) of the LCD panel used.
</p>
<h2>Test results (# means untested and all had docks, unless noted).</h2>
<ul>
<li>
<b>X60/X60s:</b>
<ul>
<li>TMD-Toshiba LTD121ECHB: #</li>
<li>CMO N121X5-L06: #</li>
<li>Samsung LTN121XJ-L07: #</li>
<li>BOE-Hydis HT121X01-101: #</li>
</ul>
</li>
<li>
<b>X60T XGA (1024x768):</b>
<ul>
<li>BOE-Hydis HV121X03-100: #</li>
</ul>
</li>
<li>
<b>X60T SXGA+ (1400x1050):</b>
<ul>
<li>BOE-Hydis HV121P01-100: #</li>
</ul>
</li>
<li>
<b>T60 14" XGA (1024x768):</b>
<ul>
<li>Samsung LTN141XA-L01: #</li>
<li>CMO N141XC: #</li>
<li>BOE-Hydis HT14X14: #</li>
<li>TMD-Toshiba LTD141ECMB: #</li>
</ul>
</li>
<li>
<b>T60 14" SXGA+ (1400x1050):</b>
<ul>
<li>TMD-Toshiba LTD141EN9B: #</li>
<li>Samsung LTN141P4-L02: #</li>
<li>Boe-Hydis HT14P12: #</li>
</ul>
</li>
<li>
<b>T60 15" XGA (1024x768):</b>
<ul>
<li>Samsung LTN150XG-L08: #</li>
<li>LG-Philips LP150X09: #</li>
<li>13N7068 (IDtech): #</li>
<li>13N7069 (CMO): #</li>
</ul>
</li>
<li>
<b>T60 15" SXGA+ (1400x1050):</b>
<ul>
<li>LG-Philips LP150E05-A2K1: #</li>
<li>BOE-Hydis HV150P01-100: #</li>
</ul>
</li>
<li>
<b>T60 15" UXGA (1600x1200):</b>
<ul>
<li>BOE-Hydis HV150UX1-100: #</li>
<li>IDTech N150U3-L01: #</li>
<li>BOE-Hydis HV150UX1-102: #</li>
</ul>
</li>
<li>
<b>T60 15" QXGA (2048x1536):</b>
<ul>
<li>IDtech IAQX10N: #</li>
<li>IDtech IAQX10S: #</li>
</ul>
</li>
</ul>
<p><a href="#pagetop">Back to top of page.</a></p>
<hr/>
<h1 id="cpu_cstates_buzzing">Buzzing / static noise when not using idle=halt or processor.max_cstate=2 in GRUB</h1>
<p>
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).
</p>
<p>
funfunctor in IRC says: <i>"sounds like the gain is set to high, AGC of a ADC is not setup correctl probably"</i>.
</p>
<p>
damo22 in IRC says: <i>"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."</i>.
</p>
<p>
CareBear\ in IRC says: <i>"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
"</i>
</p>
<p>
Another comment (mailing list):<br/>
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) <br/>
<b>[1] Intel I/O Controller Hub 7 (ICH7) Family Datasheet Document Number: 307013-003 </b>
</p>
<p>
</p>
<p><a href="#pagetop">Back to top of page.</a></p>
<hr/>
<h1 id="battery_eventc">Battery 'event c' on X60 (and T60?)</h1>
<p>
Look into this later. This isn't necessarily a bug, just a part of the code which someone noticed that seems odd.
</p>
<p>
funfuctor: fchmmr: what is 'eventc' exactly in the devicetree of your board? Is that meant to be programed sequentially somehow?<br/>
fchmmr: looks like something with EC<br/>
fchmmr: src/ec/lenovo/h8/chip.h: u8 eventc_enable;<br/>
fchmmr: src/ec/lenovo/h8/h8.c: ec_write(0x1c, conf->eventc_enable);<br/>
funfuctor: fchmmr: yes, better ask phcoder-screen why eventc is defined twice<br/>
funfuctor: and which value is correct<br/>
fchmmr: looks like 0x3c is incorrect<br/>
fchmmr: just a guess<br/>
fchmmr: in devicetree.cb it goes event2 then 3 4 5 6 7 c 8 9 then a b c d<br/>
fchmmr: but i don't know what 'event c' is<br/>
funfuctor: fchmmr: interesting, well in that case you could prob figure it out yourself..<br/>
funfuctor: fchmmr: the order should not matter. basically devicetree is syntax for fill in a C struct<br/>
funfuctor: fchmmr: look closely at build/mainboard/lenovo/t60/static.c<br/>
fchmmr: funfunctor: it was sven schnelle who wrote that (I used 'git blame')<br/>
fchmmr: I think "eventc" has something to do with battery<br/>
fchmmr: commit 95ebe66f7f5fef64d363cb48e5a441ad505353d1<br/>
fchmmr: Author: Sven Schnelle <svens@stackframe.org><br/>
fchmmr: Date: Thu Apr 28 09:29:06 2011 +0000<br/>
fchmmr: that's the commit that added those lines.<br/>
fchmmr: funfunctor:<br/>
fchmmr: "" // C: OEM information<br/>
fchmmr: src/ec/lenovo/h8/acpi/battery.asl<br/>
funfuctor: fchmmr: i'll leave you with the issue of fixing the devicetree duplicate value<br/>
funfuctor: fchmmr: you need to read the datasheet to figure out what register 0x3C is<br/>
funfuctor: sorry *0x1C rather<br/>
funfuctor: grep eventc src/ec/lenovo/h8/h8.c<br/>
funfuctor: ec_write(0x1c, conf->eventc_enable);<br/>
Also look in src/ec/lenovo/h8/h8.c and src/ec/lenovo/h8/chip.h and src/mainboard/lenovo/x60/devicetree.cb<br/>
Do a 'git blame' and a 'git log path/to/file' etc. ask sven, even.
</p>
<p><a href="#pagetop">Back to top of page.</a></p>
<hr/>
<h1 id="unlisted">Unlisted Notes</h1>
<p>
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<br/>
funfunctor: fchmmr: blow your mind (compiler security and reprodicible builds) - http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/
</p>
<p>
<a href="#pagetop">Back to top of page.</a>
</p>
<hr/>
<p>
Copyright © 2014 Francis Rowe <info@gluglug.org.uk><br/>
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 <a href="../license.txt">../license.txt</a>.
</p>
<p>
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 <a href="../license.txt">../license.txt</a> for more information.
</p>
</body>
</html>