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>
remove some unused code
BRANCH=none
TEST=none
BUG=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I048f111b4f4c7a6c987cc7404bd073848619e908
Reviewed-on: https://gerrit.chromium.org/gerrit/57017
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Not all platforms !x86 are big endian, hence actually look
at the CONFIG_LITTLE_ENDIAN flag instead of CONFIG_ARCH_X86.
BUG=none
TEST=none
BRANCH=none
Change-Id: Ibbd8f48b377a1121dd1e045834a94a2d67eda2ab
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56066
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
If we clear the framebuffer and then flush it back to memory using cache
operations, the writes are going to be full cachelines at a time. If we
make it uncacheable first, the writes will be serialized writes of
whatever sized chunks memset uses, probably 4 bytes or less.
BUG=None
TEST=None
BRANCH=None
Change-Id: I59d6699fcea1c5ca4402ae6cf45df9c14878943a
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55837
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
At one time it seemed to be necessary to disable and then re-enable the
MMU when setting the framebuffer to be uncache-able due to bugs in the
MMU management code. Since those bugs have been fixed, this is no longer
necessary.
BUG=None
TEST=None
BRANCH=None
Change-Id: I1fb2bd6e14777470456e9517d3efba24c3b170a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55836
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
The code that allocated space for the framebuffer was adding space for a
vestigial color map which was never used. It was also passing around a
structure which was used to calculate a single value which was already
known when that structure was put together. Eliminate the extra space,
and pass the single value instead of the structure.
BUG=None
TEST=None
BRANCH=None
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia21bcbfdd0007e9088c98c339aa031853a282cf5
Reviewed-on: https://gerrit.chromium.org/gerrit/55835
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
This was never completed / working and we have the working
ARMv7 port for an architecture template, so get rid of this
dead code.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ic2c1267ee5546dd6e1b63220c263b2fa86c8ae33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56065
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
These are based on the datasheet and I included the timing
values I used from the docs.
BUG=chrome-os-partner:19637
BRANCH=none
TEST=manual: Boot on falco and see working display
Change-Id: Ib75b2c5e50ac09d1e4cf9dd22229bb0f0a8965a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58540
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code which figured out the rate of the input clock to a peripheral was
doing several things wrong. First, it was using the wrong values when
determing what the source of a clock was set to. Second, it was using the
wrong offset into that register to find the current source setting.
This change fixes the constants which select a clock source which get some
more things working, but doesn't attempt to fix the bit position table.
BUG=chrome-os-partner:19420
TEST=Built for pit with another change and an external tool, and was able to
receive serial output.
BRANCH=None
Change-Id: Ia2cea7ce8ee2c8ae721e09069bcf9711b1d30aec
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57726
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
BUG=none
TEST=manual: emerge-daisy chromeos-coreboot-snow;
emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=none
Change-Id: I9b3ee083c2edac64a653d5d7dffc123d252878d7
Reviewed-on: https://gerrit.chromium.org/gerrit/58342
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The LPC-based ChromeOS EC uses several ioport regions to communicate with
the AP. In order for the new unified userspace access method to work, we
need them to be reserved by the BIOS.
Before /proc/ioports shows:
0800-0803
0804-08ff
We'd like just a single 256-byte region at 0x800, but ASL can't handle that.
So this will work:
0800-087f
0880-08ff
BUG=chromium:249009
BRANCH=none
TEST=manual
cat /proc/ioports, look for the correct regions.
Change-Id: I08ab8c3d3607ef2d43fc2b33bb20235679f2e2e4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58389
Reviewed-by: Stefan Reinauer <reinauer@google.com>
On x86 there is a 16-byte alignment requirement for the
addresses containing the CPU microcode. The cbfs files
containing the microcode are used in memory-mapped fashion
when loading new mircocode. Therefore, the data payload's
address/offset of a cbfs file in flash dictates the resulting
alignment. Fix this by processing the CPU microcode cbfs
file separately as it uses $(CBFSTOOL) to find the proper
location within the provided rom image.
BUG=chrome-os-partner:20100
BRANCH=None
TEST=Manually inspected cbfs layout:
CBFS @ Offset 0x00700000 into 0x00800000 ROM size
[0xfff00000] cmos_layout.bin type cmos layout (0x1aa) @ 0xfff00028,
0x48c (1164) bytes
[0xfff004c0] pci8086,0406.rom type optionrom (0x30) @ 0xfff004f8,
0x10000 (65536) bytes
[0xfff10500] cpu_microcode_blob.bin type microcode (0x53) @ 0xfff10560,
0x9c40 (40000) bytes
[0xfff1a1c0] config type raw (0x50) @ 0xfff1a1e8, 0x157f (5503) bytes
[0xfff1b780] fallback/vboot type stage (0x10) @ 0xfff1b7a8, 0x3ad3
(15059) bytes
[0xfff1f280] (empty) type null (0xffffffff) @ 0xfff1f2a8, 0xcd8 (3288)
bytes
[0xfff1ff80] fallback/romstage type stage (0x10) @ 0xfff1ffe4, 0xa001
(40961) bytes
[0xfff2a000] fallback/coreboot_ram type stage (0x10) @ 0xfff2a038,
0x15373 (86899) bytes
[0xfff3f3c0] fallback/payload type payload (0x20) @ 0xfff3f3f8, 0xd00e
(53262) bytes
[0xfff4c440] u-boot.dtb type unknown (0xac) @ 0xfff4c468, 0x1e4b (7755)
bytes
[0xfff4e2c0] (empty) type null (0xffffffff) @ 0xfff4e2e8, 0x51cd8
(335064) bytes
[0xfff9ffc0] mrc.bin type mrc (0xab) @ 0xfffa0000, 0x2d8b8 (186552)
bytes
[0xfffcd8c0] (empty) type null (0xffffffff) @ 0xfffcd8e8, 0x1e6d8
(124632) bytes
[0xfffebfc0] spd.bin type mrc (0xab) @ 0xfffec000, 0x200 (512) bytes
[0xfffec200] (empty) type null (0xffffffff) @ 0xfffec228, 0x13418
(78872) bytes
Change-Id: Icc676a1c76c368d77e48cf573c6f846301da42a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58238
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Set verbs to reflect the layout used for ALC283 in Falco,
which ends up being the same as Slippy.
BUG=chrome-os-partner:19934
BRANCH=none
TEST=manual - check that headphone/mic works on falco board
Change-Id: I3dce4effefaa91ee5bdcbe2a8a3750ebc41376ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58196
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change every "boot loader 1" to be same file name in different folders.
BUG=none
TEST=manual: emerge-daisy chromeos-firmware-snow
BRANCH=none
Change-Id: Ie709b74b3bd3340f2cdc7b5685300102340bb399
Reviewed-on: https://gerrit.chromium.org/gerrit/58125
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
This enables the logging of device path into CMOS
to assist in debug of boot and resume hangs.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog. Mosys has been extended to
decode the well-known POST codes:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: Ibe78499ddfeac522a73c7324da8ab6e4f2d1945b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58107
Now that there is a clearly defined boot state machine
we can add some useful post codes to indicate the current
point in the state machine by having it log a post code
before the execution of each state.
This removes the currently defined POST codes that were
used by hardwaremain in favor of a new contiguous range
that are defined for each boot state.
The reason for this is that the existing codes are mostly
used to indicate when something is done, which is confusing
for actual debug because POST code debugging relies on knowing
what is about to happen (to know what may be at fault) rather
than what has just finished.
One additonal change is added during device init step as this
step often does the bulk of the work, and frequently logs POST
codes itself. Therefore in order to keep better track of what
device is being initialized POST_BS_DEV_INIT is logged before
each device is initialized.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog. Mosys has been extended to
decode the well-known POST codes:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: Ida1e1129d274d28cbe8e49e4a01483e335a03d96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58106
One of the most common hangs during coreboot execution
is during ramstage device init steps. Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.
This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot. This way if the system hangs when
talking to the device there will be some indication where
to investigate next.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog after several test runs:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
This can be used to indicate sub-state within a POST
code range which can assist in debugging BIOS hangs.
For example this can be used to indicate which device
is about to be initialized so if the system hangs
while talking to that device it can be identified.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: emerge-slippy chromeos-coreboot-slippy
This adds new infrastructure that is not used yet.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
This function will encode the device path into 3
bytes of a dword which can be saved for debug.
It will be used by subsequent commit to store the
current device into CMOS for debugging BIOS hangs.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=New code only, nothing uses it yet.
Change-Id: I3a5155ea53c8d280806e610a0f8998dbabe15f3c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58103
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The CMOS post code storage mechanism does back-to-back
CMOS reads and writes that may be interleaved during
CPU bringup, leading to corruption of the log or of other
parts of CMOS.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: verify post codes in CMOS during suspend/resume test
Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58102
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Mass storage devices such as card readers show up as
as USB devices. However the media not be inserted. In those
situations the previous code would just fake a disk and
call usbcreate_disk. This is inappropriate because it forms
a 1:1 mapping of USB device to disk leading to the inability
to remove the disk and/or handle "hot plug" card insertion
and removals.
To alleviate this issue introduce the notion of ready to the
usbmsc structure. It tracks detached, not ready, and ready
states. The polling routine is then used to track not ready
to ready transitions thereby creating and removing disks
appropriately. This handles the case of inserting and removing
a card that shows up as a new disk.
BUG=chrome-os-partner:19596
BUG=chrome-os-parnter:20014
BRANCH=None
TEST=Booted recovery mode. Able to observe inerstion and removal
of sdcard. Also able to insert valid USB flash drive to boot
as well.
Change-Id: I3eefbe537ec1b9c975744b8984b06c17ae236f40
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57948
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There is currently a hard-coded 30 sec delay in the mass storage
driver while waiting for each device to become ready. However, mass
storage card readers that are empty return an error code on the
TEST UNIT READY command. A REQUEST SENSE command then needs to be
issued and interrogate the data to determine if no media is present.
If no media determination is found to be true the USB device is no
longer considered a candidate to be a disk.
This code does lead to the fact that the media card reader needs to be
populated at enumeration time. I suspect this is not an issue as it
appears the storage stack in libpayload can't handle removable media
coming online later.
BUG=chrome-os-partner:19596
BRANCH=None
TEST=Booted recovery and dev modes. Noted that removable mass storage
devices with no media were ignored without any boot delay.
Change-Id: Ida7a45614d97c6e6fbfc9bb099765aad4df550fd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57828
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Set verbs to reflect the layout used for the ALC283 in slippy.
BUG=chrome-os-partner:19934
BRANCH=none
TEST=manual - install on slippy and check that headphone switch works
as does external mic.
Change-Id: I2d6bcda9cf8bbf49cbb6d2dbbe7f1a5adf315d8a
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57560
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
There are hundreds of GPIOs on the Exynos5250. Don't
always print all of them per default.
BUG=none
BRANCH=none
TEST=Notice a much saner output on serial console
Change-Id: Id2a7bb26356633e4e298614a051765c644fa85fc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55556
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
