summaryrefslogtreecommitdiff
path: root/payloads/libpayload/arch/arm/Makefile.inc
AgeCommit message (Collapse)Author
2015-01-09libpayload: Add remote GDB supportJulius Werner
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>
2015-01-09libpayload: Introduce new Kconfig to explicitly allow GPL codeJulius Werner
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>
2014-12-30libpayload: Provide selfboot function.Hung-Te Lin
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)
2014-12-30libpayload: arm: Add EABI compatible utility functions.Hung-Te Lin
Some EABI conformant toolchains like GCC need additional functions like raise. To prevent payloads adding arch-specific implementations everywhere, we should provide the default version in libpayload. BUG=none TEST=emerge-nyan libpayload # pass BRANCH=none Original-Change-Id: Id1e3c29590aa5881aefd944a7551949ce9a47b8f Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/199686 (cherry picked from commit 395810c4b744dbb720050f79a2c1a30e81464554) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I2e1d8c8cb519f8e788c22d081132d23b49b8f822 Reviewed-on: http://review.coreboot.org/7906 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-09arm: Thumb ALL the things!Julius Werner
This patch switches every last part of Coreboot on ARM over to Thumb mode: libpayload, the internal libgcc, and assorted assembly files. In combination with the respective depthcharge patch, this will switch to Thumb mode right after the entry point of the bootblock and not switch back to ARM until the final assembly stub that jumps to the kernel. The required changes to make this work include some new headers and Makefile flags to handle assembly files (using the unified syntax and the same helper macros as Linux), modifying our custom-written libgcc code for 64-bit division to support Thumb (removing some stale old files that were never really used for clarity), and flipping the general CFLAGS to Thumb (some more cleanup there as well while I'm at it). BUG=None TEST=Snow and Nyan still boot. Original-Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/182212 Original-Reviewed-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 5f65c17cbfae165a95354146ae79e06c512c2c5a) Conflicts: payloads/libpayload/include/arm/arch/asm.h src/arch/arm/Makefile.inc src/arch/arm/armv7/Makefile.inc *** There is an issue with what to do with ramstage-S-ccopts, and *** will need to be covered in additional ARM cleanup patches. Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/6930 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-29arm: Fix up new cache flush algorithm and replace dcache_*_all() with itJulius Werner
This patch fixes the remaining few bugs in our shiny new cache iteration by set/way/level algorithm to actually make it work: It makes it start from cache level 0 (previously it would always start at LoC and be "done" instantly), fixes up the two shifts that isolate the set bits at the end (which didn't seem to account for the fact that the first shift affects the second), and throws an S bit on that last shift so that it actually affects the conditionals after it. In addition, also moves the next_level block to the top so that we can share (and thus eliminate) some code at initialization, and turns the whole thing into a thrice-instantiated macro to create functions that fit our existing interface. Change-Id: I1338a589cbb37d74ea6e7a3d4f67ff827e24edbe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/183879 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 6d94f8330191c316fe093ddb5288329453da8a4b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6932 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-09-22arm: Update mem* functions to newer versionsJulius Werner
The memcpy/memset/memmove assembly implementations have been taken from U-Boot, which originally got them from Linux. I turns out that they are actually not that bad, but they could use an update. This patch pulls in the current Linux upstream versions of those files, removing some old U-Boot cruft such as checking whether the two pointers in a memcpy() are equal (really now?) or side-stepping the R8 register because it was used for special purposes. It also returns to the good old Linux ENTRY/ENDPROC macros since we have them now anyway, and straightens out the W() macro in preparation for unified thumb support. Change-Id: I138af269b423bef0a237759ac29f1ee58ca206a0 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/182179 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 777127997bde5785b21d422d0b6eb04c4328b478) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6918 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-09-12arm: Remove some pointless CFLAGSJulius Werner
This patch removes the -ffixed-r8 CFLAG from the coreboot and libpayload Makefiles. This seems to be a relic from U-Boot, which uses that register to keep it's global data structure pointer. There's no reason for us to throw away a perfectly fine register on this already pretty constrained architecture. Also removed a config.h inclusion from the Makefile because that should really be done inside the C files. Change-Id: Ia176c0f323c1be07cddf88fa5488788786a27cdf Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177110 Reviewed-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 2a81112abde284ba09020db6afa363169911a7f6) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6880 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-08ARM: Generalize armv7 as arm.Gabe Black
There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)