When preparing an image for source level debugging, it is convenient
to be able to compile some modules with -O0, which makes it much
easier to follow the execution flow.
This patch allows to do it by defining GDB_DEBUG=1 in the environment
before invoking make. Adding this feature as a common config flag is
problematic, because we don't want to compile the entire image with
-O0.
BUG=none
TEST=manual
. ran make with GDB_DEBUG=1 and observed the modified compiler
invocation line in the log.
Change-Id: Ie0be653509509eeb64ea3a7229f54c0c812840a9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196359
This patch it the last one in the chain adapting the ipq9064 UART
driver for use in coreboot. A new config option
(CONSOLE_SERIAL_IPQ806X) is being introduced to control inclusion of
the driver.
The previously introduced uart_wrapper.c is now included in the build
to provide the console driver structure used by ramstage.
Necessary configuration options are added to allow use of UART in the
bootblock.
BUG=chrome-os-partner:27784
TEST=with this change the coreboot image on AP148 prints a banner on
start up:
coreboot-4.0 Wed Apr 23 16:24:51 PDT 2014 starting...
Change-Id: I129ee30ba17a5061b30cfee56c135df31eba98b5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196663
The IO accessor wrappers are used to allow integer register addresses.
A structure defining UART interface configuration is declared and
defined. A few long lines are wrapped. Interface functions are renamed
to match the wrapper API.
cdp.c is edited to fit into coreboot compilation environment, and the
only function required by the UART driver if exposed, the rest are
compiled out for now.
BUG=chrome-os-partner:27784
TEST=after all patches are applied the serial console on AP148 becomes
operational.
Change-Id: I80c824d085036c0f90c52aad77843e87976dbe49
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196662
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
These patch modifies .h files to match the coreboot API. A few more
significant changes are:
- UART specific fields removed from common board structure in cdp.h.
These fields are set at compile time in u-boot (where this
structure comes from), they will be set in a different structure in
the UART driver in an upcoming patch.
- an inline wrapper is added in gpio.h to provide GPIO API the UART
driver expects.
- the ipq_configure_gpio() is passed the descriptor placed in ro data.
BUG=chrome-os-partner:27784
TEST=none
Change-Id: Id49507fb0c72ef993a89b538cd417b6c86ae3786
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196661
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Coreboot is designed to have a single serial console at most, on top
of that it may have a CBMEM (virtual) console. Matters are complicated
by the fact that console interface is different between bootblock and
later stages.
A linker list of console driver descriptors is used to allow to
determine the set and type of console drivers at compile time. Even
though the upstream seems to have done away with this approach, which
does not seem the best idea.
As an alternative this patch introduces a common wrapper which
different UART drivers can plug in into. The driver exports a single
API which can be used both directly (in bootblock) and through the
wrapper (in later stages).
The existing drivers can be adjusted to fit this scheme one by one.
The common UART driver API also aligns fine with the upstream
approach.
BUG=chrome-os-partner:27784
TEST=none yet
Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196660
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Move the driver to where it belongs.
BUG=chrome-os-partner:27784
TEST=none
Change-Id: Iee33de0b29a6bb86ba7c37e7e89aabc0fee42e80
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196658
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
In the normal mode case these settings aren't overwritten by
the VBIOS because the VBIOS does not run. Therefore, the settings
need to align with what the VBIOS programs so that there is a
consistent panel power sequencing.
BUG=chrome-os-partner:28267
BRANCH=baytrail
TEST=Built and booted. Noted settings set by firmware for both dev
and normal mode match.
Change-Id: Iccf65e2a6bce6859fd7cb0f466d4b44d654523ce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196822
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
In order to protect ourselves from the kernel driver not honoring or
placing the correct frequency in the backlight register always set one.
This code path picks 200Hz as the default if nothing is specified in
device tree. It's somewhat arbitrary but that frequency is valid for all
the eDP panel specs we've seen being used on baytrail devices.
BUG=chrome-os-partner:28267
BRANCH=baytrail
TEST=Built and booted in normal mode. Noted register write stuck.
Change-Id: Ifec29f0671e9f14ba57b9643c29d8bb2cd07eef5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196821
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The coreboot ebuild will take care of placing the blob at the default
location when emerging.
CQ-DEPEND=CL:196414
BUG=chrome-os-partner:28059
TEST=manual
'emerge-storm coreboot' succeeds again
Change-Id: I82c9350eb70f231a0c76b63261518096dbad926c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196406
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Make sure it is initialized at different stages.
BUG=chrome-os-partner:27784
TEST=manual
. not much at this point, just verified that it compiles
Change-Id: I343e7a6648e2ca935606cd76befd204aabd93726
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196592
Include clock.c in the appropriate coreboot stages, modify the code to
build cleanly. Use proper pointer cast in .h files.
BUG=chrome-os-partner:27784
TEST='emerge-storm coreboot' still succeeds
Change-Id: I227c871b17e571f6a1db3ada3821dbb1ee884e59
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196407
These driver needs to be in src/lib, and the include file needs to be
renamed to avoid collision with the top level uart.h.
BUG=chrome-os-partner:27784
TEST=emerge-storm coreboot still works
Change-Id: Ie12f44e055bbef0eb8b1a3ffc8d6742e7a446942
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196393
Commment out nonessential timer services and modify the source code to
cleanly build in coeboot environment. Do not remove dead code just
yet, these functions might be necessary later.
Need to rename the soc timer.h to prevent collisions with timer.h in
the top level include directory.
Currently build timer code for ramstage only.
BUG=chrome-os-partner:27784
TEST='emerge-storm coreboot' still succeeds
Change-Id: Ib10133ccb42697840708845a8ea6d75ceeaeb3d5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194067
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The SBL3 currently seems to be preventing the bootblock from being
loaded into the IMEM. As a temporary measure, map bootblock into DRAM
(as it is available after SBL2 finished running) and specify the
correct stack space.
BUG=chrome-os-partner:27784
TEST=not much testing yet, just verify 'emerge-storm coreboot' still succeeds.
Change-Id: Ibe9d4911ad22ada1bbd01af54a2ef80009df3a28
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196168
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
To reenable JTAG on security mode, chip unique id needs to be built
into bct.
BUG=chrome-os-partner:27525
BRANCH=None
TEST=build nyan and verifed chip uid is built in.
Change-Id: I4f7d2136c2a7ed3254224f80316a69bc34c7245b
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/193076
Reviewed-by: Gabe Black <gabeblack@chromium.org>
These have apparently never been used because they are
incorrect.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Change-Id: I3624cb2548a0ee3da56a2cca62ed50b0dfbf7817
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196266
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This allows the chromeos header and functions to be included
without needing to guard with #if CONFIG_CHROMEOS.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Change-Id: I523813dc9521d533242ae2d2bc822eb8b0ffa5e2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196265
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is common code for Intel SOC that can be shared.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Change-Id: Ic703f36f56a8238d5cc1248b353d8c3a49827a9a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196264
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This common code can be shared across Intel SOCs.
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Change-Id: Id9ec4ccd3fc81cbab19a7d7e13bfa3975d9802d0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196263
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some LPC initialiation can save some lines of code when being able
to use the functions `io_apic_read()` and `io_apic_write()`.
As these two functions are now public, remove them from the generic
driver as otherwise we get a build errors like the following.
[…]
Building roda/rk9; i386: ok, using i386-elf-gcc
Using payload /srv/jenkins/payloads/seabios/bios.bin.elf
Creating config file... (blobs, ccache) ok; Compiling image on 4 cpus in parallel .. FAILED after 12s!
Log excerpt:
coreboot-builds/roda_rk9/arch/x86/lib/ramstage.o: In function `io_apic_write':
/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/arch/x86/lib/ioapic.c:32: multiple definition of `io_apic_write'
coreboot-builds/roda_rk9/drivers/generic/ioapic/ramstage.o:/srv/jenkins/.jenkins/jobs/coreboot-gerrit/workspace/src/drivers/generic/ioapic/ioapic.c:22: first defined here
collect2: error: ld returned 1 exit status
make: *** [coreboot-builds/roda_rk9/generated/coreboot_ram.o] Error 1
make: *** Waiting for unfinished jobs....
[…]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3180
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
(cherry picked from commit ac75bc682b)
BUG=chrome-os-partner:28234
BRANCH=None
TEST=emerge-rambi coreboot
Change-Id: Ie829995e842c33ea82920799430c3e9f813be3da
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196262
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The call was after the call to vboot_verify_firmware and so would only be
called when falling back to RO, aka recovery mode. This change moves it to
before vboot_verify_firmware so we'll always have the cbmem console.
BUG=None
TEST=Built and booted on nyan and verified that the cbmem console was the same
as the serial output. Built for big and blaze.
BRANCH=nyan
Change-Id: I02d01110659689b08d32777dae384ac3e01b3b9f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/196158
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Panel datasheet defines some delay between PWM signal out and
backlight enable. This change fixes the current sequence
and makes the delays adjustable by dt setting.
BRANCH=none
BUG=chrome-os-partner:28008
TEST=Verified on Big DVT and Nyan/Norrin panels.
Panel works fine with dev mode, and the measurement
of power on sequence meets panel requirements.
Change-Id: If6015bbb6015a3b203d425f5e90f676ad786b5e8
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/196183
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
It turns out that for SBL3 to load the next phase, the sizes int the
MBN header must be 4 byres aligned. This change makes sure that this
requirement is enforced.
BRANCH=None
BUG=chrome-os-partner:28137
TEST=manual
. examined the generated header, observed the size field aligned
. the new image gets successfully started by the SBL3 on ap148
Change-Id: Ia64f04bb281ae772b060d2f7713c98dd348972ba
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196167
Enable pinmux clamp function to avoid pinmux conflict.
For pins which are configured to tristate enabled, the inputs to the
controller will be clamped to zero. This can be used to avoid pinmux
conflicts since the tristate bit is set to 1 in the power-on-reset
pinmux setting.
With pinmux clamp enabled, we need to configure all the input pins
to tristate disabled.
BUG=chrome-os-partner:27091
BRANCH=None
TEST=built and booted successfully, display worked fine.
Change-Id: Id79a717f2025c812908c7152d439351208aee8d2
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/194060
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The sbl blobs could not yet be published, they have been moved to a
private location. Update coreboot to pick up the blobs at the correct
place.
BRANCH=None
CQ-DEPEND=CL:195003
BUG=chrome-os-partner:28059
TEST=manual
$ emerge-storm coreboot succeeds
Change-Id: I8c4163bc978307e41c156ef9f7f2a211d57db7a8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194997
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This enables event logging support for Nyan platforms.
Right now this doesn't do a whole lot. We can add events in
later CLs.
BUG=none
BRANCH=none
TEST=built and booted for Nyan Rev. 1, eventlog gets initialized
if necessary and can be printed by "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Id77a78f55c8bff9ef0ffc7109c8b03c270e8b6b1
Reviewed-on: https://chromium-review.googlesource.com/191200
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
The current algo sets dc shift clock divider to 5 and PLLD DIVP
to 0, this is causing VCO out of the characterized range for some
panels.
This CL changes the dc shift clock divider to 1 and calculates a
proper DIVP to have the VCO inside the characterized range, i.e.,
500MHz ~ 1000MHz.
BRANCH=none
BUG=none
TEST=Verify on below panels the pixel clock frequencies are correct.
1. AUO B133XTN01.3 (69.5 MHz)
pixelclk(MHz), pll_d(MHz), m/n/p
without: 69.5 695 12/695/0
with: 69.5 139 3/139/2
2. AUO B140HTT01.0 (141 MHz)
pixelclk(MHz), pll_d(MHz), m/n/p
without: VCO (1410000000) out of range. Cannot support.
with: 141 282 2/94/1
3. LG LP140WH8 (76.32 MHz)
pixelclk(MHz), pll_d(MHz), m/n/p
without: 76.32 763.2 5/381/0
with: 76.3125 152.625 8/407/2
4. N116BGE-EA2 (76.42 MHz)
pixelclk(MHz), pll_d(MHz), m/n/p
without: 76.40 764 3/191/0
with: 76.375 152.75 12/611/2
Change-Id: Id4b3a4865acde37a97d7346ec88406f5237304eb
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/195534
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
In last clean-up commit, the detailed_blocks parsing has been merged to one
for-loop and combining return values in each iteration instead of assignment.
As a result, has_valid_detailed_blocks should now be initialized as 1.
BRANCH=none
BUG=none
TEST=Tested AUO 1080p and InnoLux 720p panels on nyan_big
Change-Id: Ie4b6e25de63c0e216ae5de9bde20eed1fe3e59a6
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/195803
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
This consolidates all calls to spi_claim_bus() and spi_release_bus()
to a single location where spi_xfer() is called. This avoids confusing
(and potentially redundant) calls that were being done throughout the
generic spi_flash.c functions and chip-specific functions.
I don't think the current approach could even work since many chip
drivers assert /CS once and then issue multiple commands such as page
program followed by reading the status register. I suspect the reason
we didn't notice it on x86 is because the ICH/PCH handled each
individual command correctly (spi_claim_bus() and spi_release_bus()
are noops) in spite of the broken code.
BUG=none
BRANCH=none
TEST=tested on nyan and link
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I3257e2f6a2820834f4c9018069f90fcf2bab05f6
Reviewed-on: https://chromium-review.googlesource.com/194510
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This adds a wrapper function and a Kconfig variable to differentiate
between SPI controllers which use atomic cycle sequencing versus
those where the transaction sequence is controlled manually. Currently
this boils down to x86 vs. non-x86.
Yes, it's hideous. The current API only worked because, for better or
worse, x86 platforms have been homogeneous in this regard since they
started using SPI as an alternative to FWH for boot flash. Now that
we have non-x86 platforms which use general purpose SPI controllers,
we should overhaul the entire SPI infrastructure to be more adaptable.
BUG=none
BRANCH=none
TEST=tested on nyan and link
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: If8ccc9400a9d04772a195941a42bc82d5ecc1958
Reviewed-on: https://chromium-review.googlesource.com/195283
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
hynix-2GB-204MHz/hynix-4GB-204MHz are not workable with Samsung RAMCODE.
To replace them by samsung-2GB-204/samsung-4GB-204 for bring up purpose.
BRANCH=none
BUG=chrome-os-partner:27682
TEST=emerge-nyan_blaze coreboot builds OK; flash to blaze board and
boot to kernel successfully with all the RAMCODE
Change-Id: I7c2a96e84e6988dd739a9621ff93edc01703306a
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/195396
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
To support parsing multiple EDID blobs, the static "decode results" flags should
be changed to auto variables inside decode_edid.
This is done by packaging static variables into a structure inside decode_edid.
We also revised some functions (manufacturer_name, do_checksum) to avoid
accessing global variables directly. Extension (and detail block) parsing may
need to access and return all parsed context so we pass the whole structure to
it.
BRANCH=none
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage
# See EDID parsed correctly on Nyan.
Change-Id: Ieca93d446bacf655c145dffdfa6cc6f5dc87ac26
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195372
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This attempts to isolate/fix some x86-isms:
- Translate flash offset to memory-mapped address only on x86.
- Guard ACPI-dependent line of code
- Use a Kconfig variable for SPI bus when probing the flash rather
than assuming the bus is always on bus 0.
- Zero-out timestamp on non-x86 until we have a better abstraction.
(note: this is based off of some of Gabe's earlier work)
BUG=none
BRANCH=none
TEST=needs testing
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I887576d8bcabe374d8684aa5588f738b36170ef7
Reviewed-on: https://chromium-review.googlesource.com/191203
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The "vbe_valid" flag is used by Coreboot table to notify payloads if a valid VBE
system is available. It is possible that display system initialization may fail
after a valid EDID is found. In that case, currently payloads will crash when
trying to output to video console.
The original intention for this portion of code is to add some check so
set_vbe_mode_info_valid can abort when no valid EDID is found. However now we do
have platforms (ex, ARM/Exynos) that hard codes EDID structure without calling
decode_edid, so we should let the callers decide if they want to continue
by the return value of decode_edid. We don't need to set vbe_valid when checksum
is correct.
It should be safe to remove the setting of vbe_valid in decode_edid function,
because vbe_valid is also set in set_vbe_mode_info_valid function. Currently all
devices calling decode_edid (tegra124, link, peppy, falco) do invoke
set_vbe_mode_info_valid after decode_edid.
BRANCH=none
BUG=none
TEST=Manually built and tested on following devices:
nyan_big, link, peppy, falco.
Change-Id: I5232bca92f73b21314d37dcd6c81578232318fd5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195371
Reviewed-by: Julius Werner <jwerner@chromium.org>
The pixel clock for some panel (ex: CMN N116BGE-EA2: 76420000) cannot be matched
by our PLLD params finding algorithm, after VCO/CF limitations are applied.
To support these panels, we want to allow "best matched" params.
BRANCH=nyan
BUG=none
TEST=emerge-nyan_big coreboot chromeos-bootimage;
emerge-nyan coreboot chromeos-bootimage;
# Successfully brings up display on Nyan_Big EVT2 and Nyan Norrin.
Change-Id: If8143c2062abd2f843c07698ea55cab47bf1e41a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195327
Reviewed-by: Julius Werner <jwerner@chromium.org>
This severs a dependency the eventlog code has on initializing
chipset/SoC SPI controller. Currently elog_init() calls spi_init()
as a catch-all. This worked for x86 since the SPI controller is only
used for one thing on existing platforms. As we add eventlogging
support to non-x86 platforms we need to consider the more generalized
case where the assumptions about how SPI works on x86 are no longer
valid.
BUG=none
BRANCH=none
Signed-off-by: David Hendricks <dhendrix@chromium.org>
TEST=built and booted on Link, Beltino and Rambi. See below for
"mosys eventlog list" output on Link showing boot and suspend/resume
events (including lid close/open) added successfully.
localhost ~ # mosys eventlog list
0 | 2014-04-14 13:52:44 | Log area cleared | 4096
1 | 2014-04-14 13:52:44 | System boot | 50
2 | 2014-04-14 13:52:44 | EC Event | Power Button
3 | 2014-04-14 13:52:44 | SUS Power Fail
4 | 2014-04-14 13:52:44 | System Reset
5 | 2014-04-14 13:52:44 | ACPI Wake | S5
6 | 2014-04-14 13:53:25 | ACPI Enter | S3
7 | 2014-04-14 13:53:35 | ACPI Wake | S3
8 | 2014-04-14 13:53:35 | Wake Source | RTC Alarm | 0
9 | 2014-04-14 13:53:49 | ACPI Enter | S3
10 | 2014-04-14 13:54:00 | EC Event | Lid Open
11 | 2014-04-14 13:54:00 | ACPI Wake | S3
12 | 2014-04-14 13:54:00 | Wake Source | GPIO | 15
Change-Id: I26e25c0a856f7b8db5ab6b8e7e1acae291d2eadc
Reviewed-on: https://chromium-review.googlesource.com/194526
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
If a payload decides not to use a USB device then the device can be
detached. This prevents the device from interfering with normal
operation on some platforms. Also, it aligns the behavior of
usb_generic_init with class-specific init functions such as
usb_msc_init, which will detach unsupported devices.
BUG=None
TEST=Manual on Squawks. Test recovery boot w/ USB 2.0 media, verify
that media boots and no babble error is encountered.
BRANCH=rambi
Change-Id: I8fb30951d273e4144cda214a30a2e86df90f2c1c
Original-Change-Id: Iee522344558749603defb2966e18765aa195dae2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We found that without enabling DC in tegra_dc_sor_enable_dc, kernel would have
problem showing the text console before graphics interface is initialized, for
example "chromeos factory install shim (text only)" or the "splash screen".
BRANCH=none
BUG=chrome-os-partner:28082
TEST=emerge-nyan coreboot chromeos-bootimage
Boots factory install shim and see text console.
Change-Id: I6fce963ceddd125dd52789d2ec843cc2ee05f1f5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195388
Dump all SOR registers for debug purpose. By default, this function
is not being built in.
BRANCH=none
BUG=chrome-os-partner:27413
TEST=build nyan and nyan_big.
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I7f44709b8572b9eac33c2193b92a65bf2b22aa76
Reviewed-on: https://chromium-review.googlesource.com/194738
Reviewed-by: Tom Warren <twarren@nvidia.com>
Commit-Queue: Tom Warren <twarren@nvidia.com>
Tested-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This ensures that SPI is ready when eventlog code is used.
x86 platforms which use eventlog invoke elog_clear() in GSMI and
elog_add_event_raw() when deciding the boot path based on ME status.
For the SMM case spi_init() is called during the finalize stage in
SMM setup. For the boot path case we can call spi_init() at the
beginning of BS_DEV_INIT and it will be ready to use when the boot
path is determined from the ME status.
BUG=none
BRANCH=none
TEST=tested on Link (bd82x6x), Beltino (Lynxpoint), and Rambi
(Baytrail) with follow-up patch
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Id3aef0fc7d4df5aaa3c1c2c2383b339430e7a6a1
Reviewed-on: https://chromium-review.googlesource.com/194525
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This patch adds some documentation to the additional PLL divisor
constraints on the intermediary VCO and CF values that we just found out
about. PLLC divisors for some oscillators had to be adjusted
accordingly.
It also adds a new clock_get_pll_input_khz() function to replace
clock_get_osc_khz() in cases where you want to factor in the built-in
predivider for 38.4 and 48 MHz oscillators.
BUG=None
TEST=Still boots.
Change-Id: Ib6e026dbab9fcc50d6d81a884774ad07c7b0dbc3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194474
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This defines the FMAP offset (currently 0x100000).
BUG=none
BRANCH=none
TEST=booted on Nyan, FMAP can now be found by coreboot
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I1c13e3f8f007729b4570d54392bf5cbf0132a698
Reviewed-on: https://chromium-review.googlesource.com/194477
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This register needs to be set properly during display init.
BRANCH=none
BUG=chrome-os-partner:27413
TEST=build nyan and nyan_big. nyan display works fine.
nyan_big display works as well. However, the mode setting
needs to be based on either devicetree or EDID.
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I93c69d8042a3f3c19f4e24801423b73246e37031
Reviewed-on: https://chromium-review.googlesource.com/194739
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
BRANCH=none
BUG=chrome-os-partner:27413
TEST=build nyan and nyan_big. nyan display works fine.
nyan_big display still does't work until all related
patches are built in. (CL:194739)
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: Ic5d977f695be127693f1ecc3ba52d478f524d20f
Reviewed-on: https://chromium-review.googlesource.com/194737
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Correct SOR attaching sequence.
https://chromium-review.googlesource.com/190300
BRANCH=none
BUG=chrome-os-partner:27413
TEST=build nyan and nyan_big. nyan display works fine.
nyan_big display still doesn't work until all related
patches are built in. (CL:194737 and CL:194739)
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I8aaf65db90e5e45bd9097c9d38b231bd7d41d997
Reviewed-on: https://chromium-review.googlesource.com/194403
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Some kconfig options have changed but the configs haven't been updated. When
make oldconfig is run from the ebuild through emake, that doesn't seem to
causea problem for whatever reason. When run manually, however, kconfig stops
to ask for each config it doesn't have a value for. This change updates the
configs to correct that issue.
BUG=None
TEST=Ran make oldconfig manually for all boards. Built and booted on big.
BRANCH=None
Change-Id: I138f8ad9239a3834d28dc492e0a90a94442b2af1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194908
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tegra124 family products may want to use many different display panels with
various timing settings. To support them, we should initialize display panel by
EDID instead of hard-coded values.
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage
BRANCH=none
Change-Id: Ib125a7f9cb1e6c8cf2d79e0baab525acfd1b7a6e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192730
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
According to DP version 1.2a, The MOT (Middle-of-Transaction) bit
must be set when the I2C transaction does not stop with the current
AUX transaction.
Thus the correct steps for an I2C read shall be:
1. I2C command write with MOT set to 1
2. I2C command read to the same address with MOT set to 0
BUG=chrome-os-partner:27679
TEST=EDID data read from LP140WH8 panel is correct while it's a
repeated pattern of the first 16 bytes without this CL
BRANCH=none
Change-Id: I0526beffb8852fbbe0eb5bb80e370261617a59b8
Signed-off-by: Ken Chang <kenc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/194915
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Similar to the W25Q64DW, the W25Q32DW has basically the same
attributes as the earlier W25Q32 parts but with a different
value in the MSB of the ID.
BUG=none
BRANCH=none
TEST=tested on nyan, now SPI flash commands actually work.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I697768a443c98515d893f9cf8f8b4258ae0f159d
Reviewed-on: https://chromium-review.googlesource.com/191205
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
