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>
Most devices do not use SPI before they initialize CBMEM. This change
initializes spi_flash in the CBMEM_INIT_HOOK to initialize the postram
cbfs cache so it is not overwritten when boot_device_init is called
later.
BUG=chromium:210230
BRANCH=none
TEST=confirm that the first cbfs access can occur before RAM initialized
and after on panther and jerry.
Change-Id: If3b6efc04082190e81c3773c0d3ce116bb12421f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0ab242786a16eba7fb423694f6b266e27d7660ec
Original-Change-Id: I5f884b473e51e6813fdd726bba06b56baf3841b0
Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/314311
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12601
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add post codes for the various FSP phases and use them as appropriate
in FSP 1.0 and 1.1 implementations.
This will make it more consistent to debug FSP hangs and resets.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados and chell
Change-Id: I32f8dde80a0c6c117fe0fa48cdfe2f9a83b9dbdf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3b616ff3c9d8b6d05c8bfe7f456f5c189e523547
Original-Change-Id: I081745dcc45b3e9e066ade2227e675801d6f669a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/313822
Original-Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12595
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently the CBFS mmap cannot be accessed at the beginning of romstage
because it waits until DRAM is initialized. This change first loads CBFS
into SRAM and then switches to using DRAM as the backing once it is
initialized.
BUG=chromium:210230
BRANCH=none
TEST=confirm that the cbfs can be access at the beginning and end of
romstage on different boards.
Change-Id: I9fdaef392349c27ba1c19d4cd07e8ee0ac92dddc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ccaaba266386c7d5cc62de63bdca81a0cc7c4d83
Original-Change-Id: Idabfab99765b52069755e1d1aa61bbee39501796
Original-Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312577
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Hiding them requires #if CONFIG_HAVE_SMI_HANDLER instead of
if (IS_ENABLED(CONFIG_HAVE_SMI_HANDLER))
Change-Id: Ib874cd98e195ad7437d05be1696004b29bf97a66
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://review.coreboot.org/12565
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move the #ifdef chain to set the stage name to rules.h.
Change-Id: I577ddf2de4ef249a1a4ce627bb55608731a9f5ed
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: http://review.coreboot.org/12479
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch expands the existing ENV_<stage> macros in <rules.h> with a
set of ENV_<arch> macros which can be used to detect which architecture
the current compilation unit is built for. These are more consistent
than compiler-defined macros (like '#ifdef __arm__') and will make it
easier to write small, architecture-dependent differences in common code
(where we currently often use IS_ENABLED(CONFIG_ARCH_...), which is
technically incorrect in a world where every stage can run on a
different architecture, and merely kinda happened to work out for now).
Also remove a vestigal <arch/rules.h> from ARM64 which was no longer
used, and genericise ARM subarchitecture Makefiles a little to make
things like __COREBOOT_ARM_ARCH__ available from all file types
(including .ld).
BUG=None
TEST=Compiled Falco, Blaze, Jerry and Smaug.
Change-Id: Id51aeb290b5c215c653e42a51919d0838e28621f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12433
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.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)
HDMI driver need to know whether the monitor is DVI
or HDMI interface, so this commit just introduce a
new number 'hdmi_monitor_detected' to struct edid.
There were four bits to indicate the monitor interfaces,
it's better to take use of that. But those bits only
existed in EDID 1.4 version, but didn't persented in
the previous EDID version, so I decided to detect the
hdmi cea block.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'.
When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'.
Change-Id: I1a4f1410e1cce1474ffae858db161a18578cac3a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 409f041805d9fdff2d49faa1a3a262cf4dc609c2
Original-Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309055
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's been decided to only support ARM Trusted Firmware for
any EL3 monitor. That means any SoC that requires PSCI
needs to add its support for ATF otherwise multi-processor
bring up won't work.
Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11897
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Per IRC and Gerrit discussion, the normal / fallback
selector code is a rather weak spot in coreboot, and
did not function correctly for certain use cases.
Rework the selector to more clearly indicate proper
operation, and also remove dead code. Also tentatively
abandon use of RTC bit 385; a follow-up patch will
remove said bit from all affected mainboards.
The correct operation of the fallback code selector
approximates that of a power line recloser, with
a user option to attempt normal boot that can be
cleared by firmware, but never set by firmware.
Additionally, if cleared by user, the fallback
path should always be used on the next reboot.
Change-Id: I753ae9f0710c524875a85354ac2547df0c305569
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12289
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to not expose the cbmem data structures to userland
that are used by coreboot internally add each of the cbmem
entries to a coreboot table record. The payload ABI uses
coreboot tables so this just provides a shortcut for cbmem
entries which were manually added previously by doing the
work on behalf of all entries.
A cursor structure and associated functions are added to
the imd code for walking the entries in order to be placed
in the coreboot tables. Additionally a struct lb_cbmem_entry
is added that lists the base address, size, and id of the
cbmem entry.
BUG=chrome-os-partner:43731
BRANCH=None
TEST=Booted glados. View coreboot table entries with cbmem.
Change-Id: I125940aa1898c3e99077ead0660eff8aa905b13b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11757
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
TEST: Booted ASUS KGPE-D16 with single Opteron 6380
* Unbuffered DDR3 DIMMs tested and working
* Suspend to RAM (S3) tested and working
Change-Id: Idffd2ce36ce183fbfa087e5ba69a9148f084b45e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11966
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@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>
There are some inconsistencies in AMDs APIs between the coreboot
code and the vendorcode code. Unify the API.
UINTN maps to uintptr_t in UEFI land. Do the same
here. Also switch the other UEFI types to map to
fixed size types.
Change-Id: Ib46893c7cd5368eae43e9cda30eed7398867ac5b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10601
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some platforms do not have `timer_monotonic_get()` implemented. So only
call `timer_monotonic_get()` if `CONFIG_HAVE_MONOTONIC_TIMER` is
selected and set the times to 0 otherwise.
Change-Id: If9cba4c0c17a7011aa357079d8fdd0aa47ad1b66
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/12105
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is to support other gfx enable method such as Gfx Peim (AKA GOP)
for Intel soc.
BRANCH=none
BUG=chrome-os-partner:44559
TEST=Built and boot on kunimitsu/glados.
Change-Id: Ib8010ea6901ea906a8b4129807b94ace71ef1165
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ad26a99560009c487070cccf6ab132188b9e247d
Original-Change-Id: Id132718a8bcec5446cc4c0d9d636d26e8a99bb15
Original-Signed-off-by: robbie zhang <robbie.zhang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/303801
Original-Commit-Ready: Robbie Zhang <robbie.zhang@intel.com>
Original-Tested-by: Robbie Zhang <robbie.zhang@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To help hypervisors to assign PCI devices individually to virtualization
guests, page align dynamically allocated MMIO resources.
Tested with kontron/ktqm77 which has dynamically configured onboard
devices on the root bus and secondary buses. Booted Linux and checked
the configuration with `lspci -v`. Got the configuration through Muen's
tools which are very picky about overlapping and alignment. Booted a
Muen based system that uses many onboard devices. GMA, xHCI and one NIC
(on a secondary bus) were verified to function properly.
Change-Id: I2b7115070e1ccad64565feff025289732c3b5e66
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12111
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The conditions in cbmem console for supporting verstage
were implicitly utilizing CONFIG_BOOTBLOCK_CONSOLE to handle
the cbmem console enablement. Fix it so verstage is a first
class citizen for deciding actions pertaining to cbmem console.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using verstage. cbmem console
shows verstage output.
Change-Id: Iba79efd1c1d4056f1a105a5e10ffc95f3e69b597
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11820
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Now that cbfs is adding more metadata in the cbfs file
header one needs to access that metadata. Therefore,
add struct cbfsf which tracks the metadata and data
of the file separately. Note that stage and payload
metadata specific to itself is still contained within
the 'data' portion of a cbfs file. Update the cbfs
API to use struct cbfsf. Additionally, remove struct
cbfsd as there's nothing else associated with a cbfs
region aside from offset and size which tracked
by a region_device (thanks, CBFS_ALIGNMENT!).
BUG=None
BRANCH=None
TEST=Built and booted through end of ramstage on qemu armv7.
Built and booted glados using Chrome OS.
Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11679
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The EM100Pro allows the debug console to be sent over the SPI bus.
This is not yet working in romstage due to the use of static variables
in the SPI driver code. It is also not working on chipsets that have
SPI write buffers of less than 10 characters due to the 9 byte
command/header length specified by the EM100 protocol.
While this currently works only with the EM100, it seems like it would
be useful on any logic analyzer with SPI debug - just filter on command
bytes of 0x11.
Change-Id: Icd42ccd96cab0a10a4e70f4b02ecf9de8169564b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add some missing devices to device tree and header.
Remove the obsolete devices.
Change-Id: Ieeca06c68fe8c8eef6be4fab43193b898aebf013
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11378
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This removes the dependency on chromeos and vboot for the sw write protect state
function: vboot_get_sw_write_protect, renamed to get_sw_write_protect_state to
both reflect this change and become consistent with the definition of
get_write_protect_state that is already in use.
Change-Id: I47ce31530a03f6749e0f370e5d868466318b3bb6
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11496
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
This change was sitting in my git index, and I
failed to push it in the original patch.
Change-Id: If6f49c3c2b7908f93a99c23a80536ad5937959c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11622
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current endian API support in coreboot doesn't follow
any known API that can be shared in userland as well as coreboot
proper. To that end provide big and little endian helper functions
that can be used in code that can be shared within coreboot proper
and userland tools.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi
Change-Id: I737facab0c849cb4b95756eefbf3ffd69e558b32
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11618
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of having separate <stage>.ld files in src/lib
one file can be used: program.ld. There's now only one
touch point for stage layout.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I4c3e3671d696caa2c7601065a85fab803e86f971
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11509
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>
There are cases where rules.h can be pulled in, but the
usage is not associated with a particular stage. For
example, the cpu/ti/am335x build creates an opmap header.
That is a case where there is no stage associated with
the process. Therefore, provide a case of no ENV_>STAGE>
being set.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: Ia9688886d445c961f4a448fc7bfcb28f691609db
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11513
Tested-by: build bot (Jenkins)
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>
The BOOT_STATE_INIT_ENTRY macro can only be used in ramstage, however
the current state of the header meant bad build errors in non-ramstage.
Therefore, people had to #ifdef in the source. Remove that requirement.
Change-Id: I8755fc68bbaca6b72fbe8b4db4bcc1ccb35622bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11492
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Some of the Chrome OS boards were directly calling vboot
called in some form after contorting around #ifdef preprocessor
macros. The reasoning is that Chrome OS doesn't always do display
initialization during startup. It's runtime dependent. While
this is a requirement that doesn't mean vboot functions should be
sprinkled around in the mainboard and chipset code. Instead provide
one function, display_init_required(), that provides the policy
for determining display initialization action. For Chrome OS
devices this function honors vboot_skip_display_init() and all
other configurations default to initializing display.
Change-Id: I403213e22c0e621e148773597a550addfbaf3f7e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11490
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@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>
This patch will let you to choose a favourite mode to
display, while not just taking the edid detail timing.
But not all modes are able to set, only modes that
are in established or standard timing, and we only
support a few common common resolutions for now.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=tested dev mode on Mickey at 640x480@60Hz
Change-Id: I8a9dedfe08057d42d85b8ca129935a258cb26762
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 090583f90ff720d88e5cfe69fcb2d541c716f0e6
Original-Change-Id: Iaa8c9a6fad106ee792f7cd1a0ac77e3dcbadf481
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289671
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11390
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are serveral members of the edid struct which are never used
outside of the EDID parsing code itself. This patch moves them to a
struct in edid.c. They might be useful some day but until then we can
just pretty print them and not pollute the more general API.
BUG=none
BRANCH=firmware-veyron
TEST=compiled for veyron_mickey, peppy, link, nyan_big, rush, smaug
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I660f28c850163e89fe1f59d6c5cfd6e63a56dda0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: ee8ea314a0d8f5993508f560fc24ab17604049df
Original-Change-Id: I7fb8674619c0b780cc64f3ab786286225a3fe0e2
Original-Reviewed-on: https://chromium-review.googlesource.com/290333
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Aaron Durbin