From 1577195ca8899df42dfce30e5d3c72345ea17e93 Mon Sep 17 00:00:00 2001 From: Francis Rowe Date: Mon, 13 Oct 2014 21:31:47 -0400 Subject: Documentation: major cleanup. --- (limited to 'docs/future/index.html') diff --git a/docs/future/index.html b/docs/future/index.html index 0bdabf4..52f1ec8 100644 --- a/docs/future/index.html +++ b/docs/future/index.html @@ -35,16 +35,12 @@

Contents

@@ -99,89 +95,37 @@
-

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

- - - -

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

i945 VRAM size

+ +

+ Apparently, only 8MB VRAM is available on i945 GPU's (though it could do 64MB):
+ phcoder: No. Hardware default is 8 MiB. When I wanted to make it configurable, I saw that docs mention only one other alternative: 1MiB. Later isn't event enough for 1024x768 at 24bpp without any acceleration or double buffering. It's possible there are undocumented values. Which options do you have in vendor BIOS? + How to find out how much vram you have:
+ phcoder: TOM - BSM
+ phcoder: check what vendor BIOS offers as options
+ fchmmr: I thought it could do 64MB usually
+ phcoder: not accorging to doc.
+ phcoder: see mobile-945-express-chipset-datasheet page 93
+ phcoder: see also src/northbridge/intel/i945/{early_init,northbridge,gma}.c
+ fchmmr: "011 = DVMT (UMA) mode, 8 MB of memory pre-allocated for
+ fchmmr: frame buffer."
+ fchmmr: "Others - reserved"
+ phcoder: the easiest way is a loop at this position which tries different values and reads (and prints) BSM with them
+ stefanct: fchmmr: he suggest that you change the value and look how BSM reacts to that
+ stefanct: as he pointed out earlier vram size = TOM - BSM
+ stefanct: different values of GMS
+ stefanct: phcoder: hm... this could be a hint. look at the text description of TOLUD at page 103
+ stefanct: it mentions 64 MB in the text about BSM as well
+ stefanct: table 18...
+ phcoder: stefanct: I have a guess which value make is 64 but I will not tell to avoid skewing test results
+ stefanct: phcoder: sure... i assumed you were not sure if it supports it at all. testing it properly is of course a good idea :)
+ stefanct: test the various possible (but reserved) values of GMS and see what the resulting VRAM size is
+ fchmmr: so, TOM - BSM +

+

+ Back to top of page.

-

- 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. -

- -

Back to top of page.

-

LCD panels on i945 - fix incompatible panels

@@ -226,64 +170,43 @@ 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. -

- - -

- 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. + About fixing remaining LCD panels on 5345:
+ 'polarity' is mentioned in coreboot log (cbmem -c). compare output (with working and non-working panel). (and see the other notes in docs/future/index.html)
+ phcoder says: hint for T60: it might be that failing panels are 8bpc
+ fchmmr: what does 8bpc mean? And what do you think the other (non-failing) panel are?
+ phcoder: 6bpc. bits per colour. May also be reffered as 18-bit vs 24-bit panels
+ phcoder: just collect EDIDs from failing and working panels
+ phcoder gave me this for collecting EDID data: + http://www.o2genum.com/2013/08/lp156wh2-tlaa-lcd-panel-edid.html

-

Back to top of page

+

Back to top of page.

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

+

- intel_bios_dumper (use man) in intel-gpu-tools seems interesting. + intel_bios_dumper 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). + Use 'drm.debug=0x06' kernel parameter when booting in grub!

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! + Load (from the ROM) the runningvga.bin for each LCD panel on each machine; do not execute it, only load it! (coreboot will have to be modified). 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. @@ -291,78 +214,78 @@

Results (# means untested): -

Back to top of page

@@ -385,11 +308,6 @@

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

@@ -491,95 +409,6 @@
-

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. -- cgit v0.9.1