| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
That function is no longer used. All users have been updated to
use the ulzman() function which specifies lengths for the input
and output buffers.
Change-Id: Ie630172be914a88ace010ec3ff4ff97da414cb5e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15526
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
In order to ease the porting of supporting NHLT endpoints
introduce a nhlt_endpoint_descriptor structure as well as
corresponding helper functions.
Change-Id: I68edaf681b4e60502f6ddbbd04de21d8aa072296
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15486
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
Implement writeat and eraseat support into the region_device_ops struct.
Change-Id: Iac2cf32e523d2f19ee9e5feefe1fba8c68982f3d
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/15318
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Add functions to convert between seconds and a struct rtc_time. Also
add a function that can display the time on the console.
BUG=chrome-os-partner:52220
BRANCH=none
TEST=(partial) with future commits and after setting RTC on the EC:
boot on gru into linux shell, check firmware log:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:44
Then reboot ~10 seconds and check again:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:54
Change-Id: Id148ccb7a18a05865b903307358666ff6c7b4a3d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3b02dbcd7d9023ce0acabebcf904e70007428d27
Original-Change-Id: I344c385e2e4cb995d3a374025c205f01c38b660d
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/351782
Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Allow reg_script to be used during the bootblock.
TEST=Build and run on Galileo Gen2
Change-Id: I55fe0be3f50116927b801ce67a3f23bb1931f6e7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15131
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add asmlinkage to bootblock_main_with_timestamp so that it may be called
directly from the assembly code.
TEST=Build for Amenia and Galileo Gen2
Change-Id: Iefb8e5c1ddce2ec495b9272966b595d5adcebc1c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15125
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Modern platforms like Apollolake do not use XIP for early stages. In
such cases, cbfs_prog_stage_load should check for NO_XIP_EARLY_STAGES
instead of relying on ARCH_X86 to decide if a stage is XIP.
Change-Id: I1729ce82b5f678ce8c37256090fcf353cc22b1ec
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15045
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I106fccd725a5c944f4e8e0f196b31c9344f588c7
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14984
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This fixes compilation of coreboot on Glados
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=none
TEST=emerge-glados coreboot works again
BUG=none
Change-Id: Ibaae68192a3dc070c6ecf79223da4a1e1f18b352
Reviewed-on: https://chromium-review.googlesource.com/346198
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit d7c2c72698e81b1410f9839c77be2e77b8ed83d6)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14930
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Duncan Laurie <dlaurie@google.com>
|
|
Add a new function "gpio_acpi_path()" that can be implemented by
SoC/board code to provide a mapping from a "gpio_t" pin to a
controller by returning the ACPI path for the controller that owns
this particular GPIO.
This is implemented separately from the "acpi_name" handler as many
SOCs do not have a specific device that handles GPIOs (or may have
many devices and the only way to know which is the opaque gpio_t)
and the current GPIO library does not have any association with the
device tree.
If not implemented (many SoCs do not implement the GPIO library
abstraction at all in coreboot) then the default handler will return
NULL and the caller knows it cannot determine this reliably.
Change-Id: Iaa0ff6c8c058f00cddf0909c4b7405a0660d4cfb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14842
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This function will turn a string of ASCII hex characters into an array
of bytes. It will ignore any non-ASCII-hex characters in the input
string and decode up to len bytes of data from it.
This can be used for turning MAC addresses or UUID strings into binary
for storage or further processing.
Sample usage:
uint8_t buf[6];
hexstrtobin("00:0e:c6:81:72:01", buf, sizeof(buf));
acpigen_emit_stream(buf, sizeof(buf));
Change-Id: I2de9bd28ae8c42cdca09eec11a3bba497a52988c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/14837
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This is useful, for example, in the bootblock, when a timestamp is
available which predates the call to main() in lib/bootblock.c
Change-Id: I17bb0add9f2d8721504b2e534dd6904d1201989c
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
timestamp_cache_get() would call timestamp_cache_init() whenever it
found a timestamp cache in the TIMESTAMP_CACHE_UNINITIALIZED state.
That means that timestamp_cache_get() will never reurn a cache in the
uninitialized state.
However, timestamp_init() checks against the uninitialized state, as
it does not expect timestamp_cache_get() to perform any initialization.
As a result, the conditional branch can never be reached.
Simply remove the timestamp_cache_init() call from timestamp_cache_get().
Change-Id: I573ffbf948b69948a3b383fa3bc94382f205b8f8
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14861
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The FLASHMAP_OFFSET config variable is used in lib/fmap.c, however
the fmdtool creates a fmap_config.h with a FMAP_OFFSET #define.
Those 2 values are not consistent. Therefore, remove the Kconfig
variable and defer to the #define generated by fmdtool.
Change-Id: Ib4ecbc429e142b3e250106eea59fea1caa222917
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14765
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
|
Extend the serial port description to include the input clock frequency
and a payload specific value.
Without the input frequency it is impossible for the payload to compute
the baud-rate divisor without making an assumption about the frequency.
This breaks down when the UART is able to support multiple input clock
frequencies.
Add the UART_PCI_ADDR Kconfig value to specify the unique PCI device
being used as the console UART. Specify this value as zero when the
UART is not on the PCI bus. Otherwise specify the device using bus,
device and function along with setting the valid bit.
Currently the only payload to consume these new fields is the EDK-II
CorebootPayloadPkg.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Testing is successful when CorebootPayloadPkg is able to properly
initialize the serial port without using built-in values.
Change-Id: Id4b4455bbf9583f0d66c315d38c493a81fd852a8
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14609
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Before multi-CBFS support was added, x86 platforms cached their
ramstage in TSEG so that it could be re-used on the resume
path. However, more resources/assets are being put in cbfs that are
utilized during ramstage. Just caching ramstage does not mean that
correct cbfs region is used for all the data. Thus, provide an option
to allow platforms to skip caching any component for resume.
Change-Id: I0e957a6b859cc7d700aaff67209a17c6558be5de
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14636
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
In If0d4d61ed8ef48ec20082b327f358fd1987e3fb9 the code
was changed from one to two lines in the body of an if()
statement, without adding braces.
Change-Id: Ibbbdf240157adae95151fb2ce0135948caa60108
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
|
|
Add the ability to enable the display of the script:
* Added REG_SCRIPT_COMMAND_DISPLAY to enable and disable display output
* Added context values to manage display support
* display_state - Updated by the command to enable or disable display
* display_features - May be updated by step routine to control what
the step displays for register and value
* display_prefix - Prefix to display before register data
* Added REG_SCRIPT_DISPLAY_ON and REG_SCRIPT_DISPLAY_OFF macros to
control the display from the register script
* Added REG_SCRIPT_DISPLAY_REGISTER and REG_SCRIPT_DISPLAY_VALUE as
two features of the common display. With these features enabled
the following is output:
* Write: <optional prefix> register <-- value
* Read: <optional prefix> register --> value
TEST=Build and run on Galileo Gen2
Change-Id: If0d4d61ed8ef48ec20082b327f358fd1987e3fb9
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14553
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It used to use CONFIG_CBFS_SIZE. The plan is that CBFS_SIZE only informs
default*.fmd generation, while everything else derives its information
from there.
Also document the existing assumption that boot media should access the
COREBOOT region (and not any other potentially existing fmap region
containing a CBFS).
Change-Id: I08254e4510f71edf99c2c8b56ac8f92008727c4a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14572
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Utilize the architecture dependent coreboot table size value
from <arch/cbconfig.h>
Change-Id: I80d51a5caf7c455b0b47c380e1d79cf522502a4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14455
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Remove the platform_bus_table routine and replace it with a link time
table. This allows the handlers to be spread across multiple modules
without any one module knowing about all of the handlers.
Establish number ranges for both the SOC and mainboard.
TEST=Build and run on Galileo Gen2
Change-Id: I0823d443d3352f31ba7fa20845bbf550b585c86f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14554
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Add xor support which enables toggling of a bit:
* REG_SCRIPT_COMMAND_RXW enum value
* REG_*_RXW* macros to support using REG_SCRIPT_COMMAND_RXW
* REG_*_XOR* macros to support using REG_SCRIPT_COMMAND_RXW
* reg_script_rxw routine to perform and/xor operation
* case in reg_script_run_step to call reg_script_rxw
TEST=Build and run on Galileo Gen2
Change-Id: I50a492c7c2643df5dc2d2fa7113e3722c1e480c7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14495
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Decode each cbfs_payload_segment into native byte order during
segments iteration.
Note :
List ordering has been changed, segments are now always inserted
at the end.
cbfs_serialized.h PAYLOAD_SEGMENT definitions have been changed
to their standard order (big-endian).
Change-Id: Icb3c6a7da2d253685a3bc157bc7f5a51183c9652
Signed-off-by: George Trudeau <george.trudeau@usherbrooke.ca>
Reviewed-on: https://review.coreboot.org/14294
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
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>
|
|
The x86 architecture needs to add a forwarding table to
the real coreboot table. Provide a helper function to do
this for aligning the architectures on a common
write_tables() implementation.
Change-Id: I9a2875507e6260679874a654ddf97b879222d44e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14433
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>
|
|
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>
|
|
Some ld versions seem to merge the .zeroptr section (NOLOAD, address 0)
with some debug sections (NOLOAD, address 0) which makes the build
explode when the debug sections are then stripped (including the zeroptr
symbol).
Just define zeroptr to be 0, no sections needed, to avoid this
"optimization".
Checked the objdump -dS of code using it that the accesses look sane.
Change-Id: Ia7cb3e5eae87076caf479d5ae9155a02f74b5663
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14344
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Our EDID code had always been aligning the framebuffer's
bytes_per_line (and x_resolution dependent on that) to 64. It turns out
that this is a controller-dependent parameter that seems to only really
be necessary for Intel chipsets, and commit 6911219cc (edid: Add helper
function to calculate bits-per-pixel dependent values) probably actually
broke this for some other controllers by applying the alignment too
widely.
This patch makes it explicitly configurable and depends the default on
ARCH_X86 (which seems to be the simplest and least intrusive way to make
it fit most cases for now... boards where this doesn't apply can still
override it manually by calling edid_set_framebuffer_bits_per_pixel()
again).
Change-Id: I1c565a72826fc5ddfbb1ae4a5db5e9063b761455
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14267
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
A long time ago many Chrome OS boards had pages full of duplicated
boilerplate code for the fill_lb_gpios() function, and we spent a lot of
time bikeshedding a proper solution that passes a table of lb_gpio
structs which can be concisely written with a static struct initializer
in http://crosreview.com/234648. Unfortunately we never really finished
that patch and in the mean time a different solution using the
fill_lb_gpio() helper got standardized onto most boards.
Still, that solution is not quite as clean and concise as the one we had
already designed, and it also wasn't applied consistently to all recent
boards (causing more boards with bad code to get added afterwards). This
patch switches all boards newer than Link to the better solution and
also adds some nicer debug output for the GPIOs while I'm there.
If more boards need to be converted from fill_lb_gpio() to this model
later (e.g. from a branch), it's quite easy to do with:
s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/
Based on a patch by Furquan Shaikh <furquan@google.com>.
BUG=None
BRANCH=None
TEST=Booted on Oak. Ran abuild -x.
Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14226
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
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>
|
|
Coreboot and most payloads support three basic pixel widths for the
framebuffer. It assumes 32 by default, but several chipsets need to
override that value with whatever else they're supporting. Our struct
edid contains multiple convenience values that are directly derived from
this (and other properties), so changing the bits per pixel always
requires recalculating all those dependents in the chipset code. This
patch provides a small convenience wrapper that can be used to
consistently update the whole struct edid with a new pixel width
instead, so we no longer need to duplicate those calculations
everywhere.
BUG=None
TEST=Booted Oak in all three pixel widths (which it conveniently all
supports), confirmed that images looked good.
Change-Id: I5376dd4e28cf107ac2fba1dc418f5e1c5a2e2de6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14158
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@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>
|
|
This patch adds support for an alternative ternary number system in
which group of GPIOs can be interpreted. In this system, the digit
combinations that would form a binary number (i.e. that contain no 'Z'
state) are used to represent the lower values in the way they're used in
the normal binary system, and all the combinations that do contain a 'Z'
are used to represent values above those. We can use this for boards
that originally get strapped with binary board IDs but eventually
require more revisions than that representation allows. We can switch
their code to binary_first base3 and all old revisions with already
produced boards will still get read as the correct numbers.
Credit for the algorithm idea goes to Haran Talmon.
BRANCH=None
BUG=None
TEST=Stubbed out the actual GPIO reading and simulated all combinations
of 4 ternary digits for both number systems.
Change-Id: Ib5127656455f97f890ce2999ba5ac5f58a20cf93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14116
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In order for a caller to utilize an rmodule's parameters section
after calling rmodule_stage_load() export the rmodule's parameter
pointer in struct rmod_stage_load.
Change-Id: I9cd51652cf8cdb3fae773256989851638aa1a60f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14139
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Change 13363 (555d6c2) introduced a bug where cbmem_add_bootmem() was
converted to use a new function. Unfortunately instead of passing a
pointer, NULL was passed due to type confusion. This change fixes that
problem by passing address of stack variable instead of NULL.
Change-Id: Ib8e1add3547cda01f71bf1dea14d3e58bdd99730
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Change-Id: I8e57c23565f173afc0f4d450579b8bfb35aeb964
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13363
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
On platforms that didn't use 32-bit addresses, enabling the
CONFIG_TRACE option (Trace function calls) would break the build due
to a cast from a pointer of a different size.
This fixes this warning:
src/lib/trace.c:29:58: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
Change-Id: Iaab13c1891b6af7559ea6982ecc6e74c09dd0395
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13962
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Platforms that need to initialize WRDD package with the regulatory domain
information should implement function wifi_regulatory_domain.
A weak implementation is provided here.
Signed-off-by: fdurairx <felixx.durairaj@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/314384
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Commit-Queue: Hannah Williams <hannah.williams@intel.com>
Tested-by: Hannah Williams <hannah.williams@intel.com>
(cherry picked from commit c25d7221679d1fab830d614eeabfa3436bce6ac1)
BUG=chrome-os-partner:50516
BRANCH=glados
TEST=build and boot on chell
Change-Id: I1cbdf4e940b009c74ee8ed8f4fca85f4f5c943b2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 27bba336e620a2d3d331e350d4f46164e337fabc
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Change-Id: I84e2acd748856437b40bbf997bf23f158c711712
Original-Reviewed-on: https://chromium-review.googlesource.com/329291
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There was no 'early' call into the SoC code prior to console
getting initialized. Not having this enforces the mainboard to
drive the setup of the console which typically just ends up
calling into the SoC code. Provide a SoC early init call
to handle this without having to duplicate the same code
in mainboards utilizing the same SoC.
Change-Id: Ia233dc3ae89a77df284d6d5cf5b2b051ad3be089
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13791
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Fix an error where a variable named 'free' was shadowing the
function 'free'.
src/lib/memrange.c:293:73: error: declaration of 'free' shadows a global
declaration [-Werror=shadow]
Change-Id: Ie57194b392f8f00ed4fd5c76dab27299b00ae293
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13788
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add all needed functions to fsp_baytrail so that reg_script can
do full iosf access. To keep it simple, this patch synchronises
iosf access between baytrail and fsp_baytrail.
Change-Id: Ic7f52d7d90c0fe3560fa5a5d96f7fc15062d66d1
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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>
|
|
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>
|
|
Add the DEBUG_BOOT_STATE Kconfig value to enable boot state debugging.
Update include/bootstate.h and lib/hardwaremain.c to honor this value.
Add a dashed line which displays between the states.
Testing on Galileo:
* select DEBUG_BOOT_STATE in mainboard/intel/galileo/Kconfig
* Build and run on Galileo
Change-Id: I6e8a0085aa33c8a1394f31c030e67ab3d5bf7299
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13716
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Reduce the debug output from FMAP lookups. When we had one or
two FMAP lookups in a boot this was not a big deal, but now that
we do many lookups it is a lot of unnecessary output duplication.
This change reduces these 3 lines:
FMAP: area VBLOCK_A found
FMAP: offset: 200000
FMAP: size: 65536 bytes
To just one line:
FMAP: area VBLOCK_A found @ 200000 (65536 bytes)
And makes the header output only print once:
FMAP: Found "FMAP" version 1.0 at c10000.
FMAP: base = 0 size = 1000000 #areas = 29
BUG=chrome-os-partner:40635
BRANCH=glados
TEST=boot on chell and enjoy non-truncated memconsole
Change-Id: Ib5862b8bfad113a700faae89089557094aa6d499
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6890f36536d4ae6fc4988fc8191b0cff4e33e2e6
Original-Change-Id: Ifefee1ab26e6ee406de552880fbbd5b7916fcadd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/326887
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13695
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
