HDMI driver need to know whether the monitor is DVI
or HDMI interface, so this commit just introduce a
new number 'hdmi_monitor_detected' to struct edid.
There were four bits to indicate the monitor interfaces,
it's better to take use of that. But those bits only
existed in EDID 1.4 version, but didn't persented in
the previous EDID version, so I decided to detect the
hdmi cea block.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'.
When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'.
Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/309275
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
This patch will let you to choose a favourite mode to
display, while not just taking the edid detail timing.
But not all modes are able to set, only modes that
are in established or standard timing, and we only
support a few common common resolutions for now.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=tested dev mode on Mickey at 640x480@60Hz
Change-Id: Iaa8c9a6fad106ee792f7cd1a0ac77e3dcbadf481
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293606
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
Notes for cherry-picking: Reverted ToT's changes to
src/soc/nvidia/tegra132/dp.c. Most of that file wasn't implemented
in the firmware-veyron branch, so pretty much the whole file showed
up as a diff. For src/soc/rockchip/rk3288/hdmi.c, there were some
simple conflicts caused by the writel/write32 transition.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289964
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293605
There are serveral members of the edid struct which are never used
outside of the EDID parsing code itself. This patch moves them to a
struct in edid.c. They might be useful some day but until then we can
just pretty print them and not pollute the more general API.
Note for cherry-picking: There seem to be some formatting patches for
edid.c that never made it into the firmware branch, so for this patch
conflicts were resolved by just taking the newer (more correct)
version that was tested in ToT.
BUG=none
BRANCH=firmware-veyron
TEST=compiled for veyron_mickey, peppy, link, nyan_big, rush, smaug
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I7fb8674619c0b780cc64f3ab786286225a3fe0e2
Reviewed-on: https://chromium-review.googlesource.com/290333
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293604
Reviewed-by: David Hendricks <dhendrix@chromium.org>
ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with
digests that attest the chosen boot mode (developer/recovery) and the
HWID in a secure way. This patch uses the newly added vboot2 support
functions to fetch these digests and store them in the TPM.
CQ-DEPEND=CL:245530
BRANCH=veyron
BUG=chromium:451609
TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my
vboot1 Blaze and Falco (and PCR1 contains some non-zero hash).
Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245119
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245496
We've traditionally tucked the framebuffer at the end of memory (above
CBMEM) on ARM and declared it reserved through coreboot's resource
allocator. This causes depthcharge to mark this area as reserved in the
kernel's device tree, which may be necessary to avoid display corruption
on handoff but also wastes space that the OS could use instead.
Since rk3288 boards now have proper display shutdown code in
depthcharge, keeping the framebuffer memory reserved across the handoff
(and thus throughout the lifetime of the system) should no longer be
necessary. For now let's just switch the rk3288 implementation to define
it through memlayout instead, which is not communicated through the
coreboot tables and will get treated as normal memory by depthcharge.
Note that this causes it to get wiped in developer/recovery mode, which
should not be a problem because that is done in response to VbInit()
(long before any images are drawn) and 0 is the default value for a
corebootfb anyway (a black pixel).
Eventually, we might want to think about adding more memory types to
coreboot's resource system (e.g. "reserved until kernel handoff", or
something specifically for the frame buffer) to model this situation
better, and maybe merge it with memlayout somehow.
CQ-DEPEND=CL:243110
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes
than before (curiously not 0x80000 bytes, I guess there's some alignment
waste in the kernel somewhere). Made sure the memory map output from
coreboot looks as expected, there's no visible display corruption in
developer/recovery mode and the 'cbmem' utility still works.
Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240819
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243097
Define the signature for the FSP HOB list pointer and add it to the
table parser.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. Test successful if the code attempts to load the payload
Change-Id: I3e340289b0ba560147d9766583a82b783adb1605
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/234525
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234063
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_early_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_early_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234062
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233051
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229975
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI
read and write transactions. Limiting transfer size in the wrapper
allows to provide the API user with unlimited transfer size
transactions.
The tranfer size limitation is added to the spi_slave structure, which
is set up by the controller driver. The value of zero in this field
means 'unlimited transfer size'. It will work with existion drivers,
as they all either keep structures in the bss segment, or initialize
them to all zeros.
This patch addresses the problem for reads only, as coreboot is not
expected to require to write long chunks into SPI devices.
BRANCH=none
BUG=chrome-os-partner:32441, chrome-os-partner:31438
TEST=set transfer size limit to artificially low value (4K) and
observed proper operation on both Pistachio and ipq8086: both
Storm and Urara booted through romstage and ramstage.
Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232239
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Extend lib/reg_script.c to use a platform table to declare
additional platform specific register access routine functions.
REG_SCRIPT_TYPE_PLATFORM_BASE is the starting value for platform
specific register types. Additional register access types may be
defined above this value. The type and access routines are placed
into reg_script_type_table.
The Baytrail type value for IOSF was left the enumeration since it
was already defined and is being used for Braswell.
BRANCH=none
BUG=None
TEST=Use the following steps to test:
1. Build for a Baytrail platform
2. Build for the Samus platform
3. Add a platform_bus_table routine to a platform which returns the
address of an array of reg_script_bus_entry structures and the
number of entries in the array.
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/215645
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7cd37abc5a08cadb3166d4048f65b919b86ab5db
Reviewed-on: https://chromium-review.googlesource.com/229612
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Merge change from coreboot.org: Add new finalize functions for devices
and chips
BUG=None
TEST=Requires FSP for testing
commit 2a58ecde78
Author: Marc Jones <marc.jones@se-eng.com>
Date: Tue Oct 29 17:32:00 2013 -0600
Add new finalize functions for devices and chips
Many chipset devices require additional configuration after
device init. It is not uncommmon for a device early in the
devicetree list to need to change a setting after a device later
in the tree does PCI init. A final function call has been added
to device ops to handle this case. It is called prior to coreboot
table setup.
Another problem that is often seen is that the chipset or
mainboard need to do some final cleanup just before loading the
OS. The chip finalize has been added for this case. It is call
after all coreboot tables are setup and the payload is ready to
be called.
Similar functionality could be implemented with the hardwaremain
states, but those don't fit well in the device tree function
pointer structure and should be used sparingly.
Change-Id: Ib37cce104ae41ec225a8502942d85e54d99ea75f
Reviewed-on: http://review.coreboot.org/4012
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I4f918a5908f2016f6e57f954284f9f8856bd8301
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/213694
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229572
Reviewed-by: Erik C Bjorge <erik.c.bjorge@intel.com>
This is the unified FSP interface code from coreboot.org. To present
a consistent interface with the FSPs for all of the different CPUs,
and to cut down on code maintenance, all of the FSPs use this
interface.
Bug=None
Test=Builds and runs on Broadwell
Change-Id: Idcca5c42b06c47c67946c706e424e0349405ddf0
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://chromium-review.googlesource.com/221182
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/229573
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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>
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 region is used to store the timestamps from bootblock and verstage when
cbmem is not yet initialized. Once cbmem is setup, the timestamps from this
region can be retrieved and filled up properly in cbmem. In order to achieve
this a new Kconfig option is introduced HAS_TIMESTAMP_REGION. This is to
maintain compatbility with older boards which do not use this region.
BUG=chrome-os-partner:32973
BRANCH=None
TEST=cbmem -t and verified timestamps on ryu
Change-Id: I4d78653c0595523eeeb02115423e7fecceea5e1e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/223348
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: 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 is a no-op change just sorting the CBMEM entries' definitions for
easy look up and comparison.
BRANCH=storm
BUG=none
TEST=Booted a storm device, observed the expected CBMEM entries
present in the console output.
Change-Id: Ibcd4f184ef1bade10ad677384f61243da7e3c713
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225259
Reviewed-by: Aaron Durbin <adurbin@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>
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>
This patch adds an mmu_config_range_kb() function, which can set memory
types at the 4KB level by chaining a fine-grained page table to an
existing superpage entry. It is only intended for special cases where
this level of precision is really necessary and therefore comes with a
few practical limitations (the area for each invocation must be confined
within a single superpage, and you are not allowed to remap the same
region with mmu_config_range() again later). Since the fine-grained page
tables need some space, boards intending to use this feature must define
a TTB_SUBTABLES() region in their memlayout.ld.
BUG=chrome-os-partner:32848
TEST=Booted both Veyron_Pinky (normal) and Nyan_Blaze (LPAE), ensured
that they still work. Checksummed the page tables with and without this
patch, confirmed that they end up equal. Hacked in some subtable test
entries, hexdumped all tables and manually confirmed that they look as
expected.
Change-Id: Iedf7ca435ae337ead85115200d6987fb0d4828d7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223781
Force 4-byte alignment for .bs_init section to ensure that no padding
data is added to init structures.
BUG=chromium:416651
BRANCH=none
TEST=build firmware with GCC 4.9 and test on Auron and Rambi.
Change-Id: I3f94cd419b5951fdc6e5749576c4df2cc44f8a24
Signed-off-by: Ryan Lin <ryan.lin@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/223116
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Enable L1 Sub-State when both root port and endpoint support it.
BUG=chrome-os-partner:31424
TEST=Build a image and run on Samus proto boards to check if the
settings are applied correctly. I just only have proto boars and
need someone having EVT boards to confirm the settings.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: Id1b5a52ff0b896f4531c4a6e68e70a2cea8c736a
Reviewed-on: https://chromium-review.googlesource.com/221436
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds some simple constants to more easily write and do math
with frequencies, analogous to the existing KiB, MiB and GiB constants
for sizes. They are exemplary added to the Veyron_Pinky/Rk3288 code for
now and will hopefully be adopted by other parts of the codebase in the
future.
BUG=None
TEST=Compiled Veyron_Pinky.
Change-Id: I4a1927fd423eb96d3f76f7e44b451192038b02e0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221800
Reviewed-by: David Hendricks <dhendrix@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
Set PCIE "Enable Clock Power Management", if endp supports
BUG=chrome-os-partner:31424
BRANCH=none
TEST=build and boot on rambi, check Enable Clock Power Management
in link control register is set properly
Change-Id: Ie54110d1ef42184cfcf47c9fe4d735960aebe47f
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/220742
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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 change makes coreboot initialize kernel space and backup space in the tpm
when no firmware space is found in the tpm.
BUG=chrome-os-partner:32410
TEST=Forced factory initialization and verified it went through without errors.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I777e3cb7004870c769163827543c83665d3732b9
Reviewed-on: https://chromium-review.googlesource.com/220412
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@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>
Most Baytrail based devices MMIO registers are reported in ACPI
space and the device's PCI config space is disabled. The PCI config
space is required for many "legacy" OSs that don't have the ACPI
driver loading mechanism. Depthcharge signals the legacy boot
path via the SMI 0xCC and the coreboot SMI handler can switch the
device specific registers to re-enable PCI config space.
BUG=chrome-os-partner:30836
BRANCH=None
TEST=Build and boot Rambi SeaBIOS.
Change-Id: Ia5e54f4330eda10a01ce3de5aa4d86779d6e1bf9
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: https://chromium-review.googlesource.com/219801
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
Tested-by: Mike Loptien <mike.loptien@se-eng.com>
There's a lot of places where expiration and running time are
open coded. Allow for those places to be simplified by adding
a stopwatch construct. The stopwatch can have an expiration or
just be used to accumulate time.
BUG=None
TEST=Built and verified API works as expected by using implementation.
Change-Id: I53604900fea7d46beeccc17f1dc7900d5f28518b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219492
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@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>
mosys will use this field to identify system
BRANCH=none
BUG=chromium:359155
TEST=build ok, use dmidecode to check whether data is
written correctly
Change-Id: Icfbd4c61fc49a9cb3d3ecd2b622339957963150c
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/217400
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
There was a hacky and one-off spintable support in tegra132.
Make this support generic for all arm64 chips.
BUG=chrome-os-partner:32082
BRANCH=None
TEST=Ran with and without secure monitor booting smp into the kernel.
Change-Id: If12083a9afc3b2be663d36cfeed10f9b74bae3c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218654
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The GIC is ARM's "Generic Interrupt Controller". This
change essentially implements the rudimentary support
for a GICv2 implementation that routes all interrupts
to Group1. This should also work for GICv1 with security
extensions.
BUG=chrome-os-partner:31945
BRANCH=None
TEST=Built and booted kernel using the code.
Change-Id: I4c5b84bfe888ac33fa01c8d64a3dffe1b5ddc823
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217512
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
vprintk is created out of do_printk for all the archs.
BUG=none
TEST=Built Nyans, Falco, and Ryu. Verified serial output on Blaze and Falco.
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Idf708359f0e9e9a9f32a601a5a117e469d5025ba
Reviewed-on: https://chromium-review.googlesource.com/214566
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
