Read-only mirror of https://review.coreboot.org/coreboot.git. Synced every hour. We don't handle Pull Requests.
https://coreboot.org
- C 93.8%
- ASL 2.2%
- Makefile 1.1%
- C++ 0.5%
- Pawn 0.5%
- Other 1.8%
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
|
||
|---|---|---|
| 3rdparty@a8b0c52850 | ||
| documentation | ||
| payloads | ||
| src | ||
| util | ||
| .gitignore | ||
| .gitmodules | ||
| .gitreview | ||
| COPYING | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
| toolchain.inc | ||
------------------------------------------------------------------------------- coreboot README ------------------------------------------------------------------------------- coreboot is a Free Software project aimed at replacing the proprietary BIOS (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a payload. With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like PC BIOS services or UEFI. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required. coreboot was formerly known as LinuxBIOS. Payloads -------- After the basic initialization of the hardware has been performed, any desired "payload" can be started by coreboot. See http://www.coreboot.org/Payloads for a list of supported payloads. Supported Hardware ------------------ coreboot supports a wide range of chipsets, devices, and mainboards. For details please consult: * http://www.coreboot.org/Supported_Motherboards * http://www.coreboot.org/Supported_Chipsets_and_Devices Build Requirements ------------------ * gcc / g++ * make Optional: * doxygen (for generating/viewing documentation) * iasl (for targets with ACPI support) * gdb (for better debugging facilities on some targets) * ncurses (for 'make menuconfig') * flex and bison (for regenerating parsers) Building coreboot ----------------- Please consult http://www.coreboot.org/Build_HOWTO for details. Testing coreboot Without Modifying Your Hardware ------------------------------------------------ If you want to test coreboot without any risks before you really decide to use it on your hardware, you can use the QEMU system emulator to run coreboot virtually in QEMU. Please see http://www.coreboot.org/QEMU for details. Website and Mailing List ------------------------ Further details on the project, a FAQ, many HOWTOs, news, development guidelines and more can be found on the coreboot website: http://www.coreboot.org You can contact us directly on the coreboot mailing list: http://www.coreboot.org/Mailinglist Copyright and License --------------------- The copyright on coreboot is owned by quite a large number of individual developers and companies. Please check the individual source files for details. coreboot is licensed under the terms of the GNU General Public License (GPL). Some files are licensed under the "GPL (version 2, or any later version)", and some files are licensed under the "GPL, version 2". For some parts, which were derived from other projects, other (GPL-compatible) licenses may apply. Please check the individual source files for details. This makes the resulting coreboot images licensed under the GPL, version 2.