This adds the RAM config code to the coreboot tables. The purpose is
to expose this information to software running at higher levels, e.g.
to print the RAM config coreboot is using as part of factory tests.
The prototype for ram_code() is in boardid.h since they are closely
related and will likely have common code.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=tested w/ follow-up CLs on pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Idd38ec5b6af16e87dfff2e3750c18fdaea604400
Reviewed-on: https://chromium-review.googlesource.com/227248
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since gpio.c is more generic now and will be used in various
stages (ie for board_id()), compile it for all stages.
BUG=none
BRANCH=none
TEST=compiled for peppy and veyron_pinky
Change-Id: I77ec56a77e75e602e8b9406524d36a8f69ce9128
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228325
Reviewed-by: Julius Werner <jwerner@chromium.org>
This deprecates TERTIARY_BOARD_ID. Instead, a board will set
BOARD_ID_SUPPORT (the ones affected already do) which will set
GENERIC_GPIO_SUPPORT and compile the generic GPIO library.
The user is expected to handle the details of how the ID is encoded.
BUG=none
BRANCH=none
TEST=Compiled for peppy, nyan*, storm, and pinky
Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228322
Reviewed-by: Julius Werner <jwerner@chromium.org>
This adds gpio_base2_value() which reads an array of 2-state
GPIOs and returns a base-2 value, where gpio[0] represents the
least significant bit.
BUG=none
BRANCH=none
TEST=tested with follow-up patches for pinky
Change-Id: Ia7ffc16eb60e93413c0812573b9cf0999b92828e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228323
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch makes a few cosmetic changes:
- Rename tristate_gpios.c to gpio.c since it will soon be used for
binary GPIOs as well.
- Rename gpio_get_tristates() to gpio_base3_value() - The binary
version will be called gpio_base2_value().
- Updates call sites.
- Change the variable name "id" to something more generic.
BUG=none
BRANCH=none
TEST=compiled for veyron_pinky and storm
Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228324
Empty functions are provided when !CONFIG_COLLECT_TIMESTAMPS
so stop guarding the compilation.
BUG=None
BRANCH=None
TEST=Built
Change-Id: Ib0f23e1204e048a9b928568da02e9661f6aa0a35
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228190
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add support for:
1) Using timestamps in bootblock and verstage
2) Allowing the timestamps to be stashed into _timestamp region so that they can
be used across multiple stages
3) Performing operations over the timestamps in _timestamp region
Instead of having two separate APIs for stashing and adding timestamps, let the
timestamp library decide on its own where to save depending on timestamp cache
status. Now the sequence of operations would be something like:
timestamp_init / timestamp_early_init : Set the base time
timestamp_add / timestamp_add_now
cbmem_initialize : It internally calls timestamp_sync
timestamp_add / timestamp_add_now
BUG=chrome-os-partner:32973
BRANCH=None
TEST=Compiles successfully for ryu and samus. cbmem -t on ryu works fine.
Change-Id: Ie5ffda3112d626068bd1904afcc5a09bc4916d16
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/224024
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
This patch adds plumbing necessary to ensure that the CBMEM WiFi
calibration blobs entry, if present, is referenced if the coreboot
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none - the entry is not yet in the CBMEM
Change-Id: I04d52934ad1c5466d0d124b32df5ab17c0f59686
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225270
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
this change makes bootblock and verstage built for armv7-m use generic memset,
memcpy, and memmove because arch/arm/memset.S, memcpy.S, and memmove.S are not
compatible with armv7-m.
BUG=none
BRANCH=ToT
TEST=Ran bootblock on Cosmos prototype board. Emerged all current boards.
Change-Id: Ie1df2525362ffc2e8438ff7bd5fad7629b0477de
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225312
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219901
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220975
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch aligns baytrail to the new SoC header include scheme.
BUG=None
TEST=Tested with whole series. Compiled Rambi.
Change-Id: If5d2a609354b3d773aa3d482e682ab97422fd9d5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222026
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Retrieval of the MAC address from the VPD is a Chrome OS specific
feature, required just on one platform so far. There is no need to
look for the MAC address in the VPD on all other Chrome OS boards.
BRANCH=storm
BUG=chromium:417117
TEST=with the upcoming patch applied verified that MAC addresses still
show up in the device tree on storm
Change-Id: I8e6f8dc38294d3ab11965931be575360fd12b2fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223796
Reviewed-by: Julius Werner <jwerner@chromium.org>
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER
configuration option enabled, so the verstage is missing the relevant
files in some Makefiles. This patch fixes the problem.
BRANCH=none
BUG=none
TEST=with the rest of the patches applied cosmos target builds fine
with COMMON_CBFS_SPI_WRAPPER enabled
Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223751
Reviewed-by: Aaron Durbin <adurbin@chromium.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.
Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222899
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When cbfs debug is enabled, compilation fails because one of the debug
messages is using an non-existing variable.
BRANCH=nonr
BUG=None
TEST=compiling with CONFIG_DEBUG_CBFS enabled does not fail anymore.
Change-Id: Ic83f5e96cdcb5275ec0b7fadbc901e254a1002ca
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213370
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get
predefined in their respective stages by make, so that we have one
specific macro for every stage. It also renames __BOOT_BLOCK__ and
__VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency.
This change is intended to provided finer control and clearer
communication of intent after we added a new (optional) stage that falls
under __PRE_RAM__, and will hopefully provide some robustness for the
future (we don't want to end up always checking for romstage with #if
defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) &&
!defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The
__PRE_RAM__ macro stays as it is since many features do in fact need to
differentiate on whether RAM is available. (Some also depend on whether
RAM is available at the end of a stage, in which case #if
!defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be
authoritative.)
It's unfeasable to change all existing occurences of __PRE_RAM__ that
would be better described with __ROMSTAGE__, so this patch only
demonstratively changes a few obvious ones in core code.
BUG=None
TEST=None (tested together with dependent patch).
Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch started out as an attempt to run linker scripts through the
preprocessor. However, since that required some more infrastructure
changes, the build system is so intertwined, and there are so many other
small issues that turned up and are easier to fix (and get running, and
test thoroughly) in a single go, it turned out a little bigger. In order
of appearance, it:
- wraps direct linker invocations in a macro to avoid the widespread
ifeq($(CONFIG_COMPILER_LLVM_CLANG),y) duplication.
- introduces an $(generic-deps) (equivalent to $(<class>-deps)) variable
for targets that all files depend on
- makes the $(src-to-obj) function usable in multiple places as the
authoritative way to get an output file name (even if the respective
source file is also under build/), and makes it preserve extensions on
everything except %.c and %.S (e.g. %.ld and %.asl)
- replaces the old $(<class>-postprocess) with a single
$(postprocessors) variable. The old ramstage-postprocess was weird
because it contained unescaped $(eval ...)s, meaning it gets executed
as soon as the variable is first substituted (and the other
$(eval ...) in the toplevel Makefile does essentially nothing). The
new mechanism is just $(eval ...)ed directly after the recursive parse
with no further magic. Files can freely append their own (escaped)
content to it and access variables valid in the calling context (like
$(<class>-objs)) directly.
- enhances the existing $(<class>-<type>-ccopts) mechanism with
$(<class>-generic-ccopts) and $(generic-<type>-ccopts) to reduce
duplication.
- makes .ld a type that can be added like a normal class file, causing
it to be preprocessed with the correct #defines for the current class
(needed for a follow-up feature). Migrates all linker scripts to this
mechanism, which allows us to get rid of the weird $(ldoptions)
mechanism (Kconfigs are replaced by preprocessor and no longer need to
be defined as symbols).
- removes duplicate $(INCLUDES) from $(CFLAGS)
- repairs the crazy state of MIPS Makefiles, which seem to have been
copied together from X86 despite having absolutely nothing in common
with that architecture. They were using the same code to paste
assembly pieces and linker scripts together without really needing it
for anything, and even accidentally relied on a Kconfig default set
in the arch/x86 subdirectory (I wish I was kidding). Changed them to
work equivalent to the arm/arm64 Makefiles which are far closer
related (also being SRAM-based platforms).
- moves the x86-specifc $(OPTION_TABLES_H) into the x86 Makefile.inc and
fixes an rule that would've had an empty target if it wasn't defined
- removes the custom ldscript-gathering variables for x86 bootblock and
romstage. The Makefile simply combines all .ld files that have been
added to the respective class now.
- uses the normal class build system to replace some of the custom rules
for autogenerated bootblock/crt0 files on x86, and removes some
hardcoded flags by using the normal $(...-ccopts) variables.
- moves the handling of .asl files from the global Makefile.inc to x86.
Changed to reuse the generic template for the preprocessing and C
compilation steps.
- removed the extra <name>.o linking step before linking an rmodule for
modules that don't require special linker flags (most of them).
- removes the incorrect assumption that there was a global $(LDFLAGS)
from the SMM Makefile.inc (it was named $(LDFLAGFS in one place so it
couldn't have been all that important ;) ).
- allow -j flag for parallel builds to be properly passed through to
vboot child invocation by using special $(MAKE) variable.
BUG=None
TEST=Built for Falco, Nyan_Blaze, Stout, Rush_Ryu and Urara. Binary
diffed old and new coreboot.rom (and some manually uncompressed stages),
confirmed that images/stages are byte-for-byte identical except for some
embedded timestamps and commit hashes. (Addresses in Falco/Stout
ramstages shifting slightly due to different link order for ASL object
files within their directory. Some addresses in Urara ramstage .rodata
and some relocation entries in rmodules moved around due to linking them
in fewer steps.)
Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add GENERIC_UDELAY Kconfig option so that a generic
udelay() implementation is provided utilizing the
monotonic timer. That way each board/chipset doesn't
need to duplicate the same udelay(). Additionally,
assume that GENERIC_UDELAY implies init_timer()
is not required.
BUG=None
BRANCH=None
TEST=Built nyan, ryu, and rambi. May need help testing.
Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219719
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Chrome OS devices firmware usually includes an area called VPD (Vital
Product Data). VPD is a blob of a certain structure, in particular
containing freely defined variable size fields. A field is a tuple of
the field name and field contents.
MAC addresses of the interfaces are stored in VPD as well. Field names
are in the form of 'ethernet_macN', where N is the zero based
interface number.
This patch retrieves the MAC address(es) from the VPD and populates
them in the coreboot table so that they become available to the
bootloader.
BUG=chrome-os-partner:32152, chromium:417117
TEST=with this and other patches in place the storm device tree shows
up with MAC addresses properly initialized.
Change-Id: I12c0d15ca84f60e4824e1056c9be2e81a7ad8e73
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219443
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Coreboot generic CBFS media API does not support
multiple media access instances, but it should.
With this fix the CBFS context (memory cache for
SPI accesses) is shared among all open media access
streams. A better memory management scheme might be
required, but for now this fix allows to support
booting deptcharge and accessing VPD through two
independent CBFS media streams.
BUG=chrome-os-partner:32152
TEST=no exception is thrown when the second stream
is opened
Change-Id: Ib9d9d1f5209c2e515a95d7acbf4a8ac1255d3f8a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219441
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Change-Id: I0797b5010afd7316fdec605784e8f48e2d62c37f
Reviewed-on: https://chromium-review.googlesource.com/218883
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
this change makes cbfs able to load a decompressed stage to the load
address without using the cache. this reduces sram footprint in early
boot stages.
BUG=none
TEST=Booted veyron pinky and nyan blaze.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ie60dbaedfa740b84037e7f059812dc5617ad8502
Reviewed-on: https://chromium-review.googlesource.com/217978
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Reviewed-on: https://chromium-review.googlesource.com/212365
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In some cases, we need to use 1 common VGA device ID to share
among different VGA devices.
But it will show error when it can't find a specific pci rom
by PCI DID.
in fact, it will find the pci rom with common vga ID.
Without this commit, you may need to skip error check during
suspend_stress_test
BUG=none
BRANCH=none
TEST=build OK, and check no error on Auron and Samus
Change-Id: Ib743e960f772b7e2e73a1feb80790a13bd8c06c7
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/217415
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Required for arm64 platforms: rmodules used for arm64 require module_params and
rodata to be placed at 8-byte boundary in order to avoid unaligned access.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully and address verified during boot
Change-Id: I4820efad2b408ebd3930943f7771805a7bbb62e9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216374
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Fix the alignment for 64-bit systems
BUG=chrome-os-partner:31615
BRANCH=None
TEST=Compiles successfully and rmodule load and run for arm64 works fine
Change-Id: I7fcb1683d760b96307759b7d44d8770dd49a02e3
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214326
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
nyan blaze fails to boot because tristates of the board id are interpreted in
the reverse order. this change fixes it.
BUG=none
TEST=Booted Blaze to Linux. Built firmware for Storm.
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I6d81092becb60d12e1cd2a92fc2c261da42c60f5
Reviewed-on: https://chromium-review.googlesource.com/211700
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
The name was changed due to review comments misunderstanding, it
should be restored to properly convey what the function does.
BUG=chrome-os-partner:30489
TEST=verified that Storm still properly reports board ID
Change-Id: I4bd63f29afbfaf9f3e3e78602564eb52f63cc487
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211413
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For the majority of Chrome OS boards there is no need to include board
ID calculation in any stage but ramstage, where the ID should be
available for inclusion into the coreboot table.
BUG=chrome-os-partner:30489
TEST=build only, no other tests yet
Change-Id: Ib9c06698a399d31e79a9b14143343ba2ad46d0fb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210117
Reviewed-by: Julius Werner <jwerner@chromium.org>
Board ID value is usually of interest to bootloaders. Instead of
duplicating the board ID discovery code in different bootloaders let's
determine it in coreboot and publish it through coreboot table, when
configured.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210116
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209673
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide functionality to create dynamic classes based on program name and the
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class and compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/209379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to Coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation
the bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Reviewed-on: https://chromium-review.googlesource.com/206065
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
1) Add check for zero size in memrange.
2) Add public memrange_init_empty function to allow initializing only the
memrange structure without filling in device resources
BUG=None
BRANCH=None
TEST=Compiles and runs succesfully for rush MMU memranges.
Change-Id: I8e4d864cbc9a770cd208f8a9f83f509dc7ace894
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208957
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
vboot2 abtracts tpm storage as some 'secure' space. Thus, it's firmware's
responsibility to handle vboot specific operations with tpm. This CL just copies
related files from vboot_reference so that we can see how code was modified in
the next CL. Note rollback_index.c/h were renamed to antirollback.c/h.
TEST=none
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1792a622058f70a8fcd3c4037547539ad2870420
Reviewed-on: https://chromium-review.googlesource.com/206462
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a generic primitive memory test. We should look into
using tests in src/lib/ramtest.c, but they seem to rely too heavily
on x86 asm and this test has been useful on multiple ARM platforms.
BUG=none
BRANCH=none
TEST=builds and runs on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ia0fb4e12bc59bf708be13faf63c346b531eb3aed
Reviewed-on: https://chromium-review.googlesource.com/186309
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This patch has a basic structure of vboot2 integration. It supports only Nyans,
which have bootblock architecture and romstage architecture are
compatible from linker's perspective.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa
Reviewed-on: https://chromium-review.googlesource.com/204522
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Allow for reading from cbfs media without having a handle
to a non-CBFS_DEFAULT_MEDIA cbfs_media. In conjunction with
cbfs_locate_file() one can locate and cbfs_read() a file
without bringing the entire file through a potentially
temporary buffer (non-memory-mappable cbfs media platforms).
BUG=chrome-os-partner:29922
BRANCH=None
TEST=Built.
Change-Id: Ib5d965334bce1267650fc23c9e9f496675cf8450
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205991
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
cbfs_locate_file() can be used to locate the data within the
cbfs file. Based on the offset and length of the file it can
then be read into any address without bringing the contents
into another buffer (platforms without memory-mapped access
to entire contents of cbfs at once).
BUG=chrome-os-partner:29922
BRANCH=None
TEST=Built and booted rush into romstage (stage load still works).
Change-Id: I2932f66478c74511ec1c876b09794d9a22a526b3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206000
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.
BUG=none
TEST=manual
. the new firmware still displays proper CBMEM table entry descriptions:
coreboot table: 276 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
. running make in util/cbmem still succeeds
Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199791
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Eliminate duplicated printout and if needed, print only changed
information.
BUG=none
TEST=verified that the 'New segment dstaddr...' message is not
duplicated anymore
Change-Id: Ia13593394fccbb225f2bd9ab2b9228bac29d50fb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199672
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
