From 4c3d46238022f0c9955ae7e8b10c9f1716dd871a Mon Sep 17 00:00:00 2001 From: Francis Rowe Date: Wed, 04 Feb 2015 04:14:49 -0500 Subject: Documentation: implement theme, drastically improve readability --- (limited to 'docs/future') diff --git a/docs/future/index.html b/docs/future/index.html index 6f05022..450e85a 100644 --- a/docs/future/index.html +++ b/docs/future/index.html @@ -16,199 +16,333 @@ -
-

Development notes

- -
- -

- Or go back to main document index. -

+
-
+

Development notes

+

+ These are development notes, for future use. For old (obselete) notes, see old.html. +

+

+ Or go back to main document index. +

+ +
-

Contents

- +
+ +

Table of contents

+ + +
-
+
+ +

standard test

+

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

+ -

standard test

-

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

-
+ +
+ +

T60 cpu microcode

+ +

+ TODO: T60: find (for rare buggy CPUs 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.

+ +
+ +
+ +

i945 VRAM size

+ +

+ Apparently, only 8MB VRAM is available on i945 GPUs (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 that 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. +

+ +
+ +
+ +

LCD panels on i945 - fix incompatible panels

+ +

+ Fix T60 issues (see incompatible panels listed at ../hcl/index.html#supported_t60_list). +

+ +

+ Run that tool (resources/utilities/i945gpu/intel-regs.py) as root on machines with the offending panels in: +

- -
  • - Record these outputs: + +

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

    + +

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

    + +
    • + +
    + +

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

    + +

    + intel_bios_dumper in intel-gpu-tools seems interesting. +

    +

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

    +

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

    + +

    You are supposed to:

    - -
  • - Try some 3D games with latest kernel. -
    • - - -

    Back to top of page.

    - -
    - -

    T60 cpu microcode

    - -

    - TODO: T60: find (for rare buggy CPUs 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.

    - -
    - -

    i945 VRAM size

    -

    - Apparently, only 8MB VRAM is available on i945 GPUs (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 that 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. -

    - -
    - -

    LCD panels on i945 - fix incompatible panels

    - -

    - Fix T60 issues (see incompatible panels listed at ../hcl/index.html#supported_t60_list). -

    +

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

    -

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

    + Results (# means untested): + -

    - Other values/registers might also need to be added to the script for these tests. -

    +

    Back to top of page

    + +
    -

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

    +

    intelvbttool test results (VGA ROM dumps)

    +

    + The VBIOS on i945 (intel gpu) platforms is self-modifying; that is, + its contents change when you run it. intelvbttool takes a dump of + the currently running vbios, and parses it. +

    -

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

    +

    + The idea is that we can extract the VBT tables using this knowledge, on the X60, X60 Tablet and T60 (Intel GPU). +

    -

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

    +

    + Here is an example of how VBT was implemented on the ThinkPad X230: + http://review.coreboot.org/#/c/5396. +

    -

    Back to top of page.

    +

    + 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 its dock, make sure that the dock is attached when getting this output. +

    -

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

    +

    + Get intelvbttool here: http://review.coreboot.org/#/c/5842 (util/intelvbttool). +

    -

    - intel_bios_dumper in intel-gpu-tools seems interesting. -

    -

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

    -

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

    +

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

    -

    You are supposed to:

    - +

    + Backup both files (runningvga.bin and intelvbttool_out), renaming them to match the machine and LCD panel used. + ../misc/index.html#get_edid_panelname will show you how to get the name (model) of the LCD panel used. +

    -

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

    +

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

    - Results (# means untested):
  • - X60T XGA: + X60T XGA (1024x768):
    • BOE-Hydis HV121X03-100: #
  • - X60T SXGA+: + X60T SXGA+ (1400x1050):
    • BOE-Hydis HV121P01-100: #
  • - T60 14" XGA: + T60 14" XGA (1024x768):
    • Samsung LTN141XA-L01: #
    • CMO N141XC: #
      • @@ -241,7 +375,7 @@
  • - T60 14" SXGA+ + T60 14" SXGA+ (1400x1050):
    • TMD-Toshiba LTD141EN9B: #
    • Samsung LTN141P4-L02: #
      • @@ -249,24 +383,23 @@
  • - T60 15" XGA + T60 15" XGA (1024x768):
    • Samsung LTN150XG-L08: #
    • LG-Philips LP150X09: #
    • 13N7068 (IDtech): #
    • 13N7069 (CMO): #
      • -
  • - T60 15" SXGA+ + T60 15" SXGA+ (1400x1050):
    • LG-Philips LP150E05-A2K1: #
    • BOE-Hydis HV150P01-100: #
  • - T60 15" UXGA + T60 15" UXGA (1600x1200):
    • BOE-Hydis HV150UX1-100: #
    • IDTech N150U3-L01: #
      • @@ -274,7 +407,7 @@
  • - T50 15" QXGA + T60 15" QXGA (2048x1536):
    • IDtech IAQX10N: #
    • IDtech IAQX10S: #
      • @@ -282,175 +415,69 @@
    -

    Back to top of page

    - -
    - -

    intelvbttool test results (VGA ROM dumps)

    -

    - The VBIOS on i945 (intel gpu) platforms is self-modifying; that is, - its 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. -

    +

    Back to top of page.

    + +
    • + +
    + +

    Fallback patches

    -

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

    + + +

    Back to top of page.

    + +
    + +
    -

    - T60 has DVI on its dock, make sure that the dock is attached when getting this output. -

    +

    Other - unlisted (low priority)

    + + + +

    Back to top of page.

    + +
    -

    - 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 + Copyright © 2014, 2015 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.

    - Backup both files (runningvga.bin and intelvbttool_out), renaming them to match the machine and LCD panel used. - ../misc/index.html#get_edid_panelname will show you how to get the name (model) of the LCD panel used. + 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.

    - -

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

    - - - -

    Back to top of page.

    - -
    - -

    Fallback patches

    - - -
    - -

    Other - unlisted (low priority)

    - - - -
    - -

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

    +
    diff --git a/docs/future/old.html b/docs/future/old.html index eeaa96e..0f77a0a 100644 --- a/docs/future/old.html +++ b/docs/future/old.html @@ -16,256 +16,272 @@ -
    -

    Development notes (old/obsolete notes)

    - -
    - -

    - These are old (obsolete) notes that mare kept because they might become useful again in the future. -

    - -
    - -

    Contents

    - +
    -
    +

    Development notes (old/obsolete notes)

    +

    + For current notes, see index.html. +

    -

    X60 native graphics initialization (with backlight controls)

    +

    + These are old (obsolete) notes that mare kept because they might become useful again in the future. +

    + +
    -

    - - This is now obsolete. A better way was found (included in libreboot): http://review.coreboot.org/#/c/6731/ - -

    +
    + +

    Table of contents

    + + +
    + +
    + +

    X60 native graphics initialization (with backlight controls)

    -

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

    +

    + + This is now obsolete. A better way was found (included in libreboot): http://review.coreboot.org/#/c/6731/ + +

    -

    Further 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.. + Also check #5320_kernel312fix (to fix 3D on kernel 3.12/higher)

    - Intel-gpu-tools may prove useful for further debugging: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ + The fix below was done on 5320/6 (from review.coreboot.org) but should work just fine on later versions of 5320.

    - 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. + Native gpu init + backlight controls! (Fn keys). Also confirmed on X60 Tablet (1024x768) and X60 Tablet (1400x1050)

    - 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. + Add backlight controls: in src/mainboard/lenovo/x60/devicetree.cb, change gpu_backlight to 0x879F879E

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

    - phcoder (Vladimir Serbinenko) who is author of 5320 (review.coreboot.org) talks about 'duty cycle limit' and 'flickering frequency'. + 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).

    -

    Back to top of page

    - -
    +

    Further 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'. +

    + +

    Back to top of page

    + +
    + +
    + +

    T60 native graphics initialization (with backlight controls)

    -

    T60 native graphics initialization (with backlight controls)

    +

    + + This is now obsolete. A better way was found (included in libreboot): http://review.coreboot.org/#/c/6731/ + +

    +

    + 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 ../misc/index.html#get_edid_panelname to know what LCD panel you have. This is important for the next step! +

    -

    - - This is now obsolete. A better way was found (included in libreboot): http://review.coreboot.org/#/c/6731/ - -

    -

    - 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 ../misc/index.html#get_edid_panelname to know what LCD panel you have. This is important for the next step! -

    +

    Supported panels

    +

    + ../hcl/index.html#supported_t60_list. +

    -

    Supported panels

    - ../hcl/index.html#supported_t60_list. + See index.html#lcd_i945_incompatibility.

    + +

    Back to top of page

    + +
    -

    - See index.html#lcd_i945_incompatibility. -

    - -

    Back to top of page

    - -
    +
    -

    i945: 3D fix (based on 5927) for kernel 3.12+ on 5320

    +

    i945: 3D fix (based on 5927) for kernel 3.12+ on 5320

    -

    - - This is now obsolete. Merged in coreboot: http://review.coreboot.org/#/c/5927/ - -

    +

    + + This is now obsolete. Merged in coreboot: http://review.coreboot.org/#/c/5927/ + +

    -

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

    +

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

    +

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

    +

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

    +

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

    +

    + Here is some debugging output using intel_gpu_tools v1.2-1 (from trisquel repositories) using tool "intel_gtt": +

    - + + +

    Back to top of page

    + +
    + +
    + +

    i945/X60: Coreboot 5927 testing (3D fix for kernel 3.12+ on replay code)

    -

    Back to top of page

    +

    + + This is now obsolete. Merged in coreboot: http://review.coreboot.org/#/c/5927/ + +

    -
    +

    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.

    -

    i945/X60: Coreboot 5927 testing (3D fix for kernel 3.12+ on replay code)

    +

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

    -

    - - This is now obsolete. Merged in coreboot: http://review.coreboot.org/#/c/5927/ - -

    +

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

    -

    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.

    +

    + Read the information on http://review.coreboot.org/#/c/5927/. +

    -

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

    +

    + For historical purposes, here is a collection of IRC logs that once existed on this page, related to the issue: + kernel312_irc. +

    -

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

    +

    + PGETBL_CTL differs between VBIOS (-) and native graphics init (+).
    -

    - Read the information on http://review.coreboot.org/#/c/5927/. -

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

    + + + +

    Back to top of page

    + +
    + +
    +

    - For historical purposes, here is a collection of IRC logs that once existed on this page, related to the issue: - kernel312_irc. + Copyright © 2014, 2015 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.

    - PGETBL_CTL differs between VBIOS (-) and native graphics init (+).
    - - - PGETBL_CTL: 0x3ffc0001
    - + PGETBL_CTL: 0x3f800001 + 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.

    - -

    GTT (graphics translation table) size is PGETBL_save, max 256 KiB. BSM (Base of Stolen Memory) is given by the bios.

    - - - -

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

    + +
    -- cgit v0.9.1