| Age | Commit message (Collapse) | Author |
|---|
|
The vboot library currently relies on link-time known
address and sizes of the work buffer. Not all platforms
can provide such semantics. Therefore, add an option
to use cbmem for the work buffer. This implies such platforms
can only do verification of the firmware after main memory
has been initialized.
Change-Id: If0b0f6b2a187b5c1fb56af08b6cb384a935be096
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10157
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of using the symbols directly provide a size
function to provide symmetry between getting the work
data and size. It also allows for an abstraction where
the linker symbols may not be the only source of this
information.
Change-Id: I4568064a0050d118c3544ab1ea59a08eb0bad8e4
Signed-off-by: Aaron Durbi <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
vboot_verify_firmware() was only defined to ease upstreaming.
It was only an empty inline as it is so remove it. Additionally,
vboot2 does not require romstage_handoff so there's no need in
adding it for the nyan boards.
Change-Id: I4d84ac9fb60c756cf10742f26503f7f11af5f57b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10155
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As previously done the vboot loader can be optionally
inserted in the stage loading logic in order to
decide the source of each stage. This current patch
allows for verstage to be loaded and interrogated
for the source of all subsequent stages. Additionally,
it's also possible to build this logic directly into
one of the additional stages.
Note that this patch does not allow x86 to work.
Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10154
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
If the limit of the large starting region was set with
a NULL pointer then the limit field will be 0. If the
limit is zero then no attempt to recover is necessary
as there is no region to recover.
This prevented an early call cbmem_find() from hanging a
rambi device. The config was with vboot enabled and was
way before memory init in the sequence.
Change-Id: I7163d93c31ecef2c108a6dde0206dc0b6f158b5c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10175
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This make it pass through -fno-stack-protector, and also uses
libverstage fields consistently.
verstage is for 'stage' stuff, libverstage for all the vboot logic.
Change-Id: I3032e072414bed52effd2dc5057896781ad562c6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/10174
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
In order to allow easier setting of variables without
changing mainboards and/or chipset Kconfig files allow
the vboot options to be selected by the user.
Change-Id: I6e995eb209b4cd63c73ef679d0c5699759d129f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10153
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The VB_FIRMWARE_ARCH variable was not being set correctly,
and the VBOOT_STARTS_IN_BOOTBLOCK Kconfig option was not properly
prefixed with CONFIG_. Correct both of these oversights.
Change-Id: Id27974c285d2629bd47b90b6a93aca1ec8a76512
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10152
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Somewhere along the development path the following
vboot functions were dropped:
int vboot_enable_developer(void)
int vboot_enable_recovery(void)
Add them back, but also refactor the flag extraction
so as not duplicate all that same logic.
Change-Id: Id58f3b99f29caeff98b2d3111cfa28241d15b54f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10151
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The linker scripts are added to stage objs so remove those
from the object lists. boot.c will be needed to link verstage
properly.
Change-Id: Ib8427fe015b72e2282219f116a39949739a0af48
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10150
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The linker scripts are added to stage objs so remove those
from the object lists. boot.c will be needed to link verstage
properly. Lastly, VERSTAGE_LIB has no value so remove it.
Change-Id: Ie53b42c4995a96006463ec5b358aa43a731cb1b8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10149
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
arch_program_segment_loaded ensures that the program segment loaded is
synced back from the cache to PoC. dcache_flush_all on arm64 does not
guarantee PoC in case of MP systems. Thus, it is important to track
and sync back all the required segments using
arch_program_segment_loaded. Use this function in rmodules as well
instead of cache_sync_instructions which guarantees sync upto PoC.
BUG=chrome-os-partner:37546
BRANCH=None
TEST=Boots into depthcharge on foster
Change-Id: I64c2dd5e40ea59fa31f300174ca0d0aebcf8041d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 35ba0b882b86ff2c29ac766e1d65f403c8346247
Original-Change-Id: I964aa09f0cafdaab170606cd4b8f2e027698aee7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/260908
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10173
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
secmon is referring to uart's default_baudrate() and
various coreboot version strings.
Change-Id: I40a8d1979146058409a814d94ea24de83ee4d634
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
So that's more precise than "anything non-pre-ram".
Change-Id: I21db536a5ea704c4b087f57d0b761dd3fdf43e3e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10128
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
They're essentially collected on a stack before they're
parsed. So we push them backwards, then parse them in
the correct order.
Change-Id: Ibf29559389cd19f260d67bae8e0b5ef9f4f58d91
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10169
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
These tables are not referenced anywhere, thus all
comments about adjustments are void.
Also drop stub AgesaReadSpd that is all commented out.
Change-Id: I12233ea0dc4baaf36a75f359c52cc59c9b6dad79
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10143
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
|
|
Change-Id: Iaec748b4bdbb5da287520fbbd7c3794bf664eff6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10161
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Sol Boucher <solb@chromium.org>
|
|
Change-Id: I928efe6f63305a0099d64e83091aa80768582f48
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10160
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The ACPI power state generator for AMD 10xxx CPUs did not generate
the _PSD object required for reliable PowerNow! operation. Without
a correct _PSD object PowerNow! does not know the required core
clock relationships, potentially causing unstable system operation.
Generate the _PSD object in accordance with the BKDG Rev. 3.62.
Change-Id: I255a4837ab29ff1b0874daf189ffb61798645795
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/10142
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
1.) Removed invalid set of TRANS_STATE_MASK bit
2.) Used i915 register defines to clarify code
Change-Id: I08d016e9d66b5eeea8f2174abaa35a98e2b4eca3
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/9329
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
A few hardcoded values could be fixed after this commit
Change-Id: I3ae67f4f6136361d67d4fdae2a5a29b7b1a75478
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: http://review.coreboot.org/10065
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
This allows the backlight control register to be set via devicetree.cb
Change-Id: I32b42dfc1cc609fb6f8995c6158c85be67633770
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/9330
Tested-by: build bot (Jenkins)
|
|
Fine tune the following two checks:
- Check for incorrect file permissions
This one had a linux path hard coded, so it would choke on
some commits unnecessarily.
- FILE_PATH_CHANGES seems to not be working correctly. It will
choke on added / deleted files even if the MAINTAINERS file
is touched. Hence, switch from WARN to CHK (as WARN currently
blocks commits as well)
Change-Id: I9fccfbd75e94f420de45cf8b58071e3198065cf3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10123
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The fmd compiler now processes "(CBFS)" annotations, distilling them
into a comma-separated list of the names of sections containing
CBFSes. This list is the only thing printed to standard output to
enable easy capture and machine consumption by other tools.
Additionally, the ability to generate a tiny header with a define for
the primary CBFS's size is implemented and can be requested via a
new command-line switch.
Here's an example of how to use the new features:
$ ./fmaptool -h layout.h layout_arm_8192.fmd layout.fmap 2>/dev/null
FW_MAIN_A,FW_MAIN_B,COREBOOT
The hypothetical fmd file contains three sections annotated as (CBFS),
the names of which are printed to standard output. As before, a binary
FMAP file named layout.fmap is created; however, because the command
was invoked with -h, a header #define ing the offset of its FMAP
section (i.e. where it will be relative to the base of flash once the
boot image is assembled) is also generated.
BUG=chromium:470407
TEST=Verify that fmd files without a "COREBOOT" section or with one
that isn't annotated as "(CBFS)" are not accepted. Ensure that the
list of CBFS sections matches the descriptor file's annotations and
is led by the "COREBOOT" section. Invoke with the header generation
switch and check that output file for reasonableness.
BRANCH=None
Change-Id: I496dd937f69467bfd9233c28df59c7608e89538f
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 9227698adecf675770b2983380eb570676c2b5d2
Original-Change-Id: I8b32f6ef19cabe2f6760106e676683c4565bbaad
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262956
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9967
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The tool now makes use of the ERROR() macros from common.h.
Change-Id: Ie38f40c65f7b6d3bc2adb97e246224cd38d4cb99
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10048
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The buffer API that cbfstool uses to read and write files only directly supports
one-shot operations on whole files. This adds an intermediate partitioned_file
module that sits on top of the buffer system and has an awareness of FMAP
entries. It provides an easy way to get a buffer for an individual region of a
larger image file based on FMAP section name, as well as incrementally write
those smaller buffers back to the backing file at the appropriate offset. The
module has two distinct modes of operation:
- For new images whose layout is described exclusively by an FMAP section, all
the aforementioned functionality will be available.
- For images in the current format, where the CBFS master header serves as the
root of knowledge of the image's size and layout, the module falls back to a
legacy operation mode, where it only allows manipulation of the entire image
as one unit, but exposes this support through the same interface by mapping
the region named SECTION_NAME_PRIMARY_CBFS ("COREBOOT") to the whole file.
The tool is presently only ported onto the new module running in legacy mode:
higher-level support for true "partitioned" images will be forthcoming. However,
as part of this change, the crusty cbfs_image_from_file() and
cbfs_image_write_file() abstractions are removed and replaced with a single
cbfs_image function, cbfs_image_from_buffer(), as well as centralized image
reading/writing directly in cbfstool's main() function. This reduces the
boilerplate required to implement each new action, makes the create action much
more similar to the others, and will make implementing additional actions and
adding in support for the new format much easier.
BUG=chromium:470407
TEST=Build panther and nyan_big coreboot.rom images with and without this patch
and diff their hexdumps. Ensure that no differences occur at different locations
from the diffs between subsequent builds of an identical source tree. Then flash
a full new build onto nyan_big and watch it boot normally.
BRANCH=None
Change-Id: I25578c7b223bc8434c3074cb0dd8894534f8c500
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 7e1c96a48e7a27fc6b90289d35e6e169d5e7ad20
Original-Change-Id: Ia4a1a4c48df42b9ec2d6b9471b3a10eb7b24bb39
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265581
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10134
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This allows calls to buffer_delete() to work on a buffer that has been
buffer_seek()ed or the buffer created by a buffer_splice(). The same
information could also be useful for other purposes, such as writing
slices back to a file at the offset they originally occupied.
BUG=chromium:470407
TEST=Attempt to perform the following sequence of buffer actions, then run it
through valgrind to check for memory errors:
for (int pos = 0; pos <= 3; ++pos) {
struct buffer seek_test;
buffer_create(&seek_test, 3, "seek_test");
if (pos == 0) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 1) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 2) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 3) {
buffer_delete(&seek_test);
continue;
}
}
for (int pos = 0; pos <= 14; ++pos) {
struct buffer slice_test;
buffer_create(&slice_test, 3, "slice_test");
if (pos == 0) {
buffer_delete(&slice_test);
continue;
}
struct buffer sliced_once;
buffer_splice(&sliced_once, &slice_test, 1, 2);
if (pos == 1) {
buffer_delete(&slice_test);
continue;
}
if (pos == 2) {
buffer_delete(&sliced_once);
continue;
}
struct buffer sliced_twice;
buffer_splice(&sliced_twice, &sliced_once, 2, 1);
if (pos == 3) {
buffer_delete(&slice_test);
continue;
}
if (pos == 4) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 5) {
buffer_delete(&sliced_twice);
continue;
}
struct buffer sliced_same;
buffer_splice(&sliced_same, &slice_test, 1, 1);
if (pos == 6) {
buffer_delete(&slice_test);
continue;
}
if (pos == 7) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 8) {
buffer_delete(&sliced_twice);
continue;
}
if (pos == 9) {
buffer_delete(&sliced_same);
continue;
}
struct buffer sliced_thrice;
buffer_splice(&sliced_thrice, &sliced_twice, 1, 0);
if (pos == 10) {
buffer_delete(&slice_test);
continue;
}
if (pos == 11) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 12) {
buffer_delete(&sliced_twice);
continue;
}
if (pos == 13) {
buffer_delete(&sliced_same);
continue;
}
if (pos == 14) {
buffer_delete(&sliced_thrice);
continue;
}
}
BRANCH=None
Change-Id: Id67734654a62302c0de37746d8a978d49b240505
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 00c40982a21a91a488587dd3cead7109f3a30d98
Original-Change-Id: Ie99839d36500d3270e4924a3477e076a6d27ffc8
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/267467
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10133
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Previously, this function allowed one to pass a size of 0 in order to
indicate that the entire buffer should be copied. However, the
semantics of calling it this way were non-obvious: The desired
behavior was clear when the offset was also 0, but what was the
expected outcome when the offset was nonzero, since carrying over the
original size in this case would be an error? In fact, it turns out
that it always ignored the provided offset when the size was zero.
This commit eliminates all special handling of 0; thus, the resulting
buffer is exactly as large as requested, even if it's degenerate.
Since the only consumer that actually called the function with a size
of 0 was buffer_clone(), no other files required changes.
Change-Id: I1baa5dbaa7ba5bd746e8b1e08816335183bd5d2d
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10132
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The only operation performed on this struct turned out to be sizeof...
Change-Id: I619db60ed2e7ef6c196dd2600dc83bad2fdc6a55
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10131
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patches a memory leak on every struct cbfs_image creation that
was introduced by c1d1fd850ee7b8e52bd2ea5064fab68ac0c27098. Since that
commit, the CBFS master header has been copied to a separate buffer so
that its endianness could be fixed all at once; unfortunately, this
buffer was malloc()'d but never free()'d. To address the issue, we
replace the structure's struct cbfs_header * with a struct cbfs_header
to eliminate the additional allocation.
Change-Id: Ie066c6d4b80ad452b366a2a95092ed45aa55d91f
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10130
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The function hadn't been updated to account for the fact that we now
copy an endianness-corrected CBFS master header into a separate buffer
from the CBFS data: it still performed pointer arithmetic accross the
two buffers and wrote the copied buffer into the image without
restoring the original endianness.
Change-Id: Ieb2a001f253494cf3a90d7e19cd260791200c4d3
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10122
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
With the recent rename of documentation -> Documentation, the
checkpatch.pl script broke. Fix the tree check, and change the
user visible output of "kernel" to coreboot.
Change-Id: I34f538d4436e468b1c91eb36aa2f60a2a3308111
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10125
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This adds a compiler for a language whose textual representation of flashmap
regions will be used to describe the layout of flash chips that contain more
than just a single CBFS. Direct integration with cbfstool (via a new
command-line switch for the create action) is forthcoming but will be added
separately.
BUG=chromium:461875
TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for
panther. Using the latter file as a reference, write a corresponding
fmap.fmd file and feed it through fmaptool. Run both binary output files
though the flashmap project's own flashmap_decode utility. Observe only
the expected differences.
BRANCH=None
Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142
Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255031
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9942
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
There has been a problem with out of tree build directories specified
using relative paths, as in
$ make obj=../build/peppy
while specifying full path to obj works fine. This patch fixes the
problem, making sure that make's path manipulation string substitute
command is applied to both source and build roots.
To test this ran the following script
echo > /tmp/build.log
for build_root in ./ ../ ''; do
build_dirs="${build_root}build/peppy"
if [ -n "${build_root}" ]; then
build_dirs+=" $(realpath ${build_root})/build/peppy"
fi
for build_dir in ${build_dirs}; do
rm -rf $build_dir .config* build* ../build*
make obj=${build_dir} menuconfig # configure for google peppy board
echo "building in ${build_dir}" >> /tmp/build.log
if ! make obj=${build_dir}; then
exit
fi
done
done
and then checked the generated file:
$ cat /tmp/build.log
building in ./build/peppy
building in /home/vbendeb/old_projects/coreboot/source_code/build/peppy
building in ../build/peppy
building in /home/vbendeb/old_projects/coreboot/build/peppy
building in build/peppy
Change-Id: If46b046108e906796fe84716e93bf341b3785f14
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/10127
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This is being fixed in a separate commit so we can diff against the
library as it existed in its own repo.
Change-Id: Id87cd8f4e015a5ed7dd8a19302cc22ab744fefe8
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10141
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
flashmap was developed in a separate repository until now.
Import the files from the 2012 version of the project [1].
[1] https://code.google.com/p/flashmap
BUG=chromium:461875
TEST=None
BRANCH=None
Change-Id: Ida33f81509abc1cf2e532435adbbf31919d96bd8
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: f44e1d1864babe244f07ca49655f0b80b84e890d
Original-Change-Id: Ibf191d34df738449c9b9d7ebccca3d7f4150d4d3
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254801
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9940
Tested-by: build bot (Jenkins)
|
|
This fixes an inconsistency between `cbfstool create` and `cbfstool add` that
was resulting in confusing claims about the amount of free space at the end of a
CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file
entry by testing whether it would collide with the beginning of the *subsequent*
file header; thus, if a file's end is unaligned, its reported size will not
match the actual available capacity. Although deleted entries always end on an
alignment boundary because `cbfstool remove` expands them to fill the available
space, `cbfstool create` doesn't necessarily size a new entries region to result
in an empty entry with an aligned end.
This problem never resulted in clobbering important data because cbfstool would
blindly reserve 64B (or the selected alignment) of free space immediately after
the all-inclusive empty file entry. This change alters the way this reservation
is reported: only the overhang past the alignment is used as hidden padding, and
the empty entry's capacity is always reported such that it ends at an aligned
address.
Much of the time that went into this patch was spent building trust in the
trickery cbfstool employs to avoid explicitly tracking the image's total
capacity for entries, so below are two proofs of correctness to save others time
and discourage inadvertent breakage:
OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS
empty file header is small enough that it won't cross another aligned address.
OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such
that its contents end on an aligned address.
THM. 1: Placing a new file within an empty entry located below an existing file
entry will never leave an aligned flash address containing neither the beginning
of a file header nor part of a file.
We can prove this by contradiction: assume a newly-added file neither fills to
the end of the preexisting empty entry nor leaves room for another aligned
empty header after it. Then the first aligned address after the end of the
newly-inserted file...
- CASE 1: ...already contains a preexisting file entry header.
+ Then that address contains a file header.
- CASE 2: ...does not already house a file entry header.
+ Then because CBFS content doesn't fall outside headers, the area between
there and the *next* aligned address after that is unused.
+ By (A), we can fit a file header without clobbering anything.
+ Then that address now contains a file header.
THM. 2: Placing a new file in an empty entry at the very end of the image such
that it fits, but leaves no room for a final header, is guaranteed not to change
the total amount of space for entries, even if that new file is later removed
from the CBFS.
Again, we use contradiction: assume that creating such a file causes a
permanent...
- CASE 1: ...increase in the amount of available space.
+ Then the combination of the inserted file, its header, and any padding
must have exceeded the empty entry in size enough for it to cross at
least one additional aligned address, since aligned addresses are how
the limit on an entry's capacity is determined.
+ But adding the file couldn't have caused us to write past any further
aligned addresses because they are the boundary's used when verifying
that sufficient capacity exists; furthermore, by (B), no entry can ever
terminate beyond where the initial empty entry did when the CBFS was
first created.
+ Then the creation of the file did not result in a space increase.
- CASE 2: ...decrease in the amount of available space.
+ Then the end of the new file entry crosses at least one fewer aligned
address than did the empty file entry.
+ Then by (A), there is room to place a new file entry that describes the
remaining available space at the first available aligned address.
+ Then there is now a new record showing the same amount of available space.
+ Then the creation of the file did not result in a space decrease.
BUG=chromium:473726
TEST=Had the following conversation with cbfstool:
$ ./cbfstool test.image create -s 0x100000 -m arm
Created CBFS image (capacity = 1048408 bytes)
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 null 1048408
$ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1
1+0 records in
1+0 records out
1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big?
E: Failed to add 'toobigmed.bin' into ROM image.
$ truncate -s -1 toobigmed.bin
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
toobig 0x40 raw 1048408
$ ./cbfstool test.image remove
-n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
BRANCH=None
Change-Id: I118743e37469ef0226970decc900db5d9b92c5df
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e
Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263962
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9939
Tested-by: build bot (Jenkins)
|
|
Shouldn't be necessary, doesn't hurt either.
Change-Id: I4fa5cc2931523b5beac5ea5126e3e8b841446017
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10140
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In linking ramstage a single object file is created before linking
with the linker script. Though there is a weak timestamp_get() symbol
in timestamp.c any of its dependent symbols need to be available
during the incremental link. As not all platforms have
HAVE_MONOTONIC_TIMER enabled this will create a linking error.
Fix this by providing a hint to the compiler to remove dead code
and thus the dependent symbols causing linking errors in the presence
of !HAVE_MONOTONIC_TIMER.
Change-Id: Ib8a5dca2c12c2edac7605f403ed91b793823c8a3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10138
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Id1685c0b28ec8e3ab972a671af6f2de6f321c645
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9805
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I54fea74897010718cf495ffb51667c9cb15869b9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10124
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Change-Id: I9cbdf06f4d0956b5374915f8af7501c6f75b4687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10113
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
To avoid having to dig up the constraints again, document
the memory layout right in memlayout.ld.
Change-Id: I298cc880ae462f5b197ab2f64beb2f0e0d9f5a7d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10039
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add a Linux style MAINTAINERS file and the get_maintainer.pl
script from the Linux kernel source (adapted to work in the
coreboot source tree)
Change-Id: I983e30c20c371d238cfa7c0a074587b731387c63
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10021
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
We have discussed dropping lbtdump since 2007, since it was obsoleted
by lxbios (nowadays aka nvramtool) back then.
http://www.coreboot.org/pipermail/coreboot/2007-August/024188.html
Well, it's only eight years later.
Change-Id: I5242118cd3763d1b8c4bdc6f023cf93ae1b5b85d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10121
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This utility is AMD SC520 specific (and AMD SC520 support has been
dropped from coreboot)
Change-Id: I8ebd52c2e6af113d2110c106f88fdd7c0a672c98
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This utility was useful on older VIA Epia-M boards, which we
have dropped from the tree a while ago. Hence drop the utility
as well.
Change-Id: Ie0d6303f4f4cfb6b21cd90696c60e124f0a5f4d8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10119
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The Kconfig option list generator was broken by two different changes
to the project in the last few years:
- the switch to git from svn
- allowing wild card includes in Kconfig
Change-Id: I6bc5024a04958e9718d2e3a3a3bb6d69d4277eb6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10115
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This tool has had its own repository since a long time:
https://code.google.com/p/i915tool/
Drop the obsolete copy we kept in the tree.
Change-Id: Idee4ea3423453f6ced6e95c0bd2e45d95ca61851
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10114
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This utility links in coreboot code, and has been broken for a long
time. These changes get it to compile again.
Change-Id: I69445a8b3cbfc9a2b560c68b8de2e080837ec502
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10112
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This utility was only used to debug the initial ARM Chromebook bringup,
but it's not really useful anymore.
Change-Id: Icff0a80f244adae3c35a8430c54de9e415fbd7d0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10111
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In order to be closer to the Linux kernel source tree
structure, rename documentation to Documentation.
Change-Id: I8690f666638ef352d201bd3c3dc1923b0d24cb12
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10110
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This allows providing a verified boot mechanism in the
default distribution, as well as reusing vboot code like
its crypto primitives for reasonably secure checksums over
CBFS files.
Change-Id: I729b249776b2bf7aa4b2f69bb18ec655b9b08d90
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10107
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There's now room for other repositories under 3rdparty.
Change-Id: I51b02d8bf46b5b9f3f8a59341090346dca7fa355
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
To move 3rdparty to 3rdparty/blobs (ie. below itself
from git's broken perspective), we need to work around
it - since some git implementations don't like the direct
approach.
Change-Id: I1fc84bbb37e7c8c91ab14703d609a739b5ca073c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Adopted style from later Chromebooks.
Change-Id: I4993b8f40489b6bf5d08e00089f36f293853629e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/9992
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I708041133dfafdc97e052952ad9d8f2e4164209c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10105
Tested-by: build bot (Jenkins)
|
|
Change-Id: I2e7f17a686f6af3426c9d68cd9394e9a88dbf358
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10104
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
And we don't support lzma compressed data in verstage.
Change-Id: I3d8d3290f147871c49e9440e9b54bbf2742aaa9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10103
Tested-by: build bot (Jenkins)
|
|
The timestamp code's restriction to run only on the BSP
is for AMD systems. No need to run it everywhere, so
tighten the test (and only run boot_cpu() when required).
Change-Id: I800e817cc89e8688a671672961cab15c7f788ba8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
verstage still needs to be built with its flags.
Change-Id: I125e4be283d3838fc7ce6587bf9996731540d517
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10098
Tested-by: build bot (Jenkins)
|
|
bootblock et al were listed twice, which shouldn't happen.
Change-Id: I3e6077d70e064ebe74bd4e5e3156f87d548c2fcb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10097
Tested-by: build bot (Jenkins)
|
|
The name is more consistent with what we have elsewhere,
and the callsite didn't build at all (with vboot enabled)
Change-Id: I3576f3b8f737d360f68b67b6ce1683199948776d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10096
Tested-by: build bot (Jenkins)
|
|
It's not used at all.
Change-Id: I97bf02a9277f6ca348443c6886f77b4dfc70da78
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10095
Tested-by: build bot (Jenkins)
|
|
The vboot mechanism will be implemented within the program loader
subsystem to make it transparent to mainboards and chipsets.
Change-Id: Icd0bdcba06cdc30591f9b25068b3fa3a112e58fb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10094
Tested-by: build bot (Jenkins)
|
|
On current Danger boards, VCC_LCD is gated by BL_EN. Thus we
need to enable BL_EN in order to power on the display so that
we can read the EDID and set things up.
Later board revisions may change this ordering, but for now it
doesn't seem to be causing a significant issues (no noticable
"snow" or other corruption using Pepto display).
BUG=none
BRANCH=none
TEST=booted on Danger, saw dev mode screen come up
Change-Id: I70aab8c1f6da2d0fce310d59073026eef0f67821
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a918824e747600a2f3a88602320f4f563ce17b7
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Iaf17cc4682bd3c46f62cba789e3ecf8d5a474362
Original-Reviewed-on: https://chromium-review.googlesource.com/266913
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10089
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This patch initializes the GPIO for the Chrome EC interrupt line on
Veyron boards and passes its description through the coreboot table, so
that payloads with keyboard support can use it to detect pending key
presses.
BRANCH=none
BUG=chrome-os-partner:39514
TEST=Booted Jerry, confirmed that it could still detect keypresses.
Confirmed that EC log does not show a huge amount of MKBP polls.
Change-Id: I4de35ef411c3acc02282ebf8e764785a1e7bf6f1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8ad95d667ef3af3fb217e3c370468dc1d6ec36c9
Original-Change-Id: I8b426621af088460929cfff0a4b46618e2a86725
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/267344
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/10088
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
When CONFIG_CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM is set, this
function is now linked into the ramstage as well as the romstage,
since the former makes calls to it in panther builds.
With this commit, it's possible to build panther using the config file
from the Chromium OS project[1] if you supply the appropriate Intel
descriptor and ME binary blobs and manually set
CONFIG_VBOOT_VERIFY_FIRMWARE=n, CONFIG_BUILD_WITH_FAKE_IFD=n, and
CONFIG_HAVE_ME_BIN=y. The resulting image is at least able to load a
payload, although I only tested with depthcharge, which immediately
complained, "vboot handoff pointer is NULL" and gave up the ghost.
[1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/sys-boot/coreboot/files/configs/config.panther
Change-Id: Id3bb510fa60129a4d36a0117dc33e7aa62d6c742
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10046
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Do this to avoid reporting incorrect resource window in the logs.
Change-Id: Icb7978deeb54f0ec6c29473ce9034fe44b6d7602
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8890
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Remove some redundancy in both source code and console output.
Change-Id: I32350966de7af30b3ca4ac747fe3bf623ea9484b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8889
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Once a bridge window resource is allocated, it becomes the base and limit
for any resource on the secondary bus. Upper limit was incorrectly
reported in the log while assigning secondary resources.
Change-Id: I69f0a02aae6d13f77aaa2dace924b8970b23edad
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8888
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I19af5f36a55d6c2906d603e940b3aadd2ca97140
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/8317
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The 'A' indicates the production process(64 nm). All other chips from
the same family leave this out.
TEST=Build and booted on Minnowboard Max
Change-Id: I21e6c01de5d547bbc2252e679a001948e7ab752c
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10078
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
'.op_erase' was not specified for this chip. Set it to sub sector
erase(CMD_M25PXX_SSE). Adjust page/sector size for sub sector erase
to work.
TEST=Untested, due to lack of hardware.
Change-Id: Icc2748fbd3afeb56693e1c17d97eb490fba67064
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10077
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
N25Q064 is similar to N25Q128.
TEST=Build and booted twice on Minnowboard Max
Change-Id: Iec105f8b81f619846cf40b40042cc59150b81149
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10076
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Fix compiler error's due to type mismatch. This is broken since commit
bde6d309 (x86: Change MMIO addr in readN(addr)/writeN(addr, val) to
pointer).
TEST=Build with CONFIG_DEBUG_SPI_FLASH=y and booted on Minnowboard Max
Change-Id: Id3d448e219716135897f381a73d416ff34036118
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10075
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
What is described by the comment has already been fixed in f0d038f4
(flash: use two bytes of device ID to identify stmicro chips).
This also means that STM_ID_N25Q128 doesn't have to be at the top of
stmicro_spi_flash_table anymore.
TEST=Untested, due to lack of hardware
Change-Id: I7a9e9a0cdfdb1cf34e914e186fc6957c1d9b5ca6
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10068
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The log message says 'page size' while actually the sector size is
printed. This is confusing since for stmicro page size != sector size.
Also add '0x' prefix to numbers to make it clear they are in hex.
TEST=Build and booted on Minnowboard Max
Change-Id: I795a4b7c1bc8de2538a87fd4ba56f5a78d9ca2ac
Signed-off-by: David Imhoff <dimhoff_devel@xs4all.nl>
Reviewed-on: http://review.coreboot.org/10067
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
OpenBSD refuses to implement it due to security concerns,
so use glob instead.
Change-Id: I7531cfe91deff240f7874d94d5acb340b87e51b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10028
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Make the XHCI driver compile on ARM again. The Panther Point
specific shutdown handler is certainly _not_ necessary there.
Change-Id: I470afd4d82d101902b119b3ead4381e2b36a94b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10091
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
None of the sockets has actual configuration options, so the source
for them is only cosmetical boilerplate. Hence, drop it. This reduces
the sockets to be selectors for certain CPU types, which will be dropped
in future commits, and mainboards will select their CPUs directly rather
than through an additional layer of indirection (sockets)
Change-Id: I0f52a65838875a73531ef8c92a171bb1a35be96e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9797
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
The file have been updated to warn wiki users to edit
the page as it is generated by a bot.
Change-Id: I5802ff8c7986c0fd93adf58e2353df81de9c2b75
Signed-off-by: David Englund <public@beloved.name>
Reviewed-on: http://review.coreboot.org/8682
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Patrick Georgi <pgeorgi@google.com>
|
|
Currently `xcompile` generates `.xcompile` with the following at the
top.
# platform agnostic and host tools
IASL:=iasl
HOSTCC:=gcc
The assignment `:=` doesn’t allow to override the variable. So use `?=`
instead so the host compiler can be passed to coreboot.
HOSTCC=gcc-5 make
Note, that this is just a hack, as the existence of `gcc` is checked
beforehand.
Change-Id: Iebf3e43eb7eaffa7cf0efe97710d9feb3fe2a989
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/9457
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
If the buildgcc is interrupt by Ctrl-C, probably part of
an archive is downloaded. If we run buildgcc again, the
incomplete archive would be considered as cached file
and skipped.
We check file hashes to see if the file is complete. If test
is failed, we need to delete the partially-downloaded file
and download it again.
sha1sum is quite different among the distributions.
Only Linux, Cygwin, Darwin have been tested.
Once new archive is deployed, a new checksum would be created,
which should be uploaded along with the script buildgcc.
Change-Id: Ibb1aa25a0374f774e1e643fe5e698de7bf7cc418
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4511
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Commit 0e53931f (cbfstool: Clean up in preparation for adding new
files) split out the flags and introduced the variable `LINKFLAGS`.
Rename it to `LDFLAGS` which is more commonly used.
Change-Id: Ib6299f8ef5cf30dbe05bfae36f30ae4371f0a738
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10064
Tested-by: build bot (Jenkins)
Reviewed-by: Sol Boucher <solb@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I226a1a6bc6b1f921c03f8ec57875a88314928aeb
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/9318
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fix up commit c13ad6c6 (driver/intel/fsp: Correct the fastboot data (MRC
data) printing length) unintentionally making the changed files
executable.
Change-Id: I909c323023a9ccfb0c20094d9085ae90043b9e04
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10060
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Change-Id: I9f65922d0785e06a173221b3262e73b575087dfd
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/9321
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The Rangeley chipset has the MMIO PCI config space feature
enabled at 0xe0000000-0xefffffff. This is a 256MB space
which covers all of config space. The ACPI table for
this space only defines it as being 64MB. This change
fixes that setting.
Change-Id: I8205a9b89ea6633ac6c4b0d5a282cd2745595b2e
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/10047
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
|
|
Several of the intel platforms define the region reserved
for PCI memory resources in a location where it overlaps
with the MMIO (MCFG) region.
Using the memory map from mohon_peak as an example:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-000000007fbcffff: RAM
4. 000000007fbd0000-000000007fbfffff: CONFIGURATION TABLES
5. 000000007fc00000-000000007fdfffff: RESERVED
6. 00000000e0000000-00000000efffffff: RESERVED
7. 00000000fee00000-00000000fee00fff: RESERVED
8. 0000000100000000-000000017fffffff: RAM
The ACPI table describing the space set aside for PCI memory
(not to be confused with the MMIO config space) is defined
as the region from BMBOUND (the top of DRAM below 4GB) to
a hardcoded value of 0xfebfffff. That region would overlap
the MMIO region at 0xe0000000-0xefffffff. For rangeley
the upper bound of the PCI memory space should be set
to 0xe0000000 - 1.
The MCFG regions for several of the affected chipsets are:
rangeley 0xe0000000-0xefffffff
baytrail 0xe0000000-0xefffffff
haswell 0xf0000000-0xf3ffffff
sandybridge 0xf8000000-0xfbffffff
TEST = intel/mohonpeak and intel/bayleybay.
Change-Id: Ic188a4f575494f04930dea4d0aaaeaad95df9f90
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/9972
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
|
|
Commit e2c2bb9 (dmp/vortex86: move PLL config to cpu Kconfig)
failed to properly restrict the PLL config selection to that cpu,
resulting in the selection option being present/required for all CPUs.
Fix by guarding the Kconfig options with if/endif.
Change-Id: Ifecf291b985ab9d0d13d6b1264d3bc9a314b8546
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/10038
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
As the first step in adding support for FSP 1.1, add common header files
for EDK2. Internally FSP is based upon EDK2 and uses the defines and
data structures within these files for its interface.
These files come from revision 16227 of the open source EDK2 tree at
https://svn.code.sf.net/p/edk2/code/trunk/edk2. These files are
provided in an EDK2 style tree to allow direct comparison with the EDK2
tree.
Updates may be done manually to these files but only to support FSP 1.1
on UEFI 2.4. A uefi_2.5 tree should be added in the future as FSP
binaries migrate to UEFI 2.5.
Note: All the files were modified to use Linux line termination.
BRANCH=none
BUG=None
TEST=Build for Braswell or Skylake boards using FSP 1.1.
Change-Id: Ide5684b7eb6392e12f9f2f24215f5370c2d47c70
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9943
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I3091437444ffd9ca3e103c41c37a5374805b1231
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10045
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Remove dependency of Haswell on cpu/intel/socket_rpga989 code,
which is a carry-over from Sandy Bridge/Ivy Bridge and older
coreboot conventions where features were structured around socket types.
Add CPU-specific options to Kconfig and required subdirs to
Makefile.inc which are curently included with socket_rpga989.
TEST=successfully built and booted on google/panther
Change-Id: Ic788e2928df107d11ea2d2eca7613490aaed395c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/10037
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
So don't try to use it elsewhere.
Change-Id: Ia600ba654bde36d3ea8a0f3185afae00fe50bfe9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10030
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fixes up commit 93d8e3c4 (armv7-m: add armv7-m configuration).
Change-Id: Ie0b6c90e9ce89d564e3345d2746297f39ba9121d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10042
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ieac02fcc4508f7c1b194802453d6222b902a38a2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10032
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
That's a Haswell exclusive, used nowhere else, but confusing
when hunting for the monotonic timer used on that SoC.
Change-Id: I60ec523e54e5af0d2a418bcb9145de452a3a4ea9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10034
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
