| Age | Commit message (Collapse) | Author |
|---|
|
Some of these can be changed from #if to if(), but that will happen
in a follow-on commmit.
Change-Id: Idcea3f8b1a4246cb6b29999a84a191a3133e5c78
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Fix the following errors detected by checkpatch.pl:
ERROR: "foo* bar" should be "foo *bar"
ERROR: "(foo*)" should be "(foo *)"
ERROR: "foo * const * bar" should be "foo * const *bar"
TEST=Build and run on Galileo Gen2
Change-Id: I0d20ca360d8829f7d7670bacf0da4a0300bfb0c1
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18696
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This patch adds an API to find file by name from
any specific region of fmap.
Change-Id: Iabe785a6434937be6a57c7009882a0d68f6c8ad4
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/17664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add implementation to use actual requirements of ramstage size
for S3 resume backup in CBMEM. The backup covers complete pages of 4 KiB.
Only the required amount of low memory is backed up when ACPI_TINY_LOWMEM_BACKUP
is selected for the platform. Enable this option for AGESA and binaryPI, other
platforms (without RELOCATABLE_RAMSTAGE) currently keep their romstage ramstack
in low memory for s3 resume path.
Change-Id: Ide7ce013f3727c2928cdb00fbcc7e7e84e859ff1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15255
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This patch adds functionality to compile a C data structure into a raw
binary file, add it to CBFS and allow coreboot to load it at runtime.
This is useful in all cases where we need to be able to have several
larger data sets available in an image, but will only require a small
subset of them at boot (a classic example would be DRAM parameters) or
only require it in certain boot modes. This allows us to load less data
from flash and increase boot speed compared to solutions that compile
all data sets into a stage.
Each structure has to be defined in a separate .c file which contains no
functions and only a single global variable. The data type must be
serialization safe (composed of only fixed-width types, paying attention
to padding). It must be added to CBFS in a Makefile with the 'struct'
file processor.
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: I06f138078c47a1e4b4b3edbdbf662f171e11c9d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16228
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This reverts commit a83bbf58541cf41ea7a97dedbc8c02dffa59e86d.
This was submitted out of order.
Change-Id: Ic5a28faf94c1f1901a72e46343722eb4224c5086
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16226
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: Ibdd7c8754f9bf560a878136b1f55238e2c2549d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16193
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
VBOOT_VERIFY_FIRMWARE should be independent of CHROMEOS. This allows use
of verified boot library without having to stick to CHROMEOS.
BUG=chrome-os-partner:55639
Change-Id: Ia2c328712caedd230ab295b8a613e3c1ed1532d9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15867
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
The build fails during postcar when ULZMA compression is not selected.
Fix cbfs.c to support LZ compression for ramstage as well.
The build error is:
build/postcar/lib/cbfs.o: In function `cbfs_load_and_decompress':
/home/lee/coreboot/public/src/lib/cbfs.c:116: undefined reference to
`ulzman'
make: *** [build/cbfs/fallback/postcar.debug] Error 1
TEST=Build and run on Galileo Gen2
Change-Id: I7fa8ff33c0d32e0c5ff5de7918e13e6efb1df38e
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15841
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>
|
|
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>
|
|
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>
|
|
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>
|
|
To continue sharing more code between the tools and
coreboot proper provide cbfs parsing logic in commonlib.
A cbfs_for_each_file() function was added to allow
one to act on each file found within a cbfs. cbfs_locate()
was updated to use that logic.
BUG=chrome-os-partner:48412
BUG=chromium:445938
BRANCH=None
TEST=Utilized and booted on glados.
Change-Id: I1f23841583e78dc3686f106de9eafe1adbef8c9f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12783
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now that only CBFS access is supported for finding resources
within the boot media the assets infrastructure can be removed.
Remove it.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Chrome OS verified boot path supported multiple CBFS
instances in the boot media as well as stand-alone assets
sitting in each vboot RW slot. Remove the support for the
stand-alone assets and always use CBFS accesses as the
way to retrieve data.
This is implemented by adding a cbfs_locator object which
is queried for locating the current CBFS. Additionally, it
is also signalled prior to when a program is about to be
loaded by coreboot for the subsequent stage/payload. This
provides the same opportunity as previous for vboot to
hook in and perform its logic.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
CQ-DEPEND=CL:307121,CL:31691,CL:31690
Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12689
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The proper return value to signal an error from cbfs_prog_stage_load()
is -1, not 0.
Change-Id: Ie53b0359c7c036e3f809d1f941dab53f090b84ab
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/12633
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On x86 the early stages are currently execute-in-place which
means they live in the memory-mapped spi flash. However, when
loading romstage from verstage the romstage is
execute-in-place so it's unnecessary to write over a read-only
media -- not to mention writing to read-only memory is wrong
to begin with.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. Noted reduction of 20ms when
loading romstage.
Change-Id: I7cd399302a3925a05fbce82600b4c50ea66a0fcb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11823
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
Assume that it's 64 byte.
Change-Id: I168facd92f64c2cf99c26c350c60317807a4aed4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10919
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
That function will be used by the vboot loader.
Change-Id: I204c6cd5eede3645750b50fe3ed30d77c22dbf43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10101
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add the absolute offset value to the CBFS log, to make it easier to
understand which particular CBFS section the file is loaded from.
BRANCH=storm
BUG=none
TEST=rebooted a Whirlwind device, observed an empty line before the
ramstage section of the log and absolute offsets reported by
CBFS.
Change-Id: Ifcb79ab386629446b98625a5416dfa5850a105f6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ecc4d1df7c51a263230c45ecac5981d53bdd44b1
Original-Change-Id: I5cc727127374d6e55b8ff6f45b250ef97125a8ec
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255120
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9827
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If you try to boot a VBOOT2_VERIFY_FIRMWARE with less than 4K CBFS cache
right now, your system will try and fail to validate the FMAP signature
at (u8 *)0xFFFFFFFF and go into recovery mode. This patch avoids the
memcmp() to potentially invalid memory, and also adds an error message
to cbfs_simple_buffer_map() to make it explicit that we ran out of CBFS
cache space.
BUG=None
TEST=Booted on Veyron_Pinky with reduced CBFS cache, saw the message.
Original-Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222899
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 0ed3c0c2b63be0d32e8162faf892e41cef1f1f23)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I20ccac83bff4a377caca6327d0e21032efff44c1
Reviewed-on: http://review.coreboot.org/9373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The struct prog serves as way to consolidate program
loading. This abstraction can be used to perform more
complicated execution paths such as running a program
on a separate CPU after it has been loaded. Currently
t124 and t132 need to do that in the boot path. Follow
on patches will allow the platform to decide how to
execute a particular program.
Note: the vboot path is largely untouched because it's
already broken in the coreboot.org tree. After getting
all the necessary patches pushed then vboot will be
fixed.
Change-Id: Ic6e6fe28c5660fb41edee5fd8661eaf58222f883
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8839
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
currently, if the cache size is, for example, 4096 byte, mapping 4096 byte data
fails due to the overly strict check. this change allows cbfs_simple_buffer_map
to use all the cache space to the last byte.
BUG=None
TEST=Booted Nyan Blaze.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I0797b5010afd7316fdec605784e8f48e2d62c37f
Original-Reviewed-on: https://chromium-review.googlesource.com/218883
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit b0b31da336fa2f87fe73f063782d6243f8262d10)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I15e11e574cd14484fe83c9c3674bb5c2d14422f6
Reviewed-on: http://review.coreboot.org/9178
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of having 2 different functions to call when a program
is loaded provide a single callback with flags parameter. The
previous callbacks for cache management routines did this:
for_each_program_segment:
arch_program_segment_loaded(start, size);
arch_program_loaded();
Now, use one callback instead:
for_each_program_segment:
arch_segment_loaded(start, size, SEG_FINAL?);
Change-Id: I3811cba92e3355d172f605e4444f053321b07a2a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The run_address() function is not used. Remove it.
Change-Id: I96de4cf0a529b08943ff8281cedead642eb415de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9124
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Two weak functions were added so that architecture specific operations
on each segment of payload or stage can be performed.
Each architecture must define its own operations, otherwise the
behavior will default to do-nothing functions.
This patch has been updated by to fit more in line with
how program loading is currently being done. The API is the
same as the original, but all call sites to stages/payloads
have been updated. This is known to break any archs that use
rmodule loading that needs cache maintenance. That will be fixed
in a forthcoming patch. Also, the vboot paths are left as is
for easier upstreaming of the rest of the vboot patches.
Original-Change-Id: Ie29e7f9027dd430c8b4dde9848fa3413c5dbfbfa
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/239881
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit c82c21ce87a4c02bd9219548a4226a58e77beef0)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ifcee5cd9ac5dbca991556296eb5e170b47b77af7
Reviewed-on: http://review.coreboot.org/8837
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
I broke cbfs loading with commit 358901. As multiple
functions are being reused one needs to ensure there is
always a cbfs media object allocated on the stack and
initialized. Ya for no common writable globals.
TEST=Ran qemu-armv7. CBFS loading works again.
Change-Id: Ibd047af7dcd8575e6203651471079fc2042da282
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8973
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
this change allows vboot_load_stage to load a decompressed stage directly to the
load address without using the cbfs cache.
BUG=None
TEST=Booted Nyan Blaze.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I76530276ff9a87b44f98a33f2c34bd5b2de6888f
Original-Reviewed-on: https://chromium-review.googlesource.com/219028
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 0ad6f7fee9df31e1b35d4df9a8c373516416a235)
Change-Id: I7abdbdda0cc549894dfb9d599a576bba0a4fadfc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8883
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
BUG=None
BRANCH=none
TEST=Ran image in foundation model
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Original-Change-Id: I80a92673c163b3df312ce632eb52e5bb1e7ab1db
Original-Reviewed-on: https://chromium-review.googlesource.com/185273
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Marcelo Póvoa <marcelogp@chromium.org>
Original-Tested-by: Marcelo Póvoa <marcelogp@chromium.org>
(cherry picked from commit e2f19689acb973aedee6e4b324ed27b64f2d47de)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Icc3fc82779d18963f0fe8d5fb655f96027164a18
Reviewed-on: http://review.coreboot.org/7660
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ieb7f383c84401aab87adc833deebf289cd0c9a0f
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7426
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Change-Id: I5499a99cec82b464c5146cfc2008d683d079b23a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7068
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
A payload can be loaded either from a vboot region or from cbfs.
Provide a common place for choosing where the payload is loaded
from. Additionally, place the logic in the 'loaders' directory
similarly to the ramstage loader infrastructure.
Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5296
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Not used anymore.
Change-Id: Icf3a4a7f932776981048b805478582ad2b784182
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5132
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
There are 3 places rmodule stages are loaded in the
existing code: cbfs and 2 in vboot_wrapper. Much of the
code is the same except for a few different cbmem entry
ids. Instead provide a common implementation in the
rmodule library itself.
A structure named rmod_stage_load is introduced to manage
the inputs and outputs from the new API.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I146055005557e04164e95de4aae8a2bde8713131
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4897
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I5b93e5321e470f19ad22ca2cfdb1ebf3b340b252
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4659
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
Clean up superfluous line terminators.
Change-Id: If837b4f1b3e7702cbb09ba12f53ed788a8f31386
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4562
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The code is wrong (it's calling ntohl on an entry point that is actually
already le due to an old cbfs bug) and nothing calls it any more anyway.
Change-Id: Ief2c33faf99e3d2fc410524a5aae7bde378f088b
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4090
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
If ramstage is not compressed, the CBFS module in romstage doesn't
need to support LZMA. Removing the LZMA module in this case can save
about 3000 bytes in romstage.
Change-Id: Id6f7869e32979080e2985c07029edcb39eee9106
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3878
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
For reasons explained in a previous CL, it might be necessary to "load" a file
from CBFS in place. The loading code in CBFS was, however, zeroing the area of
memory the stage was about to be loaded into. When the CBFS data is located
elsewhere this works fine, but when it isn't you end up clobbering the data
you're trying to load. Also, there's no reason to zero memory we're about to
load something into or have just loaded something into. This change makes it
so that we only zero out the portion of the memory between what was
loaded/decompressed and the final size of the stage in memory.
Change-Id: If34df16bd74b2969583e11ef6a26eb4065842f57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3579
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Instead of returning 0 on success and -1 on error, return the decompressed
size of the data on success and 0 on error. The decompressed size is useful
information to have that was being thrown away in that function.
Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
There were some cbfs calls that did not get transitioned
to the new cbfs API. Fix the callsites to conform to the
actual cbfs, thus fixing the copilation errors.
Change-Id: Ia9fe2c4efa32de50982e21bd01457ac218808bd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
