# libreboot tutorials
tutorials for libreboot, the reboot library.
Author: glugman

Or go back to main document index.

## Contents

- TODO list
- Standard test
- T60 cpu microcode
- Fast boot
- LCD panels on i945 - fix incompatible panels
- Blind X60 - kernel git bisect
- i945 X60/T60 VBT implementation (experimental: testing)
- IntelVbtTool results
- CPU c-states (X60/T60) buzzing sound on CPU idle
- Battery 'event c' on X60 (and T60?)

# standard test

These logs are usually obtained when testing changes related to graphics on i945 (X60 and T60).

- Make a copy of these files:
  - /var/log/dmesg
  - /var/log/kern.log
  - /var/log/Xorg.0.log
  - /proc/ioports
  - /proc/iomem
  - /sys/class/drm/card0/error
- Record these outputs:
  - sudo intel_reg_dumper
  - uname -r
  - lspci -vvvvnnnnxxxx
  - sudo modprobe msr
  - sudo inteltool -a
  - sudo cbmem -c
- Try some 3D games with latest kernel.

Back to top of page.

# T60 cpu microcode

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.

Back to top of page.

# Fast boot

Based on information supplied by Charles Devereaux. Look into this. The following are the files that he gave me, and what he said:

- x60.config
- get-systemd.sh
- grub.cfg.memdisk
- grub.cfg

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:

- the memdisk acts as a failsave in case the flash has had its grub.cfg removed or damanged
- the flash grub.cfg is a failsafe in case the HD grub.cfg was damaged or removed

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.

Back to top of page.

# LCD panels on i945 - fix incompatible panels

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:

- Coreboot (or libreboot, whatever) with VBIOS (disable native graphics also)
- (Factory BIOS also?)

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.

Back to top of page.

# Blind X60 - kernel git bisect

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.

- See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613979#102
- git help bisect has an example of how to bisect
- See http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search
- I have ccache. Read on how to compile kernel using ccache instead of regular gcc. (speeds up compiling). How I installed it:
  - sudo apt-get install ccache
  - echo 'export PATH="/usr/lib/ccache:$PATH"' | tee -a ~/.bashrc \ && source ~/.bashrc && echo $PATH

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.

Back to top of page

# i945 gfx: X60/T60 VBT implementation (experimental: testing)

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:

- Enable kernel to see VBT tables so that it can see the panel. (theoretically this will make T60 15" XGA/1024x768 work)

You are supposed to:

- enable native graphics in menuconfig
- include the self-modified VGA ROM (load, but not execute) - for reverse engineering the correct VBT tables.

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):

- X60/X60s:
  - TMD-Toshiba LTD121ECHB: #
  - CMO N121X5-L06: #
  - Samsung LTN121XJ-L07: #
  - BOE-Hydis HT121X01-101: #
- X60T XGA:
  - BOE-Hydis HV121X03-100: #
- X60T SXGA+:
  - BOE-Hydis HV121P01-100: #
- T60 14" XGA:
  - Samsung LTN141XA-L01: #
  - CMO N141XC: #
  - BOE-Hydis HT14X14: #
  - TMD-Toshiba LTD141ECMB: #
- T60 14" SXGA+
  - TMD-Toshiba LTD141EN9B: #
  - Samsung LTN141P4-L02: #
  - Boe-Hydis HT14P12: #
- T60 15" XGA
  - Samsung LTN150XG-L08: #
  - LG-Philips LP150X09: #
  - 13N7068 (IDtech): #
  - 13N7069 (CMO): #
- T60 15" SXGA+
  - LG-Philips LP150E05-A2K1: #
  - BOE-Hydis HV150P01-100: #
- T60 15" UXGA
  - BOE-Hydis HV150UX1-100: #
  - IDTech N150U3-L01: #
  - BOE-Hydis HV150UX1-102: #
- T50 15" QXGA
  - IDtech IAQX10N: #
  - IDtech IAQX10S: #

Back to top of page

# intelvbttool test results (VGA ROM's)

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.

## Test results (# means untested and all had docks, unless noted).

- X60/X60s:
  - TMD-Toshiba LTD121ECHB: #
  - CMO N121X5-L06: #
  - Samsung LTN121XJ-L07: #
  - BOE-Hydis HT121X01-101: #
- X60T XGA (1024x768):
  - BOE-Hydis HV121X03-100: #
- X60T SXGA+ (1400x1050):
  - BOE-Hydis HV121P01-100: #
- T60 14" XGA (1024x768):
  - Samsung LTN141XA-L01: #
  - CMO N141XC: #
  - BOE-Hydis HT14X14: #
  - TMD-Toshiba LTD141ECMB: #
- T60 14" SXGA+ (1400x1050):
  - TMD-Toshiba LTD141EN9B: #
  - Samsung LTN141P4-L02: #
  - Boe-Hydis HT14P12: #
- T60 15" XGA (1024x768):
  - Samsung LTN150XG-L08: #
  - LG-Philips LP150X09: #
  - 13N7068 (IDtech): #
  - 13N7069 (CMO): #
- T60 15" SXGA+ (1400x1050):
  - LG-Philips LP150E05-A2K1: #
  - BOE-Hydis HV150P01-100: #
- T60 15" UXGA (1600x1200):
  - BOE-Hydis HV150UX1-100: #
  - IDTech N150U3-L01: #
  - BOE-Hydis HV150UX1-102: #
- T60 15" QXGA (2048x1536):
  - IDtech IAQX10N: #
  - IDtech IAQX10S: #

Back to top of page.

# Buzzing / static noise when not using idle=halt or processor.max_cstate=2 in GRUB

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

Back to top of page.

# Battery 'event c' on X60 (and T60?)

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.

Back to top of page.

# Unlisted Notes

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/

Back to top of page.

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.