| Age | Commit message (Collapse) | Author |
|---|
|
There is no measurable performance impact, but
this positively impacts the memory used by payloads.
Change-Id: Ib2bdba4a7bf2a4c2391a20b3225bbb44422d3194
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10751
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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.)
Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202563
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b
Reviewed-on: http://review.coreboot.org/8119
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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.
Original-Change-Id: I6e3a75b1a8e46291c75a876844c7a01f7d3f2a0e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/203513
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit d8e5a9fdf583b5ac861f34baea6a16c4d8536512)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I446fef028264c793b946dd9f765e446bf708b4db
Reviewed-on: http://review.coreboot.org/8118
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The calling convention of payload entry function is different by architecture.
For example, X86 takes no arguments and ARM needs first param to be a
cb_header_ptr*.
To help payloads load and execute other payloads easily and correctly, we should
provide the selfboot() function in libpayload, using same prototype as defined
in coreboot environment.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Original-Change-Id: I8f1cb2c0df788794b2f6f7f5500a3910328a4f84
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199503
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 1e916cf021ce68886eb9668982c392eadedc7b7e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7279ef27f49ef581d25a455dd8f1f2f7f1ba58cb
Reviewed-on: http://review.coreboot.org/7907
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
This functionality is already available for ARM, so lets add it to x86 as
well. We'll want to be able to hook exceptions when running as a remote GDB
target.
Change-Id: I42f640b08eb9eb86a1bcab3c327f7780191a2eb5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179601
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5b8cf0c9f70a7e14766a2b095e6739a8d6321a34)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6898
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Upgrade CBFS in libpayload to use new media-based implementation from coreboot
( http://review.coreboot.org/#/c/2182/ ).
Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still
supported, although the recommended way is to use new CBFS API.
To migrate your existing x86 payload source:
- Change cbfs_find to cbfs_get_file
- Change cbfs_find_file to cbfs_get_file_content
- Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument.
Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH);
=> char *jpeg_data = cbfs_get_file_content(
CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH);
The legacy setup_cbfs_from_{ram,flash} is also supported, although the better
equivalent is to make a new media instance:
struct cbfs_media ram_media;
init_cbfs_ram_media(&ram_media, start, size);
char *data = cbfs_get_file_content(&ram_media, "myfile", my_type);
Verified by being successfully linked with filo.
Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2191
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
Change-Id: Ia9170bd3d04e76dbf9321ca7ea4be23b5e468d21
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2033
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
