Otherwise we have to worry about hand off between bootblock and
romstage. Too much complexity
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=none
BRANCH=none
Change-Id: I3979be4b1d67de27275bc7ba4f45131b09a276f0
Reviewed-on: https://gerrit.chromium.org/gerrit/59323
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=Run sudo cbmem -l on Snow w/ coreboot, observe that it finds
CBMEM
BRANCH=none
Change-Id: If5f961afb23791af6f32dd4fc9a837a1aa41b70e
Reviewed-on: https://gerrit.chromium.org/gerrit/59322
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
It's done in bootblock_simple.c just after returning from
the mainboard specific bootblock function.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=Boot on Snow
BRANCH=none
Change-Id: I96cab5e406132a9f7dc30d48ff99f524773a1a14
Reviewed-on: https://gerrit.chromium.org/gerrit/58473
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
This is already called in ARMv7 bootblock_simple.c so we don't
want to do it twice
BUG=none
TEST=boot on Snow
BRANCH=none
Change-Id: I4e9e7c3a0a5e6c9a78cb71dc55c1b48ed8764867
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58472
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
This was used by Ron 13ys ago and was never used again
ever since.
BUG=chrome-os-partner:18637
BRANCH=none
TEST=none
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Currently, the exception handling code on ARM in libpayload turns on alignment
checks as an easy way to generate an exception for testing purposes. It was
leaving it on which disabled unaligned accesses for other, unlreated code
running later. This change adjusts the code so the original value of the
alignment bit is restored after the test exception.
BUG=chrome-os-partner:18635
TEST=Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the depthcharge's main. Before this
change, the access caused an exception. After this change, the access
completed successfully.
BRANCH=None
Change-Id: If92cab3cc8eabca7c5b0560ce88a8796a27fe3b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59372
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Currently, the exception handling code on ARM turns on alignment checks as an
easy way to generate an exception for testing purposes. It was leaving it on
which disabled unaligned accesses for other, unlreated code running later.
This change adjusts the code so the original value of the alignment bit is
restored after the test exception.
BUG=chrome-os-partner:18635
TEST=Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the RAM stage. Before this change, the
access caused an exception. After this change, the access completed
successfully.
BRANCH=None
Change-Id: Ic2584650bb8e01dfe2285af6e2896e8c87477f50
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59371
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The address range to scan for the coreboot tables varies from machine to
machine based on the range memory occupies on the SOC being booted and on the
amount of memory installed on the machine. To make libpayload work on
different ARM systems with different needs, this change makes the region to
scan configurable. In the future, we might want to come up with a more
automatic mechanism like on x86, although there's less consistency on ARM as
far as what ranges are even memory in the first place.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on snow and pit and saw serial output
which implies that the coreboot tables were found and parsed.
BRANCH=None
Change-Id: Ib50efe25a6152171b0fbd0e324dbc5e89c527d6e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59242
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The GPIOs used by vboot and setting up the display and backlight were still
the ones for snow. This change updates them so they're correct for pit.
BUG=chrome-os-partner:19420
TEST=Built and booted to when the payload is loaded on pit
BRANCH=None
Change-Id: I3ae4c2baefbab26bbc7b3716242c37885a5b44c0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59241
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The MAX_CPUS option is only used on x86 currently, so there's no reason to
have it in the pit config.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit
BRANCH=None
Change-Id: I78d035afe533ae46b7825b877b1bcc73b4e68f24
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59240
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
That part isn't used on pit.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit.
BRANCH=None
Change-Id: I889343b4dd6398281cebd2ebd66f13e888b113e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59239
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
On pit, the tps65090 is connected to the EC and has to be accessed by proxy.
Until we have that implemented, this change removes calls to tps69050 which
will never succeed, and stops compiling in the driver.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit and saw that error spew from trying to access the
tps69050 we away.
BRANCH=None
Change-Id: I409339b283b1516a52efefdcbd1f20cc8f4c2154
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59238
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The members data structures in dmc.h are intended to have a particular size.
Rather than assume that particular types are the right size, we should use
types that are guaranteed to be the right size. Also, since the registers are
at particular offsets as well, the structures should be packed.
BUG=chrome-os-partner:19420
TEST=Built for pit.
BRANCH=None
Change-Id: Ie52a5eba459bc2a070656b264e00ef783838026e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59237
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The previous driver was a bit awkward and not entirely correct. This change
primarily replaces the read/write functions with simpler and more robust
(hopefully) version.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit into the RAM stage without any errors reading or
writing registers on the PMIC. There isn't really any direct feedback from the
PMIC, so I'm assuming since it didn't complain it worked. I looked at some of
the transaction on an oscilloscope and they looked correct.
BRANCH=None
Change-Id: I01b1f9ea43eafb4aae1dbebddc051cd5ec5aea74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59201
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
LynxPoint-LP has a lot of GPEs and the "default" set has been
moved to register 4 starting at bit offset 96. This means
that PME_B0 bit in GPE0_EN/GPE0_STS is now bit 109 in LPT-LP
but still bit 13 in LPT-H.
BUG=chrome-os-partner:20174
BRANCH=none
TEST=manual: suspend on falco and wake from usb
4 | 2013-06-19 10:49:17 | ACPI Enter | S3
5 | 2013-06-19 10:49:22 | ACPI Wake | S3
6 | 2013-06-19 10:49:22 | Wake Source | Internal PME | 0
Change-Id: I443cd4d17796888debed70c0bda27ae09accd09b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59265
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Otherwise the code would try to parse GPIOs when encountering
a mainboard entry in the coreboot table. This never caused any
problems because the mainboard entry is parsed before the GPIO
entry.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=no functional change
BRANCH=none
Change-Id: I1443bda8585a990a39115743d48304ec4b54bccb
Reviewed-on: https://gerrit.chromium.org/gerrit/59292
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
For all other CPUs, we unconditionally include the CPU Kconfig
files in the CPU directory, not in the vendor directory. Do the
same thing for the Exynos CPUs. This allows us to make CPU dependent
changes in the directory of that CPU alone.
Also, drop some unused Kconfig variables from the Exynos Kconfig
files.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=no functional change
BRANCH=none
Change-Id: I57667dc5c5af5f61a54186a8fd47ceeae143d688
Reviewed-on: https://gerrit.chromium.org/gerrit/59291
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Some of the pcie logic was located in pch.c as well
as pcie.c. Move all pcie logic to the same pcie.c
file. This is a straight cut-and-paste (no logic changes)
except for a rename from pch_pcie_enable() ->
pch_pcie_enable_dev().
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built and booted.
Change-Id: I338c53039b95f255ab9ced313c51193a9d34b404
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59277
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The function to disable devices was formerly named
pch_hide_devfn(). This routine was doing more than hiding
devices. It was disabling them, i.e. turning them off.
Therefore, rename it to pch_disable_devfn(). Also, allow
external callers to this function.
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built and booted.
Change-Id: Id5bb319d4e67892c02a39dff49e45b2811a2f016
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59276
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The iobp functions are useful to may of the southbridge
devices as certain values need to be updated to properly
initialize the devices. Therefore expose read, write, and
updated iobp functions.
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built and booted. Analyzed the console messages.
Change-Id: Id7fdd8d0d9f022f92d6285ecd8f85a52024ec2bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59275
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The dmb should be executed before reading operations, and before/after writing
operations.
BUG=none
TEST=manual: emerge-daisy chromeos-firmware-snow; booted Snow.
BRANCH=none
Change-Id: I3405cd8bef35b5454c423790d1886c87509c0f28
Reviewed-on: https://gerrit.chromium.org/gerrit/58441
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
This updates the low-level I2C code to handle the new high-speed
HSI2C/USI inteface. It also outputs a bit more error information
when things go wrong. Also adds some more error prints. Timeouts
really need to be noted.
In hsi2c_wait_for_irq, order the delay so that we do an initial
sleep first to avoid an early-test that was kicking us out of the
test too soon. We got to the test before the hardware was ready
for us. Finally, test clearing the interrupt status register every time
we wait for it on the write. Works.
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I785a4b9038d25c1a564784da0b7d54eaa9ef651d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58761
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This updates the setup_power() function to actually set up the PMIC
which is on this board (the MAX77802).
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I686740cc34e40256c6607132ec7a94d5156b5d55
Reviewed-on: https://gerrit.chromium.org/gerrit/58763
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This adds register offsets and important values for the Maxim
MAX77802 PMIC.
This adds a header
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I615c56215d5dbb8913eae707e1adfb2945c65068
Reviewed-on: https://gerrit.chromium.org/gerrit/58762
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
We saw a problem on x86 last year in which setting direction, then value,
glitched the output and caused problems. Change this code to set the output,
then the direction.
BUG=chrome-os-partner:19420
TEST=Build and boot on pit.
BRANCH=None
Change-Id: Ie40786139b0b496e22a80dc3dd712b6adff03d1e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59087
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
A quirk of the Kconfig used in coreboot is that config options
cannot be overriden by local config changes unless they have
a description string.
BUG=chrome-os-partner:20208
BRANCH=none
TEST=manual:
1) Add CONFIG_MAINBOARD_VENDOR="Custom" to local config
2) Build and flash coreboot
3) cat /sys/class/dmi/id/sys_vendor and look for "Custom"
Change-Id: I1b5f2124cd4a22c056c025143ae5bcaafa6b03f0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59088
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The 5420 clock code still had a data structure in it for the 5250 clock
registers which was used by some of the clock functions. That caused some
clocks to be configured incorrectly, specifically the i2c clock which was
running at about 80KHz instead of about 600KHz as configured by U-Boot.
Also, the registers and bit positions used to set up the SPI bus were not
consistent with U-Boot, and if the bus clock rate were set to 50MHz, a rate
which has historically worked on snow, loading would fail. With these fixes
the clock rate can be set to 50MHz and the device boots as much as is
expected. I haven't yet measured the actual frequency of the bus to verify
that it's now being calculated correctly.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit and saw that the SPI now works at what is
nominally 50MHz, and that the I2C bus connected to the PMIC is running at the
same frequency as it does under U-Boot.
BRANCH=None
Change-Id: I9fede9cd3defdff7cbb2a76bb0e0bf86967bebb7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59020
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Tested and working. Gets us to ramstage.
BUG=chrome-os-partner:19420
TEST=Build and boot on pit.
BRANCH=None
Change-Id: I603aec97155a468a12b3fd492521b5a4e7169f9e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57363
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This adds entries for I2C8-10 to giant switch statement in
clock_get_periph_rate(). It also eliminates the I2C peripheral's
usage of clk_bit_info since it's confusing and error-prone.
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I4b006c034575e6bd1f4722503668b9a142020eb5
Reviewed-on: https://gerrit.chromium.org/gerrit/58782
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The code has been there for quite a while but was never enabled.
BUG=none
TEST=none
BRANCH=none
Change-Id: Ifc30e735e78f88ab2c84e374e2aa245b370c4e03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57018
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
The wake device input pins are active low and the
GPIOs need to be set as inverted when they are marked
as an input so they are not spuriously logged.
Also sync pin states from Falco initial commit.
Reference change: I15d38dcc9b2fb4b2b0eb27da358fa3c343e22323
BUG=chrome-os-partner:19636.
TEST=Manual. Build + boot peppy FW.
BRANCH=None.
Change-Id: I66e136d389d53a367436d816fa84dacdc8e86bad
Reviewed-on: https://gerrit.chromium.org/gerrit/58334
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and started booting on pit.
BRANCH=None
Change-Id: I06ea5dfdb1de2d32bd1f3b276f98617c0c3efc46
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58788
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The pinmux code for the exynos5250 was all bundled into a single, large
function which contained a switch statement that would set up the pins for
different peripherals within the SOC. There was also a "flags" parameter, the
meaning of which, if any, depended on which peripheral was being set up.
There are several problems with that approach. First, the code is inefficient
in both time and space. The caller knows which peripheral it wants to set up,
but that information is encoded in a constant which has to be unpacked within
the function before any action can be taken. If there were a function per
peripheral, that information would be implicit. Also, the compiler and linker
are forced to include the entire function with all its cases even if most of
them are never called. If each peripheral was a function, the unused ones
could be garbage collected.
Second, it would be possible to try to set up a peripheral which that function
doesn't know about, so there has to be additional error checking/handling. If
each peripheral had a function, the fact that there was a function to call at
all would imply that the call would be understood.
Third, the flags parameter is fairly opaque, usually doesn't do anything, and
sometimes has to have multiple values embedded in it. By having separate
functions, you can have only the parameters you actually want, give them
names that make sense, and pass in values directly.
Fourth, having one giant function pretends to be a generic, portable API, but
in reality, the only way it's useful is to call it with constants which are
specific to a particular implementation of that API. It's highly unlikely that
a bit of code will need to set up a peripheral but have no idea what that
peripheral actually is.
Call sights for the prior pinmux API have been updated. Also, pinmux
initialization within the i2c driver was moved to be in the board setup code
where it really probably belongs. The function block that implements the I2C
controller may be shared between multiple SOCs (and in fact is), and those
SOCs may have different pinmuxes (which they do).
Other places this same sort of change can be made are the pinmux code for the
5420, and the clock configuration code for both the 5250 and the 5420.
BUG=None
TEST=Built and booted Coreboot on Snow. Went into recovery mode and back.
BRANCH=None
Change-Id: Ib6f6921ffcf749da02e25519279d2dc7cbf8f2ec
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58784
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The memset and memcpy functions are assembled as ARM code, likely because
that's the default of the assembler. Without special annotation, the assembler
and linker don't know that those symbols are functions which need special
handling so that ARM/thumb issues are handled properly. This change adds that
annotation which gets those functions working in Coreboot which is compiled as
thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the
annotation since it just works out in ARM mode, but it's the safe thing to do
in case we change that in the future.
We should explicitly select ARM vs. thumb when assembling assembly files to be
consistent across builds and toolchains.
BUG=None
TEST=Built with the assembly versions of memcpy and memset turned on and saw
that we could boot after this change where we couldn't before. Disassembled a
function which calls memset and saw that it was using the blx instruction
which can change mode instead of the bl instruction which can't.
BRANCH=None
Change-Id: Ic3ef4faf17d3467b5042c944106b8743d517cce3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58728
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Set nid 0x12 instead of nid 0x05. The DMIC is on NIC 0x12.
BUG=chrome-os-partner:19934
BRANCH=none
TEST=yongjaek verified on Falco
Change-Id: Ifc883b65a50aeec6a6d3ad02fe8418f124e6241d
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58711
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Jay Kim <yongjaek@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
There was always exactly one elog descriptor declared and initialized, but its
contents were being accessed through a pointer that was passed back and forth
between functions instead of being accessed directly. This made the code more
verbose than it needed to be and harder to follow. To address this the
descriptor type was eliminated, its contents were turned into individual
global variables, and various functions were adjusted to no longer take the
descriptor as an argument.
Similarly, the code was more verbose and complicated than it needed to be
because of several wrapper functions which wrapped a single line of code which
called an underlying function with particular arguments and were only used
once. This makes it harder to tell what the code is doing because the call to
the real function you may already be familiar with is obscured behind a
new function you've never seen before. It also adds one more text to the file
as a whole while providing at best a marginal benefit. Those functions were
removed and their callers now call their contents directly.
BUG=chrome-os-partner:16132
TEST=Built and booted on Link. Ran mosys eventlog list. Cleared the event log
and ran mosys eventlog list again. Added 2000 events and ran mosys eventlog
list. Cleared the log again and ran mosys eventlog list.
BRANCH=None
Change-Id: I4f5f6b9f4f508548077b7f5a92f4322db99e01ca
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49310
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The elog driver's design was a bit more elaborate than it really needed to be
since it no longer had to keep track of multiple copies of the log in flash
and also in memory. This change streamlines it by removing unnecessary
compartmentalization of some bits of code, and some variables which tracked
the last entry added which were never used.
BUG=chrome-os-partner:16132
TEST=Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the event log and ran mosys eventlog list again. Cleared the log by echoing 1
into /sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
BRANCH=None
Change-Id: I7d4cdebf2f5b1f6bb1fc70e65eca18f71b124b18
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49309
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
elog_validate_and_fill was called in exactly one place, in
elog_init_descriptor. It didn't actually do what its name implied since the
data in the event log was already "filled" by elog_init_descriptor. Likewise
elog_init_descriptor was delegating an important part of its own job, scanning
through the list of events, to elog_validate_and_fill.
Since one function was basically just a displaced part of the other which
couldn't really stand on its own, this change merges them together.
BUG=chrome-os-partner:16132
TEST=Built and booted on Link. Ran mosys eventlog list. Added 2000 events with
the SMI handler and ran mosys eventlog list again.
BRANCH=None
Change-Id: Ic899eeb18146d0f127d0dded207d37d63cbc716f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49308
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This function was just a wrapper around elog_init_descriptor, and all it did
was pass the current backing store location and size back in so it would be
reused. Those values, which never change, are now set in
elog_setup_descriptors, eliminating those parameters to init and eliminating
the need for _reinit_.
BUG=chrome-os-partner:16132
TEST=Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again.
BRANCH=None
Change-Id: I133768aa798dfc10f32e14db95235a88666890c3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49307
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The event log driver keeps two copies of the event log in memory, one to
take the place of the historically memory mapped image of flash which is now
read and written manually, and one originally intended to be an in memory
cache of flash. Since both are now just copies in memory, there's no value in
having them both and keeping them in sync.
BUG=chrome-os-partner:16132
TEST=Built and booted on Link. Ran mosys eventlog list. Added 2000 events to
the log and ran mosys eventlog list again. Cleared the log by echoing a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list again.
BRANCH=None
Change-Id: Ibed62a10c78884849726aa15ec795ab2914afc35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49306
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The way elog_shrink currently works is that it completely clears the data in
the flash/flash descriptor and then recreates it using the part of the log
it's going to keep as stored in the memory descriptor. That scheme depends on
there being to independent copies of the log.
This change reworks elog_shrink so that it moves the data it wants to keep
within a single descriptor and then propogates it to the other and to flash
intact. This way, when one of the descriptors goes away, all we have to do is
remove the code that would update it.
BUG=chrome-os-partner:16132
TEST=Built and booted into ChromeOS on Link. Ran mosys eventlog list. Added
2000 events to the log and ran mosys eventlog list again. Echoed a 1 into
/sys/firmware/gsmi/clear_eventlog and ran mosys eventlog list.
BRANCH=None
Change-Id: I50d77a4f00ea3c6b3e0ec8996dab1a3b31580205
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49305
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The header is at the start of the log. There's no reason to either keep a
seperate pointer to it, or to keep a copy of it in some other bit of memory.
BUG=chrome-os-partner:16132
TEST=Built and booted on Link and used 'mosys eventlog list' to list the
contents of the log. Ran
for x in $(seq 1 2000); do
cat elog.event.kernel_clean > /sys/firmware/gsmi/append_to_eventlog;
done
And ran mosys eventlog list again to verify that the log had been shrunk
correctly.
BRANCH=None
Change-Id: I2afcd52c0ce5bbb662ac56f2895cdbea28d5c2ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49304
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Currently, all Peppy boards w/ '000' SPD GPIOs have 2GB DRAM. Disable
the second DRAM channel based upon the GPIOs.
Need to change / confirm this for upcoming builds.
BUG=chrome-os-partner:20183
TEST=Manual. Verify boot on 2GB units.
Change-Id: I7085ddecb80626cc0bed99ba7b174c6b80350696
Reviewed-on: https://gerrit.chromium.org/gerrit/58620
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
SPD GPIOs were being read prior to initialization in romstage_common. To
fix, pass the copy_spd function to romstage_common, to be called at the
appropriate time (after PCH init, before DRAM init).
BUG=chrome-os-partner:20162.
TEST=Manual. Test on peppy board with non-zero SPD GPIOs, verify correct
SPD is selected.
Change-Id: I2554813e56a58c8c81456f1a53cc8ce9c2030a73
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58608
The PCI ids for the EHCI devices were not update to reflect
LynxPoint's PCI ids.
BUG=chrome-os-partner:20174
BRANCH=None
TEST=Manual: looked for "EHCI: Setting up controller.. " in console.
Change-Id: I5a2e1d746700d45341817b065bc41dc83f508063
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58622
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and booted on pit with another change and an external tool, and was
able to get serial output. Built for snow.
BRANCH=None
Change-Id: I116d7b4277e0a57a3ae7e46432ee3e5f286e1e88
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58607
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit with another change and an external tool, and was
able to get serial output. Built for snow.
BRANCH=None
Change-Id: Ie27ae7a7b22f336d23893618969efde4145fefd7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57725
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
There are hundreds of GPIOs on the Exynos5420. Don't
always print all of them per default.
BUG=none
BRANCH=none
TEST=Notice a much saner output on serial console
Change-Id: Ie0749e2a7757fd06549918208c9d6e6366f1f2f9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55812
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
