If EHCI controller has TT (Transaction Translator) support in
root-hub, then we need to keep control over this controller when
USB keyboard (low-speed device) is connected to root-hub port.
Need to add "CONFIG_LP_USB_EHCI_HOSTPC_ROOT_HUB_TT=y" to config file
(e.g. payloads/libpayload/configs/config.nyan_big) to support this
feature.
BUG=chrome-os-partner:32355
TEST=Tested on nyan_big platform.
Press ESC+REFRESH+POWER keys on internal keyboard to power up.
Press Left Arrow or Right Arrow on USB keyboard to switch between
"English" and "Default Locale" in coreboot UI. Or unplug and plug
in device and try again.
Root hub <- low-speed USB keyboard
Root hub <- full-speed hub <- low-speed USB keyboard
Root hub <- high-speed hub <- low-speed USB keyboard
Change-Id: Id86a289bc587653b85227c1d50f7a4f476f37983
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/220125
Reviewed-by: Julius Werner <jwerner@chromium.org>
Pass MAC addresses found in coreboot table into lib_sysinfo.
BUG=chrome-os-partner:32152
TEST=with all changes in place MAC addresses are properly inserted
into the kernel device tree.
Change-Id: I1d0bd437fb27fabd14b9ba1fb5415586cd8847bb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219444
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Chapter 3.1 "Periodic Frame List" of EHCI 1.0 specification says
"Frame List Link pointers always reference memory objects that are
32-byte aligned."
jwerner@chromium.org suggests setting it to be 64-byte aligned for
consistency with other EHCI queue structures.
BUG=chrome-os-partner:31993
TEST=Tested on nyan platform. Before adding patch, USB keyboard behind
an external hub is not working to switch between "Default Locale" and
"English" (after pressing ESC+REFRESH+POWER on embedded keyboard and
later Left/Right-Arrow key on USB keyboard).
Change-Id: If52ddc43ebd5d509c19f104928dced5bd09b1706
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/218403
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
What this change does:
1) Initialize limited page tables as soon as we jump into libpayload. Basically
two ranges are initialized. One is for the BASE_ADDRESS and other is for the
coreboot_tables. With page tables initialized and MMU enabled, we jump into
code to parse coreboot tables.
2) Once coreboot tables are parsed and we have complete picture of the memory,
we perform a complete page table initialzation and enable MMU and then jump to
payload.
Additionally, we also:
1) Initialize DMA memory on our own depending upon the memory map. It ensures
that the DMA buffer is placed in 32-bit memory.
CQ-DEPEND=CL:216826
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and we are able to start execution of libpayload in
EL2 and reach kernel login prompt
Change-Id: Ie0f47b7759d4ac65a6920f7f2f7502b889afda6d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216824
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Adds support for initializing mmu, setting up dma areas and enabling mmu based
on the memranges passed on in the coreboot tables.
CQ-DEPEND=CL:216826
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully
Change-Id: I217bc5a5aff6a1fc0809c769822d820316d5c434
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216823
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Libpayload should be able to setup its own dma areas and not depend on coreboot
tables for passing this information. This patch and next allow libpayload to
setup dma areas while performing mmu_init
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and dma areas are setup properly with the mmu init patch
Change-Id: I44d9f394fa349abd7182c4ba10f1eaefd6e4fdaa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216822
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
We retroactively decided to use the variant name "pinky" for the Rk3288
board we're currently bringing up, and retcon the unadorned "veyron"
name to refer to the Rockchip evaluation board. Since we currently have
no interest to maintain coreboot support for that board in our tree,
let's rename everything to "veyron_pinky" and forget about "veyron".
CQ-DEPEND=CL:217592
BUG=chrome-os-partner:30167
TEST='emerge-veyron libpayload coreboot' fails but
'emerge-veyron_pinky libpayload coreboot' succeeds.
Change-Id: I366391efc8e0a7c610584b50cea331a0164da6f3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217674
Reviewed-by: David Hendricks <dhendrix@chromium.org>
By default we dont want to use the special DC instruction. Thus getting rid of
the DONT_USE_DC macro and enabling code appropriately in memset.S
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully and memset works fine for mmu init
Change-Id: Id89ec2c1731d21496eca617a3c03abaf48062908
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/216820
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/211053
Reviewed-by: Julius Werner <jwerner@chromium.org>
Allow more flexibility by reading and writing to system registers at current
EL. Instead of specifying what _ELx register to write to, code can specify
_current.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles and boots to kernel on ryu
Change-Id: Ic1d9e18e6fc016a04f17621a148e62d6cbd04ce7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214577
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
In order to ease the process of reading and writing any register at current EL,
provide read_current and write_current assembly macros. These are included in
arch/lib_helpers.h under the __ASSEMBLY__ macro condition. This is done to allow
the same header file to be included by .c and .S files.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Compiles successfully for ryu
Change-Id: I678ab89c4aa1b08898166e135b5ab2d6453bb5e8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214576
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add library helpers to access standard arm64 registers. This library also
provides functions to directly read/write register based on current el. So, rest
of the code doesnt need to keep checking the el and call appropriate function
based on that.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Libpayload and depthcharge compile successfully for ryu
Change-Id: I9b63e04aa26a98bbeb34fdef634776d49454ca8d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
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>
