The EC can export ALS information if the sensor is attached
to it directly rather than to the host. This adds a basic
ACPI ALS device and implements the required information.
The kernel does not use the _ALR tuple set but it is required
by the ACPI spec so this just adds the sample two point
response curve defined in ACPI 5.0 section 9.2.5.
The EC does not currently send events for lux value changes so
a polling interval of 1 second is defined.
BUG=chrome-os-partner:24208
BRANCH=None
TEST=build and boot on samus, add acpi-als driver to the kernel
and read /sys/bus/iio/devices/iio:device0/in_illuminance_raw
Change-Id: Id29b72a68aa21c1a7c71d5f87223ac010cef0377
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203743
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This makes it so that we always log the generic "system boot" event.
If boot count support has not been implemented, fake it.
BUG=chrome-os-partner:28772
BRANCH=nyan
TEST=booted on Big, ran "mosys eventlog list" and saw
"System boot" event logged with boot count == 0
Change-Id: I729e28feb94546acf6173e7b67990f5b29d02fc7
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204525
Reviewed-by: Julius Werner <jwerner@chromium.org>
On Ubuntu /bin/sh is symlinked to /bin/dash. The
current toolchain.inc was doing some things that
dash doesn't support. Make the shell callouts more
conforming to the POSIX sh standard.
BUG=None
BRANCH=None
TEST=Built rush.
Change-Id: I26b6b82b8d6158c9029e8be9e7c088ca9e207f21
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5701
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://chromium-review.googlesource.com/204400
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This patch brings the cbmem utility in line with the recent change to
coreboot's device tree binding. Since trying to find the right node to
place this binding has been so hard (and still isn't quite agreed upon),
and because it's really the more correct thing to do, this code searches
through the device tree for the 'coreboot' compatible property instead
of looking up a hardcoded path. It also provides bullet-proof
'#address-cells' handling that should work for any endianness and size.
BUG=chrome-os-partner:29311
TEST=Ran cbmem -c and cbmem -t on Nyan_Big. Also straced the to make
sure everything looks as expected. 'time cbmem -t' = ~35ms shows that
there is no serious performance problem from the more thorough lookup
code.
Change-Id: I806a21270ba6cec6e81232075749016eaf18508b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204274
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add config option for customize this value by board.
BUG=chromium:366940
TEST=Manual add config for specific board and verify by dmidecode.
Signed-off-by: Kevin Cheng <kevin.cheng@intel.com>
Change-Id: I6deb7f07c00c899bad1eb08fa6a2410deb7a8c6a
Reviewed-on: https://chromium-review.googlesource.com/203657
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Kevin Cheng <kevin.cheng@intel.com>
Tested-by: Kevin Cheng <kevin.cheng@intel.com>
There have been leaks of GPL code into libpayload for a while now, for
new features or improvements that require third party code with no
adequate alternative among BSD-licensed software. It seems silly and
counter-productive to keep holding back features and performance
improvements from libpayload for a use-case (proprietary payloads) that
doesn't even seem to be implemented anywhere to date. Open-source
payloads should not need to suffer to appease commercial ones.
Instead, this patch introduces a new Kconfig option to explicitly allow
inclusion of GPL code. It will use Kconfig dependencies and/or Makefile
rules to ensure that no GPL code can end up in the final payload if that
option is unset, allowing proprietary payloads to keep working with the
existing BSD-licensed feature set. New features and patches (that are
sufficiently separate and self-contained to allow guarding through this
config option) can choose whether to import GPL code, and need to depend
on this option if they do.
Also clean up all (known) existing uses of GPL code to depend on the new
option, add some recent third-party imports to the LICENSES file, and
relicense the selfboot.c files to BSD with permission of the author.
BUG=chrome-os-partner:24957
TEST=Compiled Falco and Nyan_Big both with and without the new option,
disassembled output binaries to ensure that memcpy() looks as expected.
Change-Id: I6e3a75b1a8e46291c75a876844c7a01f7d3f2a0e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203513
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The GPIO controller (configured as IRQ14 by default) is level triggered
and active high according to documentation. At the moment it seems to
be misbehaving and firing constantly which is preventing package C-states
since one core is always busy servicing imaginary events.
Until this is understood and fixed don't report an interrupt for the GPIO
controller. Since there are 16 peripheral IRQ capable GPIOs this is not
used currently.
Also remove the hardcoded MADT IRQ override entry for IRQ14 since we are
using the GPIO controller in ACPI mode so it gets the interrupt
configuration from _CRS.
BUG=chrome-os-partner:29548
BRANCH=None
TEST=boot on wtm2 and check for package C-state entry with powertop
Change-Id: Ibf562fe3512e68d3944fda61a023a1631f7acd57
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203645
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Depthcharge clears up all unused DRAM before starting Linux, and does
not know the translation table location. Instead of adding an
exclusion term to the memory wipe descriptor lets move the table to
the top of IMEM, it is also likely to be a good location in the
future, when EFS is introduced.
BUG=chrome-os-partner:27782
TEST=manual
. built and ran firmware on ap148
Change-Id: I76546438d243076dda4d0eb3f784e0b5a8a1fa22
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203624
Reviewed-by: Julius Werner <jwerner@chromium.org>
With new config options added the existing configs became stale and
the library can't be built without make stopping and waiting for the
user to confirm new configuration defaults.
The following was used to normalize the configs:
$ for f in configs/config.*; do
cp $f .config
make oldconfig
mv .config $f
done
hitting return through each dialog.
BUG=none
TEST=manual build for strom does not stop anymore at 'make oldconfig' phase
Change-Id: I5ee85a17c1612d598b7b26c115c2e9efafde1df9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203623
Reviewed-by: Julius Werner <jwerner@chromium.org>
For some panels, the plld can't provide the pixel clock that
the panels wants, so we give it a good enough one. And we
should calculate the dp/dc settings by the real pixel clock.
BRANCH=nyan
BUG=chrome-os-partner:29489
TEST=Verified the panels N116BGE-EA2(Nyan) and N133BGE-EAB(Big).
No screen flicker is observed. No sor dp fifo underflow found.
Change-Id: I037b2bd5f5e9bb8b15ab6f47a84ac7ef2e207779
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/203358
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add XN/PXN bits to prevent cpu from fetching speculative instructions
on noncacheable region.
BUG=chrome-os-partner:28568
BRANCH=nyan
TEST=Build and run reboot tests on nyan_big
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I0cd2ad5a47a467ef609d30d42cd300b5ca45b77b
Reviewed-on: https://chromium-review.googlesource.com/203447
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Hynix 2GB/4GB configs have been fine-tuned.
Kingston 2GB config is new, uses RAMCODE 0x6.
BUG=none
TEST=emerge-nyan_big coreboot-nyan_big OK. Flashed to my
Big 2GB system (PVT1/SKU1) and it booted OK.
BRANCH=nyan_big
Change-Id: I8a23a5568ef84d5befc13623f78bce664130f314
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/203305
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch adds the ability to attach a GDB host through the UART to a
running payload. Libpayload implements a small stub that can parse and
respond to the GDB remote protocol and provide the required primitives
(reading/writing registers/memory, etc.) to allow GDB to control
execution.
The goal of this implementation is to be as small and uninvasive as
possible. It implements only the minimum amount of primitives required,
and relies on GDB's impressive workaround capabilities (such as
emulating breakpoints by temporarily replacing instructions) for the
more complicated features. This way, a relatively tiny amount of code on
the firmware side opens a vast range of capabilities to the user, not
just in debugging but also in remote-controlling the firmware to change
its behavior (e.g. through GDBs ability to modify variables and call
functions).
By default, a system with the REMOTEGDB Kconfig will only trap into GDB
when executing halt() (including the calls from die_if(), assert(), and
exception handlers). In addition, payloads can manually call gdb_enter()
if desired. It will print a final "Ready for GDB connection." on the
serial, detach the normal serial output driver and wait for the commands
that GDB starts sending on attach.
Based on original implementation by Gabe Black <gabeblack@chromium.org>.
BUG=chrome-os-partner:18390
TEST=Boot a GDB enabled image in recovery mode (or get it to hit a
halt()), close your terminal, execute '<toolchain>-gdb --symbols
/build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory
~/trunk/src/third_party/coreboot/payloads/libpayload --directory
~/trunk/src/platform/depthcharge --directory
~/trunk/src/platform/vboot_reference --ex "target remote
<cpu_uart_pty>"' and behold the magic.
(You can also SIGSTOP your terminal's parent shell and the terminal
itself, and SIGCONT them in reverse order after GDB exits. More
convenient wrapper tools to do all this automatically coming soon.)
Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202563
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This patch makes some slight changes to the exception hook interface.
The old code provides a different handler hook for every exception
type... however, in practice all those hook functions often need to look
very similar, so this creates more boilerplate than it removes. The new
interface just allows for a single hook with the exception type passed
as an argument, and the consumer can signal whether the exception was
handled through the return value. (Right now this still only supports
one consumer, but it could easily be extended to walk through a list of
hooks if the need arises.)
Also move the excepton state from an argument to a global. This avoids a
lot of boilerplate since some consumers need to change the state from
many places, so they would have to pass the same pointer around many
times. It also removes the false suggestion that the exception state was
not global and you could have multiple copies of it (which the exception
core doesn't support for any architecture).
On the ARM side, the exception state is separated from the exception
stack for easier access. (This requires some assembly changes, and I
threw in a few comments and corrected the immediate sigils from '$' to
the official '#' while I'm there.) Since the exception state is now both
stored and loaded through an indirection pointer, this allows for some
very limited reentrance (you could point it to a different struct while
handling an exception, and while you still won't be able to return to
the outer-level exception from there, you could at least swap out the
pointer and return back to System Mode in one go).
BUG=chrome-os-partner:18390
TEST=Made sure normal exceptions still get dumped correctly on both
archs.
Change-Id: I5d9a934fab7c14ccb2c9d7ee4b3465c825521fa2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202562
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This patch adds a console_kill_output_driver() function, which can
remove a previously registered output driver. This is mostly useful when
you overlay some output channel over another, such as when the GDB stub
takes direct control of the UART (and thus has to get rid of the
existing serial output driver).
BUG=chrome-os-partner:18390
TEST=None
Change-Id: I6fce95c22fd15cd321ca6b2d6fbc4e3902b1eac3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202561
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This patch adds code to initialize the two DWC3 USB host controllers and
their associated PHYs to the IPQ806x SoC (closely imitating the existing
DWC3 implementation for Exynos5), and uses them to initialize USB on the
Storm mainboard.
BUG=chrome-os-partner:29375
TEST=Hack up netboot to get around missing SPI flash, load a file over
TFTP. Hack a storage read into the storage attach function, dump the
data and confirm that it looks right. Enable USB debugging and confirm
3.0 devices get enumerated at SuperSpeed (mostly).
Change-Id: Iaf7b96bef994081ca222b7de9d8e8c49751d3f1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202157
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
- Put SSD into reset on transition to S3/S5 to prevent leakage
- Fix GPIO number for wlan disable used in smihandler
- Enable generic hub driver in libpayload
- Fix comment in devicetree about S0ix
BUG=chrome-os-partner:28502
BRANCH=None
TEST=Build and boot on samus
Change-Id: Idce566d0f22622d36697be54ab51cacb576c5d6d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203185
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
XHCI driver was not enabled in libpayload and some ports were
disabled that should be enabled.
The Chrome OS GPIOs also need to be reported as 0xFFFFFFFF to
properly indicate unused so crossystem does not attempt to
export GPIO number 255 in the kernel and trigger a warning.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2
Change-Id: Ib5727ef6e618c959640b200757cfa13f95c7cb0f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Does not compile yet because tegra132 support is not present in cbootimage
BUG=None
BRANCH=None
TEST=Does not compile (Waiting for tegra132 support in cbootimage)
Change-Id: I796f171031bacf17106878d4a554e8f1cbfe93f8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/203145
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Changes might be required for .bct files as we get to know more.
Pulling in files from mainboard nyan for now
BUG=None
BRANCH=None
TEST=Compiles successfully for rush
Change-Id: Iaf81a384af0469c77940cf7309ba68018110b5eb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/203144
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
CrOS devices with Chromeos EC need only use hostevent to communicate
recovery assertion to the BIOS. This CL removes wired GPIO from
determining recovery as it appears under certain conditions (cold
reset) the internal PU on the AP isn't strong enough and therefore the
value is sometimes seen as asserted.
BRANCH=none
BUG=chrome-os-partner:29333
TEST=compiles & BIOS no longer responds to rec_mode GPIO during boot.
Change-Id: Ib220cfa5f5bfe7193d555bfd32c0444b063d00f2
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202996
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The config files need to be renormalized after two new Kconfig options
for the IPQ806x have been added. Otherwise, trying to just 'make
oldconfig' with them from a command line hangs with extra questions. (I
never quite figured out why the ebuild seems to be unaffected by this.)
BUG=None
TEST=None
Change-Id: I272e40ef81e18c4d4e043b053d732c2e1c2599e9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202803
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The recently introduced page table location value is wrong, it
overlaps with other areas of the code. This patch fixes the location,
a more robust scheme is needed for memory layout management.
BUG=none
TEST=manual
. occasional random failures disappear after this patch is applied
Change-Id: Idc9047d38712736c5e8197e933c373488b333649
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202641
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some drivers being ported to depthcharge use io bit manipulation
macros. The libpayload include file seems the most appropriate place
to keep these macros in. There is no common io.h file across
architectures, the x86 version could be added later if required.
BUG=chrome-os-partner:27784
TEST=observed ipq806x SPI driver deptcharge port (WIP) compile properly.
Change-Id: I33f3be072faefce293c871f7e3bc3b2e6bc38ffe
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202559
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
This adds a UART driver for the ipq8064 controller. It still does not
quite work in the receive direction - the receive FIFO returns read
data in 32 bit chunks, which means that 4 keys need to be pressed
before a character pops out of the driver (and it reports it as a
single character).
This issue is being addressed separately, the driver is being checked
in to facilitate concurrent development.
BUG=chrome-os-partner:27784, chrome-os-partner:29313
TEST=with deptcharge modifications in place, the AP148 board comes up
to the depthcharge prompt:
Starting depthcharge on storm...
storm:
Change-Id: Ief2cfcca73494be5c4147881144470078adcefb8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202045
Reviewed-by: Deepa Dinamani <deepad@codeaurora.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This adds some assembly code to clear .bss segment. It might have been
already cleared by the loader, but it is not guaranteed. This also
helps when the program is loaded by the debugger.
BUG=none
TEST=observed that .bss is now initialized when the program is
restarted. Verified correct boundaries of the segment.
Change-Id: I0aed0070da53881e4cf8c27049459040c006e765
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201784
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
When preparing an image for source level debugging, it is convenient
to be able to compile some modules with '-g -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 V=1 GDB_DEBUG=1 and observed the modified compiler
invocation line in the log.
Change-Id: I4a902ad25157fa7f93614917f440e56145405a1d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201783
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
This is an interim change (before EFS is enabled), align ROM and RAM
stages so that they have enough room and do not step over each other.
BUG=chrome-os-partner:27784
TEST=manual
. booted coreboot successfully on ap148
Change-Id: I6e1710ac7ca494a69aea5ba3b117bfd882aded26
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202046
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
The driver as it was copied from u-boot provided a function to
transmit multiple characters in one invocation. This feature was not
ported to coreboot, there is no need to maintain the complexity when
only one character at a time is transmitted. It is also very desirable
to get rid of a 1024 byte array allocated on the stack.
The array was necessary to allow to convert multiple newline
characters in the transmit data flow into two character sequences
CRLF. Now just a single word is enough to keep one or two characters
to transmit.
BUG=chrome-os-partner:27784
TEST=verified that coreboot with the new code prints generates console
output.
Change-Id: I73869c5f4ca87210b34811b583386554bafff1e7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201782
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Both DDI ports may be used on this board so it needs to be
able to detect a device on either port.
BUG=chrome-os-partner:28234
TEST=None (needs hardware)
Change-Id: I5fc5ec3fe887fb51e7bdeae43c8297580e0ba6d6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202358
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ME debug info is not compiled in when the loglevel is
turned down to save the space of all the strings so the
contents in me_status.c should not be included either.
BUG=chrome-os-partner:28234
TEST=Build and boot with LOGLEVEL=BIOS_ERROR
Change-Id: Ibef46d0da038e13b0de0a29ab038ab6fce395730
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202357
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Enable the option to always load the VBIOS even when not executing
- If the option rom is not executed then DDI-A needs to be enabled
for the internal panel to work when the kernel comes up.
BUG=chrome-os-partner:28234
TEST=Build and boot with working OS graphics in normal mode.
Change-Id: I4ebfbf9d8714490dfd2dc2e634928c449719a2bf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
xHCI Spec says TD Size (5 bits) field shall be forced to 31,
if the number of packets to be scheduled is greater than 31.
BUG=chrome-os-partner:27837
BRANCH=rambi,nyan
TEST=Manual: Ensure recovery boot with USB 2.0 media on Squawks
works fine without any babble errors.
Change-Id: Iff14000e2a0ca1b28c49d0da921dbb2a350a1bbd
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Originally-Reviewed-on: https://chromium-review.googlesource.com/202297
Reviewed-on: https://chromium-review.googlesource.com/202330
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Define a base address for page table entries. Place it 64KB below the
bootblock loading address.
BUG=chrome-os-partner:28467
TEST=verified that the page tables are being populated at this
address. Also observed that the SPI driver takes 900 ns to
process a byte as opposed to 1.5 us in case caching is not
enabled.
Change-Id: I3d8bd3104c55389aa5768033642ebbf1fda0fec7
Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200332
This change updates the cfg file for Hynix/Micron/Samsung 4GB,
792MHz DRAM based on the data generated by t124_emc_reg_tool.
BUG=none
BRANCH=blaze
TEST=emerged coreboot, booted successfully into kernel.
Change-Id: I7621e60d8dcc568e0bb400a6c96b7f8909a15aa6
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/202059
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
- Update GPIO map
- Update SPD for new memory and 4-bit table decode
- Enable USB3 port 3 and 4 (shared with PCIe port 1)
- Enable PCIe port 3 and disable port 1
- Enable SerialIO ACPI mode for devices
- Disable S0ix for now to prevent use of C10
- Special handling for memory with broadwell CPU
BUG=chrome-os-partner:28234
TEST=Boot on P1.9
Change-Id: If6adcc2ea76f1af7613b715133483d7661e94dd8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201083
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Put all the SPD related information in one place including
the onboard SPD sources and the board specific parsing.
BUG=chrome-os-partner:28234
TEST=Build and boot on samus
Change-Id: If5cd826ecc9cc856008b7c29aa3cfade5ae7f685
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201082
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- The old pei_data structure from haswell was still present
- Add a function for romstage to read CPU family/model
- Add quick_ram_check after memory init
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2 with broadwell CPU
Change-Id: I48ae199351d383796b28197fc0368770cba80ec4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201690
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Broadwell CPUs can have a region reserved just below TSEG for a
PCODE patch or TXT/BootGuard data. The DPR register reports the
TOP of this region with the size also reported in bits 8:4.
Compute and use the DPR base address as the top of memory for
coreboot.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2+broadwell, check that the
usable memory is adjusted by 1MB:
- 3. 0000000000100000-000000007ce3efff: RAM
- 4. 000000007ce3f000-000000007cffffff: CONFIGURATION TABLES
- 5. 000000007d000000-000000007f9fffff: RESERVED
+ 3. 0000000000100000-000000007cd3efff: RAM
+ 4. 000000007cd3f000-000000007cefffff: CONFIGURATION TABLES
+ 5. 000000007cf00000-000000007f9fffff: RESERVED
Change-Id: Ia6ba25bc9992c3a3f859edd8d4a9c64aa42cfa98
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201081
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
