| Age | Commit message (Collapse) | Author |
|---|
|
Create the way of adding the discrete VGA OpROM at config UI (alternative to
./cbfstool ./cb.rom add -f vgabios_dgpu.bin -n pci1002,6663.rom -t optionrom )
DGPU options are accessible only if CONFIG_VGA_BIOS is enabled.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I0a7bf0fe95c833cf3df0c7cb20fc27b6ab218c5a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The current implementation was designed for x86_32, so don't
attempt to compile it on x86_64 until it is fixed.
Fixes compilation error on x86_64.
Change-Id: Ibd87dc2979f6d45a988119c06c5f9e61b3e86171
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/31467
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Link walkfcbfs.S in the C_ENVIRONMENT_BOOTBLOCK case and also in the
romstage.
This is useful for cbfs access in pre-CAR environments.
Change-Id: I9a17cdf01c7cbc3c9ac45ed1f075731f3e32f64b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/30681
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Also remove global ramstage-y += get_bus_conf.c, this is
specific to amdfam10.
Change-Id: I49b604ebff6bcfe85518b2c3896ab798c3c7878d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Platforms with SSE=y or SSE2=y will invoke romcc with -mcpu=k7.
This implicitly enabled romcc to consume MMX registers, if XMM
set was consumed first.
Explicitly tell romcc not to clobber MMX set.
Change-Id: I37f1d6ea01873036712dfbb32bb1dcd5d769e85d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Link 32bit ramstage if CONFIG_ARCH_RAMSTAGE_X86_32 is set.
Required for 64bit ramstage support.
Change-Id: Ib0c06f494dcc035d182ab9034e910ceceb236198
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/29878
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Fixes building vb2lib for postcar. Since postcar is an x86ism, add the
Kconfig options only for x86.
Change-Id: Ib92436bc7270c24689dcf01a47f0c6fe7661814b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/29395
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It's very common across many x86 silicon vendors, so place it in
`arch/x86/`.
Change-Id: I06c27afa31e5eecfdb7093c02f703bdaabf0594c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Currently src/mainboard/*/romstage.c is mandatory for compiling,
this makes having the file present even though there is nothing to
initialize in romstage on the mainboard side. Eliminate the need to
have empty romstage.c files using the wildcard function.
BUG=None
BRANCH=None
TEST= build cannonlake_rvp after removing the romstage.c file.
Change-Id: Id6335a473d413d1aa89389d3a3d174ed4a1bda90
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/28849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
|
|
Add code for generating the region pointed to in an ACPI Boot Error
Record Table.
The BERT region must be reported as Reserved to the OSPM, so this
code calls out to a system-specific region locator. cbmem is
reported as type 16 and is not usable for the BERT region.
Events reported via BERT are Generic Error Data, and are constructed
as follows (see ACPI and UEFI specs for reference):
* Each event begins with a Generic Error Status Block, which may
contain zero or more Generic Data Entries
* Each Generic Data Entry is identifiable by its Section Type field,
and the data structures associated are also in the UEFI spec.
* The GUIDs are listed in the Section Type field of the CPER
Section Descriptor structure. BERT doesn't use this structure
but simply uses its GUIDs.
* Data structures used in the Generic Data Entry are named as
Error Sections in the UEFI spec.
* Some sections may optionally include a variable number of
additional structures, e.g. an IA32/X64 processor error
can report error information as well as machine contexts.
It is worth noting that the Linux kernel (as of v4.4) does not attempt
to parse IA32/X64 sections, and opts to hexdump them instead.
BUG=b:65446699
TEST=inspect BERT region, and dmesg, on full patch stack. Use test
data plus a failing Grunt system.
Change-Id: I54826981639b5647a8ca33b8b55ff097681402b9
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/28470
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We already explicitly generated a dependencies file for the romcc
bootblock. Though, as it has its own rule and isn't registered
to any of our object-file classes, the dependencies file wasn't
included automatically.
Change-Id: I441cf229312dff82f377dcb594939fb85c441eed
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/28442
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I24d219b4ce6033f64886e22973ca8716113d319f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/27919
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ia75205001f2443cb8221a0762f182aae01ee615e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/26924
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Remove the last bits of building romstage with romcc.
Change-Id: I70bb1ed23a5aeb87bf7641e0b0bd604a4e622e61
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/26807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This commit adds support for writing ACPI _PLD structures that
describe the physical location of a device to the OS.
This can be used by any device with a physical connector, but is
required when defining USB ports for the OS.
A simple function is provided that generates a generic _PLD
structure for USB ports based on the USB port type.
Change-Id: Ic9cf1fd158eca80ead21b4725b37ab3c36b000f3
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/26171
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
MMConf is not architecture specific. We also always provide a
pci_bus_default_ops() now if MMCONF_SUPPORT is selected.
Change-Id: I3f9b403da29d3fa81914cc1519710ba7d1bf2bb5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26062
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In each stage keep GDT in the code region. This accommodates
platforms, such as glk, that are executing out of CAR. The
gdt is small and loading it is trivial so just do it unconditionally
instead of introducing another Kconfig.
BUG=b:78656686
Change-Id: I01ded6e9b358b23e04d92bef5263bfe8c2a5ec5a
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25895
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
Move x86 specific pci_bus_default_ops into arch/x86 folder.
Fixes compilation on platforms that do neither have MMCONF_SUPPORT
nor NO_MMCONF_SUPPORT (for example: all non-x86) but select PCI.
Change-Id: I0991ab00c9a56b23cd012dd2b8b861f9737a9e9c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add Kconfig IDT_IN_EVERY_STAGE to optionally specify having
the interrupt handling code available to all stages. In order
to do this the idt setup is moved to a C module. The vecX
entries are made global so that a table of references to all
the interrupt vector entry points can be used to dynamically
initialize the idt. The ramification for ramstage is that
exceptions are initialized later (lib/hardwaremain.c). Not
all stages initialize exceptions when this Kconfig variable
is selected, but bootblock for the C, stages using
assembly_entry.S, and of course ramstage do. Anything left
out just needs a call to exception_init() at the right
location.
BUG=b:72728953
Change-Id: I4146a040e5e43bed7ccc6cb0a7dc2271f1e7b7fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Currently the idt setup and handling is only in ramstage. In
order to prepare having an exception handler in other stages
move the interrupt vector entry code to its own compilation
unit. vec0 and int_hand need to be global so c_start.S
references will resolve at link time.
BUG=b:72728953
Change-Id: I435b96d987d69fb41ea27a73e2dd634b5d6ee3d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Some x86 platforms don't have a TSC that is invariant w.r.t.
rate to get accurate timestamps. As such a different timestamp
is required. Therefore, allow one to specify non-TSC timestamp
source and not compile in the default x86 TSC code.
BUG=b:72378235,b:72170796
Change-Id: I737fcbba60665b3bc2b5864269536fda78b44d90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
All boards and chips that are still using LATE_CBMEM_INIT are being
removed as previously discussed.
If these boards and chips are updated to not use LATE_CBMEM_INIT, they
can be restored to the active codebase from the 4.7 branch.
chips:
cpu/intel/socket_mFCBGA479
northbridge/intel/i82830
Mainboards:
mainboard/rca/rm4100
mainboard/thomson/ip1000
Change-Id: I9574179516c30bb0d6a29741254293c2cc6f12e9
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/22032
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
This patch provides a kconfig option as EARLY_EBDA_INIT to
ensures user can make use of EBDA library even during early
boot stages like romstage, postcar.
Change-Id: I603800a531f56b6ebd460d5951c35a645fbfe492
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/21388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch ensures acpi APIs are available for postcar
stage.
Change-Id: Ia0f83cd4886ba7a16286dbbeb3257ede014ee3c7
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/21626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Boards with CBMEM_TOP_BACKUP=y can also use POSTCAR_STAGE
for MTRR setup after adding this file in the build.
Change-Id: I5f9a673ff59ccfbba16308d27f653f5cf3b49017
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/21445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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 romstage files into the romstage section of the file.
Eliminate duplicate conditional statements.
TEST=None
Change-Id: Ie2d65cef3797a2c091c0cd76b147b30a765332ad
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15891
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
There is nothing to backup with RELOCATABLE_RAMSTAGE.
Change-Id: I780a71e48d23e202fb0e9c70e34420066fa0e5b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15243
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>
|
|
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>
|
|
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>
|
|
It's unused.
Change-Id: I50af2b50d2c5a7a24afe9099c5c01d17ce54a6c9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14569
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It isn't used anymore.
Change-Id: Ie554d1dd87ae3f55547466e484c0864e55c9d102
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14567
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.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>
|
|
When CONFIG_X86_TOP4G_BOOTMEDIA_MAP was introduced verstage
was not updated. Correct this oversight.
Change-Id: I2775c08798906ba0ba55a361407d7d2b52313229
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14142
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
|
|
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>
|
|
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)
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
$(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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I15375ac1247b7cc8d80d910a767c7f3e67eb8739
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11904
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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)
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: I5efd3cb3e6970b5740f740507244a1ab823e0bb6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10590
Tested-by: build bot (Jenkins)
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>
|
|
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>
|
|
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>
|
|
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 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>
|
|
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)
|
|
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>
|
|
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>
|
|
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>
|
