First copy over from SeaBIOS git repo, then adapt for coreboot:
Disable cpu/pci hotplug bits. Disable dynamic pci window.
Both depend on stuff in the SSDT tables created by SeaBIOS.
Bits are left in, but deactivated via #if 0, so it's easier
to see the differences when diffing the coreboot tables with
the SeaBIOS tables.
Adapt dsdt DefinitionBlock.
Enable acpi table generation in acpi_tables.c.
With this patch linux boots successfully with ACPI enabled.
It's not bug-free though. Missing cpu detection leads to
funky messages like this one:
weird, boot CPU (#0) not listed by the BIOS.
and SMP most likely wouldn't work either.
Change-Id: Ic3803a6f1ef6d54c11cc4ca3844d3032a374ae6b
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3342
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Port most of the functions found in ec/acpi/ec.c to ACPI Source Language
(ASL). These functions are used to control embedded controllers with the
standard ACPI interface (mostly through i/o ports 0x62 / 0x66).
The following methods are implemented and tested against the power
managements channels of a ITE IT8516E embedded controller:
* WAIT_EC_SC Wait for a bit in the EC_SC register
* SEND_EC_COMMAND Send one command byte to the EC_SC register
* SEND_EC_DATA Send one data byte to the EC_DATA register
* RECV_EC_DATA Read one byte of data from the EC_DATA register
* EC_READ Read one byte from ec memory (through cmd 0x80)
* EC_WRITE Write one byte to ec memory (through cmd 0x81)
To use the provided methods, one should include `ec/acpi/ec.asl` in the
EC device code. Prior doing so, two macros should be defined to identify
the used i/o ports:
* EC_SC_IO I/o address of the EC_SC register
* EC_DATA_IO I/o address of the EC_DATA register
Change-Id: I8c6706075fb4980329c228e5b830d5f4e9b188dd
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3285
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The DDI connector table and the PCIe Port List lookup table are
copied onto HEAP. This copy is not needed since these are lookup
tables used to define the platform configuration.
Change-Id: If4760f80e08faa8da4fd11337a3812f89cf805f9
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add CONST modifiers to read-only pass-by-reference function
parameters in AGESA. This allows the use of "const" modifiers
on the declaration of lookup tables that are pass-by-reference.
These will be used to identify tables that are copied onto the
HEAP but don't need to be.
Change-Id: Ie1187a427804fddf47b935a110ad23931a3447a9
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add boot cpu to the device tree. Figure the number of CPUs installed
(using the qemu firmware config interface) and add cpu devices for them,
so they show up in all generated BIOS tables correctly. This gets SMP
going.
Change-Id: I0e99f98942d8ca90150b27fc13c1c7e926a1a644
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds a qemu x86 cpu chip. It has no initialization function
as this isn't needed on virtual hardware. A virtual machine can have
pretty much any CPU: qemu emulates a wide range of x86 CPUs (try 'qemu
-cpu ? for a list), also with 'qemu -cpu host' the guest will see a cpu
which is (almost) identical to the one on the host machine. So I've
added X86_VENDOR_ANY as wildcard match for the cpu_table.
Change-Id: Ib01210694b09702e41ed806f31d0033e840a863f
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3344
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This driver communicates with the IT8516e on the Kontron KTQM77.
Since we don't know if the firmware and protocol are standard for
the chip or customized to the board, call it kontron/it8516e.
Change-Id: I7382172c6d865d60106c929124444821a07a5184
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3390
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ica3afbf8277cb025251da7af181f8de0d0036b45
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3389
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When I've first written this macro in 2011, the correct define for
verbose SMBus message was CONFIG_DEBUG_SMBUS_SETUP. This has since
been changed to CONFIG_DEBUG_SMBUS. I didn't catch that, and this made
the printsmbus macro always evaluate to an empty statement.
Use the proper CONFIG_DEBUG_SMBUS define. This makes printsmbus
functional again.
Change-Id: Iaf03354b179cc4a061e0b65f5b746af10f5d2b88
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3379
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Needed to make 'register "gpo" = ...' work.
While being at it add comments saying which device is which.
Change-Id: I911d5e4a7b6c7abf4ad73e863ab201e9e55ee0d4
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3346
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The qemu debugcon port returns 0xe9 on reads in case the device is
present. Use that for detection and write console output to the
port only in case the device is actually present.
Change-Id: I41aabcf11845d24004e4f795dfd799822fd14646
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3338
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
qemu has a special device to pass configuration information
from qemu to the firmware. This patch adds initial support
the interface, namely some infrastructure, detection code and
a function to query the number of CPUs.
Change-Id: I43ff5f4fbf12334a91422aa38f514a82a1d5219e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3343
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit eed28f97b3.
For whatever reason, the dependencies were lost in Gerrit and the
commit [1] was submitted without its dependencies. As a result
buidling the ASUS F2A85-M fails now [2] and therefore commits
based on this commit fail to pass the buid tests by Jenkins.
[…]
Created CBFS image (capacity = 8387656 bytes)
LINK cbfs/fallback/romstage_null.debug
CC cbfs/fallback/coreboot_ram.debug
coreboot-builds/asus_f2a85-m/generated/coreboot_ram.o:(.data+0x16b9c): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/coreboot_ram.debug] Error 1
make: *** Waiting for unfinished jobs....
coreboot-builds/asus_f2a85-m/mainboard/asus/f2a85-m/buildOpts.romstage.o:(.data+0x3d8): undefined reference to `GnbIommuScratchMemoryRangeInterface'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1
[…]
Therefore revert the commit to get the tree working again and
submit this patch with its dependencies again.
[1] http://review.coreboot.org/#/c/3317/
[2] http://qa.coreboot.org/job/coreboot-gerrit/6618/testReport/junit/(root)/board/i386_asus_f2a85_m/
Change-Id: I911755884da09eb0a0651b8db07ee2a32e6eaaaa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Do the setup for all PCI slots, not only the third.
Also remove the bogus message, as slot 3 may carry
any device, not only NICs.
This makes IRQ setup simliar to SeaBIOS.
SeaBIOS assignments (with patch for logging added,
and a bunch of pci devices for testing purposes):
PCI IRQ [piix]: bdf=00:01.3 pin=1 line=10
PCI IRQ [piix]: bdf=00:03.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:04.0 pin=1 line=11
PCI IRQ [piix]: bdf=00:05.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:06.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.0 pin=1 line=10
PCI IRQ [piix]: bdf=00:1d.1 pin=2 line=10
PCI IRQ [piix]: bdf=00:1d.2 pin=3 line=11
PCI IRQ [piix]: bdf=00:1d.7 pin=4 line=11
Coreboot assignments without this patch:
Assigning IRQ 11 to 0:3.0
Coreboot assignments with this patch:
Assigning IRQ 10 to 0:1.3
Assigning IRQ 11 to 0:3.0
Assigning IRQ 11 to 0:4.0
Assigning IRQ 10 to 0:5.0
Assigning IRQ 10 to 0:6.0
Assigning IRQ 10 to 0:1d.0
Assigning IRQ 10 to 0:1d.1
Assigning IRQ 11 to 0:1d.2
Assigning IRQ 11 to 0:1d.7
Change-Id: Ie96be39185f2f1cbde3c9fc50e29faff59c28493
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3334
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
X86EMU_DEBUG_TIMING is needed for producing i915tool
compatible output. So add its dependencies to the
i945’s Kconfig in order to be able to use X86EMU_DEBUG_TIMINGS,
which depends on HAVE_MONOTONIC_TIMER which
LAPIC_MONOTONIC_TIMER provides/selects.
Note that UDELAY_LAPIC is already selected by the Intel CPU.
Change-Id: Ie834ebc92e527eb186a92b39341ebd0a08889fb0
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3356
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch was made by listenning to what Ron Minnich told
me to do on #coreboot IRC channel on Freenode with my
adaptations on top.
i915tool is at https://code.google.com/p/i915tool/ ,
the one in coreboot is outdated.
Change-Id: I13cd684f4c290114836fbd7babd461153e8d6124
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3277
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The MARK_GRAPHICS_MEM_WRCOMB was spreading like a cancer
since it was defined in sandybridge. It is really
more of an x86 thing however, and we now have
three systems that can use it.
I considered making this more general, since it technically
can apply to PTE-based systems like ARM, and maybe we should.
But the 'WRCOMB' moniker is usually closely tied to the x86.
Change-Id: I3eb6eb2113843643348a5e18e78c53d113899ff8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3349
Tested-by: build bot (Jenkins)
After removing power and the CMOS Battery, putting it back
and booting coreboot we have:
# ./nvramtool -a
boot_option = Fallback
last_boot = Fallback
baud_rate = 115200
debug_level = Spew
hyper_threading = Enable
nmi = Enable
boot_devices = ''
boot_default = 0x40
cmos_defaults_loaded = Yes
lpt = Enable
volume = 0xff
tft_brightness = 0xbf
first_battery = Primary
bluetooth = Enable
The code for handling the invalid CMOS space in mainboard.c
is now useless and so it was removed.
Change-Id: Ic57a14eeeea861aa034cb0884795b0152757bf5b
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3335
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Early SMBUS code with similar functionality is duplicated for all
southbridges. Add a generic SMBus API (function declarations) designed to
unify the early SMBus structure.
This patch only adds the API. It does not implement any hardware-specific
bits.
Change-Id: I0861b7a3f098115182ae6de9f016dd671c500bad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/143
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MRS commands are used to tell the DRAM chip what timing and what
termination and drive strength to use, along with other parameters.
The MRS commands are defined by the DDR3 specification [1]. This
makes MRS commands hardware-independent.
MRS command creation is duplicated in various shapes and forms in any
chipset that does DDR3. This is an effort to create a generic MRS API
that can be used with any chipset.
This is used in the VX900 branch.
[1] www.jedec.org/sites/default/files/docs/JESD79-3E.pdf
Change-Id: Ia8bb593e3e28a5923a866042327243d798c3b793
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3354
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
While we had support for updating microcode on the VIA Nano CPUs for a
while now, we never included the actual microcode. Unlike, Intel and
AMD CPUs, VIA microcode is not available for download, and was
extracted from the vendor BIOS. It was not included in coreboot since
we never had explicit permission to do so. I have just received
confirmation from VIA that we can distribute the microcode.
Change-Id: I4c15b090cd2713cfe5dc6b50db777ff89dbc0f19
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3357
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Move the include before static inline int spd_read_byte().
Change-Id: I4cac4b1f55368041b067422d95c09208e15d0f2d
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3368
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This commit fixes problems if we build raminit.c
for romstage.
Change-Id: Ic1380f3635ac28b939fa2a8ce614814012455c44
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3363
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to get rid of the bad #include "northbridge/amd/lx/raminit.c"
line we need to do some prepartion steps. This commit is one of them.
Change-Id: I33173660bbda8894e7672e41e1b994d254d7ae8a
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3362
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Take a Parmer board with 4G memory as an example.
Use 'cat /proc/meminfo' to check memory, it reads 'MemTotal 3327540kB'.
Parmer uses 512M as video memory when it has 4G.
3327540+512*1024 = 3851828(kB), so some memory is lost.
When Parmer has 4G memory, TOM2 low is 0x1F000000, TOM2 high is
0x00000001. But in e820 table or coreboot table, the last item is
6: 0000000100000000 - 0000000118000000 = 1 RAM
This is not correct, it should be
6: 0000000100000000 - 000000011f000000 = 1 RAM
This patch changes the memory layout when TOM2 is set.
Change-Id: I4e2d163ae8fe1e65ddc384b520a5112ca067b1d1
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3366
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This file was missing some definitions, so add them. Also turn the defines
into an enum. The reason for doing this is that functions can now
explicitly take an spd_memory_type as a parameter:
> int do_something_with_dram(enum spd_memory_type type, ...)
Which is a lot more explicit and readable than:
> int do_something_with_dram(u8 type, ...)
These are used in the VX900 branch.
Change-Id: Ic7871e82c2523a94eac8e07979a8e34e0b459b46
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3266
Tested-by: build bot (Jenkins)
Probably due to different (character) widths for a tab, sometimes only
one tab was used for aligning the define `CPU_ID_EXT_FEATURES_MSR`. For
the “correct” alignment, that means where a tab is eight characters,
two tabs are necessary. Change it accordingly.
Change-Id: I450a7796dc00b934b5a6bab8642db04a27f69f4b
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3263
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On Asus F2A85-M, the Linux kernel complains that the _CRS method does
not specify the number of PCI busses.
[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS
Just put there 256. This should be part of re-factoring of the whole
ACPI stuff.
The same change was already done for the AMD Brazos (SB800) boards,
based on commit »Persimmon DSDT: Add secondary bus range to PCI0«
(4733c647) [1].
[1] http://review.coreboot.org/2592
Change-Id: I06f90ec353df9198a20b2165741ea0fe94071266
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/3320
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
There is no need to use everywhere BIOS_ERR.
Change-Id: If33d72919109244a7c3bd96674a4e386c8d1a19e
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/3307
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Denis Carikli <GNUtoo@no-log.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add support for sending debug output to an I/O port.
It can be used together with QEMU's isa-debugcon driver to log the
coreboot output to a file. The port is configurable and defaults
to 0x402 which has established as the de facto standard. For example,
SeaBIOS+OVMF [1] use that one too.
[1] http://www.linux-kvm.org/page/OVMF
Open Virtual Machine Firmware
Change-Id: I0803f7fc70030242f80003e25c9449c37d71975e
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3331
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There were assumptions being made in the haswell
MP and SMM code which assumed the APIC id space
was 1:1 w.r.t. cpu number. When hyperthreading is
disabled the APIC ids of the logical processors
are all even. That means the APIC id space is sparse.
Handle this situation.
Change-Id: Ibe79ab156c0a171208a77db8a252aa5b73205d6c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3353
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's possible that the TOUUD can be set to less than
4GiB. When that is the case the size_k variable is
an extremely large value. Instead ensure TOUUD is greater
than 4GiB before adding said resources.
Change-Id: I456633d6210824e60665281538300fd15656b86d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3352
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Remove local copies of reading and writing I/O APIC registers by
using already available functions.
This change is similar to
commit db4f875a41
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Jan 31 17:24:12 2012 +0200
IOAPIC: Divide setup_ioapic() in two parts.
Reviewed-on: http://review.coreboot.org/300
and
commit e614353194
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Feb 26 17:24:41 2013 +0200
Unify setting 82801a/b/c/d IOAPIC ID
Reviewed-on: http://review.coreboot.org/2532
and uses `io_apic_read()` and `io_apic_write()` too. Define
`ACPI_EN` in the header file `pch.h`.
As commented by Aaron Durbin, a separate `pch_enable_acpi()` is
not needed: “The existing code path *in this file* is about enabling
the io apic.” [1].
[1] http://review.coreboot.org/#/c/3182/4/src/southbridge/intel/lynxpoint/lpc.c
Change-Id: I6f2559f1d134590f781bd2cb325a9560512285dc
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3182
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Remove local copies of reading and writing I/O APIC registers by
using already available functions.
This change is similar to
commit db4f875a41
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Jan 31 17:24:12 2012 +0200
IOAPIC: Divide setup_ioapic() in two parts.
Reviewed-on: http://review.coreboot.org/300
and
commit e614353194
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Feb 26 17:24:41 2013 +0200
Unify setting 82801a/b/c/d IOAPIC ID
Reviewed-on: http://review.coreboot.org/2532
and uses `io_apic_read()` and `io_apic_write()` too. Define
`ACPI_EN` in the header file `pch.h`.
As commented by Aaron Durbin, a separate `pch_enable_acpi()` is
not needed: “The existing code path *in this file* is about enabling
the io apic.” [1].
[1] http://review.coreboot.org/#/c/3182/4/src/southbridge/intel/lynxpoint/lpc.c
Change-Id: I4478b1902d09061ca1db8eab6b71fef388c7a74c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3183
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
From ISO C99 standard: »The placement of a storage-class specifier
other than at the beginning of the declaration specifiers in a
declaration is an obsolescent feature.«
Found at <http://www.approxion.com/?p=41>.
The following command was used to make the change.
$ git grep -l 'const static' src/ | xargs sed -i 's/const static/static const/'
As asked by Bruce Griffith, the changes in `src/vendorcode` were
reverted as that is what AMD prefers.
The same change was done already for AMD Persimmon in the following
commit.
commit 824e192809
Author: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Date: Wed Feb 20 21:24:20 2013 +0100
Persimmon: platform_cfg.h: Declare codec arrays as `static const`
Reviewed-on: http://review.coreboot.org/2474
Change-Id: I233c83fdc95ea4f83f7296c818547beb52366a3d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3197
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Some settings in the am335x Kconfig weren't actually used for anything, some
where place holders, and some where left over from another CPU. The memory
addresses are in the internal RAM in the SOC as described in the reference
manual. The stack is put where the internal ROM had its stack, and the
bootblock is put at the bottom of that region as the manual suggests. The
ROM stage offset is set to 10K which is a bit bigger than the ~7.5K the
bootblock currently takes up.
Change-Id: I1a117d789a791d7e3db1118823f8216b3361433c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3327
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Without that fix we have with CONFIG_USE_OPTION_TABLE:
OPTION cmos_layout.bin
build/util/nvramtool/nvramtool -y /home/gnutoo/x86/coreboot-alix/src/mainboard/pcengines/alix1c/cmos.layout -L build/cmos_layout.bin
make: *** No rule to make target `nvramtool', needed by `build/coreboot.pre1'. Stop.
rm build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c
That log was captured with make V=1 but the error also appear with make.
Tested on the PC Engines ALIX.1C with the following commit (Change-Id: Ia87b090) [1]:
PC Engines ALIX.1C: Add CMOS defaults.
[1] http://review.coreboot.org/#/c/3323/
Change-Id: I548005a58f430ed7b6da5249a24bbdcae440a1e9
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3223
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
- SPI controller base address gets overwritten by SD controller under Linux.
- Reason for overwrite is the SPI base address isn't in a standard BAR and doesn't
get automatically reserved. Solution is to add it as a reserved memory area in
ACPI.
- This issue was found on the ASUS F2A85-M platform. Currently a workaround on this
platform was made as part of: http://review.coreboot.org/#/c/3167/3
- Once approved a follow-on patch for other southbridges using a non-standard BAR for
the spi controller.
Change-Id: I1b67da3045729a6754e245141cd83c5b3cc9009e
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: http://review.coreboot.org/3270
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This issue can be reproduced in Linux by the following steps:
1) use pm-suspend to suspend.
2) use USB keyboard to wake up.
3) use pm-suspend to suspend. FAIL To SUSPEND.
The cause of this issue is:
USB devices use bit 11(0x0b) of GP0_STS represents S3 wake up event,
but this bit is not clear after wake up. So OS thinks there is a
wake up signal and wake up immediately.
In this patch, I add AcpiGpe0Blk using MMIO access and write 1
on bit 11. I have tested on Parmer.
Change-Id: Iec3078bf29de99683e7cd3ef4e178fbeb4dc09c1
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3347
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change `sizeof(type) * n`, where n is the number of array
elements, to `sizeof(variable)` to directly get the size of the
variable (struct, array). Determining the size by counting array
elements is error prone and unnecessary.
Rudolf Marek’s patch »ASUS F2A85-M: Correct and clean up PCIe
config« [1] contains the same change and is ported over. In
the commit message Rudolf makes the following comment.
»Not sure why the copy is needed instead of direct reference.
Maybe it has something to do with CAR?«
Testing on the ASRock E350M1, no regressions were noticed.
[1] http://review.coreboot.org/#/c/3194/
Change-Id: I123031b3819a10c9c85577fdca96c70d9c992e87
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3248
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Change `sizeof(type) * n`, where n is the number of array
elements, to `sizeof(variable)` to directly get the size of the
variable (struct, array). Determining the size by counting array
elements is error prone and unnecessary.
Not sure why the copy is needed instead of direct reference.
Maybe it has something to do with CAR?
These changes are based on Rudolf’s original patch »ASUS F2A85-M:
Correct and clean up PCIe config« [1], where it was just done for
the ASUS board.
[1] http://review.coreboot.org/#/c/3194/
Change-Id: I4aa4c6cde5a27b7f335a71afc21d1603f2ae814b
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3247
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Extra care for the qemu vga should not be needed any more.
Since release 0.12 qemu loads the vgabios into the PCI ROM
bar, so everything works exactly like it does on real hardware.
Change-Id: I4b9bf1244cad437cbe5168600aeee52031456033
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3333
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Initial structure of Beaglebone port
Change-Id: Ia255ab207f424dcd525990cdc0d74953e012c087
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This allows other boards to have the same choice block without confusing
kconfig.
Change-Id: Iea5a7f2d1c263aa7992f504b832ca9c862833c3f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3293
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
multiply_to_tsc was being copied everywhere, which is bad
practice. Put it in the tsc.h include file where it belongs.
Delete the copies of it.
Per secunet, no copyright notice is needed.
This might be a good time to get a copyright notice into tsc.h
anyway.
Change-Id: Ied0013ad4b1a9e5e2b330614bb867fd806f9a407
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3242
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Commit »haswell: 24MHz monotonic time implementation« (c46cc6f1) [1]
added the Kconfig variable `MONOTONIC_TIMER_MSR` with a help text,
but only used one space instead of the suggested two spaces for
indentation. So add one space.
»Lines under a "config" definition are indented with one tab, while
help text is indented an additional two spaces.« [2]
[1] http://review.coreboot.org/3153
[2] https://www.kernel.org/doc/Documentation/CodingStyle
(Chapter 10: Kconfig configuration files)
Change-Id: I39cf356bfd54c66a2f1b837c6667dcc915e41f29
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3262
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Currently code in `udelay.c` differs between the Intel northbridges
GM45, 945 on the one hand and Sandy Bridge on the other hand.
The reason for this is that a wrong comparison > was used.
The following commit
commit 784ffb3db6
Author: Sven Schnelle <svens@stackframe.org>
Date: Tue Jan 10 12:16:38 2012 +0100
i945: fix tsc udelay()
Reviewed-on: http://review.coreboot.org/530
fixed the sign from > to <, whereas Stefan Reinauer changed it from
> to <= before adding the Sandy Bridge port in the following commit.
commit 00636b0dae
Author: Stefan Reinauer <stefan.reinauer@coreboot.org>
Date: Wed Apr 4 00:08:51 2012 +0200
Add support for Intel Sandybridge CPU (northbridge part)
Reviewed-on: http://review.coreboot.org/854
As there are no technical reasons for this difference, unify this
between the chipsets. See the discussion of the other patch set in
Gerrit [1].
[1] http://review.coreboot.org/#/c/3220/1/src/northbridge/intel/i5000/udelay.c
Change-Id: I64f2aa1db114ad2e9f34181c5f3034f6a8414a11
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3259
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Add debug output for the timing values of the edges found during
read and write training.
Now, output for one DIMM of DDR3-1066 in a roda/rk9 looks like:
[...]
Lower bound for byte lane 0 on channel 0: 0.0
Upper bound for byte lane 0 on channel 0: 8.4
Final timings for byte lane 0 on channel 0: 4.2
Lower bound for byte lane 1 on channel 0: 0.0
Upper bound for byte lane 1 on channel 0: 10.2
Final timings for byte lane 1 on channel 0: 5.1
Lower bound for byte lane 2 on channel 0: 0.0
Upper bound for byte lane 2 on channel 0: 7.5
Final timings for byte lane 2 on channel 0: 3.6
Lower bound for byte lane 3 on channel 0: 0.0
Upper bound for byte lane 3 on channel 0: 11.4
Final timings for byte lane 3 on channel 0: 5.6
Lower bound for byte lane 4 on channel 0: 0.0
Upper bound for byte lane 4 on channel 0: 9.4
Final timings for byte lane 4 on channel 0: 4.6
Lower bound for byte lane 5 on channel 0: 0.0
Upper bound for byte lane 5 on channel 0: 11.2
Final timings for byte lane 5 on channel 0: 5.5
Lower bound for byte lane 6 on channel 0: 0.0
Upper bound for byte lane 6 on channel 0: 8.4
Final timings for byte lane 6 on channel 0: 4.2
Lower bound for byte lane 7 on channel 0: 0.0
Upper bound for byte lane 7 on channel 0: 10.4
Final timings for byte lane 7 on channel 0: 5.2
Lower bound for group 0 on channel 0: 1.7.5
Upper bound for group 0 on channel 0: 2.2.2
Final timings for group 0 on channel 0: 1.10.7
Lower bound for group 1 on channel 0: 1.6.1
Upper bound for group 1 on channel 0: 2.0.2
Final timings for group 1 on channel 0: 1.9.1
Lower bound for group 2 on channel 0: 2.0.7
Upper bound for group 2 on channel 0: 2.8.1
Final timings for group 2 on channel 0: 2.4.4
Lower bound for group 3 on channel 0: 2.4.7
Upper bound for group 3 on channel 0: 3.0.0
Final timings for group 3 on channel 0: 2.8.3
[...]
Final timings are always the average of the two bounds. The last dots
separate eights (not decimals) and the middles are elenvenths or twelfths
depending on the clock speed (twelfths in this case).
Change-Id: Idb7c84b514716c7265b94890c39b7225de7800dc
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3257
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We halted the machine on any overflow during the write training.
However, overflows during the search for a good to bad edge are
non-fatal, and should be ignored.
Change-Id: I45ccbabc214e208974039246d806b0d2ca2fdc03
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3256
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Split some code in individual functions. It's the refactoring part of
a bigger change, following...
Change-Id: Id19be4588ad8984935040d9bcba4d7c5f2e1114f
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3255
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We halted the machine on any overflow during the read training. However,
overflows during the search for a good to bad edge are non-fatal, and
should be ignored.
Change-Id: I77085840ade25bce955480689c84603334113d1f
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3254
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Split some code in individual functions. It's the refactoring part of
a bigger change, following...
Change-Id: Ied551a011eaf22f6f8f6db0044de3634134f0b37
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3253
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When configuring the GTT size for the integrated graphics, the state
of VT-d was read wrong. Bit 48 of CAPID0 (D0F0) is set when VT-d is
_disabled_.
In the log of a VT-d enabled roda/rk9 we have now:
[...]
VT-d enabled
[...]
IGD decoded, subtracting 32M UMA and 4M GTT
[...]
Without this patch, only 2M GTT were reported.
Change-Id: I87582c18f4769c2a05be86936d865c0d1fb35966
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3252
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's a copy from i945 and looks like not beeing included in a
build at all.
If you should ever want to use that file for the Intel 5000,
please copy it from another chipset like the Intel 945 as it
is going to be improved.
Change-Id: I5c113bb0b2fed7b93feb3dcb1b5d962e1442963a
Reported-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3219
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Apparently the files `smbus.{h,c}`, where never used and therefore
build beforehand. Needing one function in them for the ASUS F2A85-M
the build fails as some headers are missing. Including the headers
`stdint.h` and `io.h` fixes the following errors.
[…]
CC southbridge/amd/agesa/hudson/smbus.romstage.o
In file included from src/southbridge/amd/agesa/hudson/smbus.c:23:0:
src/southbridge/amd/agesa/hudson/smbus.h:67:24: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:67:43: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:67:55: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:68:25: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:68:44: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:68:56: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:68:69: error: unknown type name 'u8'
src/southbridge/amd/agesa/hudson/smbus.h:69:24: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:69:43: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:70:24: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:70:43: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:70:55: error: unknown type name 'u8'
src/southbridge/amd/agesa/hudson/smbus.h:71:20: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:71:35: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:71:49: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:71:59: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:71:69: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:72:20: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:72:35: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:72:49: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:72:59: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:73:20: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:73:32: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:73:44: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.h:73:54: error: unknown type name 'u32'
src/southbridge/amd/agesa/hudson/smbus.c: In function 'smbus_delay':
src/southbridge/amd/agesa/hudson/smbus.c:27:2: error: implicit declaration of function 'outb' [-Werror=implicit-function-declaration]
src/southbridge/amd/agesa/hudson/smbus.c:27:2: error: implicit declaration of function 'inb' [-Werror=implicit-function-declaration]
[…]
Probably all the (AMD(?)) `smbus.{h,c}` suffer from this and
should be fixed. Even better, as these function do not differ
between most boards, the file should be moved out from the
specific southbridge directories.
[1] http://qa.coreboot.org/job/coreboot-gerrit/6168/testReport/junit/(root)/board/i386_asus_f2a85_m/
Change-Id: I285101fa06a365da44fa27b688c536e614d57f50
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3202
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Currently the code in the if statement
if (!byte)
do_smbus_write_byte(0xb20, 0x15, 0x3, byte);
only gets executed if `byte == 0x0`, that means only in the
default case where RAM voltage is 1.5 Volts. But the RAM voltage
should be changed when configured for the non-default case.
So negate the predicate to alter the RAM voltage for the
non-default cases.
To prevent the build error
OBJCOPY cbfs/fallback/coreboot_ram.elf
coreboot-builds/asus_f2a85-m/generated/crt0.romstage.o: In function `cache_as_ram_main':
/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/mainboard/asus/f2a85-m/romstage.c:106: undefined reference to `do_smbus_write_byte'
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/asus_f2a85-m/cbfs/fallback/romstage_null.debug] Error 1
add `southbridge/amd/agesa/hudson/smbus.c` providing the function
`do_smbus_write_byte` to ROM stage in `Makefile.inc`. That can
actually be used after the needed header files are included in a
previous commit.
Change-Id: I89542479c4cf6d412614bcf4586ea98e097328d6
Reported-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3200
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
This feature has not been used and was never fully integrated.
In the progress of cleaning up coreboot, let's drop it.
Change-Id: Ib40acdba30aef00a4a162f2b1009bf8b7db58bbb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3251
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The following commit
commit 05f3b117dd
Author: Paul Menzel <paulepanter@users.sourceforge.net>
Date: Tue May 14 09:28:26 2013 +0200
AMD Inagua: PlatformGnbPcie.c: Allocate exact needed size for buffer
Reviewed-on: http://review.coreboot.org/3246
changed one calculation for the size of the array PortList[] to
reflect only four elements, but neglected three additional calculations
of the size of the same table.
Correct that by setting the size for four array elements in all four
calculations.
[1] http://review.coreboot.org/#/c/3239/3/src/mainboard/amd/inagua/PlatformGnbPcie.c
Change-Id: Ib66b7b2b388d847888663e9eb6d1c8c9d50b9939
Reported-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3250
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The following commit
commit d0790694b0
Author: Kerry Sheh <shekairui@gmail.com>
Date: Thu Jan 19 13:18:37 2012 +0800
Inagua: Inagua GNB ddi lanes and pcie lanes config update
Reviewed-on: http://review.coreboot.org/544
assigns lanes 4 and 5 to PCI device number 4, but does not
adapt the rest of the code.
After the commit above, the array `PortList []` only has four
elements, but the buffer size `AllocHeapParams.RequestedBufferSize`
is set to a size as it still has five elements.
Correct that by setting the size for four array elements.
[1] http://review.coreboot.org/#/c/3239/3/src/mainboard/amd/inagua/PlatformGnbPcie.c
Change-Id: I3ff07f308ffd417d2bf73117eda9da2a1a05f199
Reported-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3246
Tested-by: build bot (Jenkins)
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
The haswell code allows for vboot ramstage verification.
However, that code path relies on accessing global cache-as-ram
variables after cache-as-ram is torn down. In order to avoid
that situation enable cache-as-ram migration.
cbmemc_reinit() no longer needs to be called from romstage
because it is invoked automatically by the cache-as-ram
migration infrastructure.
Change-Id: I08998dca579c167699030e1e24ea0af8802c0758
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3236
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Allow for automatic cache-as-ram migration for the cbmem
console. The code was refactored in the thought of making
it easier to read. The #ifdefs still exist, but they are no
longer sprinkled throughout the code. The cbmem_console_p
variable now exists globally in both romstage and ramstage.
However, the cbmem_console_p is referenced using the
cache-as-ram API. When cbmem is initialized the console
is automatically copied over by calling cbmemc_reinit()
through a callback.
Change-Id: I9f4a64e33c58b8b7318db27942e37c13804e6f2c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3235
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's possible that the vbnv global variables may be accessed
in romstage after cache-as-ram is torn down. Therefore use
the cache-as-ram migration API. Wrappers were written to
wrap the API to keep the existing code as close as possible.
Change-Id: Ia1d8932f98e00def0a44444a1ead0018a59d3d98
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3234
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As the TPM driver can be accessed in romstage after
cache-as-ram is torn down use the cache-as-ram migration
API to dynamically determine the global variable address.
Change-Id: I149d7c130bc3677ed52282095670c07a76c34439
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3233
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
Change-Id: I2e77219647c2bd2b1aa845b262be3b2543f1fcb7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3232
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
build-snow got broken when the snow makefile improved. So fix it.
While we're at it, create a script like the update-microcode
scripts that gets the bl1. I thought about making this a common
script but the various names and paths always evolve, leaving
me thinking it's not worth it. This script is just a
piece of the snow build script.
Change-Id: I65c0f8697a978c62fe12533c4f0152d14dbaefda
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3238
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
These arrays are declared as `static` for AMD SB800 based boards,
so do the same for this generation.
Rudolf Marek just changed `const CODEC_TBL_LIST` to `static const`
in [1]. Adapt all Fam15tn based boards (AMD Parmer, AMD Thatcher,
ASUS F2A85-M) to keep the differences between them small.
[1] http://review.coreboot.org/#/c/3170/3/src/mainboard/asus/f2a85-m/BiosCallOuts.c
Change-Id: I353b38bd8bc77ba500a4b7fe9250e9aa3071c530
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3198
Tested-by: build bot (Jenkins)
To make it easier to fill in the values, place the table
from the BIOS and Kernel Developer’s Guide (BKDG) [1]
as a comment.
[1] http://www.coreboot.org/Datasheets#AMD_Fam15
Change-Id: I218f76e9fa2dc88d47af51ea6c062e315afb0000
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3221
Tested-by: build bot (Jenkins)
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
Change-Id: Ie39b9eb565eb189676c06645bdf2a8720fe0636a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3207
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c). All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.
The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.
Note that the intention on when to yield a thread will be on
calls to udelay().
Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In `PlatformGnbPcie.c` AGESA functions are used to reserve memory
space to save the PCIe configuration to. This is the
With the following definitions in `AGESA.h`
$ more src/vendorcode/amd/agesa/f14/AGESA.h
[…]
/// PCIe port descriptor
typedef struct {
IN UINT32 Flags; /**< Descriptor flags
* @li @b Bit31 - last descriptor in complex
*/
IN PCIe_ENGINE_DATA EngineData; ///< Engine data
IN PCIe_PORT_DATA Port; ///< PCIe port specific configuration info
} PCIe_PORT_DESCRIPTOR;
/// DDI descriptor
typedef struct {
IN UINT32 Flags; /**< Descriptor flags
* @li @b Bit31 - last descriptor in complex
*/
IN PCIe_ENGINE_DATA EngineData; ///< Engine data
IN PCIe_DDI_DATA Ddi; ///< DDI port specific configuration info
} PCIe_DDI_DESCRIPTOR;
/// PCIe Complex descriptor
typedef struct {
IN UINT32 Flags; /**< Descriptor flags
* @li @b Bit31 - last descriptor in topology
*/
IN UINT32 SocketId; ///< Socket Id
IN PCIe_PORT_DESCRIPTOR *PciePortList; ///< Pointer to array of PCIe port descriptors or NULL (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST).
IN PCIe_DDI_DESCRIPTOR *DdiLinkList; ///< Pointer to array DDI link descriptors (Last element of array must be terminated with DESCRIPTOR_TERMINATE_LIST).
IN VOID *Reserved; ///< Reserved for future use
} PCIe_COMPLEX_DESCRIPTOR;
[…]
memory has to be reserved for the `PCIe_COMPLEX_DESCRIPTOR` and,
as two struct members are pointers to arrays with elements of type
`PCIe_PORT_DESCRIPTOR` and `PCIe_DDI_DESCRIPTOR`, space for these
times the number of array elements have to be reserved:
a + b * 5 + c * 2.
sizeof(PCIe_COMPLEX_DESCRIPTOR)
+ sizeof(PCIe_PORT_DESCRIPTOR) * 5
+ sizeof(PCIe_DDI_DESCRIPTOR) * 2;
But for whatever reason parentheses were put in there making this
calculation incorrect and reserving too much memory.
(a + b * 5 + c) * 2
So, remove the parentheses to reserve the exact amount of memory
needed.
The ASRock E350M1 still boots with these changes. No changes were
observed as expected.
Rudolf Marek made this change as part of his patch »ASUS F2A85-M:
Correct and clean up PCIe config« [1]. Factor this hunk out as it
affects all AMD Brazos and Trinity based boards.
[1] http://review.coreboot.org/#/c/3194/
Change-Id: I32e8c8a3dfc5e87eb119eb17719d612e57e0817a
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3239
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Revert commit f90071faee [1] as
it was merged without its dependencies and therefore the source
tree currently does not build [2][3].
OPTION option_table.h
GEN build.h
SCONFIG mainboard/pcengines/alix1c/devicetree.cb
CC arch/x86/lib/cbfs_and_run.romstage.o
CC arch/x86/lib/memcpy.romstage.o
CC arch/x86/lib/memset.romstage.o
CC arch/x86/lib/rom_media.romstage.o
CC arch/x86/lib/romstage_console.romstage.o
CC console/die.romstage.o
CC console/post.romstage.o
CC console/vtxprintf.romstage.o
CC device/device_romstage.romstage.o
CC lib/cbfs.romstage.o
CC lib/compute_ip_checksum.romstage.o
CC lib/gcc.romstage.o
CC lib/lzma.romstage.o
CC lib/memchr.romstage.o
CC lib/memcmp.romstage.o
CC lib/memmove.romstage.o
CC lib/ramtest.romstage.o
CC lib/uart8250.romstage.o
CC southbridge/amd/cs5536/smbus.romstage.o
ROMCC generated/bootblock.inc
GEN generated/bootblock.ld
make: *** No rule to make target `nvramtool', needed by `coreboot-builds/pcengines_alix1c/coreboot.pre1'. Stop.
make: *** Waiting for unfinished jobs....
OPTION cmos_layout.bin
[1] http://review.coreboot.org/#/c/3229/
[2] http://www.coreboot.org/pipermail/coreboot/2013-May/075864.html
[3] http://qa.coreboot.org/job/coreboot-gerrit/6251/testReport/junit/(root)/board/i386_pcengines_alix1c/
Change-Id: I4764d90c39ccdb4dc7e7a9aef7525c306614e1a8
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3245
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This was an early bring-up reference board for ULT but it is no
longer being worked on and was never complete enough to be useful
and I no longer have a board so it is already stale and untested.
All ULT bring-up work has moved to the wtm2 mainboard instead.
Change-Id: If64d61bf7a3fc8c9e16096ffc28fa4128aa99477
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3231
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This continues the work done in patch 6b908d08abhttp://review.coreboot.org/#/c/1685/
and makes the early x86 post codes follow the same options.
Change-Id: Idf0c17b27b3516e79a9a53048bc203245f7c18ff
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3237
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The format of this function changed but was not updated in
all mainboards. This fixes BaskingRidge and WTM2.
The int15 handler no longer takes a regs structure as an
argument and instead uses global variables. The yabel interface
is now similar enough that we can drop the duplicate handler.
Change-Id: Ia717ae14f99cee6d83ccdb1e26b9d7defe1638c4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48896
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3230
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This option has never had much if any use. It solved a problem over 10
years ago that resulted from an argument over the value or lack thereof
of including all the debug strings in a coreboot image. The answer is
in: it's a good idea to maintain the capability to print all messages,
for many reasons.
This option is also misleading people, as in a recent discussion, to
believe that log messges are controlled at build time in a way they are
not. For the record, from this day forward, we can print messages at all
log levels and the default log level is set at boot time, as directed by
DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and
if you are having trouble override it in CMOS and get more messages.
Besides, a quick glance shows it's always set to max (9 in this case) in
the very few cases (1) in which it is set.
Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3188
Tested-by: build bot (Jenkins)
In the process of streamlining coreboot code and getting
rid of unneeded ifdefs, drop a number of unneeded checks
for the GNU C compiler. This also cleans up x86emu/types.h
significantly by dropping all the duplicate types in there.
Change-Id: I0bf289e149ed02e5170751c101adc335b849a410
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3226
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The macros GNB_GPP_PORTx_PORT_PRESENT, GNB_GPP_PORTx_SPEED_MODE,
GNB_GPP_PORTx_LINK_ASPM and GNB_GPP_PORTx_CHANNEL_TYPE are not used.
Change-Id: I5c7b7d45880367dba452ebcd4f01fbd0c15aac22
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/3087
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Nothing from the header `console.h` is needed in `udelay.c`, so do
not include it.
This header was included since commit
»Add Intel i5000 Memory Controller Hub« (17670866) [1].
[1] http://review.coreboot.org/491
Change-Id: Ie136a1b862b55c9471f9293ed616ce27a1d01a50
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3218
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Gerd Hoffmann