| Age | Commit message (Collapse) | Author |
|---|
|
Having this header file in the mainboard directory breaks
the dinar build on cygwin because the header file in the
dinar mainboard is used instead of the correct header file
src/vendorcode/amd/cimx/sb700/OEM.h. The build probably works
fine on Linux systems because, due to case-sensitivity, Oem.h
will not match the #include "OEM.h" statement in
src/southbridge/amd/cimx/sb700/Platform.h.
The Oem.h file in the dinar mainboard is not used by any other
source files, and the defines in the dinar mainboard are duplicated
by defines in the correct OEM.h file. Therefore, the file can be
safely removed.
Change-Id: I81b97eca8116d63644d335edc3bb51f90c7094d9
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2776
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
This commit pulls in all the common logic for romstage into
the Haswell cpu directory. The bits specific to the mainboard
still reside under their respective directories. The calling
sequence bounces from the cpu directory to mainboard then back
to the cpu directory. The reasoning is that Haswell systems use
cache-as-ram for backing memory in romstage. The stack is used to
allocate structures. However, now changes can be made to the
romstage for Haswell and apply to all boards.
Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2754
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It was found that the Haswell reference code was smashing through the
stack into the reference code's heap implementation. The reason for this
is because our current CAR allocation is too small. Moreover there are
quite a few things to coordinate between 2 code bases to get correct.
This commit separates the CAR into 2 parts:
1. MRC CAR usage.
2. Coreboot CAR usage.
Pointers from one region can be passed between the 2 modules, but one
should not be able to affect the others as checking has been put into
place in both modules.
The CAR size has effectively been doubled from 0x20000 (128 KiB) to
0x40000 (256KiB). Not all of that increase was needed, but enforcing
a power of 2 size only utilizes 1 MTRR.
Old CAR layout with a single contiguous stack with the region starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| MRC global variables |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+
| ROM stage stack |
| |
| |
+---------------------------------------+
| MRC Heap 30000 bytes |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
There was some hard coded offsets in the reference code wrapper to start
the heap past the console buffer. Even with this commit the console
can smash into the following region depending on what size
CONFIG_CONSOLE_CAR_BUFFER_SIZE is.
As noted above This change splits the CAR region into 2 parts starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+
| MRC Region |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| ROM stage stack |
| |
| |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE,
which represents the expected stack usage for the romstage. A marker
is checked at the base of the stack to determine if either the stack
was smashed or the console encroached on the stack.
Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2752
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is causing a hang in depthcharge. For now just disable
this port.
Change-Id: I87a6db2d8361588e82eee640c74cea690115bed5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2764
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Rather than have to repeat this bit in every mainboard.
Also, remove the reset of the RTC power status from here.
We had done this in TOT for current platforms but did not
carry it back to emeraldlake2 where this branched from.
If we clear the status here then we don't get an event
logged later which can be important for the devices that
do not have a CMOS battery.
Change-Id: Ia7131e9d9e7cf86228a285df652a96bcabf05260
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2683
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We're happy to announce coreboot support for the "Stout"
Chromebook, a.k.a Lenovo X131e Chromebook.
Change-Id: I9b995f8d0dd48e41c788b7c3d35b4fac5840e425
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2636
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is mostly a copy of Whitetip Mountain 1 with specific GPIO
map for this Customer Reference Board (CRB).
This mainboard currently has basic funcionality and is able to
boot a Linux Kernel but many of the new Haswell ULT specific
devices are not yet enabled.
Change-Id: I999452d86f00a2c245fa39b1b76080f6a3b1e352
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2725
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There was a mix of setup code sprinkled across the various components:
southbridge code in the northbridge, etc. This commit reorganizes the
code so that northbridge code doesn't initialize southbridge components.
Additionally, the calling dram initialization no longer calls out to ME
code. The main() function in the mainboard calls the necessary ME
functions before and after dram initialization.
The biggest change is the addition of an early_pch_init() function
which initializes the BARs, GPIOs, and RCBA configuration. It is also
responsible for reporting back to the caller if the board is being
woken up from S3. The one sequence difference is that the RCBA config
is performed before claling the reference code.
Lastly the rcba configuration was changed to be table driven so that
different board/configurations can use the same code. It should be
possible to have board/configuration specific gpio and rcba
configuration while reusing the romstage code.
Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Lots of things are still placeholder and need work.
Due to the useful GPIOs being run to either the EC or the SIO1007
I have hard coded developer mode on and recovery mode off.
Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2736
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2737
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2738
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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@se-eng.com>
Reviewed-on: http://review.coreboot.org/2740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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: I9017a7619b3b17e0e95ad0fe46d0652499289b00
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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
Change-Id: If8d86f959822d528c44ab011a851659d486289b5
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2726
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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.
Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2684
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It's no longer required.
Change-Id: I621226a3bdfba9bc8edfd6e511a5337ae603ae19
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2723
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
The current code is attempting to convert from an invalid
starting temperature. Since we aren't sure where the temperature
will come from yet just return a static value.
This stops the kernel from going to S5 on boot because it
thinks the temperature is too high.
Change-Id: I433fa407e545458344af5842b353df5bc71bfdad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2679
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This option is not required for haswell. Enabling the option doesn't
do anything aside from complicate mtrr calculation. Therefore, remove
it.
Change-Id: I897523ff7d3606eb89961674c2eb3d384e584857
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2678
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This commit adds support for the deveveloper, recovery,
and write protect querying. It just uses jumpers on the
Basking Ridge board.
Noted ability to togggle jumpers results in toggling the
respective modes.
Change-Id: Iac189a1fa0245654591e2e9075380db422a329a0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2676
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
While looking at the Basking Ridge schematic I noticed some changes
and wanted to make sure they were reflected in the GPIO map.
Change-Id: I686653c164314ae9f68c42331d2f950751411d4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2675
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The baskingridge has a non-zero alt_gp_smi_en value in the
devicetree.cb file. It has just to be determined which GPI
pins should trigger an SMI on basking ridge. Without this change
the board would hang during boot (presumably through a SMI flood).
No more hangs once the value is zero.
Change-Id: I9704071bb7966bd3d0bbbc4aafede3f42d829b17
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2673
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The Grays Reef CRB is deprecated by order of Intel. Basking Ridge
is the new hotness. Therefore, rename graysreef to basking ridge.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I203497e165d8efc99d3438c4c548140a6e9cc649
Reviewed-on: http://review.coreboot.org/2672
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Some of the Lynx Point ids were off. Correct those and make
the pei data BAR fields consistent with the others.
Change-Id: I4102439588362cdb94643bd1ce69c9fa4278329e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2622
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The CS5536 companion device has three different power domains.
* working domain
* standby domain
* RTC domain
When the system is "off" only the standby domain is powered.
MFGPT[7:6] are member of the standby power domain.
MFGPT7 is used to control the backlight of the device and so the
timer gets used and configured during system boot. If the system
does a reboot the timer stays configured and the Linux driver
can not use it:
"ot200-backlight: ot200-backlight.0: MFGPT 7 not availale"
The cs5535-mfgpt has a function to hard-reset all MFGPTs but the
system hangs after the first access to a MFGPT register - cause
unknown.
/*
* This is a sledgehammer that resets all MFGPT timers. This is required by
* some broken BIOSes which leave the system in an unstable state
* (TinyBIOS 0.98, for example; fixed in 0.99). It's uncertain as to
* whether or not this secret MSR can be used to release individual timers.
* Jordan tells me that he and Mitch once played w/ it, but it's unclear
* what the results of that were (and they experienced some instability).
*/
static void reset_all_timers(void)
{
uint32_t val, dummy;
/* The following undocumented bit resets the MFGPT timers */
val = 0xFF; dummy = 0;
wrmsr(MSR_MFGPT_SETUP, val, dummy);
}
After playing around with this undocumented MSR it looks like I only
need to set bit 7 to free the MFGPT7.
BTW, all MFGPT[0:5] will be reset during pll_reset().
Change-Id: I54a8d479ce495b0fc2f54db766a8d793bbb5d704
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2527
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Even though this is under the graysreef board it really
applies to the Basking Ridge board. A subsequent patch will
rename graysreef to baskingridge.
The GPIO pins were updated to reflect the Basking Ridge schematics
as well as the DIMM spd addresses and USB over current pins.
Change-Id: Ice4e05f5203de3024cd463dfccf0bcfec1e247c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2632
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a FIXME about checking a MCHBAR register that isn't setup yet.
Also, remove revision updating because I can't find anything in the
docs that suggest this is required for haswell.
Change-Id: Ia8a6e08f82e18789e31c6c2ec2c1d63740c18dc4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2631
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The intel-framework code has an updated pei_data structure.
Use the new structure and revision. Also, remove the scrambler
seed saving in CMOS since that appears to be handled in the saved
data from the reference code.
Change-Id: Ie09a0a00646ab040e8ceff922048981d055d5cd2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2630
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Grays Reef is one of Intel's CRBs for the Haswell processor. The
platform is named Shark Bay.
GPIOs were the main focus so IRQ routing and ACPI still needs to be
further looked at.
Change-Id: Ie94b7af66f772714992a92612c76ca93b9b27088
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2621
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change the OSC method to actually grant control of
PCIe capabilities to the OS instead of granting no
control. I believe the logic was backwards in the
original commit. Bits should be set when granting
control and cleared when not granting control. By
setting the return value to 0x00, we effectively
tell the OS that it cannot control any PCIe
capability. See section 6.2.9 of the ACPI spec
version 3.0 for more information.
This edit is a duplication of the OSC method that
is in the src/southbridge/intel/bd82x6x/pch.asl
file.
Change-Id: Id2462ab12203afceb9033f24d06b4dfbf2236d2e
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2714
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This enables branch prediction. We can probably find a better place
to do this, but for now we'll do it in snow's romstage main().
Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2701
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Since commit »Drop redundant CHIP_NAME in mainboard.c« (a93c3fe7) [1]
`CHIP_NAME` is unneeded for mainboards as the name is composed
automatically in `src/devices/root_device.c` from the strings in
Kconfig.
Unfortunately the ports for Google Butterfly, Link and Parrot as
as well as IEI PM-LX2-800-R10 introduced CHIP_NAME again. So drop
it again too.
[1] http://review.coreboot.org/1635
Change-Id: Ice7577a2a5c6070e196f2647c440b7a8e140e27e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2708
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Call the power_init() function. We appear to have forgotten about it
when deprecating lowlevel_init_subsystems(), but it didn't seem to
cause problems until we got to doing more interesting stuff recently.
There are some clean-ups to do from the original code, such as not
attempting to configure I2C from PMIC code, which we'll get around
to in follow-up patches.
(Credit to Gabe for spotting this)
Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2699
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Despite everywhere the model name M5A88-V is used, in Kconfig the
string M5A88PM-V is used. Searching for that model string on the
WWW does not return anything which is unrelated to coreboot, so
change that string to M5A88-V.
Change-Id: I25cf9d4a5fc3f9b9356e8616452066ebf873f44c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2613
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: QingPei Wang <wangqingpei@gmail.com>
|
|
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 change will apply to other AMD mainboards and
will be in a different commit.
Change-Id: I44f22bc03a0dcbcd2594d4291508826cc2146860
Signed-off-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/2592
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Changes:
- Get rid of the inagua mainboard specific code and use the
platform generic function wrapper that was added in change
http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: Id05227fcf18c6ab94ffe1beb50b533ab7b0535db
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2607
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Currently for Advansus A785E-I, ASRock E350M1 and ASUS M5A88-V
despite what is chosen in Kconfig »Chipset« menu item,
$ more .config
[…]
# CONFIG_ENABLE_IDE_COMBINED_MODE is not set
CONFIG_IDE_COMBINED_MODE=0x1
# CONFIG_SB800_SATA_IDE is not set
CONFIG_SB800_SATA_AHCI=y
# CONFIG_SB800_SATA_RAID is not set
CONFIG_SB800_SATA_MODE=0x2
[…]
the SATA controller is put into IDE mode.
$ lspci -nn | grep SATA
00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] [1002:4390] (rev 40)
Commit »sb800: Add sata ahci/raid mode kconfig option«
(d4a0e7d0) [1] added the options above to configure the mode
using Kconfig and some SB800 boards were adapted already. For
example commit »persimmon: sb800 sata mode configure update«
(1386fa74) [2] did so for AMD Persimmon.
Doing the same by assigning the Kconfig variable to the value in
`platform_cfg.h` integrates this with the three remaining boards
listed above.
The patch is successfully tested with the ASRock E350M1.
$ lspci -nn | grep SATA
00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40)
[1] http://review.coreboot.org/225
[2] http://review.coreboot.org/227
Change-Id: I227257e2c8f04f18c27ff00fe62d42e372de67e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2610
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
Replace »persimmon« by »board« in comment to keep `diff` output
between boards small.
Change-Id: Ieae2a63782c488ae35f22eb30f5b1049200d12c8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2611
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
Changes:
- Get rid of the union_station mainboard specific code and
use the platform generic function wrapper that was added
in change http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: I19d6b0d674b67294519383f80928471b37da1e14
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2609
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Changes:
- Get rid of the south_station mainboard specific code and
use the platform generic function wrapper that was added
in change http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: If4291d25ea81bf375f55b64c07c223a847a211d0
Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-on: http://review.coreboot.org/2608
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This is previously used exception code from libpayload.
On startup it installs and then tests an exception handler.
The test is an unaligned memory operation.
Yes, we've seen what might be exceptions in the ramstage, and
it makes sense to handle them. This code is identical in structure
and operation to the previously committed payload exception handler,
though we reserve the right to change it as circumstances require.
The remaining question is whether we need it in romstage.
Change-Id: I24484686c33c9757af8ba171ebae9773828fb69d
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2614
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
According to BKDG:
"Memory controller (MCT) and DRAM controllers (DCTs) additions:
• Support for 933 MHz (1866 MT/s) MEMCLK frequency."
Change-Id: I6f307ce3fcb355d5445f1ea86def73a41b928a57
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2589
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The Hudson-E1's default SPI speed for normal i.e. non-fast reads is 66 MHz,
but the SST 25VF032B datasheet allows max. 25. Lower the speed to 22 MHz,
otherwise BIOS flashing fails.
Change-Id: I22e87d833a3ebd316b6e873595a2480831533ab1
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2605
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Changes:
- Get rid of the persimmon mainboard specific code which has been
moved into the wrapper as a platform generic function in change
http://review.coreboot.org/#/c/2497/
AMD f14: Add SPD read functions to wrapper code
- Move DIMM addresses into devicetree.cb
- Add the ASF init that used to be in the SPD read code into
mainboard_enable()
Notes:
- The DIMM reads only happen in romstage, so the function is not
available in ramstage. Point the read-SPD callback to a generic
function in ramstage.
Change-Id: I5f017dbb8dee5a09ec19734a6069ff9b71a6ab50
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2500
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This adds some real GPIO mappings where virtual GPIOs were used before.
Change-Id: I25d4be45f986c8d622b97151f8bdae2651baf3e6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2603
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
cosmetics
Change-Id: Iea33768d901641861aa7b2c76af8753a848f584d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2601
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
