coreboot March 2013

coreboot@coreboot.org

46 participants
782 discussions

Patch merged into coreboot/master: e6c3b1d haswell: include TSEG region in cacheable memory
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit e6c3b1d30d3fa88af6da6fcc115aa6cba3c55d1c Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Dec 21 21:22:07 2012 -0600 haswell: include TSEG region in cacheable memory The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG region is setup as cacheable through the MTTRs, accesses to the TSEG region before SMM relocation are cached. This allows for the setup of SMM relocation to be faster by caching accesses to the future TSEG (SMRAM) memory. MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BGSM: 0xad800000 MC MAP: BDSM: 0xada00000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 TSEG->BGSM: PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4 BGSM->TOLUD: PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 512MB, type WB Setting variable MTRR 2, base: 2560MB, range: 256MB, type WB Adding hole at 2776MB-2816MB Setting variable MTRR 3, base: 2776MB, range: 8MB, type UC Setting variable MTRR 4, base: 2784MB, range: 32MB, type UC Zero-sized MTRR range @0KB Allocate an msr - basek = 00400000, sizek = 0023d800, Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB Setting variable MTRR 6, base: 6144MB, range: 256MB, type WB Adding hole at 6390MB-6400MB Setting variable MTRR 7, base: 6390MB, range: 2MB, type UC MTRR translation from MB to addresses: MTRR 0: 0x00000000 -> 0x80000000 WB MTRR 1: 0x80000000 -> 0xa0000000 WB MTRR 2: 0xa0000000 -> 0xb0000000 WB MTRR 3: 0xad800000 -> 0xae000000 UC MTRR 4: 0xae000000 -> 0xb0000000 UC I'm not a fan of the marking physical address space with MTRRs as being UC which is PCI space, but it is technically correct. Lastly, drop a comment describing AP startup flow through coreboot. Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2690 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 00:26:45 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 20:05:15 2013, giving +2 See http://review.coreboot.org/2690 for details. -gerrit

1 0

Patch merged into coreboot/master: 86a1110 i945: Replace some two magic values by defined names
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 86a1110837ca61b63a9c012600302ed722997e3f Author: Patrick Georgi <patrick.georgi(a)secunet.com> Date: Fri Mar 15 14:11:37 2013 +0100 i945: Replace some two magic values by defined names Devoutly to be wish'd. To die,—to sleep;— To sleep! perchance to dream:—ay, there's the rub; For in that sleep of death what dreams may come, (Since who could argue with William Shakespeare?) Change-Id: I4e4c617dcd3ede81a0abbe16f9916562d24fa8ce Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> Reviewed-on: http://review.coreboot.org/2733 Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net> Tested-by: build bot (Jenkins) Build-Tested: build bot (Jenkins) at Sat Mar 16 10:51:13 2013, giving +1 See http://review.coreboot.org/2733 for details. -gerrit

1 0

Patch merged into coreboot/master: 594ea4a ASROCK Fam14 DSDT: Add secondary bus range to PCI0
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 594ea4ac5fef354dda573b3b3670fe946ce65cd9 Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 11:11:12 2013 -0600 ASROCK Fam14 DSDT: Add secondary bus range to PCI0 Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: I5184df8deb7b5d2e15404d689c16c00493eb01aa Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2736 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 19:14:58 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Fri Mar 15 19:39:49 2013, giving +2 See http://review.coreboot.org/2736 for details. -gerrit

1 0

Patch merged into coreboot/master: 8c72670 AMD Fam14 DSDT: Remove INI method from AZHD device
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 8c72670ba5c4283b2a1a2513f47f40b949094648 Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 13:31:20 2013 -0600 AMD Fam14 DSDT: Remove INI method from AZHD device I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same chagne as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Id560ea85a38f73aaba2c35447bbce46bd9c0d0dd Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2741 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 22:01:22 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 19:55:42 2013, giving +2 See http://review.coreboot.org/2741 for details. -gerrit

1 0

Patch merged into coreboot/master: 60d84ca ASROCK Fam14 DSDT: Remove INI method from AZHD device
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 60d84ca22b57ae5705c0659aa07a59a3407c094e Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 13:36:25 2013 -0600 ASROCK Fam14 DSDT: Remove INI method from AZHD device I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iae70c3d0af1cdaca31b206ad6daba4d38ee6b780 Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2742 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 22:31:15 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 19:55:28 2013, giving +2 See http://review.coreboot.org/2742 for details. -gerrit

1 0

Patch merged into coreboot/master: 109c08e Lippert Fam14 DSDT: Remove INI method from AZHD device
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 109c08e05ac482c72c541ae1a3e408a686c9fb03 Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 13:40:13 2013 -0600 Lippert Fam14 DSDT: Remove INI method from AZHD device I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iff594d4a3493531561eb25d1cceeb97bcefde424 Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2743 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 22:41:22 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 19:55:15 2013, giving +2 See http://review.coreboot.org/2743 for details. -gerrit

1 0

Patch merged into coreboot/master: 42ad200 Lippert Fam14 DSDT: Add secondary bus range to PCI0
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 42ad2006572ea784548a79aabfaa3b00295d1215 Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 13:05:59 2013 -0600 Lippert Fam14 DSDT: Add secondary bus range to PCI0 Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: Ie36b60973c6a5f9076bb55c8f451532711a2f8a8 Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2737 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 20:18:51 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 19:55:03 2013, giving +2 See http://review.coreboot.org/2737 for details. -gerrit

1 0

Patch merged into coreboot/master: 00a0e76 AMD Fam14 DSDT: Add OSC method
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 00a0e76bc5ffaba01c98f1c1384b0499516fdaef Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 13:17:52 2013 -0600 AMD Fam14 DSDT: Add OSC method The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: If6dd1a558d9c319d9a41ce63588550c8e81e595f Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2738 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 20:31:07 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 19:54:39 2013, giving +2 See http://review.coreboot.org/2738 for details. -gerrit

1 0

Patch merged into coreboot/master: 9c3d112 ASROCK Fam14 DSDT: Add OSC method
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 9c3d112bb686f1c044aeb501ef810e2fb8c9310e Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 13:22:32 2013 -0600 ASROCK Fam14 DSDT: Add OSC method The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: I2701d915338294bdade2ad334b22a51db980892e Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2739 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 20:41:36 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 19:54:23 2013, giving +2 See http://review.coreboot.org/2739 for details. -gerrit

1 0

Patch merged into coreboot/master: 061c664 Lippert Fam14 DSDT: Add OSC method
by gerrit＠coreboot.org 17 Mar '13

17 Mar '13

the following patch was just integrated into master: commit 061c66406ffebb298ba06ac7ecf7e14c5d55cc24 Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Fri Mar 15 13:24:53 2013 -0600 Lippert Fam14 DSDT: Add OSC method The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: Iaf7b8153cec4d730efbceae3e6957d2904b8fae4 Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2740 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> Build-Tested: build bot (Jenkins) at Fri Mar 15 21:04:38 2013, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Sun Mar 17 19:54:07 2013, giving +2 See http://review.coreboot.org/2740 for details. -gerrit

1 0

← Newer
1
...
21
22
23
24
25
26
27
...
79
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2013