This fixes a trivial error with the recovery mode GPIO index.
Change-Id: I7290c1e23cdddaf91c9021d4e4252c0c772b6eab
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2825
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A fix to eliminate warnings when building romstage files with ChromeOS
compilers
Change-Id: Ia5d7bbdde3aa3439fd493f5795f2cc2bf4c4c187
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2781
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
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>
Quoting Jens Rottmann [1]:
Nevertheless I still think this whole function is bogus for the E350M1. The
function assumes GPIO21 is wired to reset APU PCIe lane 0+1 (PCIe x8, port 4+5
as Coreboot/AGESA calls it), GPIO25 resets lane 2 (PCIe x4) and GPIO02 lane 3.
But the E350M1 has PCIe x16 i.e. probably APU lanes 0-3 bundled, completely
different layout. They could have chosen GPIO21 to force resets, or 25 - or
maybe 50 like on the Persimmon or any other they fancied or - and this is the
most probable - none at all. Having BiosGnbPcieSlotReset() toggle some GPIOs
without knowing what they do on the E350M1 (if anything at all) is nonsense.
In my opinion this whole function should just "return AGESA_UNSUPPORTED" and
good riddance.
[1] http://review.coreboot.org/#/c/2445/
Change-Id: Iac66da41182e838c7e6925250cc3982adbb3e4ec
Reported-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2489
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
These are essential functions for setting up the display port and
framebuffer, and also enable such things as aux channel
communications. We do some very simple initialization in romstage,
mainly set a GPIO so that the graphics is powering up, but the complex
parts are done in the ramstage. This mirrors the way in which graphics
is done in the x86 size.
I've added a first pass at a real device, and put it in the mainboard
Kconfig, hoping for corrections. Because startup is so complex,
depending on device type, I've created a 'displayport' device that
removes some of the complexity and makes the flow *much* clearer. You
can actually follow the flow by looking at the code, which is not true
on other implementations. Since display port is perhaps the main port
used on these chips, that's a reasonable compromise. All parameters of
importance are now in the device tree.
Change-Id: I56400ec9016ecb8716ec5a5dae41fdfbfff4817a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2570
Tested-by: build bot (Jenkins)
Since the merg of the ASRock E350M1 port (a649a96e) the compiler
warns about the following [1].
mainboard.c:35, GNU Compiler 4 (gcc), Priorität: Normal
no previous prototype for 'set_pcie_reset' [-Wmissing-prototypes]
mainboard.c:43, GNU Compiler 4 (gcc), Priorität: Normal
no previous prototype for 'set_pcie_dereset' [-Wmissing-prototypes]
Adding the function prototypes to the beginning of the file as
done in commit »Persimmon updates for AMD F14 rev C0« (d7a696d0)
addresses the warning.
[1] http://qa.coreboot.org/job/coreboot-gerrit/4975/warnings13Result/package.-139448264/file.-1544928473/
[2] http://review.coreboot.org/137
Change-Id: Iad2e62ec37c3a2f749a264974b61ac7c226e9b83
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2590
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Set up the clocks used for sound and turn on the sound clock.
Change-Id: Ic59bfa9ae87116299503e6d25aeefba98c842fb8
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2587
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The MMC0 on google/snow can run in 8 bit mode. To simplify driver development,
we thought disabling it (using zero, which runs in 1-bit / 4-bit mode) may help.
However, after some experiments in payload drivers, setting pinmux to 8 bit mode
can still allow MMC to run in 1-bit / 4-bit mode, so it's pretty safe to enable
8 bit mode by default for better performance.
Verified to boot on google/snow, and got MMC0 working.
Change-Id: Ic0acc723fe6a8aecf373429d3801beadd70815d9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2585
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The first reason for selecting the CPU model at compile time was a
multi-second pause if booting a single core Fusion T40R with MAX_CPUS=2.
Recent tests show the pause has disappeared, someone must have fixed it.
The second reason was me not knowing how to make a single vgabios image
work with two different PCI IDs. Many thanks to Martin Roth for educating
me! Quote:
"The way to make coreboot use the same vbios for different video device IDs
is through the map_oprom_vendev function. In family 14 it's in
northbridge/amd/agesa/family14/amdfam14_conf.c You would name your video
bios 1002,9802 in the config and all the other device/vendor IDs for the
family 14h processors will fall through the initial check for the video
bios and will get remapped to use that vbios. This only works if you're
initializing the vbios inside coreboot. I don't know if you're using
SeaBios as a payload, but if you are you can add the vbios to cbfs as
vgaroms/vbios.rom and the rom will always be initialized."
I'd like to add the vgabios is added as type 'optionrom' when Coreboot make
adds it, however to work with SeaBios it has to be added manually with
cbfstool and with type 'raw', or it will hang.
Change-Id: I8190d0c3202a60dfccb77dde232f9ba7ce5ce318
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2584
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit f154c018
Author: Marc Jones <marcj303@gmail.com>
Date: Wed Dec 14 11:24:00 2011 -0700
Persimmon audio codec verb patch.
Reviewed-on: http://review.coreboot.org/490
has a typo code*c* in the comments for `AZALIA_OEM_VERB_TABLE`. As
this was copied over to the LiPPERT Fam14 boards, use the following
command to fix the typo.
$ git grep -l cocec | xargs sed -i s,cocec,codec,
Change-Id: I1525b0445edab81ab136b3adece52b78ba7abc71
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2576
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
If you try to reset the system with outb(3,0x92), outb(4,0xcf9) or a
triple-fault it will instead crash with a messy screen. As the more common
outb(0xFE, 0x64) doesn't work with our setup, Linux will crash whenever you
ask it to reboot. Closer inspection shows that on a warm boot of Coreboot
agesawrapper_amdinitpost() always fails with error code 7. Looks like DDR3
re-init goes wrong somehow. I tried find the reason for this but was
unable to. I am convinced this is not board specific but a bug in AGESA.
In the end I had to settle for a workaround: if amdinitpost returns 7 this
patch resets the system harder with outb(0x06, 0x0cf9), after that RAM init
will succeed. As amdinitpost is early in POST this automatic reset is
quick enough not to be noticable.
I'd perfer a real fix, but that's all I have.
Change-Id: I4763254b489f42a135232e45328ecf0d5c4d961a
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2573
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Step 2: change the Persimmon code to adapt it to the new board's hardware.
The Toucan-AF is a COM Express Compact Type 6 form factor embedded board:
- AMD Fusion G-T56N (1.65 GHz dual core) or T40R (1 GHz single core) APU
- 1-4 GB DDR3 memory down
- 1x VGA, 2x DisplayPort (1 switchable to LVDS)
- AMD A55E (Hudson-E1) southbridge
- 8x USB 2.0
- 4x SATA
- HD Audio (with codec on baseboard)
- NEC uPD78F0532 microcontroller on I2C ("SEMA")
- 7x PCIe2.0 x1 (1 on PEG)
- Intel I210 GbE (on APU PCIe x1, can be disabled for additional PCIe)
- 2x SST 25VF032B (SO8, soldered) 4 MB SPI flash (BIOS and failsafe BIOS)
The Toucan-AF has no SIO on board. This patch includes basic support for a
Winbond W83627DHG (PS/2, 2x RS232), because the ADLINK ExpressBase-6 used
for evaluation happens to have one. The code may have to be adapted to the
actual baseboard of the application.
http://www.adlinktech.com/PD/web/PD_detail.php?pid=1132
Change-Id: I9041b905bad45852ac9b402fcbd5decbc98b377b
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2572
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Step 1: copy all files unmodified from Persimmon. This makes it much
easier later to see how the two boards actually and deliberately differ
when porting bugfixes from one to the other. Git's copy detection is
imperfect (and slow).
Change-Id: I1ff02913479c07679f8c3ae5e6dd7876e6000b55
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2571
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Step 1: copy all files unmodified from Persimmon. This makes it much
easier later to see how the two boards actually and deliberately differ
when porting bugfixes from one to the other. Git's copy detection is
imperfect (and slow).
Change-Id: I2fd1bf8428fc8a1e7becee888b6182b9bd8166a0
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2552
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The SD/MMC interface on Exynos 5250 must be first configured with, GPIO, and
pinmux settings before it can be detected and used in ramstage / payload.
Verified on armv7/snow and successfully boot into ramstage.
Change-Id: I26669eaaa212ab51ca72e8b7712970639a24e5c5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2561
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This allows to drop some special cases in romstage.c
Change-Id: I53fdfcd1bb6ec21a5280afa07a40e3f0cba11c5d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2551
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It's not used, and not needed.
Change-Id: Ifca92f3606ac58fc26e09676488c3add5d84ae79
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2548
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It's been on for all boards per default since several years now
and the old code path probably doesn't even work anymore. Let's
just have one consistent way of doing things.
Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2547
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add two more GPIOs (total 6) as needed by the Google Snow laptop.
These are faking out settings for now. This code is tested and working.
Change-Id: I2077ffb8b85958eefdf54e19763d57cc1178ce89
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2538
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Commit 8487229b (Persimmon doesn't have HDMI so the GNB HD Audio should be
disabled.) turned off the device in AGESA. Now remove it from
devicetree.cb, too. This prevents the following boot message:
PCI: Left over static devices:
PCI: 00:01.1
PCI: Check your devicetree.cb.
Also clarify the line's comment a bit for the Fam14 boards which still
retain this device (to counter the loss of information ;-).
Change-Id: Ib671ed2e0d04bdef2869e8d70208d6e55cdea3fd
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2537
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
The PCH register bit definition for sleep type is a little confusing.
For example, 7 is S5. To make this simpler for the mainbaord developer,
the mainboard smi sleep hander is called as mainboard_sleep(slp_typ-2).
A couple mainboard SMI handlers were using the PCH define for slp_ty,
so S3 code would be run for S5 and S5 code would never be run.
Change-Id: Iaecf96bfd48cf00153600cd119760364fbdfc29e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/2514
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Mainly replace spaces by tabs and format comments correctly.
Commit »Inagua: Indent and wihtespace cleanup« (f03360f3) [1] was
unfortunately incomplete and also used spaces instead of tabs in
some cases.
Hopefully fix this once and for all to have a template for the
other boards.
[1] http://review.coreboot.org/547
Change-Id: If15c797581dfefe2a57cd6f26e5bdac4cdd014dd
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2526
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch reduces unnecessary differences between AMD Inagua, Persimmon,
Union Station, South Station and Asrock E350M1. It's only cosmetical, but
makes them a little bit easier to compare.
This is the remainder of the original http://review.coreboot.org/2464,
parts of which somehow got lost in a flurry of refactoring and splitting
patches.
Change-Id: I034228be9edaaa4122506763d7bb4158f8e0ec53
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2529
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Changes:
- Fix printk warnings for these two platforms by getting rid of the
l length specifier and casting to unsigned int.
This gets rid of a bunch of warnings like this one:
agesawrapper.c:279, GNU Compiler 4 (gcc), Priority: Normal
format '%lu' expects argument of type 'long unsigned int',
but argument 3 has type 'UINT32' [-Wformat]
Notes:
- This is the same change that was done for Tyan s8226 in change:
ddff32eb - http://review.coreboot.org/#/c/2451/
Tyan S8226: Fix printk warnings
- I have not tested this change on either of these platforms, I have
just compiled it.
Change-Id: I46b4c13fde7473cd2a084c7c7cb5c893f1731b02
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Changes:
- Add #include of delay.h in mainboard.c to pick up declaration of
mdelay function.
Notes:
- This fixes this warning:
mainboard.c:69, GNU Compiler 4 (gcc), Priority: Normal
implicit declaration of function 'mdelay' [-Wimplicit-function-declaration]
Change-Id: I72f333cd87215a7fc1e62d1d7ee4b2395444b03e
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2501
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently on for example on AMD Persimmon and ASRock E350M1 Linux
complains, that the PBLK length is invalid [1].
ACPI: Invalid PBLK length [0]
Consequently, frequency scaling might not work correctly, though for
these two boards it seems to work according to PowerTOP.
Indeed, according to the ACPI specification [2], setting PBlockLength
to 0 is only allowed if there is no PBlockAddress. Otherwise it has to
be set to 6.
18.5.93 Processor (Declare Processor)
[…]
PBlockAddress provides the system I/O address for the processors
register block. Each processor can supply a different such
address. PBlockLength is the length of the processor register
block, in bytes and is either 0 (for no P_BLK) or 6. With one
exception, all processors are required to have the same
PBlockLength. The exception is that the boot processor can have
a non-zero PBlockLength when all other processors have a zero
PBlockLength. It is valid for every processor to have a
PBlockLength of 0.
And that is exactly what Linux is checking in
`drivers/acpi/processor_driver.c` [3].
static int acpi_processor_get_info(struct acpi_device *device)
{
[…]
/*
* On some boxes several processors use the same processor bus id.
* But they are located in different scope. For example:
* \_SB.SCK0.CPU0
* \_SB.SCK1.CPU0
* Rename the processor device bus id. And the new bus id will be
* generated as the following format:
* CPU+CPU ID.
*/
sprintf(acpi_device_bid(device), "CPU%X", pr->id);
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id,
pr->acpi_id));
if (!object.processor.pblk_address)
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n"));
else if (object.processor.pblk_length != 6)
printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n",
object.processor.pblk_length);
else {
pr->throttling.address = object.processor.pblk_address;
pr->throttling.duty_offset = acpi_gbl_FADT.duty_offset;
pr->throttling.duty_width = acpi_gbl_FADT.duty_width;
pr->pblk = object.processor.pblk_address;
/*
* We don't care about error returns - we just try to mark
* these reserved so that nobody else is confused into thinking
* that this region might be unused..
*
* (In particular, allocating the IO range for Cardbus)
*/
request_region(pr->throttling.address, 6, "ACPI CPU throttle");
}
[…]
}
This issue has proliferated to all AMD based boards so fix it for
all of them by setting P_BLK length to 6.
The DSDT of for example AMD Parmer and AMD Thatcher also set it
to 6 everywhere so this solution is taken instead of setting the
P_BLK system I/O base to 0 for all but the first processor which
is how it is done for earlier AMD based boards.
As note having to set this manually should not be needed and
this should be autogenerated as done for most of the Intel boards
and the AMD K8 based boards (`src/cpu/amd/model_fxx/powernow_acpi.c`).
[1] http://www.coreboot.org/pipermail/coreboot/2013-January/073636.html
[2] http://acpi.info/DOWNLOADS/ACPIspec40a.pdf
[3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/acpi/processor_driver.c;h=e83311bf1ebdaaaea1adbf2de1351cca907d3465;hb=5da1f88b8b727dc3a66c52d4513e871be6d43d19#l351
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
• ASRock E350M1:
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
• AMD Persimmon:
Tested-by: Martin Roth <martin.roth@se-eng.com>
Change-Id: Ie79fe4812532d124cc81747c75a4f3d88d00531c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2189
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
USB ports 0-4 are handled by PCI devices 12.0 (OHCI) and 12.2 (EHCI). 12.1
simply does not exist, so remove it from devicetree.cb. While at it make the
comment more detailed. Likewise for all USB ports.
USB device 14.6 is the Broadcom GbE MAC integrated in the Hudson-E1. Add it
to devicetree.cb. It's used on Inagua (on), but not on Persimmon (off).
Change-Id: Idea27b3390fa4470f2592e79fdd633d5a218b97b
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2463
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
The DSDT header contains the fields OEMID and OEM Table ID. See
for example ACPI specification 4.0a [1]
5.2.11.1 Differentiated System Description Table (DSDT)
on page 135. There Table 5-16 contains the descriptions.
Field Byte Length Byte Offset Description
===================================================
OEMID 6 10 OEM ID
OEM Table ID 8 16 The manufacture model ID.
Currently in coreboot there is no common method what to put in
these fields.
Mostly Intel based boards populate it with "CORE " ore "COREv4"
and AMD based boards populate it with the board vendor and
model number, abbreviated appropriately to fit into these fields.
On most boards the proprietary vendor BIOS seems to leave these
fields – displayed with `sudo dmidecode` under System Information –
blank
To Be Filled By O.E.M.
and fill out the Base Board Information with the board vendor and
model name.
In [2] Jens Rottmann argues that the this is really just the table
ID used for naming it and that »99% of the DSDT code is not board
specific«.
Both approaches seem to have their advantages, but using the
second one, developers often seem to forget to update them (for
example AMD Thather).
The current situation is at least not optimal. and therefore at
least unify the string in the OEM Table ID. If unifying the
OEM ID is also a good idea this should be done too.
If later on it should be decided that the board vendor and model
should be used again, this should be somehow derived from
Kconfig.
The following command was used for the change [3].
$ git grep -l '\/\* TABLE ID \*\/' | xargs sed -i '/TABLE ID/s/"\([^"]*\)"/"COREBOOT"/'
This patch is split out from [2].
[1] http://www.acpi.info/spec40a.htm
[2] http://review.coreboot.org/#/c/2464/
[3] http://stackoverflow.com/questions/5207838/sed-regex-matching-text-between-to-double-quotes-when-a-certain-text-appears-i
Change-Id: Iec98c615ce37f928abc1b500eff5aa865d772cb2
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2472
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These were not separable or it would have been two CLs.
Enable CHROMEOS configure option on snow. Write gpio support code for
the mainboard. Right now the GPIO just returns hard-wired values for
"virtual" GPIOs.
Add a chromeos.c file for snow, needed to build.
This is tested and creates gpio table entries that our hardware can use.
Lots still missing but we can now start to fill in the blanks, since
we have enabled CHROMEOS for this board. We are getting further into
the process of actually booting a real kernel.
Change-Id: I5fdc68b0b76f9b2172271e991e11bef16f5adb27
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2467
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Similar to the discussion on the coreboot list [1]
Am Freitag, den 22.02.2013, 02:17 +0100 schrieb Peter Stuge:
[…]
> Function names should try to be descriptive. "enable_dev" is not very
> descriptive. I like "mainboard_enable" because it makes output such
> as
>
> printk("%s: foo", __func__);
>
> useful.
rename the function for the northbridge to `northbridge_enable`.
[1] http://www.coreboot.org/pipermail/coreboot/2013-February/074549.html
Change-Id: I262311ec511e394550330214621b8c37780c1d4e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2496
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Fix redefinition warning for SB_GPIO_REG50 introduced in commit
fa8702cf - http://review.coreboot.org/#/c/2446/
Persimmon: adapt PCIe reset code copied from Inagua to actually
match Persimmon
The warning being fixed is:
SB800.h:1491, GNU Compiler 4 (gcc), Priority: Normal
"SB_GPIO_REG50" redefined [enabled by default]
- Enable warnings as errors so no more warnings will be accidentally
committed.
Change-Id: Ib443b2bd2067f0b7d5f93f79170899a0f8f61060
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2494
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To reduce the differences between these file name the enabling
device function in the directory `src/mainboard` uniformly
`mainboard_enable` [1].
Thanks to the awesome help of gnomon and BlastHardcheese in the
IRC channel #sed on <irc.freenode.net>. gnomon came up with the
following command to do the actual work.
$ cd src/mainboard
$ for f in */*/mainboard.c ; \
> do src="$(awk '/\.enable_dev = /{v=$NF; sub(/,$/,"",v); print v}' "$f")" ; \
> [[ -z $src ]] && continue ; \
> printf '%s\n' "g/${src}/s/${src}\([,(]\)/mainboard_enable\1/p" w | ed -s "$f" ; \
> done
`src/mainboard/digitallogic/msm586seg/mainboard.c` and
`src/mainboard/technologic/ts5300/mainboard.c` had to be adapted
manually as no comma was used separating the struct members.
And with the following statement, gnomon is even more likable!
My pleasure entirely. Good luck with coreboot; I'm a big fan of the project.
[1] http://www.coreboot.org/pipermail/coreboot/2013-February/074548.html
Change-Id: Ife9cd0c2d9cc1ed14afc6d40063450553f06a6c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2493
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is coreboot’s coding style.
Change-Id: I7441f2c1927a49a3b7171112b7798dae6b56cfb5
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2492
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Bernhard Urban <lewurm@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is the common way to name that function, so unify that.
Change-Id: I8a01051bd304039662894b89eed53ce14dde98b6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2491
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Ladies and gentlemen, I'm very happy to announce coreboot support for
the latest and greatest Google Chromebook: The Chromebook Pixel.
See the link below for more information on the Chromebook Pixel, and
its exciting specs:
http://www.google.com/intl/en/chrome/devices/chromebooks.html#pixel
The device is running coreboot and open source firmware on the EC
(see ChromeEC commit for more information on that exciting topic)
Change-Id: I03d00cf391bbb1a32f330793fe9058493e088571
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2482
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reduce unnecessary differences between AMD based boards only
using the file `platform_cfg.h` for configuration making them
a little bit easier to compare.
Inagua & co. mention the board name in several places which are really not
that board specific. Sometimes people even forget to change it:
Union Station’s platform_cfg.h starts with "#ifndef _PERSIMMON_CFG_H_".
Funny. Change that to "_PLATFORM_CFG_H_" everywhere.
The following command was used.
$ find . -name platform_cfg.h | xargs sed -i '/_CFG_H_/s/_.*_/_PLATFORM_CFG_H_/'
More boards seem to use that kind of naming (`git grep _CFG_H_`)
but it is not certain that this will not break anything as for
example the board AMD Dinar also has header files for
configuration stuff for the north- and southbridge.
$ git grep _CFG_H_
[…]
src/mainboard/amd/dinar/platform_cfg.h:#ifndef _PLATFORM_CFG_H_
src/mainboard/amd/dinar/platform_cfg.h:#define _PLATFORM_CFG_H_
src/mainboard/amd/dinar/platform_cfg.h:#endif //_PLATFORM_CFG_H_
src/mainboard/amd/dinar/rd890_cfg.h:#ifndef _RD890_CFG_H_
src/mainboard/amd/dinar/rd890_cfg.h:#define _RD890_CFG_H_
src/mainboard/amd/dinar/rd890_cfg.h:#endif //_RD890_CFG_H_
src/mainboard/amd/dinar/sb700_cfg.h:#ifndef _SB700_CFG_H_
src/mainboard/amd/dinar/sb700_cfg.h:#define _SB700_CFG_H_
src/mainboard/amd/dinar/sb700_cfg.h:#endif //_SB700_CFG_H
[…]
Change-Id: Ida15fa6a7adfc770240ac30e795946000dae3f16
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2464
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
At the request of Paul Menzel, I reran an
old classic of a coccinelle script:
@@
expression E;
@@
-(E + 7) & -8
+ALIGN(E, 8)
@@
expression E;
@@
-(E + 15) & -16
+ALIGN(E, 16)
Change-Id: I01da31b241585e361380f75aacf3deddb13d11c3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2487
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There were just whitespace differences and three boards did not
contain
printk(BIOS_DEBUG, "alib\n");
dump_mem(ssdt, ((void *)alib) + alib->length);
which is enclosed `#if DUMP_ACPI_TABLES == 1` to dump the ACPI
tables.
Basically the whitespace in the license header in Inagua’s file
was fixed and then the file copied over to the other directories.
Change-Id: I23f73acad427b5ec14cf51651af67240871f7488
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2470
Tested-by: build bot (Jenkins)
Reviewed-by: Alvaro G. <andor@pierdelacabeza.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The following command was used to correct the typo.
$ git grep -l @breif | xargs sed -i 's/@breif/@brief/'
Change-Id: If0b579279de3c41571b9cda643836f5748a752a2
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2473
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
From ISO C99 standard: »The placement of a storage-class specifier
other than at the beginning of the declaration specifiers in a
declaration is an obsolescent feature.«
Found at <http://www.approxion.com/?p=41>.
Change-Id: Iee7878affb2a5d157a94763083689d75e8218b2f
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2474
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The relational operators in the if-predicate are aligned in all
`dimmSpd.c` files so revert part of the change in
commit 36abff1dc8
Author: Marc Jones <marcj303@gmail.com>
Date: Mon Nov 7 23:26:14 2011 -0700
Cleanup Persimmon mainboard whitespace.
Reviewed-on: http://review.coreboot.org/427
to remove the incorrectly introduced tabs and to unify that. It
might contradict the current coding style but it is even used in
the latest code as seen in the following file.
src/northbridge/amd/agesa/family15tn/dimmSpd.c
Change-Id: Ib611267f99090d0830bdc2319527389f193ea1eb
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2471
Reviewed-by: Alvaro G. <andor@pierdelacabeza.com>
Tested-by: build bot (Jenkins)
This was overlooked in the following commit.
commit 36abff1dc8
Author: Marc Jones <marcj303@gmail.com>
Date: Mon Nov 7 23:26:14 2011 -0700
Cleanup Persimmon mainboard whitespace.
Reviewed-on: http://review.coreboot.org/427
Change-Id: If6bf4836b46077614a04c1e106c241a4f97da166
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2468
Tested-by: build bot (Jenkins)
Reviewed-by: Alvaro G. <andor@pierdelacabeza.com>
For AMD Inagua, the following two commits
commit 01f7ab9335
Author: Kerry Sheh <shekairui@gmail.com>
Date: Thu Jan 19 13:18:36 2012 +0800
Inagua: Synchronize AMD/inagua mainboard.
Reviewed-on: http://review.coreboot.org/542
and
commit d91c9b7e3c
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 10:59:55 2011 -0600
AMD Inagua platform updates
Reviewed-on: http://review.coreboot.org/136
replaced the constant `iobase` is set to by the define `SMBUS0_BASE_ADDRESS` from `OEM.h`.
Do the same for AMD Persimmon, South Station, Union station and ASRock E350M1.
Change-Id: If095cd9d9b28b118b4072c7c9d345bf620b774c9
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2453
Tested-by: build bot (Jenkins)
If CONFIG_CONSOLE_SERIAL is set, and we can call the standard function
and get a non-zero uart address, then we create an lb table entry.
The code was mostly right, just needed a tweak.
Change-Id: I5b36c7b4e580a23319b7ba92cc8ad61592b1757a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2466
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
For whatever reason tabs got inserted in the license header text.
Remove one occurrence of that with the following command [1].
$ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,'
[1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt
Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2460
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
The following commit was too eager replacing spaces with tabs.
commit 36abff1dc8
Author: Marc Jones <marcj303@gmail.com>
Date: Mon Nov 7 23:26:14 2011 -0700
Cleanup Persimmon mainboard whitespace.
Reviewed-on: http://review.coreboot.org/427
Fix that with the following command.
$ git grep -l 'Floor, Boston, MA'$'\t''02110-1301 USA' | xargs sed -i 's/Boston, MA[ ]*02110-1301 USA/Boston, MA 02110-1301 USA/'
Change-Id: Ia118a8c19d94ce1f1048280a0f1d49d447cfa2a7
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2461
Tested-by: build bot (Jenkins)
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
Fix warning:
mptable.c:52, GNU Compiler 4 (gcc), Priority: Normal
passing argument 3 of 'mptable_write_buses' from incompatible pointer type [enabled by default]
mptable_write_buses is expecting a pointer to an int, so I changed the
U8 isa_bus to an int to match. A U8 doesn't make sense if the value could
be greater than 255 - certainly unlikely, but possible since the value
of isa_bus gets set to the maximum PCI bus number + 1.
Change-Id: I7ea416f48285922d6cf341382109993fd3f6405c
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2450
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Fix Warning:
sb700_cfg.c:129, GNU Compiler 4 (gcc), Priority: Normal
large integer implicitly truncated to unsigned type [-Woverflow]
The issue here was that an 8 bit value was being placed into a 2-bit
bitfield.
$ more src/vendorcode/amd/cimx/sb700/SBTYPE.h
[…]
UINT32 AzaliaSdin0 :2; //6
UINT32 AzaliaSdin1 :2; //8
UINT32 AzaliaSdin2 :2; //10
UINT32 AzaliaSdin3 :2; //12
$ more src/mainboard/tyan/s8226/sb700_cfg.h
[…]
* SDIN0 is define at BIT0 & BIT1
* 00 - GPIO PIN
* 01 - Reserved
* 10 - As a Azalia SDIN pin
* SDIN1 is define at BIT2 & BIT3
* SDIN2 is define at BIT4 & BIT5
* SDIN3 is define at BIT6 & BIT7
*/
#ifndef AZALIA_SDIN_PIN
#define AZALIA_SDIN_PIN 0x2A
#endif
[…]
$ more src/mainboard/tyan/s8226/sb700_cfg.c
[…]
sb_config->AzaliaSdin0 = AZALIA_SDIN_PIN;
[…]
The 8 bit value 0x2A (binary 00 10 10 10), was being used incorrectly
– I believe the original intent of this value was to enable the SDIN
pins 0, 1, & 2. Because it was getting truncated as it was put into
AzaliaSdin0, this wasn't happening and only SDIN0 was being enabled.
I am leaving only SDIN0 enabled at this point to as not change the
actual behavior on the platform.
Change-Id: Icaeb956926309dbfb5af25a36ccb842877e17a34
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2452
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix 84 warnings all like this one:
agesawrapper.c:289, GNU Compiler 4 (gcc), Priority: Normal
format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'UINT32' [-Wformat]
Fixed by getting rid of the l length specifier and casting to unsigned int.
Change-Id: Ic143c1034f760fa5efb2220aa33861e399ddd708
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2451
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Looking at AssertSlotReset, the comments and all other case's it's
obvious this is a simple copy & paste error where someone just forgot
to change one occurrance of the GPIO nr. Also the AMD Inagua
schematics show that GPIO02 is what they really meant.
Also forward the fix to boards copied from Inagua (AMD South
Station, Union Station, Asrock E350M1).
Change-Id: I6b9a3d473245fa27604b2f148a730290277a88ed
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2445
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
This patch will cause the resource allocator to actually set aside
the memory resources using methods in the previous patch. The coreboot
table output will include "RAM" entries (there were none before):
coreboot memory table:
0. 0000000040400000-00000000bff001ff: RAM
1. 00000000bff00200-00000000bff00fff: CONFIGURATION TABLES
2. 00000000bff01000-00000000bfffffff: RAM
Change-Id: I5cd76e93fc232fdae1754253efb4e9269b3a20c0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2420
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Inagua can use GPIOs 178,179 to switch VMEM to 1.5, 1.35 or 1.25 V,
which it does according to data read from the SO-DIMM's SPD EEPROM.
On Persimmon (according to DB-FT1 rev. D schematics) both GPIOs are
unconnected, there is no way to change the 1.5 V DDR3 voltage (save
unsoldering a resistor). The whole code copied over from Inagua is
useless.
Removed the code, instead a comment hints at Inagua, for people who do designs
based on Persimmon but do have a way to change VMEM.
The line ...->DDR3Voltage = VOLT1_5; is supposed to make the AGESA DDR3 code
select the RAM timings for the actually supplied voltage instead of the
hoped-for but unavailable lower voltage. I have no idea how to test this, but
in any case it can't hurt.
Change-Id: Id098e09418b665645814a6ee2d41a3bff72238ba
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2448
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
According to DB-FT1 rev. D schematics the APU PCIe lane 3 is unconnected.
Reflect this fact in the mainboard code.
Change-Id: Ic98f4a63ef971628df7fbf97f56b80ebe7cb8517
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2447
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Comparing Persimmon and Inagua schematics and Coreboot code show the PCIe reset
code has been blindly copied even though it doesn't suit the Persimmon at all.
The Inagua can employ GPIOs 21, 25, 02 to manually reset devices on APU PCIe
lanes 0/1, 2, 3 respectively. (Appearently the motivation for this is to revive
buggy PCIe gen1 devices which got confused by PCIe gen2 signal training.)
However the Persimmon not only doesn't support this, it even needs these 3 pins
for the PCI interface! Instead it uses GPIO50 to reset devices on lanes 0-2 all
at once. Lane 3 is unconnected anyway.
This patch adapts the Persimmon mainboard code according to the DB-FT1 rev. D
schematics.
Change-Id: I05a657d9bf8cc59acc4f5174eb20375165c860c7
Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-on: http://review.coreboot.org/2446
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
»Chromebook« is the official spelling [1]. So correct that with
the following command.
$ git grep -l ChromeBook | xargs sed -i s,ChromeBook,Chromebook,
The incorrect spelling was only used for the chip name.
[1] http://www.google.com/intl/en/chrome/devices/hp-pavilion-chromebook.html#hp-pav
Change-Id: I9c19f399a3e3d36bd644ec375822daa384a14961
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2370
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was omitted earlier while we were debugging DRAM code (0a5bc7f).
It was likely broken due to inconsistent units earlier on. Now that
things are cleaned up and working, let's add it back in.
Change-Id: I2f356355c98b2896e2371fa63b9c9f20ae76d634
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2379
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These were left over from earlier debugging and are no longer
needed. They don't indicate any status or useful info (other
than which line of code has been executed). Error messages are
available in case something needs attention.
Change-Id: Ie09fac29c42908cb8924169e56d8927fb76f02da
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2386
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The commit introducing support for the Google Butterfly Chromebook
commit d7bd4eb003
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon Feb 11 11:11:36 2013 -0800
Add support for "Butterfly" Chromebook
Reviewed-on: http://review.coreboot.org/2359
contains the typo, which is corrected now.
Change-Id: I932f4cd248cac71c3ede39a7da97162e791827cb
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2373
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
Correct some whitespace inconsistencies introduced in the
following commit.
commit d7bd4eb003
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon Feb 11 11:11:36 2013 -0800
Add support for "Butterfly" Chromebook
Reviewed-on: http://review.coreboot.org/2359
Change-Id: Ifeda7eb29ddf855cdfea41ddbd685441ede55756
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2374
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The commits adding support for the Google Parrot Chromebook
commit a7198b34cc
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Tue Dec 11 16:00:47 2012 -0800
Add support for Google Parrot Chromebook
Reviewed-on: http://review.coreboot.org/2026
and the Google Butterfly Chromebook
commit d7bd4eb003
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Mon Feb 11 11:11:36 2013 -0800
Add support for "Butterfly" Chromebook
Reviewed-on: http://review.coreboot.org/2359
had macros in `fadt.c` which were not aligned correctly and did
not adhere to the coding style which uses just one space after
`#define`. Fix this and use tabs instead of spaces everywhere.
Change-Id: I1422c57a3bdc2faa29d2a6e2064e4d3aeed0f1cb
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2375
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
To simplify testing ARM implementation, we need a QEMU configuration for
ARM. The qemu-armv7 provides serial output, CBFS simulation, and full
boot path (bootblock, romstage, ramstage) to verify the boot loader
functionality.
To run with QEMU:
export QEMU_AUDIO_DRV=none
qemu-system-arm -M vexpress-a9 -m 1024M -nographic -kernel build/coreboot.rom
Verified to boot until ramstage loaded successfully by QEMU v1.0.50.
Change-Id: I1f23ffaf408199811a0756236821c7e0f2a85004
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2354
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We're happy to announce coreboot support for the "Butterfly"
Chromebook, a.k.a HP Pavilion Chromebook.
More information at:
http://www.google.com/intl/en/chrome/devices/hp-pavilion-chromebook.html
This commit also includes support for the ENE KB3940Q embedded controller
running on Quanta's firmware.
Change-Id: I194f847a94005218ec04eeba091c3257ac459510
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2359
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
It was off by a few orders of magnitude. D'oh.
Change-Id: I9c8a3d5bd9ce261f914cfc7d05d86a1c61519b81
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2355
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The hardware is there, so turn it on.
Change-Id: I40aff1e84a22a05599c62b9f0b20397df0a40b15
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2353
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
MMCONF space is defined by two config parameters:
MMCONF_BASE_ADDRESS (0xF800 0000)
MMCONF_BUS_NUMBER (64)
Coreboot allocates 1MB per bus, so MMCONF limit should be:
0xF800 0000 + 64*(0x0010 0000) - 1 = 0xFBFF FFFF
Current code does not have (-1) component, this makes MMCONF limit
equal 0xFC00 FFFF. Not 0xFC00 0000, because according to BKDG
lower two bytes of MMIO limit always equal 0xFFFF:
MMIOLimit = {MMIOLimitRegister[47:16], FFFFh}.
Add (-1) to correct this issue.
No functionality change has been experienced. The five times
slower RAM speed compared to the proprietary vendor BIOS still
remains.
Change-Id: I2c6494c28bb8d36e54ceb2aa7d8d965b0103cbe9
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2193
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
RAMBASE and RAMTOP are leftovers from the x86 port and do not apply
the same way on ARM platforms. On x86 they refer to the low memory
region where coreboot tables reside.
However on ARM we don't have such a region which is architecturally
defined. So instead we'll use the CPU-defined DRAM base address and
the mainboard-defined DRAM size.
This also has the pleasant side-effect of fixing the coreboot tables
to not clobber ramstage code...
Change-Id: I5548ecf05e82f9d9ecec8548fabdd99cc1e39c3b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This moves GPIO setup from chip-specific SPI code to mainboard-
specific bootblock code. This makes exynos_spi_open a bit more
generic so it can eventually be used for any SPI channel. This
also benefits CBFS since the user can set media->context to
to any set of SPI registers.
Change-Id: I2bcb9de370df0a79353c14b4d021b471ddebfacd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2347
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This moves the setting of SPI clock rate into romstage's main,
which allows us to eliminate a bunch of dependencies from the
bootblock (about 7KB worth).
Change-Id: I371499bb4af6a6aa838294bc56f9dbc21864957a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Except for one board, the flags can be derived from CONFIG_MMX
and CONFIG_SSE.
Change-Id: I64a11135ee7ce8676f3422b2377069a3fa78e24d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2336
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This cleans up Snow's trivial ramstage, gives it a coreboot table
address and calls hardwaremain().
Change-Id: I84c904bcfd57a5f9eb3969de8a496f01e43bc2f6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2328
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Exynos system clock can be initialized before RAM init, not necessary to be in
the very beginning (boot block). This helps reducing bootblock dependency.
Verified to boot on armv7/snow.
Note: this patch was originally introduced in 2308, but there were
some ordering issues so it was reverted.
Change-Id: Ibc91c0e26ea8881751fc088754f5c6161d011b68
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2320
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use same console initialization procedure for all ARM stages (bootblock,
romstage, and ramstage):
#include <console/console.h>
...
console_init()
...
printk(level, format, ...)
Verified to boot on armv7/snow with console messages in all stages.
Change-Id: Idd689219035e67450ea133838a2ca02f8d74557e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The console drivers (especially serial drivers) in Kconfig were named in
different styles. This change will rename configuration names to a better naming
style.
- EARLY_CONSOLE:
Enable output in pre-ram stage. (Renamed from EARLY_SERIAL_CONSOLE
because it also supports non-serial)
- CONSOLE_SERIAL:
Enable serial output console, from one of the serial drivers. (Renamed
from SERIAL_CONSOLE because other non-serial drivers are named as
CONSOLE_XXX like CONSOLE_CBMEM)
- CONSOLE_SERIAL_UART:
Device-specific UART driver. (Renamed from
CONSOLE_SERIAL_NONSTANDARD_MEM because it may be not memory-mapped)
- HAVE_UART_SPECIAL:
A dependency for CONSOLE_SERIAL_UART.
Verified to boot on x86/qemu and armv7/snow, and still seeing console
messages in romstage for both platforms.
Change-Id: I4bea3c8fea05bbb7d78df6bc22f82414ac66f973
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2299
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This reverts commit 9029f4b63f
This patch needs to go at the end of the UART patch set. Sorry 'bout the confusion!
Change-Id: I5702c7d6130daf95776f2c15d24e5d253691cefd
Reviewed-on: http://review.coreboot.org/2319
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Exynos system clock can be initialized before RAM init, not necessary to be in
the very beginning (boot block). This helps reducing bootblock dependency.
Verified to boot on armv7/snow.
Change-Id: Ic863e222871a157ba4279a673775b1e18c6eac0d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2308
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The power_init is not required on Exynos 5250 (snow) in bootblock stage. To get
a cleaner and faster bootblock, we can remove it.
Note, power_init internally calls max77686 and s3c24x0_i2c, so both files are
also removed.
Verified to boot on armv7/snow.
Change-Id: I5b15dfe5ac7bf4650565fea0afefc94a228ece29
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2317
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The I2C initialization (on component MAX77688) is already done in power_init, so
we should not need an explicit call inside bootblock.
Verified to boot on armv7/snow.
Change-Id: I68c248a8b5fee4ab838b2fb708649e112559cc41
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2316
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
"SPL" from U-Boot is deprecated by bootblock in coreboot/arm, so we don't need
it anymore.
Change-Id: Id16877075d0b870839a10160073ad70777a2af0a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2297
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This attempts to clean out some dead code which was copy + pasted
into Snow's bootblock.c file, along with some unnecessary headers.
Change-Id: If9f157a52395a047c249a2a6385e0e8ddf310e59
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2291
Tested-by: build bot (Jenkins)
This patch moves ARM core and DRAM timing functions around to simplify
the dependencies for system_clock_init().
The original code was architected such that the system_clock_init()
function called other functions to obtain core and memory timings.
Due to the way memory timing information must be obtained on Snow,
which entails decoding platform-specific board straps, the bottom-
up approach resulted in having the low-level clock init code
implicitly depend on board and vendor-specific info:
main()
->system_clock_init()
-> get_arm_ratios()
-> CPU-specific code
-> clock_get_mem_timings()
-> board_get_revision()
-> read GPIOs (3-state logic)
-> Decode GPIOs in a vendor-specific manner
-> Choose memory timings from module-specific look-up table
...then proceed to init clocks
...come back to main()
The new approach gathers all board and vendor-specific info in a
more appropriate location and passes it into system_clock_init():
main()
-> get_arm_ratios()
-> CPU-specific code
-> get_mem_timings()
-> board_get_config()
-> read GPIOs (3-state logic)
-> Decode GPIOs in a vendor-specific manner
-> Choose memory timings from module-specific look-up table
-> system_clock_init()
...back to main()
Change-Id: Ie237ebff76fc2d8a4d2f4577a226ac3909e4d4e8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2271
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This gets rid of a bunch of duplicate I2C code in the bootblock.
Change-Id: I51f625a0f738cca4ed2453fbcb78092e4110bc7e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2289
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This gets rid of a bunch of copy + pasted GPIO code.
Change-Id: I548b2b5d63642a9da185eb7b34f80cbebf9b124f
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2288
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This gets rid of a bunch of copy + pasted code from Exynos UART
files.
Change-Id: I9fbb6d79a40a338c9fdecd495544ff207909fd37
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2286
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The following command was used to correct the grammatical mistake.
$ git grep -l 'This is the stub function will call' | xargs sed -i s,This is the stub function will call,This stub function will call, '{}'
sed: -e Ausdruck #1, Zeichen 6: Nicht beendeter `s'-Befehl
As this file seems to have been copied around a lot, it originally
seems to have come with the following commit for AMD Persimmon and
AMD Inagua.
commit 69da1b676c
Author: Frank Vibrans <frank.vibrans@amd.com>
Date: Mon Feb 14 19:04:45 2011 +0000
Add IBASE DB-FT1 and AMD Inagua motherboards. Patch 8 of 8.
Change-Id: I2e6630a5172738b01e6def7062284f167e5508b1
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2268
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
AOpen DXPL Plus-U and Intel XE7501devkit use »COREBOOT« as
OEM Table ID.
Unify the DSDT by aligning the comments in the DSDT header with
tabs in accordance with the coding style [1].
[1] http://www.coreboot.org/Development_Guidelines#Coding_Style
Change-Id: I78e6aa8d0318b519b1df5e2178d387dc58e48323
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2278
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Mainboards using `COREBOOT` as their OEM Table ID in their DSDT
header were copied from the same source and therefore had spaces
instead of a tab to align that comment for that header field. These
are mostly Intel based boards.
Fix that in accordance with the coding style [1].
[1] http://www.coreboot.org/Development_Guidelines#Coding_Style
Change-Id: I299b955930dbd50b9717e8ff141ce8f3fd534e5f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2277
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Snow's AP, EC, PMU, and smarty battery share a bus. Both the AP and
EC can act as a master, so to avoid conflicts an arbitration
mechanism consisting of two GPIOs is used.
By default, the AP "owns" the bus unless it is off (in which case
the EC doesn't monitor the arbitration pins). This means the boot
firmware does not need to worry about these lines. The payload may
if it needs to communicate with the EC, though.
In any case, board-specific bus arbitration logic does not belong
in a low-level driver that is supposed to be generic for an entire
CPU family. If the payload needs to talk to the EC, we'll deal with
it there.
Change-Id: I0774d4592af2b21b6ad668441532c5ceab988404
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2272
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This removes some duplicate code from Snow's mainboard bootblock
by utilizing the bootblock build class.
Change-Id: I153247370a8c5127260082dcdca3ebdc5e104fb8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For ARM platform, the bootblock may need more C source files to initialize
UART / SPI for loading romstage. To preventing making complex and implicit
dependency by using #include inside bootblock.c, we should add a new build class
"bootblock".
Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled
for boot block.
For x86, the bootblock is limited to fewer assembly files so it's not using this
class. (Some files shared by x86 and arm in top level or lib are also changed
but nothing should be changed in x86 build process.)
Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The LVDS is on DP0, not DP1.
Change-Id: I724764d0f013e7a10d974a8716e075139982ded2
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2259
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
This is a first cut at a romstage. It sets up memory, although that
needs some work; and finds and loads a ramstage.
Change-Id: I02a0eb48828500bf83c3c57d4bacb396e58bf9a5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2245
Tested-by: build bot (Jenkins)
Continuing with the mainboard cleanup for F15tn, move the functions
to read the SPD from the mainboards for Thatcher and Parmer into the
wrapper for the northbridge/amd/agesa/family15tn.
Move the SPD address customization for the mainboard into the
devicetree.cb file.
Unrelated side note - Porting.h has an un-closed #pragma pack(1)
that can cause confusing side-effects. AGESA's structures all
use this, but coreboot's don't. Be sure to include the coreboot
.h files BEFORE Porting.h is included, not after.
This fix has been tested.
Change-Id: I89cdd225be61f60c6b8e7020e6f8b879983bbd96
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2190
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
This replaces the current stage-specific exit/entry functions with
generic versions. Now all stages compile with stage_entry(), which
is placed at .text.stage_entry.armv7, and stage_exit().
Snow's ramstage files are also updated to avoid build breakage.
Change-Id: I953a2c4b8121bd4b66c3362557997a9ca3aa53b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The SPI flash driver for Exynos chipset.
Verified to boot on snow/armv7.
Change-Id: I7eef67a9c57f825d09f13ea44c2b59b54345fa7b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2229
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
[…]
CC romstage.inc
src/mainboard/asrock/e350m1/romstage.c: In function 'cache_as_ram_main':
src/mainboard/asrock/e350m1/romstage.c:48:5: warning: unused variable 'reg8' [-Wunused-variable]
This change was already done for AMD Persimmon in the following
commit.
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
Change-Id: I8f1ae1a609b87b197583934f0556f66b64e6994d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2230
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
The previous incarnation did not use all of mmu_setup, which meant
we did not carefully disable things before (possibly) changing them.
This code is tested and works, and it's a bit of a simplification.
Change-Id: I0560f9b8e25f31cd90e34304d6ec987fc5c87699
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2204
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
This change is required in order to use a LVDS panel
attached to the LVDS connector.
Change-Id: Id97c233f964151b6515bd46c797425d0e6690cbd
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2188
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
commit 585a400697
Author: zbao <fishbaozi@gmail.com>
Date: Thu Apr 12 11:27:26 2012 +0800
Leverage the Pstate table created by AGESA.
… introduced unneeded whitespace in front of a comma.
Revert that part of the above commit. In the file for AMD Dinar
tabs and spaces are mixed, but leave that alone for the beginning.
Change-Id: I279cd0cb0be8c79258034733773f2ae1c2207cce
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2187
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Enable 'all warnings being treated as errors' in thatcher and parmer.
Fixed the following warnings on parmer / thatcher:
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:
In function 'GetGlobalCpuFeatureListAddress':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:291:14:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:
In function 'SaveDeviceContext':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:245:18:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:309:16:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuPostInit.c:
In function 'GetPstateGatherDataAddressAtPost':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuPostInit.c:235:10:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/TN/mntn.c:
In function 'MemNInitNBDataTN':
src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/TN/mntn.c:353:32:
warning: assignment from incompatible pointer type [enabled by default]
src/vendorcode/amd/agesa/f15tn/Proc/Mem/NB/TN/mntn.c:363:23:
warning: assignment from incompatible pointer type [enabled by default]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:
In function 'GetGlobalCpuFeatureListAddress':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Feature/cpuFeatureLeveling.c:291:14:
warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:
In function 'SaveDeviceContext':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:245:18:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
src/vendorcode/amd/agesa/f15tn/Proc/CPU/S3.c:309:16:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
In file included from src/northbridge/amd/agesa/family15tn/northbridge.c:37:0:
src/vendorcode/amd/agesa/f15tn/AGESA.h:1547:0:
warning: "TOP_MEM" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:31:0:
note: this is the location of the previous definition
src/vendorcode/amd/agesa/f15tn/AGESA.h:1548:0:
warning: "TOP_MEM2" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:34:0:
note: this is the location of the previous definition
In file included from src/northbridge/amd/agesa/family15tn/northbridge.c:41:0:
src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuRegisters.h:378:0:
warning: "LOCAL_APIC_ADDR" redefined [enabled by default]
src/include/cpu/x86/lapic_def.h:9:0: note:
this is the location of the previous definition
In file included from src/mainboard/amd/parmer/BiosCallOuts.h:24:0,
from src/mainboard/amd/parmer/mainboard.c:28:
src/vendorcode/amd/agesa/f15tn/AGESA.h:1547:0:
warning: "TOP_MEM" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:31:0:
note: this is the location of the previous definition
src/vendorcode/amd/agesa/f15tn/AGESA.h:1548:0:
warning: "TOP_MEM2" redefined [enabled by default]
src/include/cpu/amd/mtrr.h:34:0: note:
this is the location of the previous definition
Change-Id: Iecea28232f1761401cf09f7d2a77d3fbac2f5801
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2171
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Go through southbridge/amd/agesa/hudson, thatcher and parmer
mainboard directories and change all references to sb800 to
reference hudson instead.
This is just cleanup and should make no functional difference.
Change-Id: Icd6a9a08c4bbf5e1aed394362d24c05811ed1fba
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2177
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
There are currently too many things in the mainboard directories that
are really more suited to being in the northbridge / southbridge
wrappers. This is a start at moving some of those functions down
into the wrappers.
Move the bios callback functions into the northbridge/amd/agesa/family15tn
directory from the mainboard directories. These can still be overridden
by any mainboard just by updating the pointer in the callback table to
point to a customized version of the function.
Change-Id: Icefaa014f4a4abbe51870aee7aa2fa1164e324c1
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2169
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Add Kconfig option for Legacy free and hook it into the parmer
AGESA initialization as well as the FADT code. This should really
be done inside the southbridge wrapper and not in the mainboard,
but for now the code to attach it to is inside the mainboard.
Update Kconfig for parmer and thatcher to default to legacy free.
Change-Id: Ib899bd02ddc5506caae4aca2c589cc2526638cb8
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2157
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Re-formatting and cleaning up the devicetree.cb files for
parmer and thatcher.
Change-Id: Ic458e59701c1f2593b0a035b96cac60df476ee82
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2164
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
The way that devicetree.cb was configured for the family 15tn boards
was doing... interesting things to the video device initialization.
This was causing S3 resume to fail.
There is a disconnect between how the devicetree should be configured
if there are multiple HT links on the CPU and how it's configured if
there's only one HT link. These platforms were set up as if they
had multiple HT links, which was causing duplicate instances of
devices in the device list.
The scan for the IO Hub was removed from the northbridge code which
isn't a problem for F15tn devices.
Change-Id: I3556b43027746e36b07de7cb1bece4d1b37a3c34
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2160
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
This patch does a few things to get us into romstage:
- Add romstage as a stage (a later patch adds it as a binary, which
is probably wrong). The Makefile magic is complex enough that we
let it build the XIP file for now, but we no longer use it.
- Replace findstage with loadstage. Loadstage will find a stage,
load the code to memory, and zero the remaining part of memory.
Now we can link the romstage to go anywhere!
- Eliminate magic offsets from code/ldscripts and centralize Kconfig
variables in src/cpu/samsung/exynos5250/Kconfig.
- Tidy up code and serial output
Change-Id: Iae4d2f9e7f429cb1df15d49daf9a08b88d75d79d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2174
Tested-by: build bot (Jenkins)
This adds a wrapper around main() in romstage which is compiled using
-marm. This assumes that the bootblock branches to romstage in ARM
mode.
The long-term idea is to enforce ABI compatibility when handing off to
the next stage by using shims which are which are compiled in a pre-
determiend manner and leave the main portions of each stage up to
whatever the compiler wants. So it will eventually look like this:
1. bootblock_main (ARM/Thumb)
2. bootblock_exit (ARM)
3. romstage_entry (ARM)
4. romstage_main (ARM/Thumb)
(credit to Gabe Black for writing the patch, I'm just uploading it)
Change-Id: I4fdb8d2c6c2c0a7178bcb9154c378ddce0567309
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/2175
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the bloated Snow bootblock which includes:
- SPI driver
- UART, including requisite I2C, Maxim PMIC, and clock config code.
- Adjustments for magic offsets (id section, stack pointer address)
This is just a temporary solution until we have romstage loading.
Once that happens, we'll rip out all but the code necessary for
copying SPI ROM content into SRAM.
Change-Id: I2a11e272eb9b6f626b5d9783eabb4a720a1d06be
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Our earlier attempt was jumping straight from asm to the old u-boot
board_init_f in lowlevel_init_c.c. We are getting ready to transition
to using a real bootblock for ARM, so add romstage.c to the files
compiled and we'll make main() our entry point.
This also updates romstage.ld to place main() (*(.text.startup)) at
the beginning of romstage.
Change-Id: Ifc77a6bfba27d915c4cad62c6c8040665294628a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2163
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We don't pass any arguments into romstage on ARM.
Change-Id: I018f28a57fc486c9240345cf0f4043b79027d864
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2162
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Bits were being shifted off the end of the mask accidentally.
This results in all masks being 32 bits wide instead of 48.
Change-Id: I5f4d1b6a323df1aa4568ff4491f82447b8a2f839
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/2146
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The high bits of mtrr mask are MBZ (Must be zero). Writing 1 to these
bits will cause exception. So be carefull when spread this change.
The supermicro/h8scm needs more work. Currently it is set as it was.
We need to check if the F10 and F15 have different value.
Change-Id: I2dd8bf07ecee2fe4d1721cec6b21623556e68947
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1661
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
This replaces 0x02023400 with an SoC-specific Kconfig variable.
Change-Id: I21482d54a1e1fa6c4437c030ddae2b0bb3331551
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2130
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ACPI code:
The ACPI code is not currently being compiled in by default, but
assuming that it will be at some point, I'm fixing the loop that
waits for the IMC to respond after sending it a command. The
loop now exits after 500ms, similar to the function in agesa.
Agesa Code:
a 16 bit variable will always be less than 100000. Change to
be a 32 bit variable.
Change-Id: I9430ef900a22d056871b744f3b1511abdfea516e
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2119
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch switches the Qemu target to use (pseudo) Cache As RAM
and enables some ACPI code. This allows to use the CBMEM console
and timestamp code with coreboot in Qemu. Right now, the ACPI code
is commented out because leaving it in breaks IDE.
Change-Id: Ie20f3ecc194004f354ae3437b9cf9175382cadf8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2113
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are two CPUs on s8226 and each CPU has 8 cores.
CPU 0 takes lapic from 0x10 to 0x17 and CPU 1 takes from 0x20 to 0x27.
So the first core's lapic is 0x10 rather than 0x20.
Change-Id: I925114d44f2f4974eb62c3832d8c9139a2a06c96
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/2099
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This mirrors the naming convention of handlers in
northbridge and southbridge.
Change-Id: I45d97c569991c955f0ae54ce909d8c267e9a5173
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2058
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This imports SPL (second phase loader) files from U-Boot. Most of the
content of these files will eventually go away since they're fairly
U-Boot specific. For now they are here to make Jenkins happy.
Change-Id: Ib3a365ecb9dc304b20f7c1c06665aad2c0c53e69
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2081
Tested-by: build bot (Jenkins)
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
I have issues when AmdReadEventLog function tries to use BiosCallouts interface.
So it is necessary to provide callout pointer to this function.
Change-Id: I4080e5f07d5d28c41688b2a7deff944b7a0f7bf7
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2064
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
This commit enables the external graphics card.
In order to work, the internal graphic card has to be
disabled, that is done in src/device/device.c through:
vga_onboard->ops->disable(vga_onboard);
which calls the RS780 disable operation introduced in the following
commit: "rs780: add .disable pcie_ops"
This commit was tested with and without the following card:
02:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce 210] (rev a2)
Thanks Aladyshev for the pointer(in the #coreboot IRC channel on Freenode servers):
Dec 20 19:43:32 <Aladyshev> If you list your internal card in devicetree.cb,
coreboot will distinguish external and internal VGA and choose external one
Change-Id: I92e59dffd158db096a6e99d1ef6e2e248fef933c
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/2067
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Fix some minor discrepancies which prevented the MAX77676 from
getting compiled in properly.
Change-Id: Ib29136da6c15a4bdb24926a91729431c507cd209
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2076
Tested-by: build bot (Jenkins)
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Supermicro H8QGI has integrated Matrox G200 16MB DDR2 graphics.
List it in devicetree.cb to mark it as onboard VGA to coreboot.
This change makes menuconfig option "Use onboard VGA as primary video device" work.
Change-Id: Ia6b9f60e3ae705689f22babd544ad6e628a85df1
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2042
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Fix little mistake in get_bus_conf code
Change-Id: I8c09e501082caa0a20266b007c0744630a356de0
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2046
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Size of BiosCallouts[] struct can be calculated as:
CallOutCount = sizeof (BiosCallouts) / sizeof (BiosCallouts [0]);
There is no longer need for REQUIRED_CALLOUTS define.
Originally that change was done for AMD Persimmon in
commit d7a696d0f2
Author: efdesign98 <efdesign98@gmail.com>
Date: Thu Sep 15 15:24:26 2011 -0600
Persimmon updates for AMD F14 rev C0
without deleting the define. This was ported to some of the other
boards and for some the define was not removed.
The AMD Inagua, Parmer and Thatcher boards were already adapted but
the define was left in. So just remove it for those.
Tested on Supermicro H8QGI.
Change-Id: Ia09795579a1170fa20ab94a30feb1af6821153d2
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2049
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
H8QGI board has 2 IO-APICS with 56 IRQ’s:
IOAPIC[0]: GSI 0-23 - SB700 southbridge
IOAPIC[1]: GSI 24-55 - RD890 northbridge
`gDefaultApicDeviceInfoTable[]` structure in northbridge code
vendorcode/amd/cimx/rd890/nbIoApic.c
has IO-APIC interrupt mapping for HT and IOMMU set to last 31
IRQ pin (24+31=55).
CONST APIC_DEVICE_INFO gDefaultApicDeviceInfoTable[] = {
// Group Swizzling Port Int Pin
{0, 0, 31}, //HT
{0, 0, 31}, //IOMMU
[…]
Also the same value (55) can be found in original Supermicro BIOS ACPI DSDT.
Change-Id: Ie26da1f773716d1b7f5f5f884050ae799afc0b7e
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2047
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add configuration for AMD's IMC ROM and fan registers for cimx/sb800
platforms.
- Allows user to add the IMC rom to the build and to configure the
location of the "signature" between the allowed positions.
- Allows for no fan control, manual setup of SB800 Fan registers, or
setup of the IMC fan configuration registers.
- Register configuration is done through devicetree.cb. No files need
to be added for new platform configuration.
- Initial setup is for Persimmon, but may be extended to any cimx/sb800
platform.
Change-Id: Ib06408d794988cbb29eed6adbeeadea8b2629bae
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1977
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Marc Jones <marcj303@gmail.com>
This is the minimal set of sources that allow the board to build.
These need to be filled in with actual code. But if we get these in upstream
we can stop working against a WIP patch.
Change-Id: I9347a573bb40761f6a12be3ee8febe3ca4be55a3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2018
Tested-by: build bot (Jenkins)
Supermicro h8scm has a C32 CPU socket, the details of this board is:
http://www.supermicro.com/Aplus/motherboard/Opteron4100/SR56x0/H8SCM-F.cfm
We are planning to replace legacy C32 code with agesa and the h8scm_fam10 do not support
family 15 CPU, so we update this mainboard with this patch.
This code supports memory at 800M Hz of f10 CPU, bu f15 CPU does not has this limitation.
If you want to change the frequency of memory, please edit the macros
"BLDCFG_MEMORY_BUS_FREQUENCY_LIMIT" and "BLDCFG_MEMORY_CLOCK_SELECT"
in src/mainboard/supermicro/h8scm/buildOpts.c
Change-Id: I9ca9e70d7f3e82c07e7d36695bf31008db152afb
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1510
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Change-Id: I4b735fe4e6441f99236e43b34695fdac95b8888a
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1875
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Not sure why this never triggered an error before.
Change-Id: I85d8b3b862492df04163a5f751c7ea4288406860
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1946
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
As we move to supporting other systems we need to get rid of assembly
where we can. The log2 function in src/lib is identical to the assembly
one (tested for all 32-bit signed integers :-) and takes about 10 ns
to run as opposed to 5ns for the non-portable assembly version. While speed
is good, I think we can spare the 15 ns or so we add to boot time
by using the C version only.
Change-Id: Icafa565eae282c85fa5fc01b3bd1f110cd9aaa91
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1928
Tested-by: build bot (Jenkins)
This gets rid of the somewhat unstructured placement of AMD's
sysinfo structure in CAR.
We used to carve out some CAR space using a Kconfig variable,
and then put sysinfo there manually (by "virtue" of pointer magic).
Now it's a variable with the CAR_GLOBAL qualifier, and build
system magic.
For this, the following steps were done (but must happen together
since the intermediates won't build):
- Add new CAR_GLOBAL sysinfo_car
- point all sysinfo pointers to sysinfo_car instead of GLOBAL_VAR
- remove DCACHE_RAM_GLOBAL_VAR_SIZE
- from CAR setup (no need to reserve the space)
- commented out code (that was commented out for years)
- only copy sizeof(sysinfo) into RAM after ram init, where
before it copied the whole GLOBAL_VAR area.
- from Kconfig
Change-Id: I3cbcccd883ca6751326c8e32afde2eb0c91229ed
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
This broke because those components were not yet
committed when the patch to drop the driver class
was made.
Change-Id: I29948223503a6c4b196eafa169c064cd26da1be1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1934
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Optionally override FSB clock detection in generic
LAPIC code with constant value.
- Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz
- compile LAPIC code for romstage, too
- Remove #include ".../apic_timer.c" in AMD based mainboards
- Remove custom udelay implementation from intel northbridges' romstages
Future work:
- remove the compile time special case
(requires some cpuid based switching)
- drop northbridge udelay implementations (i945, i5000) if
not required anymore (eg. can SMM use the LAPIC timer?)
Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1618
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When dropping ramstage.a, unused functions with unresolved
symbols are not silently dropped anymore. This makes the
tim5690 compilation fail.
This fix makes sure we don't compile in the int15 handler code
when we don't set CONFIG_VGA_ROM_RUN
Change-Id: If6872c983d9fd811eb33259421f94b551f3b9b34
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1929
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
When dropping ramstage.a duplicate symbols in ramstage
will start breaking the build. Hence drop all the duplicate
functions implemented by mainboards that have those functions
in generic or component code already.
Change-Id: I5cf8245c67b6f0f348388db54256d28f47017a61
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1865
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The calculation of COMB's irq reading was wrong by the 4-bit shift.
Also, the asl compiler warned about the splitting in lo/hi bytes which
seems unnecessary.
Change-Id: Ia5101d5a19f68c2da827d7e37a18922f959604c7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1923
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Forgot to update the rk9 for the unified VGABIOS handling.
This applies to rk9 what is done for other boards in commits
3c84261e84d5d340695b
Change-Id: I892b7d81927e277778c1c5251d27416fa79c9868
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1924
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Roda RK9 is a notebook based on the GM45/ICH9 platform using DDR3 memory.
http://roda-computer.com/products/notebooks/rk9/
Tested with various Linux versions, known to work:
- 2x4GB RAM
- IGD
- HD Audio
- UHCI, EHCI
- AHCI
- NIC
- PCI
- PS/2 keyboard
- serial console
- ACPI lid switch
- ACPI battery/AC events
- power off, reboot
Change-Id: I7299dccbff2eea3544363fdd4f49f05aa3dae7bc
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1691
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Some boards have two instances of the int15 handler that supports
the onboard VGA BIOS, for YABEL and realmode.
These are now similar enough that they can be deduplicated.
Due to minor differences this requires manual effort.
Change-Id: I03ae314cb90dd65d96591ce448504aa961cbeb88
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1893
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Makes it more similar to what realmode looks like.
Change-Id: I4407431f2d979c43dd186114d67ed11845907afe
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1892
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
By using the (global) register file as defined by x86emu,
we can use the same register access for YABEL and realmode
interrupt handlers.
- the x86 realmode interrupt handlers changed in signature
- to access registers, use X86_$REGNAME now (eg. X86_EAX)
- x86_exception_handler still uses struct eregs *regs to
avoid spilling the x86emu register file stuff everywhere
Coccinelle script that handled most of this commit:
@ inthandler @
identifier FUNC, regs;
@@
int FUNC(
-struct eregs *regs
+void
)
{ ... }
@ depends on inthandler @
identifier regs;
@@
-regs->eax
+X86_EAX
@ depends on inthandler @
identifier regs;
@@
-regs->ebx
+X86_EBX
@ depends on inthandler @
identifier regs;
@@
-regs->ecx
+X86_ECX
@ depends on inthandler @
identifier regs;
@@
-regs->edx
+X86_EDX
@ depends on inthandler @
identifier regs;
@@
-regs->esi
+X86_ESI
@ depends on inthandler @
identifier regs;
@@
-regs->edi
+X86_EDI
@ depends on inthandler @
identifier regs;
@@
-regs->eflags
+X86_EFLAGS
@ depends on inthandler @
identifier regs;
@@
-regs->vector
+M.x86.intno
Change-Id: I60cc2c36646fe4b7f97457b1e297e3df086daa36
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1891
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
realmode int handlers must return the same codes as the YABEL
int handlers now: 1 for "interrupt handled", 0 for "not handled"
(ie. error).
Change-Id: Idc01cf64e2c97150fc4643671a0bc4cca2ae6668
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1890
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I4128af7912bec090bbd48acc1b20d0452e7a4a28
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1876
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
e.g.
-#if CONFIG_LOGICAL_CPUS == 1
+#if CONFIG_LOGICAL_CPUS
This will make it easier to switch over to use the config_enabled()
macro later on.
Change-Id: I0bcf223669318a7b1105534087c7675a74c1dd8a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1874
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This code used a special case for checksum calculation to
prevent the century byte from messing things up, since
writes "sometimes" didn't happen.
That should be stable now, so the special case isn't necessary.
Downside: On century rollovers (ie. 1999-12-31, 2099-12-31)
CMOS will be reset to the defaults.
Change-Id: Ibe589a1ec953b7b3ba39be30cebd9fc2b27326ae
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1870
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
intel_irq_routing_table is a local structure that should not be used
globally, because it might not be there on all mainboards.
Instead, the API has to be corrected to allow passing a PIRQ table in
where needed.
Change-Id: Icf08928b67727a366639b648bf6aac8e1a87e765
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1862
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some boards selected GENERATE_ instead of HAVE_
Change-Id: I450c22d7b044f0c88c21692246d452d516a68a83
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1841
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
hard_reset was indeed consolidated and moved into the southbridge
code a while ago, but the config variable was still kept alife, with
some duplicate code.
Change-Id: I60d4a87de916667f6e89353dfbe1a7b9eca380f7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1837
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- Add mainboard_smi.c from arch/x86/Makefile if it's there
- Add mainboard's chromeos.c from the chromeos Makefile
Change-Id: I3f80e2cb368f88d2a38036895a19f3576dd9553b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1835
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch is the beginning of a Kconfig cleanup series
- drop CONFIG_HAVE_BUS_CONFIG and add get_bus_conf.c if it
exists in the mainboard directory
- drop duplicate ACPI_SSDTX_NUM from mainboard Kconfig
if it only defines the defaul value of 0
- Add mptable.c, fadt.c, reset.c and ssdtX.asl when they
exist, not based on some Kconfig magic
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia14a7116dad6a724af7e531920fee9a51fd0b200
Reviewed-on: http://review.coreboot.org/1832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The board incorrectly overrides the southbridge hook, so use the
new mainboard hook instead. This change also activates the actual
southbridge hook to enable decode of complete 4 MB flash memory region.
Change-Id: I02c6fe89ae9ad4a7403f024fac875ebd88a8e142
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1831
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's a bool, not a number
Change-Id: I70d52c6af6703101dbd534970ec65275902a283d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1842
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The board was broken for use with CONFIG_PCI_OPTION_ROM_RUN_YABEL.
Change-Id: Ia57d630143386fe637af83b9e7345d0d3750b089
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some time ago our CMOS checksum algorithm was changed under the topic:
Fix our CMOS checksum algorithm so it matches what /dev/nvram expects
Here is another copy of the algorithm that had to be updated.
Change-Id: I58659c7b8a89c89c76efdff405ee0620e7302277
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1852
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
At boot time when the ACPI tables are created and the location
of GNVS is determined then save that address for resume time.
This also sets the values of USB charging in S3/S5 to the expected
default values for Stout/Butterfly that were not set correctly.
Change-Id: I9b94b868aa6e81aced06c0262cc2697ad4faf1e6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1768
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Using global variables with the TSEG is a bad idea because
they are not relocated properly right now. Instead make
the variables static and add accessor functions for the
rest of SMM to use.
At the same time drop the tcg/smi1 pointers as they are
not setup or ever used. (the debug output is added back
in a subsequent commit)
Change-Id: If0b2d47df4e482ead71bf713c1ef748da840073b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1764
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ChromeOS' top of the tree u-boot expects coreboot to export information
about option ROM status (started/not started). Stumpy and Lumpy were
left behind and are not exporting this information. This CL fixes the
problem.
Change-Id: Id90035bd76ab177e4fc269efc2b74f15f641c77d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1713
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Fix GPIO exporting for new Vboot for oprom-matters GPIO
and to make the power button static.
Change-Id: Ic042c428a1d43512228c686121fa057d876606e1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1761
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Right now coreboot's build process produces images that are
not booting on actual hardware because they are smaller than
the actual flash device and also don't have an IFD nor an ME
firmware in them. In order to produce bootable images, you
needed a wrapper script / extra step until now. With this
change, the resulting coreboot.rom is actually bootable.
Change-Id: I82714069fb004d4badc41698747a704bd9fed4da
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1771
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If these values are non-zero then the kernel will issue
an SMI for each core (cstate) and package (pstate).
Since we don't do anything with these SMI callbacks we
can avoid taking the extra SMIs at boot time by zeroing
these fields.
Change-Id: I3bc5fe0a9f45141d46884cb77ecdfaeaa45d2439
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1769
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On Sandybridge and Ivybridge systems the firmware image has to
store a lot more than just coreboot, including:
- a firmware descriptor
- Intel Management Engine firmware
- MRC cache information
This option allows to limit the size of the CBFS portion in
the firmware image.
Change-Id: Ib87fd16fff2a6811cf898d611c966b90c939c50f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1770
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This makes resume from S3 work again. The check is new and fails on
other boards, too.
Change-Id: I0ada569e4ba649b9ac82768b0888e16104c621e8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1809
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Compose the name from Kconfig strings instead.
As the field is for debug print use only, a minor change in the output
should do no harm. The strings no longer include word "Mainboard".
Change-Id: Ifd24f408271eb5a5d1a08a317512ef00cb537ee2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1635
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All of these capabilities exist on all CPUs supported on
this socket.
Change-Id: I54f34e48e34bb6ab5b9954ab7ece8c2c3a1a8e67
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1664
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Because enable cache is added at the end of disable_cache_as_ram,
( http://review.coreboot.org/#/c/1662/2/src/cpu/amd/agesa/cache_as_ram.inc )
enable_cache() should be removed. The 3 mainboards are: amd parmer,
amd thatcher and tyan s8226
Change-Id: If870ca07d2e97b9e860a2e2315f551251c7a4ed2
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1669
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
We had only some MSR definitions in there, which are used in speedstep
related code. I think speedstep.h is the better and less confusing place
for these.
Change-Id: I1eddea72c1e2d3b2f651468b08b3c6f88b713149
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1655
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Enable the PCIE bridge which is connected to the PCIE slot.
Change-Id: I1b3fb59990e06d7bc7cf19639f2b93dbb7bf9b3e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1098
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
We only want to add data once per device. Using the one in
chip_operations is not very usable anyway, as different
devices under the same chip directory would need to output
entirely different sets of data.
Change-Id: I96690c4c699667343ebef44a7f3de1f974cf6d6d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1492
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
The PCI registers should be accessed aligned and 0x62 is not 32bit
aligned therefore this patch changes it to a 16bit access.
Change-Id: I00725a4569f471eedb061834f626911b42e734fb
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1631
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This is not available as a config option anymore.
Change-Id: Icac173d62928423a08671321ec21d4af82c5cded
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1630
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Change-Id: I2f10909a626fb64c7f95663ddd79a3b899f73bc4
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1606
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
The used FPGA on the device triggers PIRQD for the membrane
keyboard. The used linux driver for the keyboard uses the fixed
IRQ number of 7. In order not to touch the linux driver and be
compatible with proprietary BIOS change the irq_table in
coreboot.
Change-Id: If5bc929eb48bb1eafd401941ebb7d34cf5862c35
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1571
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
HPET's min ticks (minimum time between events to avoid
losing interrupts) is chipset specific, so move it to
Kconfig.
Via also has a special base address, so move it as well.
Apart from these (and the base address was already #defined),
the table is very uniform.
Change-Id: I848a2e2b0b16021c7ee5ba99097fa6a5886c3286
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1562
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Also deletes files not included in build:
src/southbridge/amd/cimx/sb700/chip_name.c
src/southbridge/amd/cimx/sb800/chip_name.c
src/southbridge/amd/cimx/sb900/chip_name.c
Change-Id: I2068e3859157b758ccea0ca91fa47d09a8639361
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1473
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
According to file "northbridge.c" in family 15h code
IO-HUB should be placed on link_lsit[0] in devicetree.cb.
This hack in "northbridge.c" was made to satisfy both f10 and f15 cpu's.
Change-Id: I4754235bd38239460347b0dc4a82cd4e58ae7cd0
Signed-off-by: Kostr <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/1540
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
The previous commit provides a mainboard_interrupt_handlers
implementation YABEL with identical semantics to the
x86emu one, so let's use it in both cases.
This eliminates the need for the int15_install()
indirection, so let's drop that, too.
Generated using the following coccinelle patch and
manual cleanups (empty #if/#endif):
@@
type T;
identifier FUNCARR;
expression INT, HANDLER;
@@
-typedef T yabel_handleIntFunc;
-extern yabel_handleIntFunc FUNCARR[256];
-FUNCARR[INT] = HANDLER;
+mainboard_interrupt_handlers(INT, &HANDLER);
@@
@@
-void int15_install(void)
-{
-mainboard_interrupt_handlers(0x15, &int15_handler);
-}
@@
@@
-void int15_install(void)
-{
-mainboard_interrupt_handlers(0x15, &int15_handler); ... mainboard_interrupt_handlers(0x15, &int15_handler);
-}
@@
@@
-int15_install();
+mainboard_interrupt_handlers(0x15, &int15_handler);
Change-Id: I70fd780d7ebf1564a2ff7d7148411673f6de113c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1559
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
our code supports tyan s8226 now, which has two cpus on the board
the cpu socket is C32. The details of tyan s8226 is:
http://www.tyan.com/product_SKU_spec.aspx?ProductType=MB&pid=679&SKU=600000190
the test result of this mainboard is:
1) boot Ubunbu 11.10, kernel 3.0.9. there is no err and warnings in
dmesg.
2) boot windows7 x64 successfully.
3) use fwts to test the bios, there are 268 pass and 14 failed
4) pcie and usb slots are ok.
5) all network interfaces are ok.
Change-Id: I7d8534f20b4f3c16322a5c5ba2e3fba4b4f3e608
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1495
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
