They're listed in AUTHORS and often incorrect anyway, for example:
- What's a "Copyright $year-present"?
- Which incarnation of Google (Inc, LLC, ...) is the current
copyright holder?
- People sometimes have their editor auto-add themselves to files even
though they only deleted stuff
- Or they let the editor automatically update the copyright year,
because why not?
- Who is the copyright holder "The coreboot project Authors"?
- Or "Generated Code"?
Sidestep all these issues by simply not putting these notices in
individual files, let's list all copyright holders in AUTHORS instead
and use the git history to deal with the rest.
Change-Id: I89b10076e0f4a4b3acd59160fb7abe349b228321
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39611
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the POSIX standard, %p is supposed to print a pointer "as
if by %#x", meaning the "0x" prefix should automatically be prepended.
All other implementations out there (glibc, Linux, even libpayload) do
this, so we should make coreboot match. This patch changes vtxprintf()
accordingly and removes any explicit instances of "0x%p" from existing
format strings.
How to handle zero padding is less clear: the official POSIX definition
above technically says there should be no automatic zero padding, but in
practice most other implementations seem to do it and I assume most
programmers would prefer it. The way chosen here is to always zero-pad
to 32 bits, even on a 64-bit system. The rationale for this is that even
on 64-bit systems, coreboot always avoids using any memory above 4GB for
itself, so in practice all pointers should fit in that range and padding
everything to 64 bits would just hurt readability. Padding it this way
also helps pointers that do exceed 4GB (e.g. prints from MMU config on
some arm64 systems) stand out better from the others.
Change-Id: I0171b52f7288abb40e3fc3c8b874aee14b9bdcd6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: David Guckian
Since struct vb2_shared_data already contains workbuf_size and
vboot_workbuf_size is never used in depthcharge, remove it from struct
sysinfo_t. In addition, remove lb_vboot_workbuf() and add
CBMEM_ID_VBOOT_WORKBUF pointer to coreboot table with
add_cbmem_pointers(). Parsing of coreboot table in libpayload is
modified accordingly.
BRANCH=none
BUG=chromium:1021452
TEST=emerge-nami coreboot libpayload depthcharge; Akali booted correctly
Change-Id: I890df3ff93fa44ed6d3f9ad05f9c6e49780a8ecb
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
After CB:36808, CB:36844 and CB:36845, all fields except buffer_offset
were removed from struct vboot_working_data. Since buffer_offset is used
to record the offset of the workbuf relative to the whole structure, it
is no longer needed.
This patch removes the structure, and renames vboot_get_working_data()
to vboot_get_workbuf().
BRANCH=none
BUG=chromium:1021452
TEST=emerge-nami coreboot
Change-Id: I304a5e4236f13b1aecd64b88ca5c8fbc1526e592
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Drop struct cbfs_props and replace with struct region_device object.
The goal of the cbfs locator APIs are to determine the correct region
device to find the cbfs files. Therefore, start directly using struct
region_device in the cbfs location paths. Update the users of the API
and leverage the default boot region device implementation for
apollolake.
Change-Id: I0158a095cc64c9900d8738f8ffd45ae4040575ea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36939
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since buffer_size is no longer used, remove it from struct
vboot_working_data.
BRANCH=none
BUG=chromium:1021452
TEST=emerge-kukui coreboot
Change-Id: Ie770e89b4a45e0ec703d5bbb8fb6a298ce915056
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
CB:35377 changed the behavior of find_fmap_directory() to return
pointer to CBMEM_ID_FMAP if fmap is cached in
cbmem. lb_boot_media_params() calls find_fmap_directory to add offset
of fmap in flash to coreboot table. However, because of the change in
behavior of find_fmap_directory(), it ended up adding 0 as the offset.
This change adds a new function get_fmap_flash_offset() which returns
the offset of fmap in flash. Ideally, all payloads should move to
using the FMAP from CBMEM. However, in order to maintain compatibility
with payloads which are not updated, ensure that fmap_offset is
updated correctly.
Since find_fmap_directory() is no longer used outside fmap.c, this
change also removes it from fmap.h and limits scope to fmap.c.
In a follow up patch, we need to push a change to libpayload to expose
the fmap cache pointer to lib_sysinfo.
BUG=b:141723751
Change-Id: I7ff6e8199143d1a992a83d7de1e3b44813b733f4
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shelley Chen <shchen@google.com>
For platform independend exposure of FMAP through a kernel module
cache the FMAP in CBMEM. In addition add a pointer in coreboot tables
pointing to the introduced CBMEM area.
To not waste the allocated DRAM, use the cached CBMEM in RAM enabled
stages if possible.
Tested on qemu using
https://github.com/9elements/linux/commits/google_firmware_fmap2
Tested on QEMU and Supermicro X11SSH-TF.
Change-Id: I4e01c573c3edfa34dbba5fe7604d4f6e18b584d5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Every vga init implementation needs to cache the framebuffer state
to be able to fill the lb_framebuffer struct later on in the
fill_lb_framebuffer call. Showing the bootsplash afterwards
guarantees to have the same interface into all the vga drivers.
This is by far from ideal, as it only allows for a single driver at
compile-time and should be adapted in the future.
It was tested on the wip razer blade stealth using vgabios @ 1280x1024
and also in Qemu @ 1280x1024.
By default the qemu framebuffer will be initialized in 800x600@32.
This can be overwriten by configuration by setting
CONFIG_DRIVERS_EMULATION_QEMU_BOCHS_{X,Y}RES .
Change-Id: I4bec06d22423627e8f429c4b47e0dc9920f1464e
Signed-off-by: Johanna Schander <coreboot@mimoja.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34599
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
vboot_handoff is no longer used in coreboot, and is not
needed in CBMEM or cbtable.
BUG=b:124141368, b:124192753
TEST=make clean && make runtests
BRANCH=none
Change-Id: I782d53f969dc9ae2775e3060371d06e7bf8e1af6
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33536
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Also adapt all users of these symbols
Change-Id: Ibf924a283d438de49a93ce661b0d9ca1a81cd6d1
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Pass the return value from early_mmc_wake_hw() to the payload so that
payload can skip sending CMD0 and resetting the card in case of success
or in case of a failure in firmware, payload can recover by sending
CMD0 and resetting the card.
BUG=b:78106689
TEST=Boot to OS
Change-Id: Ia4c57d05433c3966118c3642913d7017958cce55
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/25464
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create a new cbtable entry called VBOOT_WORKBUF for
storing a pointer to the vboot workbuf within the
vboot_working_data structure.
BUG=b:124141368, b:124192753
TEST=Build and deploy to eve
TEST=util/lint/checkpatch.pl -g origin/master..HEAD
TEST=util/abuild/abuild -B -e -y -c 50 -p none -x
BRANCH=none
Change-Id: Id68f43c282939d9e1b419e927a14fe8baa290d91
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31887
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch is a raw application of
find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g'
Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since we can derive chromeos_acpi's location from that of
ACPI GNVS, remove chromeos_acpi entry from cbtable and
instead use acpi_gnvs + GVNS_CHROMEOS_ACPI_OFFSET.
BUG=b:112288216
TEST=None
CQ-DEPEND=CL:1179725
Change-Id: I74d8a9965a0ed7874ff03884e7a921fd725eace9
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/28190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is a confusingly named section in cbmem called vdat.
This section holds a data structure called chromeos_acpi_t,
which exposes some system information to the Chrome OS
userland utility crossystem.
Within the chromeos_acpi_t structure, there is a member
called vdat. This (currently) holds a VbSharedDataHeader.
Rename the outer vdat to chromeos_acpi to make its purpose
clear, and prevent the bizarreness of being able to access
vdat->vdat.
Additionally, disallow external references to the
chromeos_acpi data structure in gnvs.c.
BUG=b:112288216
TEST=emerge-eve coreboot, run on eve
CQ-DEPEND=CL:1164722
Change-Id: Ia74e58cde21678f24b0bb6c1ca15048677116b2e
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/27888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The write_tables function was void. It is a bit more
useful for loading payloads from the romstage
if it returns a pointer to the table it creates.
Change-Id: I6eeaf3e16bcbaf1e7ec3eada8026c466d2fb6f5a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/27537
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In https://review.coreboot.org/25383 people were confused about the
ordering of bootmem calls w.r.t. when entries are exposed to the OS. To
alleviate this add a notion of bootmem being initialized. In addition to
that, only mark bootmem initialized when bootmem_write_memory_table() is
called. Any other calls to bootmem before that will report an error on
the console.
Change-Id: I5bc31f555038ccabb82d902c54f95858679b1695
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Looks like there's a typo in the GPIO state table we print as part of
assembling the coreboot tables. Of course, high GPIOs are represented as
1 and low GPIOs as 0. Fix this display bug.
Change-Id: I59b4d49955c13f920576dd09f463e2d399ab64e0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25022
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On many recent Chrome OS boards, the desire to unite more configurations
under the same image has led to the need of a "SKU ID" that identifies
different configurations of the same board (e.g. with certain optional
components stuffed or not stuffed, or replaced with a comparable
component). This is markedly different from the existing "board ID",
because that is reserved to count "revisions" -- changes made to the
same configuration over time during the development process. This patch
adds support to have a mainboard define this SKU ID and pass it through
the coreboot table like we already have for board IDs.
Change-Id: I8aabffe8e1003b0d6fb70d689ae513ca4b46aeda
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22696
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch switches the board_id and ram_code helper framework to use
weak functions rather than Kconfigs to determine whether the board
supplies these IDs. This cuts down on the amount of boilerplate Kconfigs
many boards have to set and also gives them more flexibility, such as
being able to determine at runtime whether a given ID is present.
Change-Id: I97d6d1103ebb2a2a7cf1ecfc45709c7e8c1a5cb0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22695
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Merge the different coreboot table strapping ID structures into one
because they're really just all the same, and I want to add more. Make
the signature of the board_id() function return a uint32_t because
that's also what goes in the coreboot table. Add a printk to the generic
code handling strapping IDs in ramstage so that not every individual
mainboard implementation needs its own print. (In turn, remove one such
print from fsp1_1 code because it's in the way of my next patch.)
Change-Id: Ib9563edf07b623a586a4dc168fe357564c5e68b5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The BOARD_ID_MANUAL and BOARD_ID_STRING options were introduced for the
Urara board which is now long dead, and have never been used anywhere
else. They were trying to do something that we usually handle with a
separate SKU ID these days, whereas BOARD_ID is supposed to be reserved
for different revisions of the same board/SKU. Get rid of it to make
further refactoring of other options easier.
Also shove some stuff back into the Urara mainboard that should've never
crept into generic headers.
Change-Id: I4e7018066eadb38bced96d8eca2ffd4f0dd17110
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22694
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit just moves the vboot sources into
the security directory and fixes kconfig/makefile paths.
Fix vboot2 headers
Change-Id: Icd87f95640186f7a625242a3937e1dd13347eb60
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/22074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
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>
Zero the framebuffer structure so if it is not filled in (either if
no display is present or if there is an error) then it does not
provide garbage data to the payload.
This was noticed when booting a board without a display attached as
the payload wrote to the framebuffer at a random address.
With this change the payload can properly handle the case where a
display is not attached and not corrupt memory.
Change-Id: I8114d88496cd2a4f2e7f07f377fe76f3180a7f40
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/20367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Remove the weak function stub fill_lb_framebuffer() and guard with the
new `CONFIG_LINEAR_FRAMEBUFFER` instead.
Change-Id: Ia9e477c2d501b249a632968b5636ac803323895a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
For some reason the "interface" for adding framebuffer information
is sitting in src/include/vbe.h while also guarding the call to
fill_lb_framebuffer() with vbe_mode_info_valid() along with some
macro if CONFIG_* for good measure.
Move the fill_lb_framebuffer() declaration to coreboot_tables.h and
provide a comment about how it should be used. Also, now that
there's no need for the notion of a global vbe_mode_info_valid()
remove it from the conditional call path of fill_lb_framebuffer().
Change-Id: Ib3ade6314624091ae70424664527a02b279d0c9b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/19729
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix the following warning detected by checkpatch.pl:
WARNING: line over 80 characters
TEST=Build and run on Galileo Gen2
Change-Id: I5fa3f8e950e2f0c60bd0e8f030342dc8c0469299
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18758
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix the following error detected by checkpatch.pl:
ERROR: space required before the open parenthesis '('
TEST=Build and run on Galileo Gen2
Change-Id: I8953fecbe75136ff989c9e3cf6c5e155dcee3c3b
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18698
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fix the following warning detected by checkpatch.pl:
WARNING: braces {} are not necessary for single statement blocks
TEST=Build and run on Galileo Gen2
Change-Id: Ie4b41f6fb75142ddd75103a55e0347ed85e7e873
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18697
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins)
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>
Fix the following errors detected by checkpatch.pl:
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that close parenthesis ')'
TEST=Build and run on Galileo Gen2
Change-Id: I586c5731c080282080fe5ddf3ac82252cb35bdd4
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18636
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
They were sized to 32-bit alignment, this grows them to 64 bit-aligned.
Change-Id: I494b942c4866a7912fb48a53f9524db20ac53a8c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/18165
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The spi_flash_probe() routine was setting a global varible
unconditonally regardless if the probe was for the boot device
or even if the boot devcie was flash. Moreover, there's no need
to report the SPI information if the boot device isn't even SPI.
Lastly, it's possible that the boot device is a SPI flash, but
the platform may never probe (selecting SPI_FLASH) for the
actual device connected. In that situation don't fill anything
in as no correct information is known.
BUG=chrome-os-partner:56151
Change-Id: Ib0eba601df4d77bede313c358c92b0536355bbd0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16197
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
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>
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>
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>
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>
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>
