These bits are used by the IGD OpRegion code
Change-Id: I89a11fc5021d51e0c1675ba56f6a3bc3b79bb8aa
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1751
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
In order to support Intel's IGD Opregion standard, we need
an additional set of flags shared between firmware, ACPI, SMM, and the
graphics driver.
Change-Id: I1a9b8dff5e5ee8d501b6672bc3bcca39ea65572e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1750
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These can be stored in the code segment, since it's never changed.
Change-Id: I8b3827838e08e6cc30678aad36c39249fbca0c38
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1749
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Add support for GigaDevice SPI ROMS.
The GD25Q64B device has been tested, the other rom devices added to the
file have not.
Change-Id: If35676ca6b90329f15667ebb32efa0d1a159ae91
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1747
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These events were initially for Chrome EC but they can be
applied to any EC.
Change-Id: I0eba9dbe8bde506e7f9ce18c7793399d40e6ab3b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1746
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If the driver is initialized before the lockdown then it will
fail to work after the lockdown bit is set.
Change-Id: Idc05d33d8d726bf29cb3c9b1b4604522bd64170a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The RO_FMAP base moved from 0x5f0000 to 0x610000.
Also update Kconfig default and add a descripton so
the default can be changed by boards.
Change-Id: I0caad0ce6e6f19750dbbf042a5a489b558f62b96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1705
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
http://netbsd.gw.com/cgi-bin/man-cgi?date++NetBSD-current
The NetBSD manual tells us the date in NetBSD doesn't take any flags
to enable or disable padding in the format.
By default, date pads numeric fields with zeroes. This will convert the
number to octal one. So add "0x" to convert it to BCD directly.
Change-Id: Icd44312acf01b8232f1da1fbaa70630d09007b40
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1804
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The range of weekday in CMOS is 01-07, while the Sunday is 1, and
Saturday is 7. The comand date in coreutils defines
%u day of week (1..7); 1 is Monday
%w day of week (0..6); 0 is Sunday
There are 1 day offset for each week day. So we use "%w" and plus 1
before we update the weekday in CMOS.
Change-Id: I3fab4e95f04924ff0ba10a7012b57da1d3f0d1a5
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1802
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@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>
Read out the post code from the previous boot and
log it if the code is not one of the expected values.
Test:
1) interrupt the boot of the system, this is easiest
with warm reset button when servo is attached
2) check the event log with mosys
65 | 2012-09-09 12:32:11 | Last post code in previous boot | 0x9d
Change-Id: Id418f4c0cf005a3e97b8c63de67cb9a09bc57384
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This will use 3 bytes of CMOS to keep track of the POST
code for the current boot while also leaving a record of
the previous boot.
The active bank is switched early in the bootblock.
Test:
1) clear cmos
2) reboot
3) use "mosys nvram dump" to verify that the first byte
contains 0x80 and the second byte contains 0xF8
4) powerd_suspend and then resume
5) use "mosys nvram dump" to verify that the first byte
contains 0x81 and the second byte contains 0xFD
Change-Id: I1ee6bb2dac053018f3042ab5a0b26c435dbfd151
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a slight improvement over the rep movsb loop
Change-Id: Id71d9bfe5330b154a5c62fac85ce3955ae89b057
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The linux kernel relies on the RTC reporting pending interrupts if
the RTC alarm was used to wake the system. If we clear these flags
here then the rtc-cmos driver in the kernel will think that no
interrupts are pending and will not re-start the timerqueue to
handle the alarm timerqueue node.
This flag doesn't exist in SMM but the rtc code is compiled there.
Since rtc_init() is not called by SMM it is guarded with an ifdef.
I performed several thousand suspend/resume cycles without seeing
an issue where hwclock was unable to read from /dev/rtc. There
still is a potential kernel issue where the timerqueue can stall
but this makes that much less likely to happen on resume.
Change-Id: I5a343da4ce5c4c8ec4783b4e503869ccfa5077f0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In case tseg_relocate() is called again on a pointer we should not
relocate it again.
Change-Id: Ida1f9c20dc94b448c773b14d8864afe585369119
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We are seeing ME disabled and ME error events on some devices
and this extended info can help with debug.
Also fix a potential issue where if the log does manage to get
completely full it will never try to shrink it because the only
call to shrink the log happens after a successful event write.
Add a check at elog init time to shrink the log size.
Change-Id: Ib81dc231f6a004b341900374e6c07962cc292031
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The handling of write enable was not entirely correct,
the opcode needs to be skipped when the controller is
locked down.
Addresses were not getting set properly for erase commands
which seemed to mostly work when the previous command had
set an address.
Tested by adding events to the event log at runtime on a
freslhy flashed device (with locked down SPI controller)
until the log log shrink happens to ensure it does not hang:
hexdump -C elog.event.kernel_clean
00000000 01 00 00 00 ad de 00 00 00 00
for x in $(seq 1 232); do
cat elog.event.kernel_clean > /sys/firmware/gsmi/append_to_eventlog
done
mosys eventlog list | tail -6
154 | 2012-09-01 13:54:43 | Kernel Event | Clean Shutdown
155 | 2012-09-01 13:54:43 | Kernel Event | Clean Shutdown
156 | 2012-09-01 13:54:43 | Kernel Event | Clean Shutdown
157 | 2012-09-01 13:54:43 | Kernel Event | Clean Shutdown
158 | 2012-09-01 13:54:43 | Log area cleared | 1030
159 | 2012-09-01 13:54:43 | Kernel Event | Clean Shutdown
Change-Id: I3a50dae54422a9ff37daefce3632f8bcbe4eb89f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1717
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When bringing up VGA by running the option rom it's sometimes
useful to get more information about the mode that gets set,
or the reason why the mode could not be set or a picture could
not be displayed. Also prefix the output from VBE mode setting
with VBE:
Copying VGA ROM Image from fff0fd78 to 0xc0000, 0x10000 bytes
Real mode stub @00000600: 867 bytes
Calling Option ROM...
int15_handler: INT15 function 5fac!
... Option ROM returned.
VBE: Getting information about VESA mode 4161
VBE: resolution: 1280x1024@16
VBE: framebuffer: d0000000
VBE: Setting VESA mode 4161
VGA Option ROM has been loaded
Change-Id: I2be11f095dc62ed3c99e0d4272ad9d6521608a44
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1714
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we have FMAP support in coreboot use it to find the
offset in flash for ELOG to use.
If coreboot has elog configured with a smaller size then use
that over the FMAP size. This is because I set aside a 16KB
region in the FMAP but we only use 4KB of it to keep the impact
to boot/resume speed to a minimum.
FMAP: Found "FMAP" version 1.0 at ffe10000.
FMAP: base = 0 size = 800000 #areas = 32
FMAP: area RW_ELOG found
FMAP: offset: 3f0000
FMAP: size: 16384 bytes
FMAP: No valid base address, using 0xff800000
ELOG: base=0x003f0000 base_ptr=0xffbf0000
ELOG: MEM @0x00190ad8 FLASH @0xffbf0000
ELOG: areas are 4096 bytes, full threshold 3072, shrink size 1024
Change-Id: I3d826812c0f259d61f41b42797c58dd179f9f1c8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1706
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that WREN prefix is handled properly ELOG is able to write
when the SPI controller is locked down.
To test, ensure that runtime SPI write via ELOG is successful by
checking the event log for a kernel shutdown reason code:
5 | 2012-08-27 11:09:48 | Kernel Event | Clean Shutdown
6 | 2012-08-27 11:09:50 | System boot | 26
7 | 2012-08-27 11:09:50 | System Reset
Change-Id: If6d0dced7cb0f5ca7038b3d758f31b856826d30b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1712
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
The code that attempts to use the opmenu needs to have a special
case for write enable now that it is handled as an atomic prefix
and not as a standalone opcode.
To test, ensure that runtime SPI write via ELOG is successful by
checking the event log for a kernel shutdown reason code:
5 | 2012-08-27 11:09:48 | Kernel Event | Clean Shutdown
6 | 2012-08-27 11:09:50 | System boot | 26
7 | 2012-08-27 11:09:50 | System Reset
Change-Id: I527638ef3e2a5ab100192c5be6e6b3b40916295a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1710
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Check the RTC on boot after RTC battery failure and ensure
that the reported build date matches what is reported:
> grep ^rtc /proc/driver/rtc
rtc_time : 01:00:21
rtc_date : 2012-08-16
Change-Id: If23f436796754c68ae6244ef7633ff4fa0a93603
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1709
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
This appears to fix an infrequent resume hang on Ivybridge.
Tested on 2 devices with 15k suspend/resume cycles each
Change-Id: I53618bc7966824413f1720a2be3cbd2550e29473
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1704
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
(elog portion, support in EC code pending)
- Use a new EC command to read the last post code
from the previous boot
- If the post code is not well-known final boot
or resume code then log it
Change-Id: Id6249e9a182243eb87c777edd56f48de72125e77
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1703
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Until now, the MRC cache position and size was hard coded in Kconfig.
However, on ChromeOS devices, it should be determined by reading the
FMAP.
This patch provides a minimalistic FMAP parser (libflashmap was too
complex and OS centered) to allow reading the in-ROM flash map and
look for sections.
This will also be needed on some partner devices where coreboot will
have to find the VPD in order to set up the device's mac address
correctly.
The MRC cache implementation demonstrates how to use the FMAP parser.
Change-Id: I34964b72587443a6ca4f27407d778af8728565f8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1701
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
This is purely cosmetic. All error messages in the Sandybridge raminit
code printed a newline at the end.
Change-Id: I880d291928291d487039850a2a3d53a1101124ba
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1699
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
build.h is generated at build time,
with highly parallel builds, we might try to compile the rtc driver too
early.
Change-Id: I9a2681484d58b67ed3061669fbdf52ac5ad14dab
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: http://review.coreboot.org/1698
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
When a power failure happens on the RTC rail, the CMOS memory (including
the RTC registers) is filled with garbage.
So, we erase the full first bank (112 bytes) and we reset the RTC date
to the build date.
To test, disconnect the CMOS battery to produce an RTC power
failure, then boot the machine and observe the RTC date is the build
date using "cat /sys/class/rtc/rtc0/date"
Change-Id: I684bb3ad5079f96825555d4ed84dc0f7914e9884
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: http://review.coreboot.org/1697
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Each G34 socket has two node. Previous lapic algorithm is written for
the CPU which has one node per socket. I test the code on h8qgi with
4 family 15 CPUs(8 cores per CPU). The topology is:
socket 0 --> Node 0, Node 1
socket 2 --> Node 2, Node 3
socket 1 --> Node 4, Node 5
socket 3 --> Node 6, Node 7
Each node has 4 cores.
I change the code according to this topology.
Change-Id: I45f242e0dfc61bd9b18afc952d7a0ad6a0fc3855
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1659
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
This will allow the lower bank to be cleared without impacting the
ability to suspend/resume.
Change-Id: Iaec3c9e7e40c334053c814eaddd1f614df245a73
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1696
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
On Panther Point PCH (and maybe cougar point), when some of the register
D reserved bits are set, the RTC starts misbehaving (e.g. incrementing
the year byte every second).
There are probably undocumented features implemented behind those bits.
Let's reset register D to a known state to ensure we get the expected
RTC behavior.
Change-Id: I7e2c2a2c6130a974bccb3d760b41eaa579a58b67
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: http://review.coreboot.org/1695
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
We always define CONFIG_ variables, even if they're not set.
Hence, remove the check whether CONFIG_UDELAY_TIMER2 is defined
Change-Id: Iefdf2389941f2cc63ae4f13ac6b213da4c96b201
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1694
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Right now we only had a post code for "All devices enabled" which
was emitted at the wrong time (after the device initialize stage
rather than the device enable stage)
Change-Id: Iee82bff020de844c7095703f8d6521953003032c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1693
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Our linker script for romstage checks for global variables and
makes the build fail if there are any (on non-AMD systems).
This is great, but having the build fail without any indication
which variables are global is not very useful.
Moving the check to the Makefile allows us to let the linking stage
succeed and reveil which variable names end up in the data and bss
sections of the binary.
To test, add "int foo;" as the first line in src/mainboard/samsung/lumpy/romstage.c
and build coreboot for Lumpy. See the build break the following
way:
LINK cbfs/fallback/romstage_null.debug
Forbidden global variables in romstage:
00006a84 B foo
Change-Id: I3c8780888f46a6577ffd36bcea317997b4f84f6f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1692
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
To allow easy experimentation with thermals, leave power control
registers unlocked.
Change-Id: Ia53065f3f220c2faed58e7d53e60c3f169ae58ec
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://review.coreboot.org/1688
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Every line of text after a 'help' label in a Kconfig
file must have the same whitespace preceding it, otherwise
it's no longer considered help text.
Change-Id: I97093bee72b295b315d78d4c26d7186bf1017fda
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1687
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
PCIE devices are detected and initialized by the AMD PCIe init functions,
which is in cimx rd890. The parameters are read from devicetree.cb before PCIe init.
Now, all bridges and devices are trained on the device 0.0 enable.
After PCIe init, the PCIe ports with devices are on and the PCIe ports
without devices are off. so resources may be allocated correctly
during the rest of the PCI scan.
But if the devicetree was being used to enable/disable devices after initialization,
the problems would arise. Take a look at the serial log:
do_pci_scan_bridge for PCI: 00:02.0
PCI: pci_scan_bus for bus 01
PCI: pci_scan_bus returning with max=001
do_pci_scan_bridge returns max 1
do_pci_scan_bridge for PCI: 00:03.0
PCI: pci_scan_bus for bus 02
PCI: pci_scan_bus returning with max=002
do_pci_scan_bridge returns max 2
do_pci_scan_bridge for PCI: 00:04.0
PCI: pci_scan_bus for bus 03
PCI: pci_scan_bus returning with max=003
do_pci_scan_bridge returns max 3
PCI bridge 02.0, 03.0 and 04.0 are not inserted devices, but these bridges
are still scanned. This is not correct.
Change-Id: I87dac5f062c6926081970ed0c5f26a7e3f447395
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1640
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
There are four mainboards using agesa family15 code:
Supermicro h8scm and h8qgi, Tyan s8226 and AMD dinar.
All of these boards' PCI domain starts from 0x18.0. Take h8scm as
an example, PCI devices from 0.0 to 0x14.5 is under 0x18.0.
Now, the PCI domain's scan bus function stats from 0.0. This would
result to the PCI devices be scanned twice. Because when the function
run to device 18.0, it would scan from 0.0 again.
This issue would result to 2 problems:
1) PCI device may be assigned two different PCI address.
If this happenned on VGA device, coreboot maybe not load
vga bios correctly.
2) coreboot initializes rd890's IO APIC twice.
So this patch scans from 0x18.0 and could resolve the problems above.
Change-Id: I90fbdf695413fd24c7a5e3e9b426dc7ca6e128b1
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1639
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Adds lowlevel handling of DMAR tables for use by mainboards'
ACPI code. Not much automagic (yet).
Change-Id: Ia86e950dfcc5b9994202ec0e2f6d9a2912c74ad8
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1654
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>
This is the smallest possible change to make early_serial.c
compile when included from romstage.c.
early_serial could be reworked to be built as separate unit
(romstage-y), but that should be done for all SuperIOs,
not some individual outlier.
Change-Id: I90ee66b43c9677b86b1b5d6fcc8febfbe58d80dd
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1686
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
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>
The constant field "name" in chip_operations is common to multiple
different devices within a chip and cannot reflect the actual device
as found on the platform.
The intention is that a driver sets dev->name as part of the device
enumeration sequence with the detected hardware type and revision.
The field is for debug print use only.
Change-Id: Ib7bf90ba3c618ad0cb715d80d6a937ceaae0adcf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1634
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This adds proper support for turbo and super-low-frequency modes.
Calculation of the p-states has been rewritten and moved into an
extra file speedstep.c so it can be used for non-acpi stuff like
EMTTM table generation.
It has been tested with a Core2Duo T9400 (Penryn) and a Core Duo T2300
(Yonah) processor.
Change-Id: I5f7104fc921ba67d85794254f11d486b6688ecec
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1658
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)
add this code according to src/include/cpu/x86/cache.h ,line 92,
functin enable_cache()
Change-Id: Ida96a98397eeed98dd61ca979e8c5a33bf00f9e5
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1662
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
We parsed the MSR the wrong way, and didn't support some valid values.
Change-Id: Ia42e3de05dd76b6830aaa310ec82031d36def3a0
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1656
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Unfortunately the reference tool chain was updated
without ever even testing it on an abuild run. This
broke a number of ports.
This change gets coreboot at least compiling again
for all supported systems.
Change-Id: I92c7cbc834de6d792fdab86b75df339e2874c52e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1670
Reviewed-by: Ronald G. Minnich <rminnich@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>
Current ExecuteFinalHltInstruction function doesn't work well.
(at least in configuration
Supermicro board with Orochi AMD Opteron processors (model OS6234WKTCGGU))
System reboots when trying to halt core 2,4,6,8 or 10
(OS6234WKTCGGU is 12 core processor)
Based on this information, i think that code doesn't really work with
f15 compute unit (CU) system.
Replacing ExecuteFinalHltInstruction function with
analogous function from f15tn family code fix this problem.
Both functions written from the same cahalt.asm file, but f15tn version
seems more completed
Change-Id: I3942abcdf21f1b86a44c01cc477714e44a40b9cf
Signed-off-by: Kostr <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/1569
Tested-by: build bot (Jenkins)
Reviewed-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
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 number read from the io-apic register represents the index of the
highest interrupt redirection entry, i.e. the number of interrupts
minus one.
Change-Id: I54c992e4ff400de24bb9fef5d82251078f92c588
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1624
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The options are shown regardless of payload if CONFIG_EXPERT is set.
Change-Id: I12c81ce41a0e300e852481424eadc83f281863bf
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/1638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Also clarify that enabling these options is generally not desirable if
using SeaBIOS as payload since the option ROMs are run by SeaBIOS with
more complete BIOS interrupt services available than coreboot.
Change-Id: Ic4a45c351a4933aedad08d70a088eab04ca35b05
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/1636
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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)
Without this, the output of "Setting up ACPI…" continues right
after the output of stepping.
Change-Id: I2ad7cc3e55884ff509600b01274258b8e8250981
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1632
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)
I don't know if the size main memory supposed to be in PCI(0,0) reg 0x9c
but it is not written there. The size of memory is written in
src/northbridge/intel/sch/raminit.c to SCH port(2, 8, 4) (look for
"Setting up TOM").
Change-Id: Iea04a5185bda56f61d1c382533d5a0dac429ebbd
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1629
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The GGC register which contains the size of memory that is used for GPU
is in PCI device 2,0 and not 0,0. It is set to to 4MiB in
src/mainboard/iwave/iWRainbowG6/romstage.c.
Change-Id: Ie9f1cc60544ecd9cad770f34c83c33564a6129d4
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1628
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Without this, the hightables are placed just before the end of memory.
However we might have the GPU memory located at the exact same spot,
that is in the last 4 MiB. So without this patch, this area won't remain
marked as "CONFIGURATION TABLES" within coreboot's memory table but
becomes "RESERVED" because it is part of the PCI(2,0) device.
Change-Id: Ibd111c167c2f6ac03b0ba68581a74ecbd2c9c160
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1627
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
src/vendorcode/amd/agesa/f15/Porting.h has some conflicted typedef with
src/include/cpu/amd/common/cbtypes.h. These conflicted defines can lead to errors.
Change-Id: Idad0794018bf0bd0e4e52a5aa062a12766d56c8e
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1592
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Forcing this rule, chip_ops can be added in the static devicetree
regardless of the existence of the chip.h files.
Change-Id: Iec1c23484e85cab3f80a34f2b082088f38ac4de9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1472
Tested-by: build bot (Jenkins)
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>
Before change "Simplify VGA card discovery"
(http://review.coreboot.org/#/c/1255/)
coreboot was setting up VGA for the last found VGA device.
After this change it setting up VGA for the first found.
This change broke compatibility to my Supermicro H8QGI board.
Revert order back to old to save compatibility for this board
(and maybe any other boards)
Change-Id: Id5f2be60f95298059651c26133806e2694ff60aa
Signed-off-by: Kostr <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/1561
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
This is in preparation for sharing interrupt handlers
between YABEL and x86emu.
Change-Id: Iff92c1d899b8ada20972731944341805a49b6326
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1560
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Provide (mostly) the same API for registering
interrupt handlers as with x86emu.
Change-Id: I1364b08d9043039550786a1758508ae088813aa3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1558
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>
pirq_routing_irqs assumed that only four links are available for PIRQ
routing, INTA to INTD. Some chipsets provide more, up to INTH.
When pirq_routing_irqs found a link number greater than 4 in the pirq table,
it would not assign that IRQ. This is a shame, as it limits the flexibility
of routing IRQs.
Make the maximum number of links a Kconfig variable, and modify the code to
respect it. This works beatifully on the VX900, which provides 8 routable
interrupts.
While we're at it, also refactor pirq_routing_irqs, and add some much
needed comments.
Rename pirq_routing_irqs to pirq_route_irqs to demistify the role of this
function.
The copyrights added were determined from git log filename.
Change-Id: I4b565315404c65b871406f616474e2cc9e6e013e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1482
Tested-by: build bot (Jenkins)
Without that fix we have:
CC boot/hardwaremain.ramstage.o
src/boot/hardwaremain.c: In function 'hardwaremain':
src/boot/hardwaremain.c:136:6: error: 'cbmem_post_handling' undeclared (first use in this function)
src/boot/hardwaremain.c:136:6: note: each undeclared identifier is reported only once for each function it appears in
src/boot/hardwaremain.c:137:3: error: implicit declaration of function 'cbmem_post_handling' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make: *** [build/boot/hardwaremain.ramstage.o] Error 1
When compiling without CONFIG_WRITE_HIGH_TABLES
Change-Id: Ie45f684a6db0ab55ef469bfcef57e539ae7e994c
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/1533
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Some 32 bit machines print integer higher than 0x80000000
as negative number.
Change-Id: Ieb512ed2a7499ce7e91e45e4075d4f119780b57d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1547
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
... but no-one told intel/sch.
Change-Id: I68eaae6910bd6fc579c35b5bc038b9597cd1b3e7
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1537
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Try
sh> printf %d 0x005500AA | LC_ALL=C awk '{printf("%c%c%c%c", \
$1 % 256, $1/256 % 256, $1/65536 % 256, $1/16777216);}' | \
od -Ax -t x
On Linux with gawk, we get
000000 005500aa
000004
On FreeBSD with nongnu-awk, we get
000000 000055aa
000002
In awk, all the numbers are floating point number. So division doesn't
round the result from 0.75 (3/4) to 0.
And, There is a fact that, for the FreeBSD awk,
sh> awk 'BEGIN {printf("%c", 0.75)}';
produces nothing, instead of 0.
Here we need to convert the floating point number to
integer by int(X), which is an awk built-in function, instead of GNU
extension.
Change-Id: I3470d5f13e7ea59a978d5575a54c0d56368dc78d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1529
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
TRACE has redefined warnings in src/southbridge/amd/cimx/sb700/Platform.h,
so we do some changes to remove such warnings.
Change-Id: I24979e08b83434f91a8fa37cd9f16303fa0b298d
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1499
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Currently the C32 has some legacy boards which use the old C32 code. We need to seperate them.
CONFIG_CPU_AMD_SOCKET_C32 was used in legacy code before.
But it is not a good idea, so we change the code as follows:
So we use CONFIG_CPU_AMD_SOCKET_C32 to identify mainboard which uses agesa code,
and use CONFIG_CPU_AMD_SOCKET_C32_NON_AGESA to identify mainboard which uses legacy code.
Change-Id: If6114bf8912e78b7732f25a1adfb2e4d8eb10ee4
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1497
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Command expr in some systems only take 32bit as integer, which
value is at 0x7FFFFFFF ~ -0x80000000. Use awk as alternate way to
calculate.
And some system doesnt take hex value in Makefile, even in awk instruction.
Change-Id: Ie35d6a5b96eea4192bd9cab857af4d4dcb37b9ed
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1527
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In the field there are different hardware revisions and some
of them have problems with UDMA as a resistor is missing. We can
detect this situation in coreboot and e.g. the linux kernel
can take this knowledge and disable UDMA.
Change-Id: Ib75cad7acedbc1dc65378bb9bfc3f353cbe21427
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This eeprom is used to store some device relevant informations
like hardware revision.
Change-Id: I32bda9d5412bc5a96da0edb5ef0b6d1ba4caa2d8
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1511
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Without this change 64 bit versions of Windows will BSOD.
Change-Id: If39627a179c24184b6c956b3a50f692f8a034d2f
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1476
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Disallow tracing while in SMM.
Change-Id: Icde17629bb06a615cc48f017fd0cd1f7b720e62d
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/1503
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
The M2V-MX SE DSDT has been a copy from Asus A8V-E SE, which has VT8237R.
But the stuble change in USB interrupt routing went undetected, although
I had some USB troubles on the FOSDEM with low speed devices.
Change-Id: Ie724df440e0963f6955b3de57e4687f3ddc7f6ef
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/1505
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
this function is used on serial output of tyan s8226
Change-Id: I5f7fa535b922b224e381886f1bea64623fa549ef
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1494
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Without this change 64 bit versions of Windows will BSOD.
Change-Id: Ica4b79d798a269399341868b1c793ce745aa93fc
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1480
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add code to do the following for the VIA Nano CPUs
- Update microcode
- Set maximum frequency
- Initialize power states
- Set up cache
Attempting to change the voltage or frequency of the CPU without
applying the microcode update will hang the CPU, so we only do
transitions if we can verify the microcode has been updated.
The microcode is updated directly from CBFS. No microcode is
included in ramstage. The microcode is not included in this
commit.
To get the microcode, run bios_extract on the manufacturer supplied
BIOS, and look for the file marked "P6 Microcode". Include this
file in CBFS.
You can have the build system include this file automatically by
selecting Expert Mode, then look under
'Chipset' -> 'Include CPU microcode in CBFS' ->
Include external microcode file (check)
'Path and filename of CPU microcode' should contain the location of
the microcode file previously extracted.
Change-Id: I586aaca5715e047b42ef901d66772ace0e6b655e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1257
Tested-by: build bot (Jenkins)
This patch aims to improve the microcode in CBFS handling that was
brought by the last patches from Stefan and the Chromium team.
Choices in Kconfig
- 1) Generate microcode from tree (default)
- 2) Include external microcode file
- 3) Do not put microcode in CBFS
The idea is to give the user full control over including non-free
blobs in the final ROM image.
MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode
is handled by a special class, cpu_microcode, as such:
cpu_microcode-y += microcode_file.c
MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is
needed by intel microcode updating. Once all intel cpus are converted to
cbfs updating, this variable can go away.
These files are then compiled and assembled into a binary CBFS file.
The advantage of doing it this way versus the current method is that
1) The rule is CPU-agnostic
2) Gives user more control over if and how to include microcode blobs
3) The rules for building the microcode binary are kept in
src/cpu/Makefile.inc, and thus would not clobber the other makefiles,
which are already overloaded and very difficult to navigate.
Change-Id: I38d0c9851691aa112e93031860e94895857ebb76
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1245
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
I use the ioapic_config in my VX900 branch.
Typing:
struct drivers_generic_ioapic_config *config = (struct drivers_generic_ioapic_config *)dev->chip_info;
is clumsy at best, so just create a typedef to mahe this more elegant:
ioapic_config_t config = (ioapic_config_t*)ioapic->chip_info;
Change-Id: I407899845cfbd847ba6309dd0cf9ef836a607c8e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1481
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
In commit 6b5eb1cc2d setup of
UMA memory region was moved to happen at a later state and
this broke UMA with RS780 southbridge.
Share the TOP_MEM and UMA settings before any of the PCI or CPU
scanning takes place.
Change-Id: I9cae1fc2948cbccede58d099faf1dfe49e9df303
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1488
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Forgot to change the code back after debugging.
Change-Id: Iaf58d65c14d53ca77958080faf6ab85d60992226
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1491
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
These declarations were never or no longer used.
Change-Id: Icdbfc0838d5021ea02ab031b643b3fe6361b39b4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1489
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Prior to this change the setting would be zeroes and
would cause a BSOD in 64 bit versions of Windows.
Change-Id: I2d422ef9667457af53f9fd055799e489ed2b25db
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1475
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Maybe sooner or later python is not a default tools to build coreboot.
Most of the work is done by awk now. GNU extension of gawk is not used, isn't?
echo, expr, printf, cat, awk, test, mv are the external tools.
If XHCI, IMC or GEC firmware is not available and not defined, this script can skip
integrating them.
Change-Id: I9944b22b0b755672a46d472c355d138abafd6393
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1417
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There are hyper-threading Atom CPUs, those would not enable L2
cache with model_6ex CAR code. Switch to code that can handle
different number of threads and cores.
Change-Id: I57328c231f8998f45f7b0d26c63b24585f8476dd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1384
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: James Laird <jhl@mafipulation.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Factor CPU allocation out of AMD northbridge codes. As CPU topology
information is required for generation of certain ACPI tables, make
this code globally available.
For AMDK8 and AMDFAM10 northbridge, there is a possible case of
BSP CPU with lapicid!=0. We do not want to leave the lapic 0 from
devicetree unused, so always use that node for BSP CPU.
Change-Id: I8b1e73ed5b20b314f71dfd69a7b781ac05aea120
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1418
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use of alloc_find_dev() prevents creation of a device duplicates
for device_path and is SMP safe.
Reduce scope of variables to make the code more readable and in
preparation for refactoring the allocation out of northbridge.c.
Change-Id: I153dc1a5cab4f2eae4ab3a57af02841cb1a261c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1186
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Don't derive the IRQ pin from the function number. Especially onboard
chipset devices don't follow that rule. Instead check and add all
fixed IRQ entries.
Change-Id: I46c88bad39104c1d9b4154f180f8b3c42df28262
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1461
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The name is derived directly from the device path.
Change-Id: If2053d14f0e38a5ee0159b47a66d45ff3dff649a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The current code does some argument manipulation to detect when a stage is being
added to cbfs. This same manipulation needs to be done when adding a payload.
Change-Id: Ief4c4a81446c9437923cbbb1ce3fa90729317587
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1451
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When we encounter an x86 exception, we print the problem address, dump the
registers and die. This may not be sufficient information for debug. Also
dump the memory around the problem instruction. This has proven useful in
identifying memory issues, and DRAM burst reordering problems.
Change-Id: I6411344e89f946e16d11217d7dbd73812c45d54c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1454
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Something about HD audio was scrubbed. Take it back.
Change-Id: I0be96fd103f3ebd4e8c7ef09a184b71aa34ee3fd
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1427
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
The search loop for UMA resource was only used to check for the highest
RAM address below 4GB. The cached values from BSP CPU can now be used
for the replication.
Change-Id: I5244ffa6f8a93f5ff5aaf8a71bd006b0f9cd518a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1388
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Take a copy of BSP CPU's TOP_MEM and TOP_MEM2 MSRs to be distributed
to AP CPUs and factor out the debugging info from setup_uma_memory().
Change-Id: I1acb4eaa3fe118aee223df1ebff997289f5d3a56
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1387
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This was broken, fixing according to related patch for i945
Change-Id: I925cd205ee5beb918181740a7b981a4209688ac6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1412
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The CPU can arbitrarily reorder calls to rdtsc, significantly
reducing the precision of timing using the CPUs time stamp counter.
Unfortunately the method of synchronizing rdtsc is different
on AMD and Intel CPUs. There is a generic method, using the cpuid
instruction, but that uses up a lot of registers, and is very slow.
Hence, use the correct lfence/mfence instructions (for CPUs that
we know support it)
Change-Id: I17ecb48d283f38f23148c13159aceda704c64ea5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1422
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Adding ranges directly into coreboot memory table raised issues
as those methods bypassed the MTRR setup. Such regions are now
added as resources, so declare the functions again as static.
Change-Id: If78613da40eabc5c99c49dbe2d6047cb22a71b69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1415
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The includes removed here were previously required for
struct lb_memory and lb_add_memory_range().
Change-Id: Ie6c0d4ef55c2225aa709cf3fbad30ff1080e3610
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1391
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Dropping mainboard's chip.h broke execution of the mainboard's enable
function and the addition of mainboard specific smbios tables.
The former was fixed by Kyosti in http://review.coreboot.org/1374
This patch fixes the breakage in static.c and also backs out a small
portion of Kyosti's patch (because it's not needed anymore)
Change-Id: I6fdea9cbb8c6041663bd36f68f1cae4b435c1f9b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1421
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
These existed to provide a hook to add reserved memory regions
in the coreboot memory table. Reserved memory are now
added as resources.
Change-Id: I9f83df33845cfa6973b018a51cf9444dbf0f8667
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Use of lb_add_memory_region() is reduntant with the MMCONF
resource being set as reserved.
Change-Id: I747ea34823692b6966b2e50d22aea1fb89c73c25
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1394
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The function is a noop for all but amd/serengeti_cheetah.
Change-Id: I09e2e710aa964c2f31e35fcea4f14856cc1e1dca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1184
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The names were set at various times during development, but
the way the code works, you might end up with the wrong name
being displayed in the logs. Instead of doing magic, just
display both names for each component
Change-Id: I1f8ce44d156442f5f7d717e1a2b47ed1218d4527
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1413
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Move beep commands to board-specific area as they need to be different for
different codecs.
Change-Id: I2a1ac938c49827cc816a95df10793a7e234942bf
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: http://review.coreboot.org/1410
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use IORESOURCE_RESERVE to exclude the region from system RAM table.
Change-Id: I61b51022165e1304a41554f67af75b3089d892af
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1393
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Apply the change
http://review.coreboot.org/1390
to all the AMD southbridge.
Change-Id: I8e94014f8883a0408b68355d9aa33aea4373881f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1406
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Move the POST display to take place just before jumping
the payload, a bit later than before.
Change-Id: Ie1d1ff24dc6c1640e25681be7dc5740943c7f112
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1396
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Some mainboards have really nice capabilities for posting, beyond
simple POST cards. Further, some can not use a POST card. This
change defines a weak symbol (mainboard_post) that can be overridden
by a real mainboard_post function.
If, for example, you'd like to do something fancy before the payload starts,
you can add this to mainboard.c:
void mainboard_post(u8 value)
{
switch(value){
case POST_TIME_TO_PARTY: some_fancy_lights();
break;
}
}
Maybe the post function should be an entry in the device. We're beginning to over-use
weak symbols.
BUG=None
TEST=Build and boot a google chromebook. Observe that it still works. Use it to drive
some pretty lights.
Change-Id: I3512d2ec34a66c747287191851c3f68b6a7cc1b2
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1397
Tested-by: build bot (Jenkins)
In accordance to PCH EDS 14.1.35.1
Change-Id: I2e6cec6d4f49f404e33a171a8fbd6e4880327896
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1411
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Apply the change
http://review.coreboot.org/1265
to all the AMD northbridge.
Change-Id: Idf3994c1e9ec76cd19db9f740d825cf24059884f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1404
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Apply the change
http://review.coreboot.org/1264
to all the AMD northbridge.
Change-Id: Ied74d6f579d2c0350288e2619d7810f8d44fa574
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1403
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The board had HAVE_MAINBOARD_RESOURCES=0 so this was never
called. Drop unnecessary includes too.
Change-Id: Ia7bddf29a16966c052b5cabbb47029299e6dbd12
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1392
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Detection for a hyper-threading CPU was not compatible with multicore
CPUs. When using CPUID eax==4, also need to set ecx=0.
CAR init tested on real hardware with hyper-threading model_f25 and
under qemu 0.15.1 with multicore CPU.
Change-Id: I28ac8790f94652e4ba8ff88fe7812c812f967608
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1172
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Commit 188e3c2ff0 dropped mainboard
out of the static device tree. This left dev_root->chip_ops unset,
and mainboard_ops.enable_dev() was no longer called.
Change-Id: I6d447c8049a66041b8bb36ec9aac3e7e0d20a99b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1374
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If the CMOS is cleared or someone writes some random date/time
on purpose, the CMOS date register has a invalid date. This will
hurts some OS, like Windows 7, which hangs at MS logo forever.
When we detect that, we need to write a reasonable date in CMOS.
Alexandru Gagniuc:
Hmm, it would be interesting to use the date the coreboot image
was built and set that as the default date. At least until time
travel is invented.
Change-Id: Ic1c7a2d60e711265686441c77bdf7891a7efb42e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1389
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The field device in PCI_ADDRESS only takes 5 bits. So if the device number is
more than 32, it will truncated to 5 bits. Before this patch, other pci devices
will be incorrectly probed as processor node.
Change-Id: I64dcd4f4fda7b7080a9905dce580feb829584b94
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1264
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Parmer and thather hang at windows 7 booting process. Setting the
valid date in CMOS can fix that.
Change-Id: I5e427cfb42430ebebdb4c1e48bd25860c0fec45f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1390
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Thatcher features: Family 15 trinity FP2. Hudson.
close to Parmer.
This board and parmer both need to revert the change
http://review.coreboot.org/#/c/1359/, and add thatcher's own
chip.h,otherwise the mainboard_enable can not be called.
Change-Id: I54e1cfca845fbcea1d3aad5eff08d760d0d215c9
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1382
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Before (data flag ignored -> broken):
66 DATA:
e944f1 JMP 1ff6
After (fixed):
66 DATA:
e944f1ffff JMP 00001ff8
This subtle difference in the length of decoded instruction meant
that the VBE call jumped to the routine setting AX=0x14F (VBE Failed)
instead of the routine that set AX=0x4F (VBE success).
The ability to run the same code in vm86 significantly aided the
debugging of this issue. Those X.org developers who would like to drop
vm86 better take special care towards _all_ vesa bugs, as those will
expose further issues.
Imported from:
http://cgit.freedesktop.org/xorg/xserver/commit/hw/xfree86/x86emu?id=cc2c73ddcb4370a7c3ad439cda4da825156c26c9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Id08ead9b17468cf19ede45508e5dcc50e45b5acf
Signed-off-by: Luc Verhaegen <libv@skynet.be>
Tested-by: Luc Verhaegen <libv@skynet.be>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-on: http://review.coreboot.org/1365
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
cc2c73ddcb4370a7c3ad439cda4da825156c26c9's three-cent titanium tax
doesn't go too far enough. Fix the rest of the call and jmp
instructions to handle the data prefix correctly.
Reference: Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 2A: Instruction Set Reference, A-M
http://www.intel.com/Assets/PDF/manual/253666.pdf
Imported from:
http://cgit.freedesktop.org/xorg/xserver/commit/hw/xfree86/x86emu?id=bb18f277156c08be028a6e12d8987fb1593e9168
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I83e6245d9748ee86722cfb7d8ac65258c35c013c
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-on: http://review.coreboot.org/1366
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch validates the previous "drop uma_memory_base" patches;
there are no more references to uma_memory_base when GFXUMA is not
selected.
Change-Id: I735b5e765b0c5cb4af1b4a7470cfe1af2bda7d38
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1385
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
UMA region can be determined at any time after the amount
of RAM is known and before the uma_resource() call.
Change-Id: I2a0bf2d3cad55ee70e889c88846f962b7faa0c7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1379
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Without GFXUMA, variables were not referenced anywhere.
Fail builds on Family10 if GFXUMA is selected, because the northbridge
code does not set UMA base or size.
Change-Id: I15b91cf6241e9a890398eed03824b753828a0a51
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1247
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The code in rs690 or rs780 is always used with K8 or AMDFAM10
northbridge. Without GFXUMA, both of these set the same static value
indirectly using the variable uma_memory_base.
Make the register setting with immediate value, to remove the obscure
use of variable uma_memory_base.
Change-Id: I5354684457a76e73013b4e34a4538a6d122eee8d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1246
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
I dont known if missed something, but why an extra 0x100 was added to limit?
My board would get the wrong memory table entry 7f000000-7fffffff as RAM, which
is higher than TOM.
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000c0000-000000005e13efff: RAM
3. 000000005e13f000-000000005effffff: CONFIGURATION TABLES
4. 000000005f000000-000000007effffff: RESERVED
5. 000000007f000000-000000007fffffff: RAM
6. 00000000a0000000-00000000afffffff: RESERVED
Ronald G. Minnich:
I think someone who wrote the code was trying to round up the
next 0x100 boundary and did it incorrectly.
Here is code that would do it correctly:
limitk = ((resource_t)((d.mask + 0x00000ff) & 0x1fffff00)) << 9 ;
Zheng:
Plus 0xFF is correct, but the d.mask take bit 0 as enable it.
This bit should be clear when we try to calculate the limitk.
Change-Id: I3848ed5f23001e5bd61a19833650fe13df26eef3
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1265
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use of uma_resource() in northbridge code created a memory
resource marked as reserved. Such resources are removed
from system memory in write_coreboot_table().
Change-Id: I14bfd560140d8d30ec156562f23072bfae747bde
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1238
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
With SandyBridge northbridge code, uma_memory_size was reset to
zero before variable MTRRs were set. This means MTRR setup routine
did not previously create a un-cacheable hole for uma.
Keep the behaviour that way, mmio_resource() has a prerequisuite that
the new region does not overlap with any cacheable ram_resource().
The result is not optimal setup in the number of used MTRRs, but
continue with this approach until MTRR algorithm is improved.
Change-Id: I63c8df19ad6b6350d46a3eca3055abf684b8b114
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1373
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reserved memory resources will get removed from memory table at
the end of write_coreboot_table(),
Change-Id: I02711b4be4f25054bd3361295d8d4dc996b2eb3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1372
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This reverts commit 042c1461fb.
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I7dd1cba5a4c1e4b0af366b20e8263b1f6f4b9714
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1381
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 78efc4c36c.
The broadcast patch was reverted, so this commit should also
be reverted. The reason for reverting the broadcast patch:
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I05c27dec55fa681f455215be56dcbc5f22808193
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1380
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some usb debug devices don't respond fast enough. The linux kernel
(which uses almost the same usbdebug code) added a bit more
retry code, so let's copy that. Even if it might look stupid,
i pass the DBG_LOOPS argument through all functions to keep
the code at least a bit in sync with the linux kernel code.
Change-Id: I7c4b63b8bf1d2270fd6b8c8aa835e2cb324820bd
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1375
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Compilation fails with set_debug_port undeclared in ramstage and
smm code. Fix that by adding usb_debug.c to the appropriate stages.
Change-Id: I2a037d3c5fab76ae6ea65c3a7f4d4e7561bb6d34
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1376
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
MRC messes with USB devices, so we have to reinitialize
USB debug after MRC has finished.
Change-Id: I45c0a687cebd69d0a31235bb870f8c455f42d4f2
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1377
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit 2d42b34003 changed the
variable MTRR setup and removed compensation of uma_memory_size in
the cacheable memory resources.
Since the cacheable region size was no longer divisible by a large
power of 2, like 256 MB, this caused excessive use of MTRRs.
As first symptoms, slow boot with grub and poor user response.
As a solution, register the actual top of low ram with ram_resource(),
and do not subtract the UMA/TSEG regions from it.
TSEG may require further work as the original did not appear exactly
right to begin with. To have UMA as un-cacheable, use uma_resource().
Change-Id: I4ca99b5c2ca4e474296590b3d0c6ef5d09550d80
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1239
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Tested-by: build bot (Jenkins)
This instruction is being used in some debug VBIOSes. This implementation
doesn't even try to be accurate. Instead, it just increments the counter by a
fixed amount every time an rdtsc instruction in encountered, to avoid divides
by zero.
Imported from:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=c4b7e9d1c16797c3e4b1200b40aceab5696a7fb8
Change-Id: I8fba1a060c57ccb7bbd44aa321dd349bc56bf574
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1362
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
No need for the test, tomk is at most 1GB on these chipsets.
Even if there was no room, adjusting the memory resource would not
not divert accesses in the hardware from DRAM to PCI.
Change-Id: I2213b8d9d2e6ab8da8fd3e8081cc62bb05b6b316
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1369
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
No need for the test, tomk is top of low memory and always below 4GB.
Change-Id: Ifc8f29268b761aa9b07b578673236a673f0c70b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1368
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Hide some details of the resource allocator from rest of the world.
These should come in handy when fixing some aspects of MTRR setup.
Change-Id: I8acad98f25e56cd8bae64fb52539d81ce94f9c73
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1367
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
mainboard_config never worked right, at least not since we've had sconfig.
Hence, drop mainboard/<vendor>/<device>/chip.h and fix up the mainboards that
tried to use it anyways.
Change-Id: I7cd403ea188d8a9fd4c1ad15479fa88e02ab8e83
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1359
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Our driver infrastructure became more flexible recently.
Make use of it.
These are the low hanging fruits (files with 5 device
variants or more), but there are still lots of files
with less potential for deduplication.
Change-Id: If6b7be5046581f81485a511b150f99b029b95c3b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1358
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
We used a hard coded value for some reason. Don't do that, but use CMOS
instead.
Modelled after http://review.coreboot.org/#/c/443 to get bd82x6x in
sync.
Change-Id: I36d715310157b9f9074f2a1c80710f85833020b4
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1324
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
LX has two values that are usually automatically derived but can
be overridden, that were so far defined in each board's romstage.
These values, along with the toggle to enable override are now
part of LX's Kconfig. For boards that gave values but requested
autogeneration, the values are removed.
Further improvements: Figure out the various fields in PLLMSRlo
and make them sensible Kconfig options (instead of the hex value
it is now)
Change-Id: I8a17c89e4a3cb1b52aaceef645955ab7817b482d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1227
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Otherwise there is a flurry of TDP changes with suspend/resume
as the kernel powers devices off on suspend and brings them
back online in resume.
This also adds a mutex around the TDP operations since it is
split across two methods and can't just rely on being Serialized.
Change-Id: I7757d3ddad34ac985a9c8ce2fc202e2b2dcb2527
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1348
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Recent changes in EC/Vboot/U-boot have completely broken
the logging of developer and recovery modes.
Recovery mode may not be in VBNV, so if that is zero and
yet we are in recovery mode then assume it is there because
the button/key was pressed.
Since there may not be any actual developer mode switch
we look if option rom is loaded and the system is not
in recovery mode and consider that as developer mode.
Change-Id: I70104877b24de477217e1ff5b3a019aef22343ec
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will log if the ME is disabled or has an error.
1) disable ME via EC console: gpioset PCH_HDA_SDO 1
2) boot the device
3) read eventlog with "mosys eventlog list"
71 | 2012-07-13 10:10:55 | Management Engine | Disabled
Change-Id: I9f6ee452d2aea76e6a5ea2cd50a50ff36245692a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The required power MSRs are mirrored in MCHBAR so
it is possible to configure TDP at runtime via ASL.
This adds the required fields and a set of methods to
configure "TDP down" and "TDP nominal". It explicitly
does not support "TDP up" at the moment.
PSSS: method is added to assist in searching the _PSS
table for the appropriate entry that corresponds to the
desired max non-turbo ratio.
STND: Set TDP Down from Nominal. This will limit CPU to
the TDP down configuration by sequencing the required
changes in the right order.
STDN: Set TDP Nominal from Down. This will set the CPU
back to nominal configuration by sequencing the required
changes in the correct (reverse) order.
This does not introduce any functional changes and must
be paired with additional changes to be useful.
The current configured TDP can be checked to see that
the transition to/from a desired level is successful.
> mmio_read8 0xfed15f50
0x00 # TDP-Nominal
> mmio_read8 0xfed15f50
0x01 # TDP-Down
Change-Id: I31a2f30cc9d134cc5eee980ae9288ae45e71c6e6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1344
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The default TCC activation offset is 0, which means TCC
activation starts at Tj_max. For devices with limited
cooling ability it may be desired to lower TCC activation.
This adds an option that can be declared in the devicetree
to set the TCC activation to a non-zero value.
Enable tcc_offset=15 in devicetree.cb and build/boot
the BIOS and check that the value is set in the MSR:
> and $(shr $(rdmsr 0 0x1a2) 24) 0xf
0xf
Change-Id: I88f6857b40fd354f70fa9d5d9c1d8ceaea6dfcd1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1343
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Split this behavior out from PNOT() so the OS can
update _PPC limit without re-reading C-state tables.
Change-Id: I81b9111a4866f6b9916f74ac57a3caefaa77c565
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1342
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing NVS variable for PPCM will be used to
select a dynamic max P-state.
By itself this does not change existing behavior because
the NVS PPCM variable is initialized to zero.
PPCM can be tested by building and booting a modified BIOS
that sets gnvs->ppcm to a value greater than 1 and checking
from the OS that the P-state is limited to that value.
Change-Id: Ia7b3bbc6b84c1aa42349bb236abee5cc92486561
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will allow various teams to select which thermal sensor
will control the thermal zones.
Also add a method to notify the thermalzones of a change
so these threshold/sensor methods take effect.
Needs a modified BIOS that uses the NVS TMPS value in
the thermalzone to read a different sensor.
Then, use a kernel driver that contains the following:
/* Adjust temperature sensor id to 2 */
union acpi_object param;
struct acpi_object_list input;
param.type = ACPI_TYPE_INTEGER
param.integer.value = 2
input.count = 1;
input.pointer = ¶m;
acpi_evaluate_object(NULL, "\\TMPU", &input, NULL);
And ensure that the temperature sensor that is being
monitored switches to ID 2.
Change-Id: I6319741358ba31eb8a3dc635d64f3f0acf683386
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1340
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ME device was being sent EOP and the PCI device hidden during
coreboot so it was not available in the SMI finalize step.
This also flips the PCI vendor/device dword around for the match.
Boot on Panther Point with serial and SMI debugging enabled and see
that ME EOP message is sent and the device is hidden at end of
U-boot and before the kernel loads.
Finalizing Coreboot
SMI# #0
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
PM1_STS: TMROF
PM1_EN: 120
Starting kernel ...
Change-Id: I230038c62c50db2a1c94078c0a2a67bdc232440e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1338
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The LPC bus normally allocates the range for legacy devices,
0-0x1000. Some devices on LPC are above that range and need to
be accounted for. Check the decode range settings for addresses
> 0x1000 and reserve them.
Change-Id: Idba800d7cee3185296f29dd237ba306f3de8de55
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1337
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Events are logged for SMIs that trigger ACPI sleeps state
entry and when the power button press triggers an SMI such
as at the developer/recovery screens.
Generate ACPI sleep state events and power button
events and verify they show up in the log:
153 | 2012-06-23 17:12:59 | ACPI Enter | S5
184 | 2012-06-23 17:15:50 | ACPI Enter | S3
216 | 2012-06-23 17:28:58 | Power Button
Change-Id: Iba134d619780e459bce189d36d57844997ffb009
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1320
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Unfortunately the drive strength values are very much board
specific and different between mobile and desktop so we don't
try to do any fancy detection here but let it be specified
directly in the devicetree.
Change-Id: I66674bff0de04ecd088fb09afad1cf801a374df2
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1347
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to support the GSMI interface the SMI handler needs
to find and use the state save area from the same CPU that
initiated the SMI. In this case it is a synchronous SMI
resulting form an IO write to port 0xB2.
To find the right CPU state save area iterate over the region
until the "IO Misc Info" field reports the expected value and
then proceed to use that state save area.
This is needed because the coreboot SMI handler only executes on
one core, and that core is non-deterministic. It is likely that
the core executing the C SMM handler is not the same one that
actually did the IO write to 0xB2 and generated the SMI.
The GSMI parameter buffer is passed as a pointer to EBX in the
tate save area, and the GSMI command is extracted from EAX before
it is used as the return value.
This interface is tested by enabling CONFIG_GOOGLE_GSMI in the
kernel and generating events and verifying that they end up
in the event log.
159 | 2012-06-23 16:22:45 | Kernl Event | Clean Shutdown
184 | 2012-06-23 17:14:05 | Kernl Event | Oops
185 | 2012-06-23 17:14:05 | Kernl Event | Panic
Change-Id: Ic121ea69e9f50c88467c435e095c3e3629989806
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1317
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Read event routine didn't get the correct BIOS callout. So it could not get
the heap address. Then it would creat many warning in serial port.
Change-Id: Ia35601bda1579c7f726ed767d7be78713ac185d2
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1266
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The board has a marvell NIC, but the driver to disable NIC BIOS was adapted
from a Realtek 8168 driver. Rename to reflect the change.
Also hook up as driver, so coreboot can actually find it.
Change-Id: Ibdfd6074eb28ba537d68552a3346b06493cef2a6
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1355
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
One copy was slightly different, but all the differences were commented out
Change-Id: I3cc7b5621c681a1eb286f9b16ef3ebdce03abb6b
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1356
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
EHCI debug allows to send message with 8 bytes length, but
we're only sending one byte in each transaction. Buffer up
to 8 bytes to speed up debug output.
Change-Id: I9dbb406833c4966c3afbd610e1b13a8fa3d62f39
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1357
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
On SandyBridge systems configured to work with Panther Point the CPU
would wrongly be described as IvyBridge. Fix this issue and drop an
unneeded Kconfig variable at the same time.
Change-Id: I501a4fa00613e589cd315cfee61b2f9561dfcb4d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1335
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The linux kernel contains an SMI driver that was written by
me (Duncan) and upstreamed a couple years ago called GSMI.
This driver will format a parameter buffer and pass pointers
to this parameter buffer to the SMI handler. It uses this to
generate events for kernel shutdown reasons: Clean, Panic, Oops,
etc.
This function expects to be passed pointers into the SMM state
save area that correspond to the prameter buffer and the return
code, which are typically EAX and EBX.
The format of the parameter buffer is defined in the kernel
driver so we implement the same interface here in order to be
compatible.
GSMI_CMD_HANDSHAKE: this is an early call that it does to try
and detect what kind of BIOS is running.
GSMI_CMD_SET_EVENT_LOG: this contains a parameter buffer that
has event type and data. The kernel-specific events are
translated here and raw events are passed through as well which
allows any run-time event to be added for testing.
GSMI_CMD_CLEAR_EVENT_LOG: this command clears the event log.
First the gsmi driver must be enabled in the kernel with
CONFIG_GOOGLE_GSMI and then events can be added via sysfs
and events are automatically generated for various kernel
shutdown reasons.
These can be seen in the event log as the 'Kernel Event' type:
169 | 2012-06-23 15:03:04 | Kernl Event | Clean Shutdown
181 | 2012-06-23 16:26:32 | Kernl Event | Oops
181 | 2012-06-23 16:26:32 | Kernl Event | Panic
Change-Id: Ic0a3916401f0d9811e4aa8b2c560657dccc920c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1316
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When fixing the SMM state table for SandyBridge/IvyBridge CPUs
the wrong table was used for older 64bit capable CPUs.
Change-Id: Ia7dff21aa3f0e5aa61575634fc839777de6bef10
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1353
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a temporary workaround so the SPI bus can be accessed
at runtime in SMM code until the SPI opcode menu is used
properly.
Change-Id: I93d188c55b66d8dce49fa91a1de53ee195944b30
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1318
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is called from the SMI handler install because those
setup functions clear many of these registers.
Ensure that these events show up in the log as appropriate.
Example log output:
159 | 2012-06-23 14:31:54 | SUS Power Fail
160 | 2012-06-23 14:31:54 | System Reset
161 | 2012-06-23 14:31:54 | ACPI Wake | S5
Change-Id: I48c423c10ee7e6c2829bcc95f6cfabb4979c25a9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If a Chrome OS device is in developer mode log an event.
When the device is in recovery mode also log an event
and provide the recovery reason.
Enable developer mode and trigger recovery mode and
verify that the events are logged:
238 | 2012-06-23 17:31:56 | Chrome OS Developer Mode
239 | 2012-06-23 17:31:56 | Chrome OS Recovery Mode | User Requested from Developer Screen
Change-Id: I14d41f44e04fd91340569617c7314da7e35a154f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1321
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On both SandyBridge and IvyBridge BCLK is fixed at 100MHz. Have the
comment reflect that.
Change-Id: Ia81c3501dc3e68cf3143c3bc864dfbf88901f9f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1336
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
.. in case the system has pluggable CPUs or might come in different SKUs.
Change-Id: I7a7cd95b4de5dd78370355f448688e8d000434c1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is for GfxInitSview(GnbSview.c). It would create warning message if it
could not get VBIOS image.
Change-Id: I3b2726f612b4b7a237644a4b63b56efad52b7ab5
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The default return value should be AGESA_SUCCESS, which is zero. If it was set as TRUE,
the AGESA wrapper would think it was AGESA_UNSUPPORTED. That would make no sense. And it
would produce ASSERT warning in AGESA wrapper.
On my parmer board, with Engine sample processor, it can not create the correct DMI table.
Routine initlate will return AGESS_ERROR.
------Serial message---------
ASSERTION FAILED: file 'src/mainboard/amd/parmer/agesawrapper.c', line 427
DmiTable:100123c3, AcpiPstatein: 10010126, AcpiSrat:0,AcpiSlit:0, Mce:100111ba, Cmc:1001127c,Alib:1001ccd4, AcpiIvrs:0 in agesawrapper_amdinitlate
agesawrapper_amdinitlate failed: 5
-----------------------------
I believe the processor with acceptable name string will create the right DMI.
Change-Id: Ie86955cf9affffc964a7c9f4a2c63077ef2030de
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1350
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Remove the warning message from linux dmesg,
mtrr: your BIOS has configured as incorrect mask, fixing it.
Change-Id: I355509db12ab10c33b7c1c23e2c7c4783f30e67e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1349
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2048 * ONE_MB will cause warning,
src/northbridge/amd/agesa/family15tn/northbridge.c:667:50: warning: integer overflow in expression [-Woverflow]
I guess it will change the data type to signed integer.
I think the bit shifting is better.
Change-Id: I823f7ead1f7d622bf653cb3bf2ae2343f5e76805
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1263
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function is exported so it can be used in other
places that need similar relocation due to TSEG.
Change-Id: I68b78ca32d58d1a414965404e38d71977c3da347
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1310
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Date and time are mixed up:
microcode: updated to revision 0x12 date=2012-12-04
should be
microcode: updated to revision 0x12 date=2012-04-12
Change-Id: I85f9100f31d88bb831bef07131f361c92c7ef34e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1334
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
This patch extends the current smbios api to allow changing mainboard
serial and version during coreboot runtime. This is helpful if you
have an EEPROM etc. to access these informations and want to add
some quirks for broken hardware revision for the linux kernel.
This could be done via DMI_MATCH marco.
Change-Id: I1924a56073084e965a23e47873d9f8542070423c
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1232
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
coreboot used to pass some information to u-boot in the coreboot table
and other information in a modified flat device tree. Since the FDT code
was never upstreamed and removed from our tree, u-boot was changed to
get the information it needs from the coreboot table alone. However,
in the process of this change only the vboot shared data structure was
passed on by coreboot, so when u-boot tried to update the ChromeOS
specific ACPI entries, it would accidently overwrite the vboot data.
This patch passes on the ChromeOS specific ACPI data structure instead
of the vboot shared data. Another change to u-boot will teach it how
to get to the vboot shared data from there.
Change-Id: Ifbb64eafc0d9967887b4cdeebf97d0c4ce019290
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1282
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The LAPIC timer is running at BCLK (100MHz) on Sandy Bridge and Ivy
Bridge systems. However, the current timer code assumed that the clock
would run at 200MHz instead. This made all delays twice as long as
needed.
Change-Id: I41b1186daee11cfd9a25b3a9d5ebdeeb271293c7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1330
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This maintains a 32bit monotonically increasing boot counter
that is stored in CMOS and logged on every non-S3 boot when
the event log is initialized.
In CMOS the count is prefixed with a 16bit signature and
appended with a 16bit checksum.
This counter is incremented in sandybridge early_init which is
called by romstage. It is incremented early in order notice
when reboots happen after memory init.
The counter is then logged when ELOG is initialized and will
store the boot count as part of a 'System boot; event.
Reboot a few times and look for 'System boot' events in the
event log and check that they are increasing. Also verify
that the counter does NOT increase when resuming from S3.
171 | 2012-06-23 16:02:55 | System boot | 285
176 | 2012-06-23 16:26:00 | System boot | 286
182 | 2012-06-23 16:27:04 | System boot | 287
189 | 2012-06-23 16:31:10 | System boot | 288
Change-Id: I23faeafcf155edfd10aa6882598b3883575f8a33
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1315
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This standared SMBIOS 0able describes the location and format
of the event log to the OS and applications. In this case the
pointer is a 32bit physical address pointer to the log in
memory mapped flash.
Look for SMBIOS type15 entry with 'dmidecode -t 15'
Handle 0x0004, DMI type 15, 23 bytes
System Event Log
Area Length: 4095 bytes
Header Start Offset: 0x0000
Header Length: 8 bytes
Data Start Offset: 0x0008
Access Method: Memory-mapped physical 32-bit address
Access Address: 0xFFB6F000
Status: Valid, Not Full
Change Token: 0x00000000
Header Format: OEM-specific
Supported Log Type Descriptors: 0
Change-Id: I1e7729e604000f197e26e69991a2867e869197a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MRC returns specific error codes; print the according error
message if we know what it means.
Change-Id: Iaaf1512b9d577d4291fccfb94d879043ab5b11b5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1289
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This was introduced when porting the SPI driver over from u-boot but it
is not needed. Hence drop the extra typedef and use device_t instead.
Change-Id: I3ab797a8e482d1c9aa1d004e488e99aeaffcdd8b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1331
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
The count was only incrementing for a wake from S5 and
it was not incrementing in the normal reboot case.
Change-Id: I73bc6db6bd02e6c4677f7e44a5c098c6dcb51747
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1328
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MCHBAR 0x5f10[7:0] should be set to 0x30 for ivybridge
and 0x20 for sandybridge. Move this code to ramstage
and set it per-chipset.
Power Aware Interrupt Routing is supported in ivybridge,
enable it and set fixed priority.
Boot on ivybridge device and read MCHBAR 0x5f10:
mmio_read8 0xfed15f10
0x30
And verify PAIR is enabled (bit4=1):
mmio_read8 0xfed15418
0x24
Change-Id: If017d5ce2bd5ab5092c86f657434f2b645ee6613
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1303
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CPUs with configurable TDP will run the TSC at the max non-turbo
ratio for the maximum TDP value, which can cause issues if another
TDP is desired. To deal with this we set the flex ratio to the
nominal TDP ratio early in the boot and then configure the Soft
Reset Data registers so the PCH can tell the CPU what frequency
to run at after a reset.
This is done very early in the bootblock because it is necessary
to reset the system after setting a flex ratio.
The end result is that the TSC will now increment at the max
non-turbo frequency for the nominal TDP.
On some system with 1.8GHz CPU ensure that the kernel
detects the CPU speed as ~1800mhz rather than ~2300mhz:
> dmesg | grep "MHz processor"
[ 0.004000] Detected 1795.801 MHz processor.
Change-Id: I8436dced9199003b6423186a2b041e3f7b84ab8c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are enough differences that it is worth defining the
proper map for the sandybridge/ivybridge CPUs. The state
save map was not being addressed properly for TSEG and
needs to use the right offset instead of pointing in ASEG.
To do this properly add a required southbridge export to
return the TSEG base and use that where appropriate.
Change-Id: Idad153ed6c07d2633cb3d53eddd433a3df490834
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1309
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- add Kconfig option for CONFIG_SPI_FLASH_SMM
- compile subsystem and chip drivers for smm if enabled
- change mdelay(1) to udelay(500) since mdelay is not defined
in SMM and a 1ms delay is worth avoiding
- make flash chip structure non-const so the probe function
pointers can be relocated for use in TSEG
- Make SMM PCI access possible in southbridge SPI code
Change-Id: Icfcbbe8e4e56658769d46af0b5bf6c79a6432641
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1313
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is used by the SPI driver and ELOG.
It requires SMM TSEG and a _heap/_eheap region defined in the
linker script. The first time malloc is called in SMM the
start and end pointers to the heap region will be relocated
for the TSEG region.
Enable SPI flash and ELOG in SMM and successfully
allocate memory. The allocated addresses are verified
to be sure they are within the TSEG heap region:
smm.elf:00014000 B _eheap
smm.elf:00010000 B _heap
TSEG base is 0xad000000
Memory allocated in ELOG:
ELOG: MEM @0xad018030
Change-Id: I5cca38e4888d597cbbfcd9983cd6a7ae3600c2a3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1312
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is based around the SMBIOS event log specification but
expanded with OEM event types to support more specific and
relevant system events.
It requires flash storage and a minimum 4K block (or flash block
size) that should be allocated in the FMAP.
A copy of the event log is maintained in memory for convenience
and speed and the in-memory copy is written to flash at specific
points.
The log is automatically shunk when it reaches a configurable
full threshold in order to not get stuck with a full log that
needs OS help to clear.
ELOG implements the specification published here:
http://code.google.com/p/firmware-event-log/wiki/FirmwareEventLogDesign
And is similar to what we use in other firmware at Google.
This implementation does not support double-buffered flash
regions. This is done because speed is valued over the log
reliability and it keeps the code simpler for the first version.
This is a large commit and by itself it just provides a new
driver that is made available to coreboot. Without additional
patches it is not very useful, but the end result is an event
log that will contain entries like this:
171 | 2012-06-23 16:02:55 | System boot | 285
172 | 2012-06-23 16:02:55 | EC Event | Power Button
173 | 2012-06-23 16:02:55 | SUS Power Fail
174 | 2012-06-23 16:02:55 | System Reset
175 | 2012-06-23 16:02:55 | ACPI Wake | S5
Change-Id: I985524c67f525c8a268eccbd856c1a4c2a426889
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to support SPI and ELOG drivers the SMM region
needs to be able to be larger than the previous allocation
below 0x7400. Now that we have support for 4M TSEG we do
not need to live in this region.
This change adds a 16KB heap region abofe the save state area
at TSEG+64KB and moves the C handler above this.
The heap region is then available for malloc and the C handler
can grow to support flash and event log features.
While updating the memory map comment in assembly stub I also
added a pause instruction to the cpu spin lock as this was
added to the C code in latest upstream rebase.
Dump sympbols from smm.elf binary to see the new regions:
00010000 B _heap
00014000 B _eheap
00014000 T _smm_c_handler_start
0001b240 T _smm_c_handler_end
Change-Id: I45f0ab4df1fdef3b626f877094a58587476ac634
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1308
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The BWG says ivybridge current limit for PP1 is 50A.
Verify the PP1 current limit value on link device:
> echo $(( ( $(rdmsr 0 0x602) & 0x1fff ) >> 3 ))
50
Change-Id: I946269d21ef605f2525fe03993f569d69128294b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1305
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Ivybridge B0+ CPUs are capable of supporting multiple TDP levels.
This complicates the default case because now the registers that
were reporting max non-turbo ratio are reporting that value for
the highest possible TDP level.
For now this change just forces everything to use the Nominal TDP
values instead of the higher (or lower) levels.
- When building P-state tables, determine the P[1] (max non turbo)
ratio based on the Nominal ratio if available.
- Set the turbo activation ratio to the Nominal max ratio.
- Mirror the power level settings in new MCHBAR register after
they are written, which happens after BIOS_RESET_CPL is set.
- Set the current ratio to Nominal ratio at boot.
1) Verify that P-state table is generated properly with
P[0]=1801MHz (ratio 0x1C) and P[1]=1800MHz (ratio 0x12)
PSS: 1801MHz power 17000 control 0x1c00 status 0x1c00
PSS: 1800MHz power 17000 control 0x1200 status 0x1200
2) Verify power limits in MCHBAR match PKG_POWER_LIMIT:
> rdmsr 0 0x610
0x800080aa00dc8088
> mmio_read32 0xfed159a4
0x000080aa
> mmio_read32 0xfed159a0
0x00dc8088
3) Verify turbo activation ratio is set to nominal ratio:
> rdmsr 0 0x64c
0x0000000000000012
4) Check that proper ratio was set at boot on one core only:
> grep 'frequency set to' /sys/firmware/log
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
Change-Id: I592e60a7740f31b140986a8269dca91b4adbb270
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1304
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and don't require it to specify a cache type.
This function is only used on romcc boards, and should go away
(because all boards should be switched to CAR)
Change-Id: Ic32ca3be1afffc773c72c140e88b338d48a0c8ca
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1288
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Previous patches implemented stack overflow checking for the APs.
This patch builds on the BSP stack poisoning patch to implement
stack overflow checking for the BSP, and also prints out maximum
stack usage. It reveals that our 32K stack is ridiculously oversized,
especially now that the lzma decoder doesn't use a giant 16K on-stack
array.
Break the stack checking out into a separate function, which
we will later use for the APs.
CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8
To test failure, change the DEADBEEF stack poison value in c_start.S
to something else. Then we should get an error like this:
Stack overrun on BSP.Increase stack from current 32768 bytes
CPU0: stack from 00180000 to 00188000:Lowest stack address 00180000
Separate the act of loading from the act of starting the payload. This
allows us better error management and reporting of stack use. Now we
see:
CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8
Tested for both success and failure on Link. At the same time, feel free
to carefully check my manipulation of _estack.
Change-Id: Ibb09738b15ec6a5510ac81e45dd82756bfa5aac2
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1286
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ME needs to be talked to through the PCIe memory mapped config
space.
Change-Id: Ic2c5a572a126722a08a82d95df13d11507586c6b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1284
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The function acpi_get_vdat_info() was moved to the ChromeOS
vendor code, and is no longer required to be present for each
board. Hence, remove it.
Change-Id: I3dc8dbb6119ceffa057373bad7c0058ac0d40eb8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1283
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the short term there might be devices with Sandy Bridge CPUs
on mainboards with Panther Point PCHes. While this configuration
option is perfectly valid, coreboot currently ties Sandy Bridge to
Cougar Point and Ivy Bridge to Panther Point. One occurence is in
the ME handling code.
To make coreboot most flexible, compile both ME handlers into
coreboot and decide at runtime which one to use.
Change-Id: Icffe2930873f67c99c3f73e37e7a967f4f002b88
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1280
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- On Cougar Point there may have been stack corruption during the
ME hash verification
- On Panther Point the ME firmware hash was not passed on to the
OS
Change-Id: I73fc10db63ecff939833fb856a6da1e394155043
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Nothing is yet enabled, this is just a config skeleton change.
The MICROCODE_INCLUDE_PATH definition is going to be used by the
Makefile building the microcode blob for CBFS inclusion.
Change-Id: I7868db3cfd4b181500e361706e5f4dc08ca1c87d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1292
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Oxford PCIE Serial card has a hardcoded address at setup,
which may be moved during PCI Init. The driver re-initializes
after PCI init. Add a debug print for the new BAR address.
Initializing Oxford OXPCIe952
OXPCIe952: Class=70002 Revision ID=0
OXPCIe952: 2 UARTs detected.
OXPCIe952: Uart Bar: 0xe0800000
Change-Id: I1858d3eba09749cba3c3869060d00e621dca112a
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1327
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When microcode storage in CBFS is enabled, the make system is supposed
to generate the microcode blob and place it into the generated ROM
image as a CBFS component.
The microcode source representation does not change: it is still an
array of 32 bit constants. This new addition compiles the array into a
separate object file and then strips all sections but data.
The raw data section is then included into CBFS as a file named
'microcode_blob.bin' of type 0x53, which is assigned to microcode
storage.
Change-Id: I84ae040be52f520b106e3471c7e391e64d7847d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1295
Tested-by: build bot (Jenkins)
When CONFIG_MICROCODE_IN_CBFS is enabled, find the microcode blob in
CBFS and pass it to intel_update_microcode() instead of using the
compiled in array.
CBFS accesses in pre-RAM and 'normal' environments are provided
through different API.
Change-Id: I35c1480edf87e550a7b88c4aadf079cf3ff86b5d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1296
Tested-by: build bot (Jenkins)
The PCIe device enable function prints when it disables a device.
The PCIe ports(bridges) use a different routine that didn't print
the message. Add it to be consistent and to provide better debug
output.
Change-Id: I8462c48e7f4930db68703f0bfb710c01c9643a98
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1326
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
It's only used on AMD based boards. Hence drop it, so we don't
accidently start using it by mistake instead of MAX_CPUS
Change-Id: Id8f522f24283129874d56e70bd00df92abe9c3cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1325
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Changing CMOS value for power-on-after-power-fail was only honored
after reboot, which is counter intuitive (set from "enable" to
"disable",
power-off, replug device -> device turns on; and similar cases).
Modelled after http://review.coreboot.org/#/c/444
Change-Id: I2b8461dff1ae085c1ea4b4926084268b4da90321
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1323
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In preparation to support CBFS hosted microcode blobs, this change
renames the wrapper include file containing the microcode to be
independent of CPU model.
Change-Id: If1a4963a52e5037a3a3495b90708ffc08b23f4c1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1294
Tested-by: build bot (Jenkins)
