Fix the following warnings detected by checkpatch.pl:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: plain inline is preferred over __inline__
TEST=Build and run on Galileo Gen2
Change-Id: I8ba98dfe04481a7ccf4f3b910660178b7e22a4a7
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18863
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: space required before the open parenthesis '('
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that close parenthesis ')'
ERROR: space prohibited after that open square bracket '['
ERROR: space required after that ',' (ctx:VxV)
ERROR: space prohibited before that ',' (ctx:WxW)
ERROR: space required after that ';' (ctx:VxV)
ERROR: spaces required around that ':' (ctx:ExV)
ERROR: spaces required around that ':' (ctx:VxW)
ERROR: spaces required around that ':' (ctx:WxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: spaces required around that '+=' (ctx:VxV)
ERROR: spaces required around that '<=' (ctx:WxV)
ERROR: spaces required around that '||' (ctx:VxW)
ERROR: space prohibited before that '++' (ctx:WxO)
ERROR: need consistent spacing around '+' (ctx:WxV)
ERROR: spaces required around that '<' (ctx:WxV)
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: need consistent spacing around '>>' (ctx:WxV)
ERROR: "(foo*)" should be "(foo *)"
ERROR: "foo* bar" should be "foo *bar"
ERROR: "foo * bar" should be "foo *bar"
ERROR: code indent should use tabs where possible
WARNING: space prohibited between function name and open parenthesis '('
WARNING: unnecessary whitespace before a quoted newline
WARNING: please, no spaces at the start of a line
WARNING: please, no space before tabs
WARNING: Unnecessary space before function pointer arguments
TEST=Build and run on Galileo Gen2
Change-Id: I2d7e1a329c6b2e8ca9633a97b595566544d7fd33
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: open brace '{' following function declarations go on the next line
ERROR: that open brace { should be on the previous line
ERROR: else should follow close brace '}'
WARNING: braces {} are not necessary for any arm of this statement
WARNING: braces {} are not necessary for single statement blocks
TEST=Build and run on Galileo Gen2
Change-Id: I13d1967757e106c8300a15baed25d920c52a1a95
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18861
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
GPIO edge interrupts can report that they are ActiveBoth and will
generate an interrupt event on both rising and falling edges.
Add a macro so this type of GPIO interrupt can be used.
BUG=b:35581264
BRANCH=none
TEST=successfully use this interrupt type on Eve
Change-Id: I91408386538e442bddcacc9840e0aa14370a446c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18834
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Switch some IRQ_* macros to ACPI_IRQ_* instead so they do not
fail at compile time if they are used.
BUG=b:35581264
BRANCH=none
TEST=successfully compile with ACPI_GPIO_IRQ_LEVEL_HIGH
Change-Id: Id4040eca4c7c9d8f7b4f0add411d5d6fe5ed1eb8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18833
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Add the missing macro for ACPI_IRQ_LEVEL_HIGH so it can get
used by devicetree when necessary.
BUG=b:35585307
BRANCH=none
TEST=Add rt5514 SPI device with active high level IRQ on Eve board
and check that it is enumerated in the kernel
Change-Id: I25c7b035a198efb218f0f6b4ba3f4a1bf532bcea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18815
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The newly assigned ACPI ID for coreboot is 'BOOT'
http://www.uefi.org/acpi_id_list
Use this new range of ACPI IDs of "BOOTxxxx" for coreboot specific
ACPI objects instead of the placeholder range of "GOOGCBxx".
Change-Id: I10b30b5a35be055c220c85b14a06b88939739a31
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18521
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ie0d35c693ed5cc3e890279eda289bd6d4416d9e6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/18376
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to allow GPIOs to be set/clear according to their polarity,
provide helper functions that check for polarity and call set/clear
SoC functions for generating ACPI code.
BUG=None
BRANCH=None
TEST=Verified that the ACPI code generated remains the same as before
for reef.
Change-Id: Ie8bdb9dc18e61a4a658f1447d6f1db0b166d9c12
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18427
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This is done to avoid any conflicts with same IRQ enums defined by other
drivers.
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: I539831d853286ca45f6c36c3812a6fa9602df24c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18444
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using x86 RDRAND instruction, two functions are supplied to
generate a 32bit or 64bit number.
One potential usage is the sealing key generation for SGX.
BUG=chrome-os-partner:62438
BRANCH=NONE
TEST=Tested on Eve to generate a 64bit random number.
Change-Id: I50cbeda4de17ccf2fc5efc1fe04f6b1a31ec268c
Signed-off-by: Robbie Zhang <robbie.zhang@intel.com>
Reviewed-on: https://review.coreboot.org/18362
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add individual macros for the various interrupt types so
they can be used in devicetree.
BUG=chrome-os-partner:58666
TEST=nothing uses this yet, will be used in an upcoming commit
Change-Id: I2a569f60fcc0815835615656b09670987036b848
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18392
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Move the function that adds a power resource block from
i2c/generic to the acpi device code at src/arch/x86/acpi_device.c
so it can be used by more drivers.
BUG=chrome-os-partner:61233
TEST=verify SSDT table generation is unchanged
Change-Id: I0ffb61a4f46028cbe912e85c0124d9f5200b9c76
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18391
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add a new callback to spi_ctrlr structure - get_config - to obtain
configuration of SPI bus from the controller driver. Also, move common
config definitions from acpi_device.h to spi-generic.h
BUG=chrome-os-partner:59832
BRANCH=None
TEST=Compiles successfully
Change-Id: I412c8c70167d18058a32041c2310bc1c884043ce
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18337
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The four options are only used in X86:
- BOOTBLOCK_SIMPLE
- BOOTBLOCK_NORMAL
- BOOTBLOCK_SOURCE
- SKIP_MAX_REBOOT_CNT_CLEAR
Move them all into src/arch/x86/Kconfig - this puts them in the chipset
menu instead of general setup.
Verified that this makes no significant changes to any config file.
Change-Id: I2798ef67a8c6aed5afac34322be15fdf0c794059
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17909
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Add VFCT table to provide PCI Optiom Rom for
AMD graphic devices.
Useful for GNU Linux payloads and embedded dual GPU systems.
Tested on Lenovo T500 with AMD RV635 as secondary gpu.
Original Change-Id: I3b4a587c71e7165338cad3aca77ed5afa085a63c
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Change-Id: I4dc00005270240c048272b2e4f52ae46ba1c9422
Reviewed-on: https://review.coreboot.org/18192
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This fixes building coreboot with -std=gnu11 on gcc 4.9.x
Also needs fix ups for asus/kcma-d8 and asus/kgpe-d16 due to the missing
type.
Change-Id: I920d492a1422433d7d4b4659b27f5a22914bc438
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18220
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
cmos_post_init() is called in src/arch/x86/bootblock_simple.c, and
that function is reponsible for bootstrapping the cmos post register
contents. Without this function being called none of the cmos post
functionality works correctly. Therefore, add a call to lib/bootblock.c
which the C_ENVIRONMENT_BOOTBLOCK SoCs use.
BUG=chrome-os-partner:61546
Change-Id: I2e3519f2f3f2c28e5cba26b5811f1eb0c2a90572
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18043
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
FSP v2.0 Driver supports TempRamInit & TempRamExit APIs to initialize
& tear down Cache-As-Ram. Add TempRamInit & TempRamExit usage to
ApolloLake SoC when CONFIG_FSP_CAR is enabled.
Verified on Intel Leaf Hill CRB and confirmed that Cache-As-Ram
is correctly set up and torn down using the FSP v2.0 APIs
without coreboot implementation of CAR init/teardown.
Change-Id: Ifd6fe8398ea147a5fb8c60076b93205bb94b1f25
Signed-off-by: Brenton Dong <brenton.m.dong@intel.com>
Reviewed-on: https://review.coreboot.org/17063
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
FSP v2.0 Specification adds APIs TempRamInit & TempRamExit for
Cache-As-Ram initialization and teardown. Add fsp2_0 driver
support for TempRamInit & TempRamExit APIs.
Verified on Intel Leaf Hill CRB and confirmed that Cache-As-Ram
is correctly set up and torn down using the FSP v2.0 APIs
without coreboot implementation of CAR init/teardown.
Change-Id: I482ff580e1b5251a8214fe2e3d2d38bd5f3e3ed2
Signed-off-by: Brenton Dong <brenton.m.dong@intel.com>
Reviewed-on: https://review.coreboot.org/17062
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Just before jumping to OS wakeup vector do the same
tasks to signal coreboot completion that would be done
before entry to payload on normal boot path.
Change-Id: I7514c498f40f2d93a4e83a232ef4665f5c21f062
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17794
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
This reverts commit c86da67436.
Alas, I have to disagree with this in every single line. The comment
added to the top of the file only applies to a single function therein
which sits over a hundred lines below. That's not much helpful. More-
over, the link in the comment is already down ofc.
The comment is also irritating as it doesn't state in which way (enco-
ding!) it applies to the code, which presumably led to the wrong in-
terpretation of the IDs.
At last, if anything should have changed it is the strings, the IDs
are resolved to. `smbios_fill_dimm_manufacturer_from_id()` has to
resolve the IDs it gets actually fed and not a random selection from
any spec.
Since I digged into it, here's why the numbers are correct: The func-
tion started with the SPD encoding of DDR3 in mind. There, the lower
byte is the number of a "bank" of IDs with an odd-parity in the upper
most bit. The upper byte is the ID within the bank. The "correction"
was to clear the parity bit for naught. The function was later exten-
ded with IDs in the DDR2-SPD encoding (which is actually 64-bit not
16). There, a byte, starting from the lowest, is either an ID below
127 plus odd-parity, or 127 which means look in the next byte/bank.
Unused bytes seem to be filled with 0xff, I guess from the 0xff2c.
Change-Id: Icdb48e4f2c102f619fbdca856e938e85135cfb18
Reviewed-on: https://review.coreboot.org/17873
Tested-by: build bot (Jenkins)
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Sometime preram cbmem logs are truncated due to lack of
space (default preram cbmem console size is 0xc00).
Provide Kconfig option to configure preram cbmem console
size so that mainboard can configure it to required value.
Change-Id: I221d9170c547d41d8bd678a3a8b3bca6a76ccd2e
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17839
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Create postcar_frame object without placing stack in CBMEM.
This way same cache_as_ram.inc code can be used unmodified.
Change-Id: Ic5ed404ce268ee881e9893dd434534231aa2bc88
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17700
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are circumstances where the APs need to run a piece of
code later in the boot flow. The current MP init just parks
the APs after MP init is completed so there's not an opportunity
to target running a piece of code on all the APs at a later time.
Therefore, provide an option, PARALLEL_MP_AP_WORK, that allows
the APs to perform callbacks.
BUG=chrome-os-partner:60657
BRANCH=reef
Change-Id: I849ecfdd6641dd9424943e246317cd1996ef1ba6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17745
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Doing PCI config operations via MMIO window by default is a
requirement, if supported by the platform. This means chipset
or CPU code must enable MMCONF operations early in bootblock
already, or before platform-specific romstage entry.
Platforms are allowed to have NO_MMCONF_SUPPORT only in the
case it is actually not implemented in the silicon.
Change-Id: Id4d9029dec2fe195f09373320de800fcdf88c15d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Resource allocator and 64-bit PCI BARs will need it and
PCI use is not really restricted to x86.
Change-Id: Ie97f0f73380118f43ec6271aed5617d62a4f5532
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17733
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MMCONF was explicitly used here to avoid races of 0xcf8/0xcfc access
being non-atomic and/or need to access 4kiB of PCI config space.
All these platforms now have MMCONF_SUPPORT_DEFAULT.
I liked the style of code in pci_mmio_cfg.h more, and used those to
replace the ones in io.h.
Change-Id: Ib5e6a451866c95d1edb9060c7f94070830b90e92
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17689
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Stash and reload postcar stage in the stage cache for increased
S3 resume speed. It's impact is small (2 ms or so), but there's
no need to go to the boot media on resume to reload something
that was already loaded. This aligns with the same paths we take
on ramstage as well.
Change-Id: I4313794826120853163c7366e81346858747ed0a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17649
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having callers query the romstage handoff resume
status by inspecting the object themselves add
romstage_handoff_is_resume() so that the same information
can be queried easily.
Change-Id: I40f3769b7646bf296ee4bc323a9ab1d5e5691e21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17647
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
When running with relocatable ramstage, the gdt loaded from c_start.S
is already in CBMEM (high memory). Thus, there's no need to create
a new copy of the gdt and reload.
Change-Id: I2750d30119fee01baf4748d8001a672d18a13fb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17504
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
On S3 resume path, CBMEM_ID_GDT already exists but we only printed
the final "ok" string. Always tell GDT is about to be moved.
Change-Id: Ic91c5389cf4d47d28a6c54db152c18541c413bc1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17500
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In function definition of acpigen_write_byte_buffer, buffer size written
using acpigen_emit_byte gives wrong results in generated AML code for
buffer size greater than one.
Write buffer size using acpigen_write_integer as per ACPI spec 5.0
section 20.2.5.4 BufferOp.
Change-Id: I0dcb25b24a1b4b592ad820c95f7c2df67a016594
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17444
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
acpigen_write_if_lequal is used to generate ACPI code to check if two
operands are equal, where operand1 is an ACPI op and operand2 is an
integer. Update name of function to reflect this and fix code to write
integer instead of emitting byte for operand2.
TEST=Verified by disassembling SSDT on reef that ACPI code generated for
If with operand2 greater than 1 is correct.
If ((Local1 == 0x02))
{
Return (0x01)
}
Else
{
Return (Buffer (One)
{
0x00 /* . */
})
}
Change-Id: If643c078b06d4e2e5a084b51c458dd612d565acc
Reported-by: Naresh G Solanki <naresh.solanki@intel.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17421
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add implementation to use actual requirements of ramstage size
for S3 resume backup in CBMEM. The backup covers complete pages of 4 KiB.
Only the required amount of low memory is backed up when ACPI_TINY_LOWMEM_BACKUP
is selected for the platform. Enable this option for AGESA and binaryPI, other
platforms (without RELOCATABLE_RAMSTAGE) currently keep their romstage ramstack
in low memory for s3 resume path.
Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Add acpigen_write_opregion that generates ACPI AML code for OperationRegion,
region name, region space, region length & region size are inputs.
Add acpigen_write_field that generates ACPI AML code for Field.
Operation region name & field list are inputs.
Change-Id: I578834217d39aa3b0d409eb8ba4b5f7a31969fa8
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17113
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Currently, the only supported DSM type is I2C
HID(3CDFF6F7-4267-4555-AD05-B30A3D8938DE). This provides the required
callbacks for generating ACPI AML codes for different function
identifiers for I2C HID.
BUG=chrome-os-partner:57846
Change-Id: Ia403e11f7ce4824956e3c879547ec927478db7b1
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17091
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add acpigen_write_dsm that generates ACPI AML code for _DSM
method. Caller should provide set of callbacks with callback[i]
corresponding to function index i of DSM method. Local0 and Local1
should not be used in any of the callbacks.
BUG=chrome-os-partner:57846
Change-Id: Ie18cba080424488fe00cc626ea50aa92c1dbb199
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17090
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since reading/toggling of GPIOs is platform-dependent task, provide an
interface with common functions to generate ACPI AML code for
manipulating GPIOs:
1. acpigen_soc_read_rx_gpio
2. acpigen_soc_get_tx_gpio
3. acpigen_soc_set_tx_gpio
4. acpigen_soc_clear_tx_gpio
Provide weak implementations of above functions. These functions are
expected to be implemented by every SoC that uses ACPI. This allows
drivers to easily generate ACPI AML code to interact GPIOs.
BUG=chrome-os-partner:55988
Change-Id: I3564f15a1cb50e6ca6132638447529648589aa0e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17080
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add functions to support generation of following AML operations:
1. PowerResource
2. Store
3. Or
4. And
5. Not
6. Debug
7. If
8. Else
9. Serialized method
BUG=chrome-os-partner:55988
Change-Id: I606736b38e6a55ffdc3e814b6ae0fa367ef7595b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17079
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Instead of using hard-coded values for emitting op codes and prefix
codes, define and use enum constants. With this change, it becomes
easier to read the code as well.
BUG=chrome-os-partner:55988
Change-Id: I6671b84c2769a8d9b1f210642f3f8fd3d902cca2
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17078
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Instead of hard-coding the polarity of the GPIO to active high/low,
accept it as a parameter in devicetree. This polarity can then be used
while calling into acpi_dp_add_gpio to determine the active low status
correctly.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that correct polarity is set for reset-gpio on reef.
Change-Id: I4aba4bb8bd61799962deaaa11307c0c5be112919
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16877
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Only acpi_dp of type DP_TYPE_TABLE is allowed to be an array. This
DP_TYPE_TABLE does not have a value which is written. Thus,
acpi_dp_write_array needs to start counting from the next element type
in the array. Fix this by updating the initialization in for loop for
writing array elements.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that the correct number of elements are passed for
add_gpio in maxim sdmode-gpio.
Change-Id: I8e1e540d66086971de2edf0bb83494d3b1dbd176
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16871
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Use the GOOG ACPI ID until there is an official ID allocation
for coreboot. Since I administer this range I allocated
0xCB00-0xCBFF for coreboot use.
Change-Id: I38ac0a0267e21f7282c89ef19e8bb72339f13846
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16724
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Add a function that can be implemented by the SOC to read
and clear the status of a single GPE. This can be used
during firmware to poll for interrupt status.
BUG=chrome-os-partner:53336
Change-Id: I551276f36ff0d2eb5b5ea13f019cdf4a3c749a09
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16669
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These values are found in util/cbfstool/cbfs.h.
Change-Id: Iea4807b272c0309ac3283e5a3f5e135da6c5eb66
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a function that can be implemented by the SOC to read
and clear the status of a single GPE. This can be used
during firmware to poll for interrupt status.
BUG=chrome-os-partner:53336
Change-Id: I536c2176320fefa4c186dabcdddb55880c47fbad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Implement postcar stage cbmem console support. The postcar stage
is more like ramstage in that RAM is already up. Therefore, in
order to make the cbmem console reinit flow work one needs the cbmem
init hook infrastructure in place and the cbmem recovery called.
This call is added to x86/postcar.c to achieve that. Additionally,
one needs to provide postcar stage cbmem init hook callbacks for
the cbmem console library to use. A few other places need to
become postcar stage aware so that the code paths are taken.
Lastly, since postcar is backed by ram indicate that to the
cbmem backing store.
BUG=chrome-os-partner:57513
Change-Id: I51db65d8502c456b08f291fd1b59f6ea72059dfd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16619
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The console_init(), MTRR printing, and loading ramstage
logic was previously all in assembly. Move that logic
into C code so that future features can more easily be
added into the postcar boot flow.
BUG=chrome-os-partner:57513
Change-Id: I332140f569caf0803570fd635d894295de8c0018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16618
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
I put in the decimal values for these instead of the hex values.
Instead of running them through a BCD converter, update them to use
the hex values.
Change-Id: I3fa46f055c3db113758f445f947446dd5834c126
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16567
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
In the current implementation of postcar_frame_add_mtrr,
if provided size is bigger than the base address alignment,
the alignment is considered as size and covered by the MTRRs
ignoring the specified size.
In this case the callee has to make sure that the provided
size should be smaller or equal to the base address alignment
boundary.
To simplify this, utilize additonal MTRRs to cover the entire
size specified. We reuse the code from cpu/x86/mtrr/mtrr.c.
Change-Id: Ie2e88b596f43692169c7d4440b18498a72fcba11
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16509
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
postcar_loader.c has a useful library of funtions for
setting up stack and MTRRs. Make it available in romstage
irrespective of CONFIG_POSTCAR_STAGE for use in stack setup
after Dram init.
The final step of moving the used and max MTRRs on to stack
is moved to a new function, that can be used outside of
postcar phase.
Change-Id: I322b12577d74268d03fe42a9744648763693cddd
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The field that was previously named 'efr' is actually the iommu feature
info field. The efr field is a 64-bit field that is only present in
type 11h or type 40h headers that follows the iommu feature info field.
Change-Id: I62c158a258d43bf1912fedd63cc31b80321a27c6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16508
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The revision field was correct, but the comment was wrong. The revision
1 means that the IVRS table only uses fixed length device entries.
Update the field to use the IVRS revision #define.
Change-Id: I4c030b31e3e3f0a402dac36ab69f43d99e131c22
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16507
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Avoid the inclusion of a function declaration if the argument type
device_t is not defined.
This was not a problem until now because the
old declaration of device_t and the new one overlapped.
Change-Id: I05a6ef1bf65bf47f3c6933073ae2d26992348813
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16404
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Generate an object to describe the coreboot table region in ACPI
with the HID "CORE0000" so it can be used by kernel drivers.
To keep track of the "CORE" HID usage add them to an enum and add
a function to generate the HID in AML: Name (_HID, "CORExxxx")
BUG=chromium:589817
BRANCH=none
TEST=build and boot on chell, dump SSDT to verify contents:
Device (CTBL)
{
Name (_HID, "CORE0000") // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
Memory32Fixed (ReadOnly,
0x7AB84000, // Address Base
0x00008000, // Address Length
)
})
}
Change-Id: I2c681c1fee02d52b8df2e72f6f6f0b76fa9592fb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16056
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
PCI root ports with "Address Translation Service" capability can be
reported in DMAR table in the ATSR scope to let the OS know how to
handle these devices the right way when VT-d is used.
Add code to create an entry for a PCI root port using the type
"SCOPE_PCI_SUB".
Change-Id: Ie2c46db7292d9f1637ffe2e9cfaf6619372ddf13
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15912
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
DMAR tables can contain so called "Address Translation Service Reporting"
(ATSR) structure. It is applicable for platforms that support
Device-TLBs and describe PCI root ports that have this ability.
Add code to create this ATSR structure.
In addition, a function to fix up the size of the ATSR
structure is added as this is a new type and using the function
acpi_dmar_drhd_fixup() can lead to confusion.
Change-Id: Idc3f6025f597048151f0fd5ea6be04843041e1ab
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15911
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a Kconfig value to enable the console during postcar. Add a call
to console_init at the beginning of the postcar stage in exit_car.S.
TEST=Build and run on Galileo Gen2
Change-Id: I66e2ec83344129ede2c7d6e5627c8062e28f50ad
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16001
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Display the MTRRs after they have been updated during the postcar stage.
TEST=Build and run on Galileo Gen2
Change-Id: I1532250cacd363c1eeaf72edc6cb9e9268a11375
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15991
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Quark does not support the rdmsr and wrmsr instructions. Use SOC
specific routines to configure the MTRRs on Quark based platforms.
Add cpu_common.c as a build dependency to provide access to the routine
cpu_phys_address_size.
TEST=Build and run on Galileo Gen2
Change-Id: I43b7067c66c5c55b42097937e862078adf17fb19
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15846
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Place a map file for the postcar stage and place it into
build/cbfs/fallback.
TEST=Build and run on Galileo Gen2
Change-Id: I349c06e3c610db5b3f2511083208db27110c34d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15845
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the ramstage files to the beginning of the section. Eliminate
duplicate conditionals.
TEST=Build and run on Galileo Gen2
Change-Id: I461a5b78a76bd0d2643b85973fd0a70bc5e89581
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15892
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the postcar commands to in between romstage and ramstage. Add the
stage header.
TEST=Build and run on Galileo Gen2
Change-Id: I530da6afd8ccbcea217995ddd27066df6d45de22
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15844
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The API called to write the name of the child table in the
dp entry (type ACPI_DP_TYPE_CHILD) was not including the
quotes, e.g., it was DAAD and not "DAAD". Thus, the kernel driver
did not get the right information from SSDT.
Change the API to acpigen_write_string() to fix the issue.
Signed-off-by: Harsha Priya <harshapriya.n@intel.com>
Change-Id: Id33ad29e637bf1fe6b02e8a4b0fd9e220e8984e7
Reviewed-on: https://review.coreboot.org/15724
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In the ACPI specification the PM1 register locations are well
defined, but the sleep type values are hardware specific. That
said, the Intel chipsets have been consistent with the values
they use. Therefore, provide those hardware definitions as well
a helper function for translating the hardware values to the
more high level ACPI sleep values.
BUG=chrome-os-partner:54977
Change-Id: Iaeda082e362de5d440256d05e6885b3388ffbe43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15666
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Instead of open coding the literal values provide more
semantic symbol to be used. This will allow for aligning
chipset code with this as well to reduce duplication.
BUG=chrome-os-partner:54977
Change-Id: I022bf1eb258f7244f2e5aa2fb72b7b82e1900a5c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15663
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There is a second ACPI _DSD document from the UEFI Forum that details
how _DSD style tables can be nested, creating a tree of similarly
formatted tables. This document is linked from acpi_device.h.
In order to support this the device property interface needs to be
more flexible and build up a tree of properties to write all entries
at once instead of writing each entry as it is generated.
In the end this is a more flexible solution that can support drivers
that need child tables like the DA7219 codec, while only requiring
minor changes to the existing drivers that use the device property
interface.
This was tested on reef (apollolake) and chell (skylake) boards to
ensure that there was no change in the generated SSDT AML.
Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15537
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Have acpigen_write_package() return a pointer to the package element
counter so it can be used for dynamic package generation where needed.
Change-Id: Id7f6dd03511069211ba3ee3eb29a6ca1742de847
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15536
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Have the different acpi_device_ path functions use a different static
buffer so they can be called interchangeably.
Change-Id: I270a80f66880861d5847bd586a16a73f8f1e2511
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15521
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a function for an SOC to define that will allow it to map the
SOC-specific gpio_t value into an appropriate ACPI pin. The exact
behavior depends on the GPIO implementation in the SOC, but it can
be used to provide a pin number that is relative to the community or
bank that a GPIO resides in.
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some of the support functions will be built for romstage
once HIGH_MEMORY_SAVE is removed.
Change-Id: I43ed9067cf6b2152a354088c1dcb02d374eb6efe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15242
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No need to make low memory backup unless we are on
S3 resume path.
Hide those details from ACPI.
Change-Id: Ic08b6d70c7895b094afdb3c77e020ff37ad632a1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15241
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Variable name shadows parameter name used on other functions,
and it can be local anyway after function removal.
Change-Id: I3164b15b33d877fef139f48ab2091e60e3124c3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15240
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add Ramaxel DRAM manufacturer id.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
The manufacturer name shows up in dmidecode.
Change-Id: I14cdc82c09f0f990e2ba18083748d11d79e53874
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15183
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is more of ACPI S3 resume and x86 definition than CBMEM.
Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15190
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This Kconfig is deprecated, new platforms need to locate
ramstage stack in CBMEM instead.
Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15189
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not all x86 architectures support the mm register set. The default
routine that saves BIST in mm0 and a "weak" routine that saves the TSC
value in mm2:mm1. Select the Kconfig value
BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to
save the BIST and timestamp values.
TEST=Build and run on Amenia and Galileo Gen2.
Change-Id: I8119e74664ac3522c011767d424d441cd62545ce
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15126
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use Kconfig values to enable debug spinloops in assembly_entry.S. This
makes it easy to debug the assembly code.
TEST=Build and run on Galileo Gen2
Change-Id: Ic56bf2260b8e3181403623961874c9289f3ca945
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Conditionally add a debug spinloop to enable easy connection of JTAG
debuggers.
TEST=Build and run on Galileo Gen2 with a JTAG debugger.
Change-Id: I7a21f9e6bfb10912d06ce48447c61202553630d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15127
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Support ROM_SIZE greater than 16 MiB. Work around SMBIOS rom size
limitation of 16 MiB by specifying 16 MiB as the ROM size.
TEST=Build and run on neoncity
Change-Id: I3f464599cd8a1b6482db8b9deab03126c8b92128
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15108
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Don't write reserved bits in the Quark platform. Follow the previous
boot behavior and just enable SSE.
TEST=Build and run on Galileo Gen2
Change-Id: Ib3143eff02b2610b595bd666c10d70e43103ccda
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15128
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Leave it for the platform to fill in the string.
Change-Id: I7b4fe585f8d1efc8c9743f0d8b38de1f98124aab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14996
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The recent ACPI specification extensions have formally defined a
method for describing device information with a key=value format that
is modeled after the Devicetree/DTS format using a special crafted
object named _DSD with a specific UUID for this format.
There are three defined Device Property types: Integers, Strings, and
References. It is also possible to have arrays of these properties
under one key=value pair. Strings and References are both represented
as character arrays but result in different generated ACPI OpCodes.
Various helpers are provided for writing the Device Property header
(to fill in the object name and UUID) and footer (to fill in the
property count and device length values) as well as for writing the
different Device Property types. A specific helper is provided for
writing the defined GPIO binding Device Property that is used to allow
GPIOs to be referred to by name rather than resource index.
This is all documented in the _DSD Device Properties UUID document:
http://uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
This will be used by device drivers to provide device properties that
are consumed by the operating system. Devicetree bindings are often
described in the linux kernel at Documentation/devicetree/bindings/
A sample driver here has an input GPIO that it needs to describe to
the kernel driver:
chip.h:
struct drivers_generic_sample_config {
struct acpi_gpio mode_gpio;
};
sample.c:
static void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_generic_sample_config *config = dev->chip_info;
const char *path = acpi_device_path(dev);
...
acpi_device_write_gpio(&config->mode_gpio);
...
acpi_dp_write_header();
acpi_dp_write_gpio("mode-gpio", path, 0, 0, 0);
acpi_dp_write_footer();
...
}
devicetree.cb:
device pci 1f.0 on
chip drivers/generic/sample
register "mode_gpio" = "ACPI_GPIO_INPUT(GPP_B1)"
device generic 0 on end
end
end
SSDT.dsl:
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionInputOnly,
"\\_SB.PCI0.GPIO", 0, ResourceConsumer) { 25 }
})
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"mode-gpio", Package () { \_SB.PCI0.LPCB, 0, 0, 1 }}
}
})
Change-Id: I93ffd09e59d05c09e38693e221a87085469be3ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add required definitions to describe an ACPI SPI bus and a method to
write the SpiSerialBus() descriptor to the SSDT.
This will be used by device drivers to describe their SPI resources to
the OS. SPI devices are not currently enumerated in the devicetree but
can be enumerated by device drivers directly.
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct acpi_spi spi = {
.device_select = dev->path->generic.device.id,
.device_select_polarity = SPI_POLARITY_LOW,
.spi_wire_mode = SPI_4_WIRE_MODE,
.speed = 1000 * 1000; /* 1 mHz */
.data_bit_length = 8,
.clock_phase = SPI_CLOCK_PHASE_FIRST,
.clock_polarity = SPI_POLARITY_LOW,
.resource = acpi_device_path(dev->bus->dev)
};
...
acpi_device_write_spi(&spi);
...
}
devicetree.cb:
device pci 1e.2 on
chip drivers/spi/generic
device generic 0 on end
end
end
SSDT.dsl:
SpiSerialBus (0, PolarityLow, FourWireMode, 8, ControllerInitiated,
1000000, ClockPolarityLow, ClockPhaseFirst,
"\\_SB.PCI0.SPI0", 0, ResourceConsumer)
Change-Id: I0ef83dc111ac6c19d68872ab64e1e5e3a7756cae
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14936
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add required definitions to describe an ACPI I2C bus and a method to
write the I2cSerialBus() descriptor to the SSDT.
This will be used by device drivers to describe their I2C resources to
the OS. The devicetree i2c device can supply the address and 7 or 10
bit mode as well as indicate the GPIO controller device, and the bus
speed can be fixed or configured by the driver.
chip.h:
struct drivers_i2c_generic_config {
enum i2c_speed bus_speed;
};
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_i2c_generic_config *config = dev->chip_info;
struct acpi_i2c i2c = {
.address = dev->path->i2c.device,
.mode_10bit = dev->path.i2c.mode_10bit,
.speed = config->bus_speed ? : I2C_SPEED_FAST,
.resource = acpi_device_path(dev->bus->dev)
};
...
acpi_device_write_i2c(&i2c);
...
}
devicetree.cb:
device pci 15.0 on
chip drivers/i2c/generic
device i2c 10.0 on end
end
end
SSDT.dsl:
I2cSerialBus (0x10, ControllerInitiated, 400000, AddressingMode7Bit,
"\\_SB.PCI0.I2C0", 0, ResourceConsumer)
Change-Id: I598401ac81a92c72f19da0271af1e218580a6c49
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add definitions to describe GPIOs in generated ACPI objects and a
method to write a GpioIo() or GpioInt() descriptor to the SSDT.
ACPI GPIOs have many possible configuration options and a structure
is created to describe it accurately in ACPI terms. There are many
shared descriptor fields between GpioIo() and GpioInt() so the same
function can write both types.
GpioInt shares many properties with ACPI Interrupts and the same types
are re-used here where possible. One addition is that GpioInt can be
configured to trigger on both low and high edge transitions.
One descriptor can describe multiple GPIO pins (limited to 8 in this
implementation) that all share configuration and controller and are
used by the same device scope.
Accurately referring to the GPIO controller that this pin is connected
to requires the SoC/board to implement a function handler for
acpi_gpio_path(), or for the caller to provide this directly as a
string in the acpi_gpio->reference variable.
This will get used by device drivers to describe their resources in
the SSDT. Here is a sample for a Maxim 98357A I2S codec which has a
GPIO for power and channel selection called "sdmode".
chip.h:
struct drivers_generic_max98357a_config {
struct acpi_gpio sdmode_gpio;
};
max98357a.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_generic_max98357a_config *config = dev->chip_info;
...
acpi_device_write_gpio(&config->sdmode_gpio);
...
}
devicetree.cb:
device pci 1f.3 on
chip drivers/generic/max98357a
register "sdmode_gpio" = "ACPI_GPIO_OUTPUT(GPP_C5)"
device generic 0 on end
end
end
SSDT.dsl:
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0, ResourceConsumer, ,) { 53 }
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ibf5bab9c4bf6f21252373fb013e78f872550b167
Reviewed-on: https://review.coreboot.org/14934
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add definitions for ACPI device extended interrupts and a method to
write an Interrupt() descriptor to the SSDT output stream.
Interrupts are often tied together with other resources and some
configuration items are shared (though not always compatibly) with
other constructs like GPIOs and GPEs.
These will get used by device drivers to write _CRS sections for
devices into the SSDT. One usage is to include a "struct acpi_irq"
inside a config struct for a device so it can be initialized based
on settings in devicetree.
Example usage:
chip.h:
struct drivers_i2c_generic_config {
struct acpi_irq irq;
};
generic.c:
void acpi_fill_ssdt_generator(struct device *dev) {
struct drivers_i2c_generic_config *config = dev->chip_info;
...
acpi_device_write_interrupt(&config->irq);
...
}
devicetree.cb:
device pci 15.0 on
chip drivers/i2c/generic
register "irq" = "IRQ_EDGE_LOW(GPP_E7_IRQ)"
device i2c 10 on end
end
end
SSDT.dsl:
Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive,,,) { 31 }
Change-Id: I3b64170cc2ebac178e7a17df479eda7670a42703
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When CONFIG_C_ENVIRONMENT_BOOTBLOCK is employed there's no need for
a chipset specific verstage entry point because cache-as-ram has
already been initialized. Therefore, provide a default entry point
for verstage in that environment.
Change-Id: Idd8f45bd58d3e5b251d1e38cca7ae794b8b77a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14971
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Add a function to "struct device_operations" to return the ACPI name
for the device, and helper functions to find this name (either from
the device or its parent) and to build a fully qualified ACPI path
from the root device.
This addition will allow device drivers to generate their ACPI AML in
the SSDT at boot, with customization supplied by devicetree.cb,
instead of needing custom DSDT ASL for every mainboard.
The root device acpi_name is defined as "\\_SB" and is used to start
the path when building a fully qualified name.
This requires SOC support to provide handlers for returning the ACPI
name for devices that it owns, and those names must match the objects
declared in the DSDT. The handler can be done either in each device
driver or with a global handler for the entire SOC.
Simplified example of how this can be used for an i2c device declared
in devicetree.cb with:
chip soc/intel/skylake # "\_SB" (from root device)
device domain 0 on # "PCI0"
device pci 19.2 on # "I2C4"
chip drivers/i2c/test0
device i2c 1a.0 on end # "TST0"
end
end
end
end
And basic SSDT generating code in the device driver:
acpigen_write_scope(acpi_device_scope(dev));
acpigen_write_device(acpi_device_name(dev));
acpigen_write_string("_HID", "TEST0000");
acpigen_write_byte("_UID", 0);
acpigen_pop_len(); /* device */
acpigen_pop_len(); /* scope */
Will produce this ACPI code:
Scope (\_SB.PCI0.I2C4) {
Device (TST0) {
Name (_HID, "TEST0000")
Name (_UID, 0)
}
}
Change-Id: Ie149595aeab96266fa5f006e7934339f0119ac54
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14840
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
acpigen_write_uuid() will generate a ToUUID() 128-bit buffer object for a
common universally unique identifier that is passed as a string. The
resulting buffer is the UUID in byte format with a specific order of the
bytes as described in the ACPI specification:
ToUUID (uuid)
Compiles to:
Buffer (16) { uuid[3], uuid[2], uuid[1], uuid[0], uuid[5], uuid[4],
uuid[7], uuid[6], uuid[8], uuid[9], uuid[10], uuid[11],
uuid[12], uuid[13], uuid[14], uuid[15] }
Change-Id: Ibbeff926883532dd78477aaa2d26ffffb6ef30c0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14838
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
timestamp.c was not included in bootblock and postcar. This means that
these two stages would use the weak implementation in lib/timestamp.c
instead of the arch-specific implementation based on rdtsc.
This resulted in using timer_monotonic_get() which resets the
timestamps from 0. timer_monotonic_get() only provides per-stage
incrementing semantics on x86 because lapic implementation has
counting down values. A globally incrementing counter like rdtsc
provides the semantics like every other non-x86.
On the test configuration, the weak implementation of timestamp_get()
returned zero, resulting in wrong timestamps coming from the bootblock,
while romstage and ramstage used the arch implementation and returned
correct timestamps.
This is a great example of why weak functions are dangerous, and how
easy it is to miss subtle yet strong interactions between subsystems
and the coreboot buildsystem.
Change-Id: I656f9bd58a6fc179d9dbbc496c5b684ea9288eb5
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14860
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
strlen(string) was on the "negative" side of the selection operator, the
side where string is NULL.
Change-Id: Ic421a5406ef788c504e30089daeba61a195457ae
Reported-by: Coverity Scan (CID 1355263)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14867
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Add helper functions for generating some common objects:
acpigen_write_STA(status) will generate a status method that will
indicate the device status as provided:
Method (_STA) { Return (status) }
Full status byte configuration is possible and macros are provided for
the common status bytes used for generated code:
ACPI_STATUS_DEVICE_ALL_OFF = 0x0
ACPI_STATUS_DEVICE_ALL_ON = 0xF
acpigen_write_PRW() will generate a Power Resoruce for Wake that describes
the GPE that will wake a particular device:
Name (_PRW, Package (2) { wake, level }
Change-Id: I10277f0f3820d272d3975abf34b9a8de577782e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14795
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to produce smaller AML and not rely on the caller to size the
output type appropriately add a helper function that will output an
appropriately sized integer.
To complete this also add helper functions for outputting the single
OpCode for Zero and One and Ones.
And finally add "name" variants of the helpers that will output a
complete sequence like "Name (_UID, Zero)".
Change-Id: I7ee4bc0a6347d15b8d49df357845a8bc2e517407
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14794
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add helper function to emit a string into the SSDT AML bytestream with a
NULL terminator. Also add a helper function to emit the string OpCode
followed by the string itself.
acpigen_emit_string(string) /* Raw string output */
acpigen_write_string(string) /* OpCode followed by raw string */
Change-Id: I4a3a8728066e0c41d7ad6429fad983e6ae6962fe
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14793
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add helpers for writing word and dword values in acpigen and use them
throughout the file to clean things up:
acpigen_emit_word - write raw word
acpigen_emit_dword - write raw dword
acpigen_write_word - write word opcode and value
Change-Id: Ia758d4dd25d0ae5b31be7d51b33866dddd96a473
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14792
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The skylake-based Chromebooks use a separate verstage which runs
just after bootblock and prior to romstage. The normal path for
romstage would be to reload the gdt, however in the previously
described scenario has verstage performing that work. Therefore,
provide that path under those conditions. The only difference
from the C_ENVIRONMENT_BOOTBLOCK scenario is that the stack
should not be reloaded since there's no way to know the top
of the stack.
Change-Id: Ic39ab52a856233d3042ac02a15ae4816ddfe07c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14548
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
The path that just clears CAR_GLOBAL variables and jumps
to the stage entry point needs another condition for
separate verstage just after bootblock. However, the
current conditional is a negative conditional so
swap the logic around to make it easier to extend.
Change-Id: Iab6682498054715a6eaa0476390da6355238b9bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14547
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Stefan and others have discussed their interest in only
including options in Kconfig that are directly associated
with building a coreboot image. There are variables that
are architecture dependent that are utilized in the
coreboot infrastructure. To meet that goal, introduce
<arch/cbconfig.h> header file which defines variables
for the coreboot infrastructure that are architecture
dependent but utilized in common infrastructure.
Change-Id: Ic4cb9e81bab042797539dce004db0f7ee8526ea6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14454
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
C_ENVIRONMENT_BOOTBLOCK on x86 is like romstage and uses cache-as-ram
separately. It does not use any data/bss sections.
Change-Id: I8957f467f01e754fa2d95783466a01daa6c4e51a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14533
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
In order to de-duplicate common patterns implement one write_tables()
function. The new write_tables() replaces all the architecture-specific
ones that were largely copied. The callbacks are put in place to
handle any per-architecture requirements.
Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14436
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a architecture specific function, arch_write_tables(), that
allows an architecture to add its required tables for booting.
This callback helps write_tables() to be de-duplicated.
Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A architecture-specific function, named bootmem_arch_add_ranges(),
is added so that each architecture can add entries into the bootmem
memory map. This allows for a common write_tables() implementation
to avoid code duplication.
Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14434
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In addition to being consistent with all other architectures,
all chipsets support cbmem so the low coreboot table path is
stale and never taken. Also it's important to note the memory
written in to that low area of memory wasn't automatically
reserved unless that path was taken. To that end remove
low coreboot table support for x86.
Change-Id: Ib96338cf3024e3aa34931c53a7318f40185be34c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There were quite a number of #if/#endif guards in the
write_tables() code. Clean up that function by splitting
up the subcomponents into their own individual functions.
The same ordering and logic is kept maintained.
The changes also benefit the goal of using a common core
write_tables() logic so that other architectures don't
duplicate large swaths of code.
Change-Id: I93f6775d698500f25f72793cbe3fd4eb9d01a20c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14431
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Each arch was calling cbmem_list() in their own write_tables()
function. Consolidate that call and place it in common code
in write_coreboot_table().
Change-Id: If0d4c84e0f8634e5cef6996b2be4a86cc83c95a9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14430
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of hard coding a #define in each architecture's
tables.c for the coreboot table size in cbmem use a Kconfig
varible. This aids in aligning on a common write_tables()
implementation instead of duplicating the code for each
architecture.
Change-Id: I09c0f56133606ea62e9a9c4c6b9828bc24dcc668
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14429
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to not muddle arch vs chipset implementations provide
a generic prog_segment_loaded() which calls platform_segment_loaded()
and arch_segment_loaded() in that order. This allows the arch variants
to live in src/arch while the chipset/platform code can implement
their own.
Change-Id: I17b6497219ec904d92bd286f18c9ec96b2b7af25
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14214
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
While rmodule_load() calls arch_segment_loaded() when it's done
loading any pieces of code which further modify it, like changing
parameters within the program itself, need to notify the rest of
the system.
Change-Id: Ia3374b58488120ba6279592a77d7f9c6217f1215
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14213
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The previous implementation assumed the CPU physical address size to
be 40 which is not true of all platforms. Use an existing function to
obtain the correct CPU physical address to report in the DMAR ACPI
table.
Change-Id: Ia79e9dadecc3f5f6a86ce3789b213222bef482b3
Signed-off-by: Jacob Laska <jlaska91@gmail.com>
Reviewed-on: https://review.coreboot.org/14102
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This option is no longer needed, as FMAP support has been
fully integrated in coreboot
Change-Id: I6121b31bf946532717ba15e12f5c63d2baa95ab2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14078
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Different DIMM modules give different SMBIOS type 17 lengths, so we
can't use `meminfo->dimm_cnt*len' for entry struct size, otherwise
it'll give a wrong SMBIOS size when two or more different DIMMs are
installed on the machine.
Change-Id: I0e33853f6aa4b30da547eb433839a397d451a8cf
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/14008
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This adds a few assembly lines that are generic enough to be shared
between romstage and verstage that are ran in CAR. The GDT reload
is bypassed and the stack is reloaded with the CAR stack defined
in car.ld. The entry point for all those stages is car_stage_entry().
Change-Id: Ie7ef6a02f62627f29a109126d08c68176075bd67
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13861
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Attempt to better document the symbol usage in car.ld for
cache-as-ram usage. Additionally, add _car_region_[start|end]
that completely covers the entire cache-as-ram region. The
_car_data_[start|end] symbols were renamed to
_car_relocatable_data_[start|end] in the hopes of making it
clearer that objects within there move. Lastly, all these
symbols were added to arch/symbols.h.
Change-Id: I1f1af4983804dc8521d0427f43381bde6d23a060
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13804
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Those options have no effect or lead to compile error on ARM due
to fundamental incompatibilities. Add proper "depends on" clauses
to hide them.
Change-Id: I860fbd331439c25efd8aa92023195fda3add2e2c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13904
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of keeping track of all the combinations of entry points
depending on the stage and other options just use _start. That way,
there's no need to update the arch/header.ld for complicated cases
as _start is always the entry point for a stage.
Change-Id: I7795a5ee1caba92ab533bdb8c3ad80294901a48b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13882
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
In order to align the entry points for the various stages
on x86 to _start one needs to rename the reset_vector symbol.
The section is the same; it's just a symbol change.
Change-Id: I0e6bbf1da04a6e248781a9c222a146725c34268a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13881
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Until recently x86 romstage used to be linked at some default
address. The address itself is not meaningful because the code
was normally relocated at address calculated during insertion
in CBFS. Since some newer SoC run romstage at CAR it became
useful to link romstage code at some address in CAR and avoid
relocation during build/run time altogether.
Change-Id: I11bec142ab204633da0000a63792de7057e2eeaf
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13860
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
For C_ENVIRONMENT_BOOTBLOCK, memlayout.ld is added by call to
early_x86_stage. Remove redundant addition of memlayout.ld in this
case.
Change-Id: Ibb5ce690ac4e63f7ff5063d5bd04daeeb731e4d7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/13777
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Only i386 has code to support bounce buffer. For others coreboot
would silently discard part of binary which doesn't work and is a hell to debug.
Instead just die.
Change-Id: I37ae24ea5d13aae95f9856a896700a0408747233
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13750
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The 8254 (Programmable Interrupt Timer) is becoming optional
on x86 platforms -- either from saving power or not including it
at all. To allow a payload to still use a TSC without doing
calibration provide the TSC frequency information in the coreboot
tables. That data is provided by code/logic already employed
by platform. If tsc_freq_mhz() returns 0 or
CONFIG_TSC_CONSTANT_RATE is not selected the coreboot table
record isn't created.
BUG=chrome-os-partner:50214
BRANCH=glados
TEST=With all subsequent patches confirmed TSC is picked up in
libpayload.
Change-Id: Iaeadb85c2648587debcf55f4fa5351d0c287e971
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13670
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Add lb_arch_add_records() to allow the architecture code to
generically hook into the coreboot table generation.
BUG=chrome-os-partner:50214
BRANCH=glados
TEST=With all subsequent patches confirmed lb_arch_add_records() is
called when a strong symbol is provided.
Change-Id: I7c69c0ff0801392bbcf5aef586a48388b624afd4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13669
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
On certain platforms, the boot media is either not memory-mapped, or
not mapped at the top of 4G. This makes the default mmap_boot
implementation unsuitable. Add an option to allow such platforms to
define their own mapping implementation.
Change-Id: I8293126fd9cc1fd3d75072f7811e659765348e4a
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/13319
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Certain platforms may need to limit their bootblock size to within
a given size because specific constraints. Allow the size to be
provided by the mainboard or chipset by way of the arch Kconfig
being processed after those.
Change-Id: I46cc6315918cde575070fa2d3e2514f28008f575
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13691
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
This patch generalizes the approach previously used for ARM32
TTB_SUBTABLES to "auto-detect" whether a certain region was defined in
memlayout.ld. This allows us to get rid of the explicit Kconfig for the
TIMESTAMP region, reducing configuration redundancy and avoiding
confusion when setting up future boards.
(Removing armv4/bootblock_simple.c because it references this Kconfig
and it is a dead file that I just forgot to remove in CL:12076.)
BRANCH=None
BUG=None
TEST=Booted Oak and confirmed that all pre-RAM timestamps are still
there. Built Nyan and Falco.
Change-Id: I557a4b263018511d17baa4177963130a97ea310a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently x86s select BOOTBLOCK_CUSTOM by default. With this
change BOOTBLOCK_CUSTOM is selected only if C bootblock isn't.
Change-Id: I218f3b4044175b89697790c82c384b0f85a27ade
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13642
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Since cbmem is not initialized in bootblock, CAR_GLOBAL variables
can only be accessed directly similar to verstage.
Change-Id: Ifc705016290807c49dc8c49b581864cac2ad3f80
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13641
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Some platforms may want to use C code in bootblock so they need
writable memory and CAR can be used for it. This change reserves
memory in CAR that can be used by bootblock and other CAR stages.
Change-Id: I8dec768cf8763dbe235f0ba1339079ebc49cbd9a
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13640
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Instead of instructing users to edit xcompile when they want to build
a quark platform, give the build a way to set -march=586 so that
the quark code will build correctly. The Quark processor does not
support the instructions introduced with the Pentium 6 architecture.
Change-Id: I0ed69aadc515f86f76800180e0e33bcd75feac5a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13552
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
Some newer x86 systems can boot from non-memory-mapped boot media
(e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or
other memory, similar to how most ARM chipsets work. In such cases, we
may not have enough code space for romstage very early on. This means
that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to
be implemented within the limited amount memory of storage available.
Since the reset vector has to be contained in this early code memory,
the bootblock is the best place to implement loading of other stages.
Implement a bootblock which does the minimal initialization, up to,
and including switch to protected mode. This then transfers control
to platform-specific code. No stack is needed, and control is
transferred via a "jmp" such that no stack operations are involved.
Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/13485
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
bootblock.S was used strictly for setting up the system so that the
assembly generated by ROMCC could be executed. Since the
infrastructure now exists to run a bootblock wihtout ROMCC, rename
this file accordingly. this is done to prevent any future confusion.
Change-Id: Icbf5804b66b9517f9ceb352bed86978dcf92228f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/11784
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of tagging object files with .<class>, move them to a <class>
directory below $(obj)/. This way we can keep a 1:1 mapping between
source- and object-file names.
The 1:1 mapping is a prerequisite for Ada, where the compiler refuses
any other object-file name.
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: Idb7a8abec4ea0a37021d9fc24cc8583c4d3bf67c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13181
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
There were several spots in the tree where the path to a per class
object file was hardcoded. To make use of the src-to-obj macro for
this, it had to be moved before the inclusion of subdirs. Which is
fine, as it doesn't have dependencies beside $(obj).
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13180
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It's unused, so get rid of it.
Change-Id: I28c6dc0208686edc3aabaf624773ea70350c1c8f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13177
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For the coreboot license header, we want to use two paragraphs.
See the section 'Common License Header' in the coreboot wiki
for more details.
Change-Id: I4a43f3573364a17b5d7f63b1f83b8ae424981b18
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13118
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It ended up in .data, and that doesn't seem to be actually necessary.
Change-Id: Ib17d6f9870379d1b7ad7bbd3f16a0839b28f72c8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13134
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
When C_ENVIRONMENT_BOOTBLOCK is selected link bootblock using the
memlayout.ld scripts and infrastructure. This allows bootblock on
x86 to utilize all the other coreboot infrastructure without
relying romcc.
Change-Id: Ie3e077d553360853bf33f30cf8a347ba1df1e389
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13069
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Replace with the more familiar AT&T syntax.
Tested by sha1sum(1)ing the object files, and checking the objdump that
the code in question was actually compiled.
Change-Id: Ie85b8ee5dad1794864c18683427e32f055745221
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13132
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This provides symbols needed by CBFS and FMAP APIs, and allows running
run_romstage() in an x86 bootblock. Note that console-related files
are not added in this patch, as they are not essential for the
functinality on an x86 environment bootbock.
Change-Id: I36558b672a926ab22bc9018cd51aee32213792c2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/12880
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This header is only used for the bootblock compiled with ROMCC. As the
follow-on patches introduce a bootblock which does not make use of
ROMCC, rename this header to prevent confusion.
Change-Id: Id29c5bc6928c11cc7cb922fcfac71e5a3dcd113c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/12867
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Trivial fix for syntax highlighting in editors. Some get confused by
the double quote that doesn't have a close quote and stop highlighting
at that point. This comment closes the quote and the paren pair so
that they can recover.
Change-Id: I2bdb7c953a86905fc302d77eb9ad1200958800b7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was breaking the build on OS X, but also wasn't working correctly
under linux anymore either. It wouldn't print the illegal symbols
when it failed.
- Split the generation of the offenders file from the actual check for
offending symbols and just send all output to /dev/null.
- Rewrite the check for offending symbols in a way that works with OS X.
Tested by adding a global variable to romstage and verifying the
failure is shown correctly. Verified that it works correctly with no
illegal variables.
Change-Id: I5b3ac32448851884d78c3b3449508ffe014119ab
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13018
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These were mostly written as part of the coreboot project, so get
the standard coreboot license header.
memmove.c came from the linux kernel, so also gets the standard
coreboot v2 license header, but gets the added attribution that it
was derived from the linux kernel. Unlike many coreboot files,
this file may not be re-licensed as GPL V3.
Change-Id: I1fdc26b543e059f7a42d4b886f7222f4c74b959d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12916
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These were all written as part of the coreboot project, so get
the standard coreboot license header.
Change-Id: I51e1e504b3bc7be2a00c9356d8775b87f2a1db5a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12912
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When microcode updates are enabled, this fixes an issue identical
to that described in GIT hash 7b22d84d:
* drivers/pc80: Add optional spinlock for nvram CBFS access
Change-Id: Ib7e8cb171f44833167053ca98a85cca23021dfba
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12063
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This reverts commit 65e33c08a9.
This was the wrong logic to fix the master header.
Change-Id: I4688034831f09ac69abfd0660c76112deabd62ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12824
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Since the introduction of the new (interim?) master header, coreboot
searches the whole ROM for CBFS entries. Fix that by aligning it on top
of the ROM.
Change-Id: I080cd4b746169a36462a49baff5e114b1f6f224a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/12810
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
When enabling the IOMMU on certain systems dmesg is spammed with I/O page faults like the following:
AMD-Vi: Event logged [IO_PAGE_FAULT device=00:14.0 domain=0x000a address=0x000000fdf9103300 flags=0x0030]
Decoding the faulting address:
0x000000fdf9103300
fdf91x Hypertransport system management region
33 SysMgtCmd (System Management Command) = 0x33
3 Base Command Type = 0x3: STPCLK (Stop Clock request)
3 SMAF (System Management Action Field) = [3:1] = 0x1
1 Signal State Bit Map = [0] = 0x1
Therefore, the error appears to be triggered by an upstream C1E request.
This was eventually traced to concurrent access to the SP5100's SPI Flash controller by
multiple APs during startup. Calls to the nvram read functions get_option and read_option
call CBFS functions, which in turn make near-simultaneous requests to the SPI Flash
controller, thus placing the SP5100 in an invalid state. This limitation is not documented
in any public AMD errata, and was only discovered through considerable debugging effort.
Change-Id: I4e61b1ab767b1b7958ac7c1cf20eee41d2261bef
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12061
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Section 6.1.3 (Text Strings) of the SMBIOS specification states:
If a string field references no string, a null (0) is placed in that
string field.
Change smbios_add_string() to do that.
Change-Id: I9c28cb89dcfe2c8ef2366c23ee6203e15b7c2513
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/12697
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
$(objgenerated)/empty would touch files before the directory
is created on parallel builds.
Thanks to reproducible-builds.org for hitting this bug.
Change-Id: I7565e9fe130b4e9deaf1c7b9d568ff90b00dda52
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/12717
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The ALIGN_CURRENT macro relied on a local variable name
as well as being defined in numerous compilation units.
Replace those instances with an acpi_align_current()
inline function.
Change-Id: Iab453f2eda1addefad8a1c37d265f917bd803202
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12707
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This paves the way for AP printk spinlock on AMD platforms
Change-Id: Ice42a0d3177736bf6e1bc601092e413601866f20
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/11958
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Now that only CBFS access is supported for finding resources
within the boot media the assets infrastructure can be removed.
Remove it.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Chrome OS verified boot path supported multiple CBFS
instances in the boot media as well as stand-alone assets
sitting in each vboot RW slot. Remove the support for the
stand-alone assets and always use CBFS accesses as the
way to retrieve data.
This is implemented by adding a cbfs_locator object which
is queried for locating the current CBFS. Additionally, it
is also signalled prior to when a program is about to be
loaded by coreboot for the subsequent stage/payload. This
provides the same opportunity as previous for vboot to
hook in and perform its logic.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
CQ-DEPEND=CL:307121,CL:31691,CL:31690
Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12689
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In coreboot, bool, hex, and int type symbols are ALWAYS defined.
Change-Id: I58a36b37075988bb5ff67ac692c7d93c145b0dbc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12560
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Move initialization of entry to later in main.
- Make boot_mode an unsigned char - no need to use int.
- Remove unnecessary variable filenames.
- Only get and try to boot fallback once.
Change-Id: I823092c60dd8c2de0a36ec7fdbba3e68f6b7567a
Test: compiled.
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12574
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
verstage, romstage, and payload can be added through infrastructure now.
Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12549
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We currently race in SMM init on Atom 230 (and potentially
other CPUs). At least on the 230, this leads to a hang on
RSM, likely because both hyperthreads mess around with
SMBASE and other SMM state variables in parallel without
coordination. The same behaviour occurs with Atom D5xx.
Change it so first APs are spun up and sent to sleep, then
BSP initializes SMM, then every CPU, one after another.
Only do this when SERIALIZE_SMM_INITIALIZATION is set.
Set the flag for Atom CPUs.
Change-Id: I1ae864e37546298ea222e81349c27cf774ed251f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/6311
Tested-by: build bot (Jenkins)
Tested-by: BSI firmware lab <coreboot-labor@bsi.bund.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of having to have an ifeq() all across the code base,
use $(target-objcopy). And correct target-objcopy to a value
that objcopy actually understands.
Change-Id: Id5dea6420bee02a044dc488b5086d109e806d605
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11090
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds CC6 power save support to the AMD Family 15h
support code. As CC6 is a complex power saving state that
relies heavily on CPU, northbridge, and southbridge cooperation,
this patch alters significant amounts of code throughout the
tree simultaneously.
Allowing the CPU to enter CC6 allows the second level of turbo
boost to be reached, and also provides significant power savings
when the system is idle due to the complete core shutdown.
Change-Id: I44ce157cda97fb85f3e8f3d7262d4712b5410670
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11979
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When we first added ARM support to coreboot, it was clear that the
bootblock would need to do vastly different tasks than on x86, so we
moved its main logic under arch/. Now that we have several more
architectures, it turns out (as with so many things lately) that x86 is
really the odd one out, and all the others are trying to do pretty much
the same thing. This has already caused maintenance issues as the ARM32
bootblock developed and less-mature architectures were left behind with
old cruft.
This patch tries to address that problem by centralizing that logic
under lib/ for use by all architectures/SoCs that don't explicitly
opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option).
This works great out of the box for ARM32 and ARM64. It could probably
be easily applied to MIPS and RISCV as well, but I don't have any of
those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and
leave that for later cleanup.
BRANCH=None
BUG=None
TEST=Built Jerry and Falco, booted Oak.
Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12076
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
PMIOxEE is for setting USB3 power rail. Set it to S0, otherwise
going into hibernation can not be wake up.
Change-Id: I692497bad24d745738d670897e725a568c1db114
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11373
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Refactor acpi_create_dmar_drhd_ds_pci() and add similar functions for
I/O-APICs and MSI capable HPETs. We violate the spec [1] here, which
talks about 16-bit source-ids spread over start_bus and path entries.
Intel actually uses bus/dev/fn identification for those devices too,
and so do we.
[1] Intel Virtualization Technology for Directed I/O
Architecture Specification
Document-Number: D51397
Change-Id: I0fce075961762610d44b5552b71e010511871fc2
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12192
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a parameter to acpi_create_dmar() for the flags field and define
flags given by the spec [1].
[1] Intel Virtualization Technology for Directed I/O
Architecture Specification
Document-Number: D51397
Change-Id: I03ae32f13bb0061bd3b9bef607db175d9b0bc5e1
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12191
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fix a function call in the normal path using the original function
name and arguments in code that was changed in commit 3bfd7cc6
(drivers/pc80: Rework normal / fallback selector code)
This commit reworked most of the fallback / normal code,
however the normal code paths were not fully tested by Jenkins,
so this was missed.
Change-Id: Ied66334977272a13b7a7307ff4d9f34eb22040aa
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12315
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On x86_64 we need to leave long mode before we can switch to 16bit
mode. Oh joy! When's my 64bit resume pointer coming?
Why didn't this get caught earlier? Seems the Asrock E350M2 didn't
do Suspend/Resume?
Yes, I know it's Intel syntax. Will be converted to AT&T syntax
as soon as the whole thing actually works.. 8)
Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11106
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Since we now have more freedom in the bootblock linking step it no
longer makes sense to use a monolithic bootblock.S. Code segments must
still be included as the order in bootblock.S determines code flow.
However, non-code flow related assembly stubs don't need to be directly
included in bootblock.S
Change-Id: I08e86e92d82bd2138194ed42652f268b0764aa54
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11792
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code flow doesn't fall through to walkcbfs, as it does in the rest
of bootblock.S. Instead, walkcbfs is called (albeit via a jmp). The
linker cannot know this when walkcbfs.S is included directly.
When we use a CAR bootblock, we lose several hundred bytes because
walkcbfs is not garbage-collected, yet it isn't used. This problem
is solved by assembling walkcbfs.S separately, and linking it.
Change-Id: Ib3a976db09b9ff270b7677cb4f9db80b0b025e22
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11785
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As part of preparing for systems with non-memory-mapped media, we want
to be able to call into C code. This change allows us to link C code
directly into the bootblock. The steps of going from bootblock main()
to CAR setup to C code will be implemented in subsequent patches.
Note that a few files selected with bootblock-y will now be compiled
for the bootblock as well, but since we enabled garbage collection,
they will not be included in the final binary.
Change-Id: I5ca6dcaf176f5469c6a3bb925859399123493bc6
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11783
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The only difference between the ifeq/else/endif guarded rules is the
linker flags specific to x86. Add those flags to LDFLAGS_bootblock,
and only use one rule for bootblock.debug.
Change-Id: I986a93e0418f05fb273512d7efe0573052493332
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11782
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The x86 bootblock linking is a mess. The bootblock is treated in
a very special manner, and never received the update to link-time
garbage collection.
On newer x86 platforms, the boot media is no longer memory-mapped.
That means we need to do a lot more setup in the bootblock. ROMCC is
unsuitable for this task, and walkcbfs only works on memory-mapped
CBFS. We need to revise the x86 bootflow for this new case.
The approach this patch series takes is to perform CAR setup in the
bootblock, and load the following stage (either romstage or verstage)
from the boot media. This approach is not new, but has been done on
our ARM ports for years.
Since we will be adding .c files to the bootblock, it is prudent to
use link-time garbage collection. This is also consistent to how we
do things on other architectures. Unification FTW!
Change-Id: I16b78456df56e0053984a9aca9367e2542adfdc9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11781
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to do a verification of romstage on x86 one needs to
run verstage which verifies romstage (and the memory init code).
However, x86 doesn't have SRAM like every other modern SoC so
managing the cache-as-ram region is especially critical.
First move all of the "shared" objects to the beginning of
the .car.data section. This change then ensures that each stage
using car.ld to link has the same consistent view of the addresses
of these fixed-sized objects in cache-as-ram. The CAR_GLOBALs can
be unique per stage. However, these variables are expected to have
a value of zero at the start of each stage. In order to allow a
stage to provide those semantics outside of the initial cache-as-arm
setup routine add _car_global_start and _car_global_end symbols.
Those symbols can be used to clear the CAR_GLOBALs for that stage.
Note that the timestamp region can't be moved out similarly to the
pre-ram cbmem console because the object storage of the timestamp
cache is used *after* cache-as-ram is torn down to indicate if the
cache should be used or not. Therefore, that timestamp needs to
migrated to ram. A logic change in src/lib/timestamp.c could
alleviate this requirement, but that task wasn't tackled in this
patch.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I15e9f6b0c632ee5a2369da0709535d6cb0d94f61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11740
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to support verstage on x86 one needs to link verstage
like romstage since it needs all the cache-as-ram goodies. Therefore,
provide a macro that one can invoke that provides the necessary
recipes for linking that particular stage in such an environment.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I12f4872df09fff6715829de68fc374e230350c2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11739
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The output of command below,
# i386-elf-nm build/cbfs/fallback/romstage_null.offenders | \
grep -q "" ; echo $?
has different result on MacOS, OS X Mavericks, which outputs 0.
On linux, it outputs 1.
I assume it is misleading to search an empty string in a empty
string. Change it to testing if the string is empty.
Change-Id: Ie4b8fe1fb26df092e2985937251a49feadc61eb0
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Now that cbfstool supports XIP for romstage utilize it.
This removes the double link steps with the cbfstool
locate and add-stage sandwich.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I1ec555f523a94dd4b15fe8186cbe530520c622c0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11670
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously there were 2 paths in linking ramstage. One was used for
RELOCATABLE_RAMSTAGE while the other was fixed location. Now that
rmodtool can handle multiple secitons for a single proram segment
there's no need for linking ramstage using lib/rmodule.ld. That
also means true rmodules don't have symbols required for ramstage
purposes so fix memlayout.h. Lastly add default rules for creating
rmod files from the known file names and locations.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Inspected ramstage.debug as well as rmodules
created during the build.
Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11524
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add an LDFLAGS_common variable and use that for each stage
during linking within all the architectures. All the architectures
support gc-sections, and as such they should be linking in the
same way.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage.
Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11522
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
To reduce file clutter merge romstage.ld and ramstage.ld
into a single memlayout.ld. The naming is consistent with
other architectures and chipsets for their linker script
names. The cache-as-ram linking rules are put into a separate
file such that other rules can be applied for future verstage
support.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and dmp/vortex86ex.
Change-Id: I1e8982a6a28027566ddd42a71b7e24e2397e68d2
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11521
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking romstage. Use that same method on x86
as well for consistency.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11510
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking ramstage. The last piece to align x86 is
to use arch/header.ld and the macros within memlayout.h
to automaticaly generate the necessary linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I012c9b88c178b43bf6a6dde0bab821e066728139
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11508
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Though coreboot started as x86 only, the current approach to x86
linking is out of the norm with respect to other architectures.
To start alleviating that the way ramstage is linked is partially
unified. A new file, program.ld, was added to provide a common way
to link stages by deferring to per-stage architectural overrides.
The previous ramstage.ld is no longer required.
Note that this change doesn't handle RELOCATABLE_RAMSTAGE
because that is handled by rmodule.ld. Future convergence
can be achieved, but for the time being that's being left out.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards.
Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The current way the XIP address of romstage is calculated is by
doing a 'cbfstool locate' using a bin file of romstage linked
at address 0. That address is then used for re-linking romstage at
the address spit out by cbfstool. Currently, the linker actually
sets minimum alignment on the text sections as 32 bytes, but it
doesn't actually honor that value. Instead, provide a minimum
alignment for romstage so as not to fight the linker.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built asus/kfsn4-dre. Confirmed ROMSTAGE_BASE == gdtptr.
Change-Id: Id6ec65d257df9ede78c720b0d7d4b56acfbb3f15
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Now that the only source of ELF sections for romstage are
from directly included .inc files or ROMCC generated inc
files the subsection globs can be removed. i.e. Remove
.rom.data.* and .rom.text.* listings. Lastly, put the
.rom.data section directly after the .rom.text. They
are by definition read-only and they are generated from
the same place.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Spot checked !ROMCC and ROMCC boards. Confirmed
only .rom.text .rom.data sections exist.
Change-Id: Id17cf95c943103de006c5f3f21a625838ab49929
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11505
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system was previously determining the flow
of the romstage code by the order of files added to
the crt0s make variable. Those files were then
concatenated together, and the resulting file was added
to the build dependencies for romstage proper.
Now romstage.S is added that can be built using
the default object file rules. The generated
romstage.inc is pulled in by way of an #include in the
newly added romstage.S.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards. compared
readelf -e output.
Change-Id: Ib1168f9541eaf96651c52d03dc0f60e2489a77bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11504
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, the x86 romstage build process was unconditionally
creating a romstage.inc and adding it to crt0s. This step is
inherently not necessary in the !ROMCC case becaue the romstage.inc
was created by the compiler outputting assembler. That means
MAINBOARDDIR/romstage.c is truly a C environment that requires
some sort of assembler stub to call into (cache_as_ram.inc from
the chipset dirs). Therefore, remove this processing. The result
is that MAINBOARDDIR/romstage.c can use the normal build steps
in creating an object and linking. The layout of romstage.elf
will change but that's only from a symbol perspective.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built multitude of boards. Compared readelf -e output.
Change-Id: I9b8079caaaa55e3ae20d3db4c9b8be04cdc41ab7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11503
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system was previously determining the flow
and linking scripts bootblock code by the order of files
added to the bootblock_inc bootblock-y variables.Those
files were then concatenated together and built by a myriad of
make rules.
Now bootblock.S and bootblock.ld is added so that bootblock
can be built and linked using the default build rules.
CHIPSET_BOOTBLOCK_INCLUDE is introduced in order to allow the
chipset code to place include files in the path of the bootblock
program -- a replacement for the chipset_bootblock_inc
make variable.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards.
Change-Id: Ida4571cbe6eed65e77ade98b8d9ad056353c53f9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11495
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
coreboot has no CREDITS file.
Change-Id: Iaa4686979ba1385b00ad1dbb6ea91e58f5014384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11514
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to prepare for more unification of the linker
scripts prefix pci_drivers, epci_drivers, cpu_drivers, and
ecpu_drivers with an underscore.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built different boards includes ones w/ and w/o relocatable
ramstage.
Change-Id: I8918b38db3b754332e8d8506b424f3c6b3e06af8
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11506
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building up which files to include in romstage there
were both 'cpu_incs' and 'cpu_incs-y' which were used to
generate crt0.S. Remove the former to settle on cpu_incs-y
as the way to be included.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. No include file changes.
Change-Id: I8dc0631f8253c21c670f2f02928225ed5b869ce6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11494
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When the check for global symbols in romstage happens, if everything is
good, a warning appears, telling us that the segment is empty. While the
empty segment is good, the warning is distracting:
"BFD: build/cbfs/fallback/romstage_null.debug: warning: Empty loadable
segment detected, is this intentional ?"
This change hides that particular warning, but shouldn't hide any other
output from objcopy.
Change-Id: If22489280712d02a61c3ee5e0cb2a53db87d6082
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11302
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The asl_template previously unconditionally included
dsdt.aml. However, COMPILE_IN_DSDT=y results in the
dsdt.aml being linked directly into ramstage. Thus
the information is duplicated.
The inclusion of this file unconditionally throws
some errors as certain assets need to be included
in CBFS. However, as there isn't fine-grained
ordering control in how files are added fixed
resource requirements for other assets collide
result in failure to build.
To remedy both things, provide a 2nd argument to
asl_template which defaults to 'y' for CBFS
addition. In the COMPILE_IN_DSDT=y case pass
'n' so that dsdt.aml is no longer added.
BUG=chrome-os-partner:43419
BRANCH=None
TEST=For glados:
Built with COMPILE_IN_DSDT=y. dsdt.aml not included.
Built with COMPILE_IN_DSDT=n. dsdt.aml was included.
Original-Change-Id: I4767e5be2915c1732251fe415017f30314c5efc9
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289840
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Id1828627ba0a034eb05b2fe23be76e19f3040444
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11166
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The sysinfo object within the k8 ram init is used
to communicate progess/status from all the nodes in the
system. However, the code was assuming where the sysinfo
object lived in cache-as-ram. The layout of cache-as-ram
is dynamic so one needs to do the lookup of the correct
address at runtime. The way the amd code is compiled
by #include'ing .c files makes the solution a little
more complex in that some cache-as-ram support code
needed to be refactored.
Change-Id: I6500fa7b005dc082c4c0b3382ee2c3a138d9ac31
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10961
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The spec states (5.2.10): "The BIOS aligns the FACS on a 64-byte boundary
anywhere within the system's memory address space."
Change-Id: Ie9415e505525dbdd418028d4954018c829921a18
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: fwts 15.08
Reviewed-on: http://review.coreboot.org/11141
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On x86-64 the current way of calculating the base address
of the boot device (SPI flash) gets an unwanted sign extension,
making it live somewhere at the end of 64bit address space.
Enforce rom_base to be at the upper end of the 4G address space.
Change-Id: Ia81e82094d3c51f6c10e02b4b0df2f3e1519d39e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
bootblock.inc requires config.h to be around which may need to be
created. Have make be aware of it.
Change-Id: I79ad003b461d7da7a5afecdae55fdd07ba735821
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11057
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It never made sense to have bootblock_* in init, but
pirq_routing.c in boot, and some ld scripts on the main
level while others live in subdirectories.
This patch flattens the directory hierarchy and makes
x86 more similar to the other architectures.
Change-Id: I4056038fe7813e4d3d3042c441e7ab6076a36384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10901
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I26f1bbf027435be593f11bce4780111dcaf7cb86
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10586
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The CBFS_BASE_ADDRESS can be compared against values used with cbfstool
to generate warnings. This can help cut down on mistakes and debug
time.
Change-Id: I149007dd637661f799a0f2cdb079d11df726ca86
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10681
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is not going as far as I would like it to go, but
some of the external payloads have to be fixed up first.
Long term, I would like to directly add payloads/external/*
to subdirs-y and remove one layer of indirection from the
build process.
For now, moving the payload Makefile targets into payloads/
is already a small improvement.
Change-Id: Ie4eb492eb804e0aaaf1a4d90af2f876f27a32a75
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10829
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to accommodate tracking timestamps in all the
__PRE_RAM__ stages (bootblock, verstage, romstage, etc)
of a platform one needs to provide a way to specify
a persistent region of SRAM or cache-as-ram to store
the timestamps until cbmem comes online. Provide that
infrastructure.
Based on original patches from chromium.org:
Original-Change-Id: I4d78653c0595523eeeb02115423e7fecceea5e1e
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/223348
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Change-Id: Ie5ffda3112d626068bd1904afcc5a09bc4916d16
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/224024
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I8779526136e89ae61a6f177ce5c74a6530469ae1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10790
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The top level Makefile runs the $stage-src .ld scripts through
the preprocessor and puts them in $(obj). Use the preprocessed
.ld files and cat them together into x86 romstage_null.ld.
Change-Id: If71240fbf7231df2b1333a1f8e5160cb8694f6ce
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10743
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
While extending the SMBIOS code to write a proper maximum structure size,
the call to elog_smbios_write_type15() was botched.
Fix the name and arguments.
Change-Id: I4c93490b09ddf4da240ff8f2bd8f8cc3f2abd96e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10823
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix up all the code that is using / to use >> for divisions instead.
Change-Id: I8a6deb0aa090e0df71d90a5509c911b295833cea
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10819
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The option --divide is required by our assembler to ensure that
'/' is not parsed as a comment sign but as a division, because
some of the cache as ram code is using divisions.
The --divide parameter has been part of the GNU as since binutils 2.17.
Hence, compile romstage (which contains cache as ram init) with
-Wa,--divide unconditionally instead of probing for it and adding it to
all compiler invocations (because that is causing random trouble with
clang when compiling the SMM code and calling gcc with --divide instead of
-Wa,--divide)
Change-Id: Ideefb2a243dc1d657ba415a99c1f8ab1d93800e0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The SMBIOS Specification 2.3 and up defines Maximum Structure Size
as the "Size of the largest SMBIOS structure, in bytes, and encompasses
the structure’s formatted area and text strings." The hardcoded size
is too small to accurately represent the maximum SMBIOS structure sizes.
While the field is not used by Linux it is used by some RTOS
implementations, eg. VxWorks.
TEST=Booted Linux and ran github.com/bfrisch/dmidecode which verified
the maximum structure size on Minnowboard Max.
Change-Id: I98087975c53a02857742dea283f4e303485b2ffe
Signed-off-by: Ben Frisch <bfrisch@gmail.com>
Reviewed-on: http://review.coreboot.org/10163
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring back the ability to link in the DSDT. This is to help Chrome OS to
switch over to a new upstream quickly (because some of the custom built
mechanisms are a pain with tons of files).
This is supposed to be temporary (famous last words), but I'd rather fix the
lack of CBFS awareness in CrOS bit for good in the time I usually spend on
keeping upstream and CrOS branches close.
Change-Id: I7fa5540bbf5c568c4adca56a09c83b6c7e358ad5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10637
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Move IASL up with the other tools.
- Remove OUT= which is no longer used in the
payloads/external/SeaBIOS Makefile.
Change-Id: I211ddcf3496b533151936fa5cbfa7a92986ec28f
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10606
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ife94f5324971f4fa03e9139f458b985f6fed9d87
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10577
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I29eaba74185711df055cf56c23ef2bdae0c7b43e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10578
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This does not optimize memcpy for 64bit, it merely makes it compile.
Change-Id: I69ad6bd0c3d5f617d9222643abf7a2ba7c2a0359
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10575
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Allow calls to cpu_phys_address_size and its support functions during
romstage. This enables the proper display of MTRRs during romstage
without duplicating this code.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: I6f6465c150a683ce91f1494ebb5d9ac60b75b795
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6bfd517088b6a2e8a5958a837e6c8c471de19fd0
Original-Change-Id: I429f9beb69298836acdd71d17a7bcb717939dfc2
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/277392
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10561
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ibcfdc08c9aac02fe263afd629fc262f71da80e9a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8695
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Almost all of the code between x86 and x64 can be shared, so select it for
either architecture.
Change-Id: I681149ed7698c08b702bb19f074f369699cef1bf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8693
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8692
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It's derived from EEPROM on Lenovo machines and not from user config
which is ignored.
Change-Id: I54fb76a3160e47cd36d33d2937c4bfaddcd36a69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7055
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
The type1 family setting from chromium was mis-merged into the
type2 function. Move it to the correct type1 function.
Bad commit: 51bdc47816
Change-Id: I72e6ef80bbf185a39fcf169c8247dc16462e6bc3
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10498
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
It can be helpful to certain users of the cbmem init hooks
to know if recovery was done or not. Therefore, add this
as a parameter to the hooks.
Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I1ba4bfa0ac36a09a82b108249158c80c50f9f5fd
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9599
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I7fca8c3fa15c1be672e50e4422d7ac8e4aaa1e36
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9598
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I3fc8e0339fa46fe92cc39f7afa896ffd38c26c8d
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9597
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds a few bit counting functions that are commonly needed
for certain register calculations. We previously had a log2()
implementation already, but it was awkwardly split between some C code
that's only available in ramstage and an optimized x86-specific
implementation in pre-RAM that prevented other archs from pulling it
into earlier stages.
Using __builtin_clz() as the baseline allows GCC to inline optimized
assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and
to perform constant-folding if possible. What was previously named log2f
on pre-RAM x86 is now ffs, since that's the standard name for that
operation and I honestly don't have the slightest idea how it could've
ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm
with Float result, whereas the Find First Set operation has no direct
correlation to logarithms that I know of). Make ffs result 0-based
instead of the POSIX standard's 1-based since that is consistent with
clz, log2 and the former log2f, and generally closer to what you want
for most applications (a value that can directly be used as a shift to
reach the found bit). Call it __ffs() instead of ffs() to avoid problems
when importing code, since that's what Linux uses for the 0-based
operation.
CQ-DEPEND=CL:273023
BRANCH=None
BUG=None
TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new
log2() and __ffs() results on Falco for a bunch of test values.
Change-Id: I599209b342059e17b3130621edb6b6bbeae26876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f
Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273008
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We test for it in xcompile and add it to CFLAGS.
Change-Id: I041a881b542bc55c1725af384f038da3356e3bb1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10426
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbfs_get_file_content was replaced with cbfs_boot_map_with_leak but
36f8d27ea9 failed to get it into account.
Change-Id: I0c7840043b2ea6abaf8e70f4bf1a63c96aedebc1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10403
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Makes it cleaner by putting AML into separate file rather than having
an array in C code.
Change-Id: Ia5d6b50ad9dabdb97ed05c837dc3ccc48b8f490f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10385
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This allows SeaBIOS to fill it as necessary.
This is needed to make BitLocker work.
Change-Id: I35858cd31a90c799ee1a240547c4b4a80fa13dd8
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10274
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use separate CBMEM allocations for stack and heap on S3 resume path.
The allocation of HIGH_SCRATCH_MEMORY is specific to AGESA and is moved
out of globals and ACPI. This region is a replacement for BIOS_HEAP_SIZE
used on non-resume paths.
Change-Id: I6658ce1c06964de5cf13b4e3c84d571f46ce76f3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10316
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The boot_device is a region_device that represents the
device from which coreboot retrieves and boots its stages.
The existing cbfs implementations use the boot_device as
the intermediary for accessing the CBFS region. Also,
there's currently only support for a read-only view of
the boot_device. i.e. one cannot write to the boot_device
using this view. However, a writable boot_device could
be added in the future.
Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10216
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This avoids the need to supply weak function and avoids associated risks of
forgetting to link in relevant files.
Change-Id: Ie96475babb4aa4ea8db49023af5b31bfa63b21dc
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7373
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Now that the users of cbmem_set_top() always provide a consistent
cbmem_top() value there's no need to have cbmem_set_top() around.
Therefore, delete it.
Change-Id: I0c96e2b8b829eddbeb1fdf755ed59c51ea689d1b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10314
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
On S3 resume, CBMEM_ID_CONSOLE from previous boot is found in ramstage,
even when romstage did not create it. So buffer did not get cleared
on S3 resume path.
Also do not allocate for preram_cbmem_console in CAR when there
are no means to back it up to ram.
Change-Id: I175cebbb938adf2a7414703fefffb8da796e9fa9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Implementation for cbmem_find() did not work for boards without
EARLY_CBMEM_INIT in romstage.
This is required for S3 resume to work on AGESA plaforms.
First broken with commit 0dff57d
cbmem: switch over to imd-based cbmem
Change-Id: I9c1a4f6839f5d90f825787baad2a3824a04b5bdc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10299
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
For x86 systems employing CONFIG_LATE_CBMEM_INIT, set_top_of_ram() is
called in ramstage to note the upper address of the 32-bit address
space. This in turn is consumed by cbmem. However, in this scenario
cbmem_top() cannot always be relied upon because get_top_of_ram()
doesn't return the same value provided to set_top_of_ram().
To fix the inconsistency in ramstage save the value passed in
to set_top_of_ram() and defer to it as the return value for
cbmem_top().
Change-Id: Ida796fb836c59b9776019e7f8b3f2cd71156f0e5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10313
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Export SLIC table from file in CBFS.
Change-Id: Id0e7fe0a49b9cd50b5e43cd15030e1c2098728ec
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7202
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
All boards now use per-device ACPI. This patch finishes migration
by removing transitional kludges.
Change-Id: Ie4577f89bf3bb17b310b7b0a84b2c54e404b1606
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7372
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
SLIT and SRAT are created this way only on amdk8 and amdfam10.
This saves the need of having a lot of dummies.
Change-Id: I76d042702209cd6d11ee78ac22cf9fe9d30d0ca5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7052
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Intermediate linking may distort linker behavior (in particular related to
weak symbols). The idea is that archives are closer to 'just a list of
object files', and ideally makes the linker more predictable.
Using --whole-archive, the linker doesn't optimize out object files just
because their symbols were already provided by weak versions. However it
shouldn't be used for libgcc, because that one has some unexpected side-effects.
Change-Id: Ie226c198a93bcdca2d82c02431c72108a1c6ea60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10139
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
There were some remaining places that used __PRE_RAM__ for
romstage, while it really means 'bootblock or romstage'.
Change-Id: Id9ba0486ee56ea4a27425d826a9256cc20f5b518
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10020
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This patch removes quite a bit of code duplication between cpu_to_le32()
and clrsetbits_le32() style macros on the different architectures. This
also syncs those macros back up to the new write32(a, v) style IO
accessor macros that are now used on ARM and ARM64.
CQ-DEPEND=CL:254862
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu,
Storm and Urara. Booted on Jerry. Tried to compare binary images...
unfortunately something about the new macro notation makes the compiler
evaluate it more efficiently (not recalculating the address between the
read and the write), so this was of limited value.
Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b
Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254866
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix build bug that is referencing vboot_data from
vendorcode/google/chromeos/gnvs.c when CONFIG_HAVE_ACPI_TABLES is not
set.
BRANCH=none
BUG=None
TEST=Build and run on Glados
1. Checkout updated patches for config, skylake and glados through
FspNotify1
2. Verify that mainboard/intel/glados/Kconfig does not select
HAVE_ACPI_TABLES
3. emerge-glados coreboot
4. Test passes if build completes successfully
Change-Id: Ida5ab8b8dafe30b11dc80dab935e3223d4c760d3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1908079360aa065a36956d487eb93142e9c012a1
Original-Change-Id: Icac3845f7e2d1ddffa5f787a640033fba286c13e
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/254360
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9825
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Expand the boot block include file to allow for a file containing reset
routines to be added. Prevent breaking existing platforms by using a
Kconfig value to specify the path to this file, and have the code
include this file only if the Kconfig value is set.
BRANCH=none
BUG=None
TEST=Build and run on Glados
Change-Id: I604f701057d7018f2ed9c3ba49a643c4bca13f00
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c109481d9503916e19ed300c1a3f085e0d2b5c51
Original-Change-Id: I3214399f8156b5ea2ef709ce77e3915cea1523a3
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/248300
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
SeaBIOS doesn't like CC and LD to contain arguments, so split
those out.
Change-Id: Id651719d529adfa8602a3e4f6685228330f36432
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9378
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kevin O'Connor <kevin@koconnor.net>
With kconfig understanding wildcards, we don't need
Kconfig files that just include other Kconfig files
anymore.
Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9298
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This allows combining and simplifying linker scripts.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ie5c11bd8495a399561cefde2f3e8dd300f4feb98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Drop the inner underscore for consistency. Follows the
commit stated below.
Change-Id: I75cde6e2cd55d2c0fbb5a2d125c359d91e14cf6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-on-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Based-on-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-on-Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-on: http://review.coreboot.org/9290
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Instead of keeping this separate variable around, add linker scripts
to the $(class)-y source lists and let the build system sort things out.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I4af687becf2971e009cb077debc902d2f0722cfb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9289
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
So far we assumed that all files in *-srcs are below src/
which wasn't really true actually and will be less true with
future changes.
Fix up crt0.S handling on x86, which is covered by default rules
due to this change.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Icae563c2d545b1aea809406e73faf3b417796a1b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9288
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The ldscript_ prefix is redundant.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I0f005c0c2abe2fdd6911a2c579cb7ec49ae5c0b7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9284
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of having different structures for loading
ramstage and payload align to using struct prog.
This also removes arch_payload_run() in favor of
the prog_run() interface.
Change-Id: I31483096094eacc713a7433811cd69cc5621c43e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8849
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The prog_run() function abstracts away what is required
for running a given program. Within it, there are 2
calls: 1. platform_prog_run() and 2. arch_prog_run().
The platform_prog_run() allows for a chipset to intercept
a program that will be run. This allows for CPU switching
as currently needed in t124 and t132.
Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8846
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The struct prog serves as way to consolidate program
loading. This abstraction can be used to perform more
complicated execution paths such as running a program
on a separate CPU after it has been loaded. Currently
t124 and t132 need to do that in the boot path. Follow
on patches will allow the platform to decide how to
execute a particular program.
Note: the vboot path is largely untouched because it's
already broken in the coreboot.org tree. After getting
all the necessary patches pushed then vboot will be
fixed.
Change-Id: Ic6e6fe28c5660fb41edee5fd8661eaf58222f883
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8839
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
It's an unfortunate side effect of our different-archs-per-stage
mechanism that all src/arch/*/Kconfig files are always parsed with no
if blocks to exclude them if they're not relevant. This makes it very
easy to accidentally rely on a Kconfig default set by a totally
different and not applying architecture.
This patch moves a few Kconfigs from ARM and X86 that leaked out like
this into a common Kconfig file for clarity. It also gives ARM64 its
own BOOTBLOCK_CUSTOM mechanism so that it doesn't leech off the ARM one
(currently not used by any board).
In the future, we should maybe prefix all options in the arch/*/Kconfig
files with the architecture name (such as X86_BOOTBLOCK_NORMAL and
ARM_LPAE are already doing), to make it more apparent when they are used
in the wrong place.
BUG=None
TEST=None (tested together with dependent changes)
Change-Id: I3e8bb3dfbb2c4edada621ce16d130bd7387d4eb8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5528aa9252cdf711af3c160da387c6a7bebe9e76
Original-Change-Id: Ieb2d79bae6c6800be0f93ca3489b658008b1dfae
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219171
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9235
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It also creates file names in the build directory and with
the stage sliced in, but keeps the extension for anything
not .c or .S.
Also some handling for non-.c/.S files was adapted to match.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: If8f89a7daffcf51f430b64c3293d2a817ae5120f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9175
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
mosys will use this field to identify system
BRANCH=none
BUG=chromium:359155
TEST=build ok, use dmidecode to check whether data is
written correctly
Change-Id: I461215c012b6ad712b3f813a3928e90a23bf54f1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7adbdab761cd7b4bda0a43e7b1c4070de26f150a
Original-Change-Id: Icfbd4c61fc49a9cb3d3ecd2b622339957963150c
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217400
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9230
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of relying on the CBFS header's romsize field use
the CONFIG_ROM_SIZE Kconfig variable. That value is what is
used to create the rom file as it is. Therefore, just remove
the dependency.
Change-Id: If855d7378df20080061e27e4988e96aee233d1e0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9130
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The serialized format of CBFS is separate from the APIs
used to traverse and read from CBFS. Separate those out
so they can be consumed as a standalone header.
Change-Id: I09f71d9c474ee9f23a62b0062ffa777963d1a4dd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9125
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ia22c9fcbf8c629d0eb3f1356f80c4565f117d8b8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9110
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have .lb, .lds, and .ld in the tree. Go for .ld everywhere.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I3126af608afe4937ec4551a78df5a7824e09b04b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9107
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add smbios type 17 which can optionally be implemented
at the platform or mainboard level
In order to create SMBIOS type17, you will need to fill
memory_info data
BUG=None
BRANCH=None
TEST=Compile successfully on rambi and samus
Boot to chromeOS on samus and rambi
Original-Change-Id: Ie4da89135c879d7a687305d423103fcfcbb96e3f
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/210005
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 634b899ba41242caa800d7b570f3a339c738db77)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I61d1e8b1d32d43f0011b0f93966d57646ea0eb63
Reviewed-on: http://review.coreboot.org/8955
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When adding gargabe collection to x86 the --gc-sections
flags was inadvertently missed when linking romstage_null.debug.
Fix this omission.
Change-Id: I7d2700755afa78459c6f8707303a0e64936a1a9f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8850
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Instead of two headers for payload and ramstage loading
combine the 2 files into one. This also allows for easier
refactoring by keeping header files consistent.
Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8708
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The GCC 4.9.2 update showed that the boot_state_init_entry
structures were being padded and assumed to be aligned in to an
increased size. The bootstate scheduler for static entries,
boot_state_schedule_static_entries(), was then calculating the
wrong values within the array. To fix this just use a pointer to
the boot_state_init_entry structure that needs to be scheduled.
In addition to the previous issue noted above, the .bs_init
section was sitting in the read only portion of the image while
the fields within it need to be writable. Also, the
boot_state_schedule_static_entries() was using symbol comparison
to terminate a loop which in C can lead the compiler to always
evaluate the loop at least once since the language spec indicates
no 2 symbols can be the same value.
Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add license header with copyright of the original authors.
Change-Id: I8c55bb38a2a2a387ad2461e11d402c7392fa2497
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8691
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There is nothing platform specific in retrieving S3 resume state from
romstage_handoff structure. Boards without EARLY_CBMEM_INIT update
acpi_slp_type from ACPI power-management block or scratchpad registers.
Change-Id: Ifc3755f891a0810473b3216c1fec8e45908fc1ab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8188
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This was added to handle cases of Intel FSP platforms that had
EARLY_CBMEM_INIT but could not migrate CAR variables to CBMEM.
These boards were recently fixed.
To support combination of EARLY_CBMEM_INIT without CAR migration was
added maintenance effort with little benefits. You had no CBMEM
console for romstage and the few timestamps you could store were
circulated via PCI scratchpads or CMOS nvram.
Change-Id: I5cffb7f2b14c45b67ee70cf48be4d7a4c9e5f761
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8636
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The CAR macros and the associated functions are only employed
under the following conditions:
- chipsets which have CAR
- compilation during romstage
Therefore clean up the build-time conditionals to use those 2
constructs.
Change-Id: I2b923feeb68f2b964c5ac57e11391313d9c8ffc5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8634
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
All boards in tree use 0. Looks like this is all work that was
never completed and tested.
We also have static setting sysconf.segbit=0 which would conflict
with PCI_BUS_SEGN_BITS>0.
Having PCI_BUS_SEGN_BITS>0 would also require PCI MMCONF support
to cover over 255 buses.
Change-Id: I060efc44d1560541473b01690c2e8192863c1eb5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8554
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
As a convenience, print the actual stage name when entering a stage.
Also unify the banner between bootblock / romstage and ramstage. No
reason for two different occurences.
Instead of this:
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 booting...
you will see this:
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 bootblock starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 romstage starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 ramstage starting...
Roughly based on: https://chromium-review.googlesource.com/199671
Change-Id: Id5894535e0551d113c80e4ff0514287391be1bef
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8578
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The change in commit 5636237 allows */cpu/amd/agesa/* to be removed.
TEST: Booted the amd/parmer board.
Change-Id: I8d2d2639f8e5f3b1dd58be96be98db0eff7b268f
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8505
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The existing code generated invalid ACPI processor objects
if the core number was greater than 9. The first invalid
object instance was autocorrected by Linux, but subsequent
instances conflicted with each other, leading to a failure
to boot if more than 10 CPU cores were installed.
The modified code will function with up to 99 cores.
Change-Id: I62dc0eb61ae2e2b7f7dcf30e9c7de09cd901a81c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8422
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
In specific configurations, such as homogeneous supercomputing systems,
changeable NVRAM parameters are more of a liability than a useful tool.
This patch allows a coreboot image to be compiled that will always set
the NVRAM parameters to their default values, reducing maintainance
overhead on large clusters.
Change-Id: Ic03e34211d4a58cd60740f2d9a6b50e11fe85822
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8446
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On x86, change the type of the address parameter in
read8()/read16/read32()/write8()/write16()/write32() to be a
pointer, instead of unsigned long.
Change-Id: Ic26dd8a72d82828b69be3c04944710681b7bd330
Signed-off-by: Kevin Paul Herbert <kph@meraki.net>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7784
Tested-by: build bot (Jenkins)
The "used" attribute was added in commit 27cf2472 which caused these
warnings to start appearing when using the standard coreboot GCC
toolchain:
{standard input}: Assembler messages:
{standard input}:96: Warning: ignoring changed section type for .car.global_data
{standard input}:96: Warning: ignoring changed section attributes for
.car.global_data
The # at the end of the section name causes the assembler to
ignore everything following the name. I verified that the resulting
binaries are the same with and without the #.
Change-Id: Iaac8042533842ed887f33895f083b613a18f496a
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8301
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Although bool normally belongs in stdbool.h, for our use cases,
providing these definitions in stdint.h is acceptable.
Change-Id: I1d0ca1018efacc27d7a4a72aa452912e004401f9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8279
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.
Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
We can now create CBMEM with dynamic allocation even if CBMEM
location is resolved late in ramstage.
Change-Id: I8529ccbcd4a0e567ebe0a46232ac5d16476e81a8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7861
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
The name was always obscure and confusing. Instead define cbmem_top()
directly in the chipset code for x86 like on ARMs.
TODO: Check TSEG alignment, it used for MTRR programming.
Change-Id: Ibbe5f05ab9c7d87d09caa673766cd17d192cd045
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7888
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Move the CAR migration call to arch -specific part of CBMEM init,
it is truly a x86 specific thing.
Change-Id: I715417e54f197b8745e0670d6b900a5660178141
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7860
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
In preparation to remove the static CBMEM allocator, tag the chipsets
that still do not implement get_top_of_ram() for romstage.
LATE_CBMEM_INIT also implies BROKEN_CAR_MIGRATE.
Change-Id: Iad359db2e65ac15c54ff6e9635429628e4db6fde
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7850
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This avoids the need for separate timestamp_reinit() calls made
via CAR_MIGRATE() that is not implemented for ARM.
Change-Id: Ia683162f3cb5d3cb3d4b7983a4b7e13306b0cfc8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8033
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This replaces need for separate cbmemc_reinit() calls made
via CAR_MIGRATE() and in ramstage.
Change-Id: If7b4d855c75df58b173f26ef3c90a4a7563166d3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7859
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
With the change it becomes irrelevant if memcpy() car.global_data or
cbmemc_reinit() is done first.
Change-Id: Ie479eef346c959e97dcc55861ccb0db1321fb7b2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8032
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Until we completely can unify early_variables, use these to
handle CBMEM update hooks for both romstage and ramstage.
For x86, CAR_MIGRATE serves the purpose of romstage hooks.
Change-Id: I100ebc0e35e1b7091b4f287ca37f539fd7c9fa7a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7876
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This reverts the revert commit 5780d6f387
and fixes the build issue that cuased it to be reverted.
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains,
compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the
boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with
verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf
Reviewed-on: http://review.coreboot.org/8224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Because we had no stack on romcc boards, we had a separate, not as
powerful clone of printk: print_*.
Back in the day, like more than half a decade ago, we migrated a lot
of boards to printk, but we never cleaned up the existing code to be
consistent. Instead, we worked around the problem with a very messy
console.h (nowadays the mess is hidden in romstage_console.c and
early_print.h)
This patch cleans up the generic code pieces to use printk() on all
non-ROMCC boards.
Our two remaining ROMCC boards are fixed up in this commit:
bifferos/bifferboard and dmp/vortex86ex.
Change-Id: I16676eeabe5c892c8e3c9f3c0cd3bae2e8fd74b6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8115
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Cherry-pick from chromium and adjusted for added boards
and changed directory layout for arch/arm.
Timestamp implementation for ARMv7
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Original-Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Original-Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Original-Reviewed-on: https://gerrit.chromium.org/gerrit/63793
(cherry-picked from commit cc1a75e059020a39146e25b9198b0d58aa03924c)
Change-Id: Ic51fb78ddd05ba81906d9c3b35043fa14fbbed75
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8020
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
- @v & @i need to be @param v & @param i
- add the @file command
Change-Id: Ib4fb609629bc2dfcf1869bdf7a4d4cd9fea283cc
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/8075
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
We relocate GDT to CBMEM, this can be done late in ramstage.
Note: We currently do this for BSP CPU only.
Change-Id: I626faaf22f846433f25ca2253d6a2a5230f50b6b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7858
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Always build CBMEM for romstage, even for boards that will not use it.
We further restrict car_migrate_variables() runs to non-ROMCC boards without
BROKEN_CAR_MIGRATE.
This fixes regression of commit 71b21455 that broke CBMEM console support
for boards with a combination of !EARLY_CBMEM_INIT && !HAVE_ACPI_RESUME.
Change-Id: Ife91d7baebdc9bd1e086896400059a165d3aa90f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7877
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
After relocation the weak symbols are no longer NULL.
Always have empty stub function defined.
Change-Id: I6cb959c1fa10b4b63018e400636842e2a15d6e81
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7955
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This one is special because qemu is really far from anything real but
shares some common features.
Change-Id: Ia1631611724a074780e1fece50166730b2ee94ae
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6939
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The arm architecture currently exports cache_sync_instructions()
in <arch/cache.h>. In order for rmodule loading to work on arm
architectures the cache_sync_instructions() needs to be called to
sequence the instruction cache. To avoid sprinkling #ifdefs around
just add an empty cache_sync_instructions() definition.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built and booted nyan and rambi.
Original-Change-Id: I1a969757fffe0ca92754a0d953ba3630810556e3
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/191551
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit fda20947b928ee761d5ed15e414636af419970a6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3e8ca12e1d82ccedf1ff9851ae3c5c80cda2dd5f
Reviewed-on: http://review.coreboot.org/7710
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a section .illegal_globals to romstage and check that the section does not
contain any variables while creating romstage.
[pg: Handle individual AGESA special cases in the
linker script instead of whitelisting everything
remotely AGESA related in the Makefile.]
Change-Id: I866681f51a44bc21770d32995c281b556a90c153
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7306
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There were instances of unneeded arch/hlt.h includes,
various hlt() calls that weren't supposed to exit (but
might have) and various forms of endless loops around
hlt() calls.
All these are sorted out now: unnecessary includes are
dropped, hlt() is uniformly replaced with halt() (except
in assembly, obviously).
Change-Id: I3d38fed6e8d67a28fdeb17be803d8c4b62d383c5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7608
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
No need to keep that just because x86 has one
extra linking step.
Change-Id: Iffdbf64e0613f89070ed0dfb009379f5ca0bd3c1
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7611
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
No need to pass calls through gcc in one case and
directly to binutils in another. Just always call
binutils.
Change-Id: Icf9660ce40d3c23f96dfab6a73c169ff07d3e42b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7610
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Let's just call ld directly for gcc, too.
Change-Id: I305eb92ed0d21b098134a7eb5a9f9fe3b126aeea
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7553
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We build with either gcc or clang, no need to keep both around
Change-Id: I9af2cc7636bdc791a68ba8ed6e7c5a81973c5dfd
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7552
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
As build.h is an auto-generated file it was necessary to add it as
an explicit prerequisite in the Makefiles. When this was forgotten
abuild would sometimes fail with following error:
fatal error: build.h: No such file or directory
Fix this error by compiling version.c into all stages.
Change-Id: I342f341077cc7496aed279b00baaa957aa2af0db
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7510
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The sequence of bytes to create a method is used several times in codebase.
Put it into a function with logical arguments rather than duplicating magic
bytes everywhere.
Change-Id: I2c33fa403832eb1cfadfbf8d9adef5b63fb9cb24
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7348
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
The sequence of bytes to create a method is used several times in codebase.
Put it into a function with logical arguments rather than duplicating magic
bytes everywhere.
Change-Id: I0e55d8dc7d5e8e92a521c7a83117c470d0614008
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7347
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
There are no reasons to not load ramstage @ 0x100000.
Boards with HAVE_ACPI_RESUME enabled have performance penalty in using
excessive RAMTOP. For these boards, this change releases 11 MiB of RAM from CBMEM allocation to OS.
Change-Id: Ib71995aba5e9332d0ec1626b3eb3b4ef6a506d1c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7094
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Otherwise clang feels free to optimize away that variable
(somewhat) and revive it in a different form inside .bss.
They probably have the language lawyery excuse for why
that's perfectly legal, so let's play it safe.
(relevant URL, sorry ron: http://llvm.org/bugs/show_bug.cgi?id=9520)
Change-Id: I603312ceea7207088dd29453cc8fb8f48c31af21
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7357
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
acpigen_patch_len doesn't really need its argument: length always includes
everything from length bytes to current pointer and never bytes before it.
Hence just infer all the info implicitly.
Argument is wrong in several places through the codebase but ACPI parsing
is lax enough to swallow incorrect SSDT. After this function is used throughout
the codebase, these issues will be fixed.
Change-Id: I9fa536a614c5595146a7a1cd71f2676d8a8d9c2f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7325
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Do all the handling in SB code with few parameters from devicetree.cb
instead of having mobo callbacks.
Change-Id: I8fd02ff05553a3c51ea5f6ae66b8f5502509e2bc
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7199
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We don't want segment for .car.data section to be considered while elf_to_stage
transformation is being done. Thus, use -S option for add-stage.
Change-Id: I04868c892e3aa94113189b012d284d52bacea5f0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/7305
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Make use of '-print-librt-file-name' over '-print-libgcc-file-name'
to use Compiler-RT runtime glue over libgcc glue.
NOTE: *** Requires at least clang 3.6.x
Change-Id: I7f63284473d6067bf775409970c8dd98f5d5a8d5
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6144
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
'pci_devfn_t' and 'pnp_devfn_t' are already defined in arch/io.h
Change-Id: I006182bf6933fae21fe6671659b76e7031e74b71
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6230
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
These allocations are not really part of write_tables() and the move
opens possibilities to use CBMEM instead of SPI Flash to restore some
parts of system state after S3 resume.
Change-Id: I0c36bcee3f1da525af077fc1d18677ee85097e4d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7097
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Nowhere in database p_state_num is set. So this whole function ends up
being a noop. Moreover the offsets used by it are wrong with any
optimizing iasl. Remove it in preparation of move to per-device ACPI.
Change-Id: I1f1f9743565aa8f0b8fca472ad4cb6d7542fcecb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7012
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
As currently many systems would be barely functional without ACPI,
always generate ACPI tables if supported.
Change-Id: I372dbd03101030c904dab153552a1291f3b63518
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4609
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Windows chokes if it's not the case.
Change-Id: I3df15228ed00c3124b8d42fc01d7d63ff3fe07ba
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7017
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
With handling of this section removed it confused the linker.
Change-Id: Id096c1642c0bfed1007a4b7d7dfa89f8b4ffcae1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7042
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Otherwise "reserved" fields end up with a garbage instead of predictable
value.
Change-Id: I8a036769a8f86f1d6752651601de2800f4f1bd00
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7014
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
On non-x86 systems, the location of the preram CBMEM console may not be in a
predictable place relative to other things in the linker script. That makes it
difficult to work with as its own section because the linker will complain if
you try to move backwards as it lays out memory. If the console header is
treated as an actual blob of memory which has to be put in the image, we'd
have to predict where to put it so that it isn't before something with a lower
address or after something with a higher address. Symbols, on the other hand,
can be defined arbitrarily.
Change-Id: I3257b981eee0c15bb997a9f2c55a03494c6ec6f0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193164
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a492761c27076bcac080013d509ae4aafd6dc3e3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7013
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds stub implementations of exception_init() to all archs
so that it can be called from src/lib/hardwaremain.c. It also moves/adds
all other invocations of exception_init() (which needs to be rerun in
every stage) close to console_init(), in the hopes that it will be less
likely overlooked when creating future boards. Also added (an
ineffective) one to the armv4 bootblock implementations for consistency
and in case we want to implement it later.
Change-Id: Iecad10172d25f6c1fc54b0fec8165d7ef60e3414
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176764
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 2960623f4a59d841a13793ee906db8d1b1c16c5d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6884
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Add the option to coreboot to set the SeaBIOS buffers below 0xC0000.
This is a requirement on the Intel Rangeley processor
because it is designed so that only the processor can write
the higher memory areas. This prevents USB and SATA from bus-mastering
into the buffers when they're set in the typical 0xE0000 area.
This will be set to Y unless defaulted to N by the mainboard or
chipset.
Push the SeaBIOS buffers down to 0x90000 segment for Mohon Peak
Change-Id: I15638605d1c66a2277d4b852796db89978551a34
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6364
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Unlike in old style CBMEM, dynamic CBMEM does not have a
hand-calculated, hard-coded size, so allow up to 144K of
space for ACPI tables.
Change-Id: Id9dd7447c46d5fe7ed581be753d70e59add05320
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/6795
Tested-by: build bot (Jenkins)
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This approach avoids having same basic tables 150-lines mantra over 100 times
in codebase.
Change-Id: I76fb2fbcb9ca0654f2e5fd5d90bd62392165777c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6801
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
OEM strings should not be handled by mobo code but by common code with strings
collected from all devices.
Change-Id: Ibde61a1ca79845670bc0df87dc6c67fa868d48a9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6788
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
