Add support to check if the driver for console_out or console_in is already
present in the list. If console_init is called twice, then the driver might get
added twice leading to a loop.
BUG=None
BRANCH=None
TEST=With console_init in libpayload and depthcharge both, there are no console
loops seen anymore
Change-Id: If9a927318b850ec59619d92b1da4dddd0aa09cd1
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214072
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
EHCI driver accesses mmio space using regular struct pointers. In order to avoid
any CPU re-ordering, memory barrier is required in async_set_schedule,
especially for arm64. Without the memory barrier, there seems to be re-ordering
taking place which leads to USB errors with some flash drives as well as
transfer errors in netboot.
BUG=chrome-os-partner:31533
BRANCH=None
TEST=With the memory barrier introduced, netboot for ryu completes transfer
without any error and finishes within 6-7 seconds.
Change-Id: Ic05d47422312a1cddbebe3180f4f159853604440
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/213917
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add support for memory barriers in arch {arm,arm64,x86}. This is required to
force strict CPU ordering. Definitions are based on FREEBSD atomic.h
definitions.
BUG=chrome-os-partner:31533
BRANCH=None
TEST=Memory barriers tested with ehci driver on arm64
Change-Id: Ie51e3452f7a254b24111000da5dbe8714ac22223
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/213916
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
There are three instances of coreboot.c in libpayload. for x86, arm
and arm64 architectures. The arm and arm64 instances are exactly the
same. The differences with the x86 instance are as follows:
- a very slightly different set of coreboot table tags is parsed (one
tag added and two removed)
- instead of checking a fixed address if it contains the coreboot
table, the x86 version iterates over two address ranges.
This patch refactors the module, leaving architecture specific
processing in arch subdirectories and moving the common code into
libc.
BUG=none
TEST=none yet
Change-Id: I6dfed73f6ba5939f692d0f98d2774c0e0312a25f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210770
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make board ID value supplied in the coreboot table available to the
bootloader on all three architectures.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: I7847bd9fe2d000a29c7ae95144f4868d926fb198
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210430
Reviewed-by: Julius Werner <jwerner@chromium.org>
The serial driver hangs in cases when FIFO has more than single word to be
processed. Easiest way to reproduce is to paste a string of greater than 4
characters in cli.
Clearing the RXSTALE interrupt without draining all the characters from FIFO
leads to the issue as the driver is dependent on msm_boot_uart_dm_read
function to reinitialize for next transfer.
Logically the driver is organized in such a manner that next transfer never
gets initiated till rx_data_read < total_rx_data. Clearing the RXSTALE without
consideration of total number of characters (or words) unprocessed makes the
msm_boot_uart_dm_read to return on the first if conditional. Thus the driver is
stuck forever.
A quick fix is to avoid clearing the stale interrupt. Reset is handled whenever
a new transfer is initialized in msm_boot_uart_dm_init_rx_transfer.
BUG=chrome-os-partner:29542
TEST=manual
-Paste a string greater than 4 characters in cli.
Change-Id: I016afb01a77cd14764f0176f6bf144fb29796c2f
Signed-off-by: Yogesh Lal <ylal@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/209512
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Looks like we got our first SoC that actually insists on using
word-sized accesses for its MMIO registers with the Rk3288. This patch
changes the GDB command handler for reading and writing memory to always
perform word-sized accesses. This isn't really perfect since the remote
GDB interface is just not really meant to interact with MMIO (e.g. you
shouldn't use this on something with read side effects), but for most
of our purposes it should be good enough.
BUG=chrome-os-partner:18390
TEST=Remote GDB works on Veyron even when writing MMIO registers.
Change-Id: I2ae52636593499f70701582811f1b692c1ea8fcc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208554
Reviewed-by: David Hendricks <dhendrix@chromium.org>
setbits_le32() is not really arch-specific... the arch-specific part of
accessing memory is wrapped by readl() and writel(), and the endianness
can be accounted for with the right macros. Generalize the definitions,
add a be32 version and move them to endian.h so that all platforms can
use them. Also include endian.h from libpayload.h so we won't update any
payload's old use of the macros (endianness is something useful enough
to always have avalable anyway, and shouldn't clash with other things).
This also fixes a bug where these macros would only be available if
libpayload-config.h had been independently included before.
Also fix a bug with readl() macros on all archs where they refused to
work on const pointers (which they should).
CQ-DEPEND=CL:208712
BUG=None
TEST=Stuff still compiles. Built and booted on Storm.
Change-Id: I01a7fbadbb5d740675657d95c1e969027562ba8c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208713
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
config.veyron was written by hand and had some minor mismatches (entries
in a different order than Config.in, negative entries for some options
that no longer exist, etc.). Most importantly, it was missing the
negative entry for CONFIG_LP_REMOTEGDB, which is required to make our
ebuilds build a correct image.dev.bin with GDB support.
Ran it through make oldconfig once so that everything is in the right
place again.
BUG=None
TEST=Remote GDB on Veyron works (woohoo!)
Change-Id: Ic5ebe25fe8ef1b63031569a178c5419ca7e31754
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208255
Reviewed-by: David Hendricks <dhendrix@chromium.org>
In cases where timer clock frequency is not an integer number of
megahertz, the calculations in timer_us() lack accuracy.
This patch modifies calculations to reduce the error. The maximum
interval this calculation would support decreases, but it still is in
excess of 1844674 seconds for a timer clocked by 10 MHz, which is more
than enough.
BUG=none
TEST=manual
. verified timer accuracy using a depthcharge CLI command
Change-Id: Iffb323db10e74b0ce3b4d59a56983bfee12e6805
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207358
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add support board veyron:
1)Support driver rktimer
2)Support driver rkserial
3)Support config.veyron
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: I2cccedf3b62883dd372842a7972e93f2ebbfb282
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/206184
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: 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.
CQ-DEPEND=CL:205476
BUG=none
TEST=manual build for strom does not stop anymore at 'make oldconfig' phase
Change-Id: I9678b4c69fc01640be490907136cf8e0916e4957
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205359
Reviewed-by: Julius Werner <jwerner@chromium.org>
The current default memcpy first copies single bytes to align the
amount, then copies the rest as full words. In practice, the start of a
buffer is much more likely to be word-aligned then the end, and aligned
word access are usually more efficient. This patch reorders those
accesses to first copy as many full words as possible and then finish
the rest with byte accesses to optimize this common case.
This fixes a data abort when using USB on ARM without CONFIG_GPL. Due to
some limitations of how DMA memory is set up in coreboot on ARM, it
currently does not support unaligned accesses. (This could be fixed with
a more complicated patch, but it's usually not an issue... unless, of
course, your memcpy happens to be braindead).
Also add word-aligned accesses to memset and memcmp while I'm at it, and
make memcmp's return value standard's compliant.
BUG=chrome-os-partner:24957
TEST=Manual
Change-Id: I2a7bcb35626a05a9a43fcfd99eb958b485d7622a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203547
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add stub implementation for gdb arm64 support. Currently all functions are kept
empty to enable proper compilation of depthcharge and libpayload. As we get more
clear about context management and stuff, we can add details for gdb as well.
BUG=None
BRANCH=None
TEST=Compiles successfully for rush
Change-Id: I0a8729671ab0764d424c0e3d50af86433d05b1e8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/204877
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The exception handling was previously updated, however the
arm64 changes raced with hat one. Make the arm64 align with
the new model. Without these changes compilation will fail.
BUG=None
BRANCH=None
TEST=Can build libpayload for rush.
Change-Id: I320b39a57b985d1f87446ea7757955664f8dba8f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204402
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
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>
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>
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>
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>
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>
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>
Libpayload libc requires timer clock frequency to be at least 1MHz.
Ipq8064 code presently provides a single option of 32kHz. Pretend to
be running at 1 MHz without additional accuracy.
This is a hack which will be reverted as soon as the SOC is configured
to supply a faster running clock.
BUG=chrome-os-partner:27784, chrome-os-partner:28880
TEST=with other changes depthcharge boots to the CLI console
Change-Id: I80ec6652bc5693a549668cd6e824e9cf5c26b182
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201342
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The earlier compilation warning fix (7e4aa17) incorrectly assumed that
selfboot() is a function defined in the cbfs driver. This is a
commonly available function, it should not come from cbfs.h.
BUG=none
TEST=the following command succeeds:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload || break
done
Change-Id: I3ef49d849168ad9dc24589cbd9ce7382052345bd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201386
This is still using the 32kHz timer coreboot uses. A finer granularity
timer implementation for 806x is in the works.
BUG=chrome-os-partner:27784,chrome-os-partner:28880
TEST=none yet.
Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198021
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
As the USB driver for storm hardware is not yet available, do not
define it in llibpayload.
BUG=chrome-os-partner:27784
TEST=not much testing yet, just compilation/building
Change-Id: I6aea72cda33b61deb0a7dc69f8295f8c3f61406b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200827
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The -z "${V}" sure must have meant to be -n "${V}", but come to think
of it, this check is not necessary, as the following check will
succeed if and only if V is set to 1.
BUG=none
TEST=verified that adding V=1 to the environment causes the lpgcc
debug statements to show up in the output.
Change-Id: I1eb43ef49aeb4f16aef4fbee3a1037e853f9b40f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200501
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Make sure the build breaks in case of warnings.
BUG=none
TEST=run the following command with the previous patch removed and
then restored:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
all builds succeed with the restored patch and fail when a
compilation warning is thrown.
Change-Id: I9bdcd8938f59913e4ba86df5e4921b3f821ef920
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in commit 1f880bca0 really
meant to check for 'if (console)'. Looks like the whole video console
driver is built extra robust to not fail no matter how screwed up the
console is, so let's add this missing check here as well. Also fixed up
a few other missing 'if (!console)' checks while I'm at it.
However, what payloads should really be doing is check the return value
of video_(console_)init() and not call the other video functions if that
failed. This also adapts video_console_init() to correctly pass through
the return value for that purpose (something that seems to have been
overlooked in the dd9e4e58 refactoring).
BUG=chrome-os-partner:28494
TEST=None. I don't know what Dave did to trigger this in the first
place, but it's pretty straight-forward.
Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200688
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When emerging libpayload a warning is generated about selfboot() being
defined without a prior prototype.
Addinf cbfs.h when CBFS use if compiled fixes the warning.
BUG=none
TEST=run the following
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
verify that there is no compilation warnings thrown any more
Change-Id: Ic9cb5571f708bb006a0d477e451fd1f3b3eb833f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200099
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
ARM processors save the PC value in the Link Register when they handle
and exception, but they store it with an added offset (depending on the
exception type). In order to make crashes easier to read and correctly
support more complicated handlers in libpayload, this patch adjusts the
saved PC value on exception entry to correct for that offset.
(Note: The value that we now store is what ARM calls the "preferred
return address". For most exceptions this is the faulting instruction,
but for software interrupts (SWI) it is the instruction after that. This
is the way most programs like GDB expect the stored PC address to work,
so let's leave it at that.)
Numbers taken from the Architecture Reference Manual at the end of
section B1.8.3.
BRANCH=none
BUG=chrome-os-partner:18390
TEST=Provoked a data abort and an undefined instruction in both coreboot
and depthcharge, confirmed that the PC address was spot on.
Change-Id: Ia958a7edfcd4aa5e04c20148140a6148586935ba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199844
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The video console runs a video_console_fixup_cursor() function after
every printed character to make sure the cursor is still in the output
window and avoid overflows. For some crazy reason, this function does
not run when cursor_enabled is false... however, that variable is only
about cursor *visibility*, and it's imperative that we still do proper
bounds checking for our output even if the cursor itself doesn't get
displayed (otherwise we can end up overwriting malloc cookies that cause
a panic on the next free() and other fun things like that).
In fact, there seems to be no reason at all to even keep track of the
cursor visibility state in the generic video console framework (the
specific backends already do it, too), so let's remove that code
entirely. Also set the default cursor visibilty in the corebootfb
backend to 0 since that's consistent with what the other backends do.
BUG=None
TEST=Turn on video console on Big, generate enough output to make it
scroll, make sure it does not crash.
Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196323
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
