Commit Graph

163 Commits

Author SHA1 Message Date
Vadim Bendebury 243c614134 lib: add base64 decoder
It became necessary to decode base64 data retrieved from VPD and
convert it into binary for inclusion in the device tree.

The patch introduces the decoder function based on the description
found in http://en.wikipedia.org/wiki/Base64.

An open source implementation from http://base64.sourceforge.net was
considered, in the end the only thing borrowed from it is the table to
translate base64 ascii characters into numbers in 0..63 range.

BRANCH=none
BUG=chromium:450169

TEST=created a test harness generating random contents of random size
     (in 8 to 32766 bytes range), then converting the contents into
     base64 using the Linux utility, and then converting it back to
     binary using this function and comparing the results.

     It succeeded 1700 iterations before it was stopped.

Change-Id: I502f2c9494c99ba95ece37a7220c0c70c4755be2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6609f76e1559d3cdd402276055c99e0de7da27c8
Original-Change-Id: I5ed68af3a4daead50c44ae0f0c63d836f4b66851
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262945
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9892
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-22 08:50:54 +02:00
David Hendricks 6fab365299 gpio: compile gpio.c at all stages
Since gpio.c is more generic now and will be used in various
stages (ie for board_id()), compile it for all stages.

BUG=none
BRANCH=none
TEST=compiled for peppy and veyron_pinky

Change-Id: Ib5c73f68db92791dd6b42369f681f9159b7e1c22
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ef4e40ccf6510d63c4a54451bdfea8da695e387e
Original-Change-Id: I77ec56a77e75e602e8b9406524d36a8f69ce9128
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228325
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9414
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
2015-04-10 12:00:25 +02:00
David Hendricks 3b11de80a4 gpio: decouple tristate gpio support from board ID
This deprecates TERTIARY_BOARD_ID. Instead, a board will set
BOARD_ID_SUPPORT (the ones affected already do) which will set
GENERIC_GPIO_SUPPORT and compile the generic GPIO library.
The user is expected to handle the details of how the ID is encoded.

BUG=none
BRANCH=none
TEST=Compiled for peppy, nyan*, storm, and pinky

Change-Id: Iaf1cac6e90b6c931100e9d1b6735684fac86b8a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93db63f419f596160ce2459eb70b3218cc83c09e
Original-Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228322
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9413
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10 11:59:34 +02:00
David Hendricks 3fc6368e1c gpio: cosmetic changes to tristate_gpios.c
This patch makes a few cosmetic changes:
- Rename tristate_gpios.c to gpio.c since it will soon be used for
  binary GPIOs as well.
- Rename gpio_get_tristates() to gpio_base3_value() - The binary
  version will be called gpio_base2_value().
- Updates call sites.
- Change the variable name "id" to something more generic.

BUG=none
BRANCH=none
TEST=compiled for veyron_pinky and storm

Change-Id: Iab7e32f4e9d70853f782695cfe6842accff1df64
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c47d0f33ea1a6e9515211b834009cf47a171953f
Original-Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228324
Reviewed-on: http://review.coreboot.org/9411
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-10 11:59:25 +02:00
Aaron Durbin e5e36306a9 timer: Add generic udelay() implementation
Add GENERIC_UDELAY Kconfig option so that a generic
udelay() implementation is provided utilizing the
monotonic timer. That way each board/chipset doesn't
need to duplicate the same udelay(). Additionally,
assume that GENERIC_UDELAY implies init_timer()
is not required.

BUG=None
BRANCH=None
TEST=Built nyan, ryu, and rambi. May need help testing.

Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed
Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219719
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-08 18:35:01 +02:00
Aaron Durbin 04de97113a rmodules: fix linking
In commit ec5e5e0d the rmodules linking flags were dropped.
This resulted in relocations being removed from the ELF file.
The relocation information is quite valuable when needing to
perform relocations at runtime.

Change-Id: I699477eb023fc6132e03699992dcf81a311d2d48
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9374
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
2015-04-07 23:01:40 +02:00
Julius Werner ec5e5e0db2 New mechanism to define SRAM/memory map with automatic bounds checking
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.

The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).

BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.

Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-04-06 22:05:01 +02:00
Patrick Georgi 828e0e86f3 build system: run linker scripts through the preprocessor
This allows combining and simplifying linker scripts.

This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.

Change-Id: Ie5c11bd8495a399561cefde2f3e8dd300f4feb98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-06 19:14:00 +02:00
Aaron Durbin b3847e6424 program loading: add prog_run() function
The prog_run() function abstracts away what is required
for running a given program. Within it, there are 2
calls: 1. platform_prog_run() and 2. arch_prog_run().
The platform_prog_run() allows for a chipset to intercept
a program that will be run. This allows for CPU switching
as currently needed in t124 and t132.

Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8846
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-04-03 14:52:47 +02:00
Furquan Shaikh abde3b56ce arm64: Add support for secure monitor
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.

CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu

Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34
Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214371
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9080
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-28 07:05:09 +01:00
Ionela Voinescu 00903e5fc0 cbfs/rmodule: add architecture specific operations at stage load
Two weak functions were added so that architecture specific operations
on each segment of payload or stage can be performed.
Each architecture must define its own operations, otherwise the
behavior will default to do-nothing functions.

This patch has been updated by to fit more in line with
how program loading is currently being done. The API is the
same as the original, but all call sites to stages/payloads
have been updated. This is known to break any archs that use
rmodule loading that needs cache maintenance. That will be fixed
in a forthcoming patch. Also, the vboot paths are left as is
for easier upstreaming of the rest of the vboot patches.

Original-Change-Id: Ie29e7f9027dd430c8b4dde9848fa3413c5dbfbfa
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/239881
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit c82c21ce87a4c02bd9219548a4226a58e77beef0)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>

Change-Id: Ifcee5cd9ac5dbca991556296eb5e170b47b77af7
Reviewed-on: http://review.coreboot.org/8837
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-27 19:35:58 +01:00
Daisuke Nojiri 5799097be5 vboot2: read secdata and nvdata
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.

The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.

TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>

(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)

Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-23 19:51:47 +01:00
Vadim Bendebury b0c302fd79 Publish the board ID value in coreboot table, when configured
Board ID value is usually of interest to bootloaders. Instead of
duplicating the board ID discovery code in different bootloaders let's
determine it in coreboot and publish it through coreboot table, when
configured.

BUG=chrome-os-partner:30489
TEST=none yet

Change-Id: Ia1e36b907ac15b0aafce0711f827cb83622e27bb
Original-Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210116
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit b2057a02db9391e2085b138eea843e6bb09d3ea2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8719
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-23 17:20:13 +01:00
Vadim Bendebury 9c9c336464 Generalize revision number calculation function
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are

- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)

This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.

This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.

The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.

Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.

BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.

Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d
Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209673
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8717
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-23 17:20:04 +01:00
Vadim Bendebury 3486d1fbe8 verstage should include the CBFS SPI wrapper, when configured
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER
configuration option enabled, so the verstage is missing the relevant
files in some Makefiles. This patch fixes the problem.

BRANCH=none
BUG=none
TEST=with the rest of the patches applied cosmos target builds fine
     with COMMON_CBFS_SPI_WRAPPER enabled

Change-Id: I3ce78c8afc5f7d8ce822bbf8dd789c0c2ba4b99c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b72693c96f7d8ce94ce6fe12b316d5b88fded579
Original-Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223751
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8772
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-03-20 16:04:52 +01:00
Aaron Durbin f69a99dbf8 coreboot: x86: enable gc-sections
Garbage collected sections allow for trimming the size of the
binaries as well as allowing for not needing to config off
unused functions. To that end, on a rambi build the following
differences are observed:

$ diff -up \
	<(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \
	<(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf)
--- /dev/fd/63  2015-03-10 12:07:27.927985430 -0500
+++ /dev/fd/62  2015-03-10 12:07:27.927985430 -0500
@@ -6,9 +6,9 @@ There are 4 program headers, starting at
 Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
Align
   LOAD           0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0
-  LOAD           0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0
-  LOAD           0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0
-  LOAD           0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560     0
+  LOAD           0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0
+  LOAD           0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0
+  LOAD           0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888     0

  Section to Segment mapping:
   Segment Sections...

$ diff -up \
	<(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \
	<(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf)
--- /dev/fd/63  2015-03-10 12:08:16.855985880 -0500
+++ /dev/fd/62  2015-03-10 12:08:16.851985880 -0500
@@ -5,8 +5,8 @@ There are 1 program headers, starting at

 Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
Align
-  LOAD           0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E
   0x10
+  LOAD           0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E
0x10

  Section to Segment mapping:
   Segment Sections...
-   00     .rom .text
+   00     .rom

The following warnings needed to be applied to CFLAGS_common because for
some reason gcc was miraculously emitting the warnings with the
unrelated *-sections options:
  -Wno-unused-but-set-variable

Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8635
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-17 14:35:31 +01:00
Kyösti Mälkki ae98e83eb2 CBMEM: Always use DYNAMIC_CBMEM
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.

Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-27 22:54:32 +01:00
Kyösti Mälkki 8659e4072e CBMEM console: Fix and enhance pre-RAM support
Use the value of CONSOLE_PRERAM_BUFFER_SIZE to determine if we can
do CBMEM console in bootblock and romstage. Kconfig forces it to zero
if _BASE is unset or we cannot do CAR migration on x86.

Add CBMEM console to bootblock, except for x86. Only one of bootblock
and romstage clears the pre-RAM buffer.

To start with empty console log on S3 wakeup, ramstage now clears
previous contents of CBMEM buffer if there was no pre-RAM buffer.

Unify Kconfig variable naming.

TODO: ARM configurations do not define PRERAM_BUFFER_BASE values.

Change-Id: I70d82da629529dbfd7bc9491223abd703cbc0115
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-27 22:44:17 +01:00
Daisuke Nojiri bcc1d422a2 vboot2: implement select_firmware for pre-romstage verification
This patch has a basic structure of vboot2 integration. It supports only Nyans,
which have bootblock architecture and romstage architecture are
compatible from linker's perspective.

TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>

Original-Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa
Original-Reviewed-on: https://chromium-review.googlesource.com/204522
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit a6bce0cbed34def60386f3d9aece59e739740c58)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: I63ddfbf463c8a83120828ec8ab994f8146f90001
Reviewed-on: http://review.coreboot.org/8160
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
2015-01-27 01:43:01 +01:00
David Hendricks 560c643e32 Primitive memory test
This adds a generic primitive memory test. We should look into
using tests in src/lib/ramtest.c, but they seem to rely too heavily
on x86 asm and this test has been useful on multiple ARM platforms.

BUG=none
BRANCH=none
TEST=builds and runs on nyan
Signed-off-by: David Hendricks <dhendrix@chromium.org>

Original-Change-Id: Ia0fb4e12bc59bf708be13faf63c346b531eb3aed
Original-Reviewed-on: https://chromium-review.googlesource.com/186309
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit e7625c15415eaf6053ce32b67d9d6ab18d776f5f)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Conflicts:
	src/lib/Makefile.inc

Change-Id: I34e7aedfd167199fd5db4cd4a766b2b80ddda79b
Reviewed-on: http://review.coreboot.org/8150
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2015-01-09 16:50:55 +01:00
Kyösti Mälkki de53bdf569 CBMEM: Rename utility file
This file will have CBMEM init hooks API one day.

Change-Id: I0c31495d4217a5eb235b13e6d8e8c99a87a3b840
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8031
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-07 06:09:42 +01:00
Vadim Bendebury adcb095e9e Provide a common CBFS wrapper for SPI storage
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.

COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.

init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.

BUG=none
TEST=manual
   . with this change and the rest of the patches coreboot on AP148
     comes up all the way to attempting to boot the payload (reading
     earlier stages from the SPI flash along the way).

Original-Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197800
Original-Tested-by: Vadim Bendebury <vbendeb@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 60eb16ebe624f9420c6191afa6ba239b8e83a6e6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: I7b0bf3dda915c227659ab62743e405312dedaf41
Reviewed-on: http://review.coreboot.org/7932
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-12-30 19:29:47 +01:00
Kyösti Mälkki 87accccdc2 CBMEM: Always build for x86 romstage
Always build CBMEM for romstage, even for boards that will not use it.
We further restrict car_migrate_variables() runs to non-ROMCC boards without
BROKEN_CAR_MIGRATE.

This fixes regression of commit 71b21455 that broke CBMEM console support
for boards with a combination of !EARLY_CBMEM_INIT && !HAVE_ACPI_RESUME.

Change-Id: Ife91d7baebdc9bd1e086896400059a165d3aa90f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7877
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-12-30 17:47:22 +01:00
Kyösti Mälkki c7c02673e4 RELOCATABLE_RAMSTAGE: Fix weak symbols with ramstage_cache
We had NULL reference with cache_loaded_ramstage() if
CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM was not set so boot never
proceeded to ramstage.

Cache implementation outside CBMEM provides means for platform-specific
location so there is no need of weak attributes here.

Change-Id: I1eb1a713896395c424fde23252c374f9065fe74d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7954
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-12-28 19:56:58 +01:00
Patrick Georgi 6d0cba7978 gcc.c: Test for gcc, not for non-clang
This is gcc specific, not necessary-everywhere-but-on-clang.

Change-Id: Ie02587bd41c856cbf730ea2f72f594a20b5fefbe
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7609
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-30 12:20:37 +01:00
Patrick Georgi 1b2f2a0714 Introduce halt()
It's a portable and generic way to halt the system.
Useful when waiting for the platform to reset.

Change-Id: Ie07f3333d294a4d3e982cbc2ab9014c94b39fce0
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7605
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-30 12:20:05 +01:00
Patrick Georgi 95948934e7 build system: unify linker use across gcc and clang
Let's just call ld directly for gcc, too.

Change-Id: I305eb92ed0d21b098134a7eb5a9f9fe3b126aeea
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7553
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-25 08:47:41 +01:00
Patrick Georgi 3ce96bd49c build system: use a single variable name for compiler runtimes
We build with either gcc or clang, no need to keep both around

Change-Id: I9af2cc7636bdc791a68ba8ed6e7c5a81973c5dfd
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7552
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-25 08:47:38 +01:00
Kyösti Mälkki c36af7b00a Replace includes of build.h with version.h
As build.h is an auto-generated file it was necessary to add it as
an explicit prerequisite in the Makefiles. When this was forgotten
abuild would sometimes fail with following error:

   fatal error: build.h: No such file or directory

Fix this error by compiling version.c into all stages.

Change-Id: I342f341077cc7496aed279b00baaa957aa2af0db
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7510
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-20 07:28:37 +01:00
Edward O'Callaghan cd31afdc3c lib/lzma.c: Use header over .c include
Change-Id: I904eb1703eaf4f8de1b4ec443173686c7985be12
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7427
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
2014-11-19 00:13:44 +01:00
Edward O'Callaghan cdabc880e1 lib/cbfs: Use linker symbols over .c include in cbfs.c
Change-Id: Ieb7f383c84401aab87adc833deebf289cd0c9a0f
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7426
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-11-19 00:13:26 +01:00
Edward O'Callaghan 5b5db8794f src/lib/Makefile.inc: Allow rmodules to link under Clang
rmodules were getting linked with libgcc and not libcompiler-rt.
Unfortunately this is pretty ugly however we do this else where
in the build system so its consistently ugly. The build system
will later need a unification pass between compilers once we are
tree stable on Clang.

Change-Id: I380f7386de2c5adfa9036311323ad9f703b6e712
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7440
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-11-12 18:13:57 +01:00
Isaac Christensen 0b4e8df7e8 reg_script: include in romstage
The new broadwell support uses the reg_script functions in romstage.

Change-Id: Ic040bf947d35854711f4c1547858b0e4378ef759
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7003
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-10-22 03:58:40 +02:00
Stefan Reinauer 3905e3d47c delay: Have mdelay() / delay() available in romstage, too
Some drivers (like the I2C TPM driver) call mdelay instead of
udelay. While it's a shame that these chips are so slow, the
overhead of having those functions available in romstage is
minimal.

Signed-off-by: Stefan Reinauer <reinauer@google.com>

Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792
Reviewed-on: https://chromium-review.googlesource.com/167542
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 7083b6b843d803bd4ddbd8a5aaf9c5c05bad2044)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6531
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-25 19:02:18 +02:00
Furquan Shaikh 133096b6dc coreboot classes: Add dynamic classes to coreboot
Provide functionality to create dynamic classes based on program name and
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class. Also, compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.

One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.

Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/6426
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-08-11 15:42:20 +02:00
Edward O'Callaghan 9b229858b2 lib/Makefile.inc: Stop gcc.c getting into SMM clang builds
The libgcc runtime workarounds found in gcc.c are not needed for
compiler-rt used by the Clang toolchain. Stop gcc.c from sneaking into
Clang builds while processing boards that use SMM code.

Change-Id: I51e8d517784721d28b4d951bd0bebc8b52682a8e
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6121
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2014-06-27 17:11:19 +02:00
Edward O'Callaghan 4ba8ba4654 build: Drop libgcc runtime wrapper in Clang builds
This GCC specific workaround of wrapping of libgcc runtime symbols with
gcc.c is not nessary with libcompiler-rt linkage.

Change-Id: I50a2bc99d97f68a2ad2b51a92ea0e7086bab35fe
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5812
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-06-06 01:45:20 +02:00
Furquan Shaikh 99ac98f7e1 Introduce stage-specific architecture for coreboot
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.

These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.

In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.

Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.

We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.

Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-05-06 20:23:31 +02:00
Kyösti Mälkki 5687fc9d21 Declare recovery and developer modes outside ChromeOS
Move the implementation for recovery and developer modes from
vendorcode/google/chromes to lib/.

Change-Id: I33335fb282de2c7bc613dc58d6912c47f3b5c06c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4308
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-05-01 15:38:41 +02:00
Kyösti Mälkki deb2cb27e9 Static CBMEM / CAR: Flag boards with BROKEN_CAR_MIGRATE
Use of CAR_GLOBAL is not safe after CAR is torn down, unless the
board properly implements EARLY_CBMEM_INIT.

Flag vulnerable boards that only do cbmem_recovery() in romstage on S3
resume and implementation with Intel FSP that invalidates cache before
we have a chance to copy the contents.

Change-Id: Iecd10dee9b73ab3f1f66826950fa0945675ff39f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5419
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-04-01 11:36:00 +02:00
Aaron Durbin 3eb8eb7eba rmodules: use rmodtool to create rmodules
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.

Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.

Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
2014-03-20 23:55:55 +01:00
Duncan Laurie 7274800ea3 Add a generic register script handler
This is based on the RCBA configuration setup from haswell.
It handles PCI, BARs, IO, MMIO, and baytrail-specific IOSF.
I did not extend it to handle MSR yet but that would be another
potential register type.

There are a number of approaches to this kind of thing, but in the
end they have a lot of switch statements and a mass of #defines.
I'm not particularly set on any of the details so comments welcome.

BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=emerge-rambi chromeos-coreboot-rambi

Change-Id: Ib873936ecf20fc996a8feeb72b9d04ddb523211f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175206
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4923
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-04 16:31:14 +01:00
Kyösti Mälkki bea6bf07df uart8250: Move under drivers/uart
Change-Id: Ic65ffaaa092330ed68d891e4a09a8b86cdc04a3a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5236
Tested-by: build bot (Jenkins)
2014-03-04 15:34:27 +01:00
Aaron Durbin 4904802efc coreboot: introduce notion of bootmem for memory map at boot
The write_coreboot_table() in coreboot_table.c was already using
struct memrange for managing and building up the entries that
eventually go into the lb_memory table. Abstract that concept
out to a bootmem memory map. The bootmem concept can then be
used as a basis for loading payloads, for example.

Change-Id: I7edbbca6bbd0568f658fde39ca93b126cab88367
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5302
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-03 21:47:27 +01:00
Aaron Durbin 0f333071ef coreboot: infrastructure for different ramstage loaders
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.

To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.

Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-02-15 18:39:29 +01:00
Kyösti Mälkki 207379db12 ne2k: Move under drivers/net
Change-Id: I978b6009c09c31be4429f57be40ef82f438f7574
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-06 11:14:50 +01:00
Kyösti Mälkki 5148642c56 spkmodem: Move under drivers/pc80
Change-Id: I46eb17ab19cea8759b3e4822019285cbe907e83a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5134
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2014-02-06 11:14:24 +01:00
Kyösti Mälkki e2227a23a7 usbdebug: Move under drivers/usb
Also relocate and split header files, there is some interest
for EHCI debug support without PCI.

Change-Id: Ibe91730eb72dfe0634fb38bdd184043495e2fb08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-02-06 11:13:57 +01:00
Aaron Durbin 75e297428f coreboot: config to cache ramstage outside CBMEM
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.

BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
     falco successfully.

Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-30 06:04:02 +01:00
Alexandru Gagniuc af4bd599ca lib: Make log2() available in romstage on ARM, not just x86
On x86, log2() is defined as an inline function in arch/io.h. This is
a remnant of ROMCC, and forced us to not include clog2.c in romstage.
As a result, romstage on ARM has no log2().
Use the inline log2 only with ROMCC, but otherwise, use the one in
clog2.c.

Change-Id: Ifef2aa0a7b5a1db071a66f2eec0be421b8b2a56d
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-13 04:03:06 +01:00
Stefan Reinauer 2f38b07570 Add simple hexdump function
- prints hex and ascii
 - detects duplicate all zero lines

Change-Id: I557fed34f0f50ae256a019cf893004a0d6cbff7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62655
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4392
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21 08:25:44 +01:00
Kyösti Mälkki ce22cd066b Fix build with USE_OPTION_TABLE
Parallelized build might try to build SMM before option_table.h is
created. Remove related redundant explicit rules.

Change-Id: Ida8b5c408af05adcf3210ce7bfc8a1e5959194c7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4299
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-12-01 23:15:08 +01:00
Kyösti Mälkki ac16405799 usbdebug: Fix boards without EARLY_CBMEM_INIT
The main usbdebug file lib/usbdebug.c was removed from romstage
build with commit f8bf5a10 but the chipset-specific parts were not,
leading to unresolved symbol errors for AMD platforms.

Add a silent Kconfig variable USBDEBUG_IN_ROMSTAGE for convenient
use of this feature.

Change-Id: I0cd3fccf2612cf08497aa5c3750c89bf43ff69be
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3983
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-10-22 21:35:05 +02:00
Kyösti Mälkki f8bf5a10c5 Revert "CBMEM: Always have early initialisation"
This reverts commit de1fe7f655.

While things appeared to work, there were actually invalid references
to CAR storage after CAR was torn down on boards without
EARLY_CBMEM_INIT. It was discussed use of CAR_GLOBAL should be
restricted to boards that handle CAR migration properly.

Change-Id: I9969d2ea79c334a7f95a0dbb7c78065720e6ccae
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3968
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-10-14 17:16:22 +02:00
Kyösti Mälkki de1fe7f655 CBMEM: Always have early initialisation
Assume EARLY_CBMEM_INIT=y everywhere and remove option from Kconfig.

If romstage does not make the cbmem_initialize() call, features like
COLLECT_TIMESTAMPS and early CBMEM_CONSOLE will execute during
romstage, but that data will get lost as no CAR migration is
executed.

Change-Id: I5615645ed0f5fd78fbc372cf5c3da71a3134dd85
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3917
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-21 06:26:54 +02:00
Kyösti Mälkki a2f6af3330 ROMCC boards: Fix builds with CBMEM console, timestamps or usbdebug
These features depend on CAR_GLOBAL region, which is not available
when romstage is built with ROMCC. Exclude these from romstage, keep
them available for ramstage.

A follow-up patch will fix the dependencies and allows enabling these
features in menuconfig.

Change-Id: I9de5ad41ea733655a3fbdc734646f818e39cc471
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3919
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-09-21 06:22:33 +02:00
Kyösti Mälkki 93b2bd70ff usbdebug: Do not support logging from SMM
Letting SMI handler touch EHCI controller is an excellent source
of USB problems. Remove usbdebug entirely from SMM.

It may be possible to make usbdebug console work from SMM
after hard work and coordination with payloads and even
OS drivers. But we are not there.

Change-Id: Id50586758ee06e8d76e682dc6f64f756ab5b79f5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3858
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
2013-08-23 05:05:34 +02:00
Andrew Wu eabfd3a7c1 Don't include LZMA in romstage if ramstage is not compressed.
If ramstage is not compressed, the CBFS module in romstage doesn't
need to support LZMA. Removing the LZMA module in this case can save
about 3000 bytes in romstage.

Change-Id: Id6f7869e32979080e2985c07029edcb39eee9106
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3878
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-19 21:05:44 +02:00
Gabe Black c6b44162f5 CBFS: Use memmove instead of memcpy when loading a file from CBFS.
It might be the case that a file is being loaded from a portion of CBFS which
has already been loaded into a limitted bit of memory somewhere, and we want
to load that file in place, effectively, so that it's original location in
CBFS overlaps with its new location. That's only guaranteed to work if you use
memmove instead of memcpy.

Change-Id: Id550138c875907749fff05f330fcd2fb5f9ed924
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3577
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-15 18:53:37 +02:00
Gabe Black 545c0caac8 Add a HAVE_ARCH_MEMMOVE option to allow overriding memmove.
Change-Id: I4b6a57e7d8e7e685c609b1d85368585b9dd197dc
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3761
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-14 20:33:58 +02:00
Denis 'GNUtoo' Carikli 8a0a8488fe Dynamic cbmem: don't compile src/lib/cbmem.c when dynamic cbmem is selected.
src/lib/cbmem.c is for the static cbmem.

Thanks to adurbin for the Makefile.inc pointer and code on #coreboot IRC channel on freenode:
  <adurbin> no. if you have CONFIG_DYNAMIC_CBMEM then cbmem.c shouldn't be compiled
  [...]
  <adurbin> +ifeq ($(CONFIG_EARLY_CBMEM_INIT),y)
  <adurbin> +ifneq ($(CONFIG_DYNAMIC_CBMEM),y) romstage-$(CONFIG_EARLY_CBMEM_INIT) += cbmem.c
  <adurbin> +endif
  <adurbin> +endif

Without that fix we have:
  src/lib/cbmem.c:58:43: error: no previous prototype for 'get_cbmem_toc' [-Werror=missing-prototypes]
  src/lib/cbmem.c:76:6: error: no previous prototype for 'cbmem_init' [-Werror=missing-prototypes]
  src/lib/cbmem.c:107:5: error: no previous prototype for 'cbmem_reinit' [-Werror=missing-prototypes]

This commit was tested on qemu-i440fx with the following commit:
  qemu-i440fx: Make it compile with CONFIG_DYNAMIC_CBMEM
  ( http://review.coreboot.org/#/c/3504/ ).

Change-Id: I98636aad4bb4b954f3ed3957df67c77f3615964a
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3503
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
2013-06-21 19:29:52 +02:00
Aaron Durbin 4409a5eef6 coreboot: add thread cooperative multitasking
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c).  All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.

The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.

Note that the intention on when to yield a thread will be on
calls to udelay().

Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-14 05:18:47 +02:00
Aaron Durbin 340ca91f18 coreboot: add timer queue implementation
A timer queue provides the mechanism for calling functions
in the future by way of a callback. It utilizes the MONOTONIC_TIMER
to track time through the boot. The implementation is a min-heap
for keeping track of the next-to-expire callback.

Change-Id: Ia56bab8444cd6177b051752342f53b53d5f6afc1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3158
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01 07:19:12 +02:00
Vladimir Serbinenko 45988dab6b spkmodem console
Change-Id: Ie497e4c8da05001ffe67c4a541bd24aa859ac0e2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2987
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-18 22:47:59 +02:00
Aaron Durbin a05a8522ce lib: add memrange infrastructure
The memrange infrastructure allows for keeping track of the
machine's physical address space. Each memory_range entry in
a memory_ranges structure can be tagged with an arbitrary value.
It supports merging and deleting ranges as well as filling in
holes in the address space with a particular tag.

The memrange infrastructure will serve as a shared implementation
for address tracking by the MTRR and coreboot mem table code.

Change-Id: Id5bea9d2a419114fca55c59af0fdca063551110e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2888
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29 19:55:48 +01:00
Aaron Durbin c15551ab08 dynamic cbmem: fix memconsole and timestamps
There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM
rely on EARLY_CBMEM_INIT. This isn't true in the face of
DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT.
Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM
when DYNAMIC_CBMEM is selected.  Lastly, don't hard code the cbmem
implementation when COLLECT_TIMESTAMPS is selected.

Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23 19:44:25 +01:00
Stefan Reinauer 3e4e303858 Unify coreboot table generation
coreboot tables are, unlike general system tables, a platform
independent concept. Hence, use the same code for coreboot table
generation on all platforms. lib/coreboot_tables.c is based
on the x86 version of the file, because some important fixes
were missed on the ARMv7 version lately.

Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d
Signed-off-by: Stefan Reinauer <reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2863
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
2013-03-22 00:17:55 +01:00
Aaron Durbin df3a109b72 cbmem: dynamic cbmem support
This patch adds a parallel implementation of cbmem that supports
dynamic sizing. The original implementation relied on reserving
a fixed-size block of memory for adding cbmem entries. In order to
allow for more flexibility for adding cbmem allocations the dynamic
cbmem infrastructure was developed as an alternative to the fixed block
approach. Also, the amount of memory to reserve for cbmem allocations
does not need to be known prior to the first allocation.

The dynamic cbmem code implements the same API as the existing cbmem
code except for cbmem_init() and cbmem_reinit(). The add and find
routines behave the same way. The dynamic cbmem infrastructure
uses a top down allocator that starts allocating from a board/chipset
defined function cbmem_top(). A root pointer lives just below
cbmem_top(). In turn that pointer points to the root block which
contains the entries for all the large alloctations. The corresponding
block for each large allocation falls just below the previous entry.

It should be noted that this implementation rounds all allocations
up to a 4096 byte granularity. Though a packing allocator could
be written for small allocations it was deemed OK to just fragment
the memory as there shouldn't be that many small allocations. The
result is less code with a tradeoff of some wasted memory.

           +----------------------+ <- cbmem_top()
  |   +----|   root pointer       |
  |   |    +----------------------+
  |   |    |                      |--------+
  |   +--->|   root block         |-----+  |
  |        +----------------------+     |  |
  |        |                      |     |  |
  |        |                      |     |  |
  |        |   alloc N            |<----+  |
  |        +----------------------+        |
  |        |                      |        |
  |        |                      |        |
 \|/       |   alloc N + 1        |<-------+
  v        +----------------------+

In addition to preserving the previous cbmem API, the dynamic
cbmem API allows for removing blocks from cbmem. This allows for
the boot process to allocate memory that can be discarded after
it's been used for performing more complex boot tasks in romstage.

In order to plumb this support in there were some issues to work
around regarding writing of coreboot tables. There were a few
assumptions to how cbmem was layed out which dictated some ifdef
guarding and other runtime checks so as not to incorrectly
tag the e820 and coreboot memory tables.

The example shown below is using dynamic cbmem infrastructure.
The reserved memory for cbmem is less than 512KiB.

coreboot memory table:
 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
 1. 0000000000001000-000000000002ffff: RAM
 2. 0000000000030000-000000000003ffff: RESERVED
 3. 0000000000040000-000000000009ffff: RAM
 4. 00000000000a0000-00000000000fffff: RESERVED
 5. 0000000000100000-0000000000efffff: RAM
 6. 0000000000f00000-0000000000ffffff: RESERVED
 7. 0000000001000000-000000007bf80fff: RAM
 8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES
 9. 000000007c000000-000000007e9fffff: RESERVED
10. 00000000f0000000-00000000f3ffffff: RESERVED
11. 00000000fed10000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-00000001005fffff: RAM
Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf
coreboot table: 948 bytes.
CBMEM ROOT  0. 7bfff000 00001000
MRC DATA    1. 7bffe000 00001000
ROMSTAGE    2. 7bffd000 00001000
TIME STAMP  3. 7bffc000 00001000
ROMSTG STCK 4. 7bff7000 00005000
CONSOLE     5. 7bfe7000 00010000
VBOOT       6. 7bfe6000 00001000
RAMSTAGE    7. 7bf98000 0004e000
GDT         8. 7bf97000 00001000
ACPI        9. 7bf8b000 0000c000
ACPI GNVS  10. 7bf8a000 00001000
SMBIOS     11. 7bf89000 00001000
COREBOOT   12. 7bf81000 00008000

And the corresponding e820 entries:
BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16
BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable
BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved
BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable
BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable
BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved
BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable
BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16
BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved
BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved
BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable

Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2848
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21 23:24:19 +01:00
Aaron Durbin 2b7c88f99e rmodule: add string functions to rmodules class
The standard string functions memcmp(), memset(), and memcpy()
are needed by most programs. The rmodules class provides a way to
build objects for the rmodules class. Those programs most likely need
the string functions. Therefore provide those standard functions to
be used by any generic rmodule program.

Change-Id: I2737633f03894d54229c7fa7250c818bf78ee4b7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2821
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21 23:14:04 +01:00
Aaron Durbin 8e4a355773 coreboot: introduce CONFIG_RELOCATABLE_RAMSTAGE
This patch adds an option to build the ramstage as a reloctable binary.
It uses the rmodule library for the relocation. The main changes
consist of the following:

1. The ramstage is loaded just under the cmbem space.
2. Payloads cannot be loaded over where ramstage is loaded. If a payload
   is attempted to load where the relocatable ramstage resides the load
   is aborted.
3. The memory occupied by the ramstage is reserved from the OS's usage
   using the romstage_handoff structure stored in cbmem. This region is
   communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem.
4. There is no need to reserve cbmem space for the OS controlled memory for
   the resume path because the ramsage region has been reserved in #3.
5. Since no memory needs to be preserved in the wake path, the loading
   and begin of execution of a elf payload is straight forward.

Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2792
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-03-21 22:28:28 +01:00
Ronald G. Minnich b3b72f350e link/graphics: Add support for EDID
This code is taken from an EDID reader written at Red Hat.

The key function is
int decode_edid(unsigned char *edid, int size, struct edid *out)

Which takes a pointer to an EDID blob, and a size, and decodes it into
a machine-independent format in out, which may be used for driving
chipsets. The EDID blob might come for IO, or a compiled-in EDID
BLOB, or CBFS.

Also included are the changes needed to use the EDID code on Link.

Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-20 05:35:50 +01:00
Aaron Durbin ad93552b86 lib: add rmodule support
A rmodule is short for relocation module. Relocaiton modules are
standalone programs. These programs are linked at address 0 as a shared
object with a special linker script that maintains the relocation
entries for the object. These modules can then be embedded as a raw
binary (objcopy -O binary) to be loaded at any location desired.

Initially, the only arch support is for x86. All comments below apply to
x86 specific properties.

The intial user of this support would be for SMM handlers since those
handlers sometimes need to be located at a dynamic address (e.g. TSEG
region).

The relocation entries are currently Elf32_Rel. They are 8 bytes large,
and the entries are not necessarily in sorted order. An future
optimization would be to have a tool convert the unsorted relocations
into just sorted offsets. This would reduce the size of the blob
produced after being processed. Essentialy, 8 bytes per relocation meta
entry would reduce to 4 bytes.

Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2692
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18 18:40:34 +01:00
David Hendricks ae0e8d3613 Eliminate do_div().
This eliminates the use of do_div() in favor of using libgcc
functions.

This was tested by building and booting on Google Snow (ARMv7)
and Qemu (x86). printk()s which use division in vtxprintf() look good.

Change-Id: Icad001d84a3c05bfbf77098f3d644816280b4a4d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2606
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-08 23:14:26 +01:00
Kyösti Mälkki d59fc5340e Fix build by adding `cbmem.c` to `COLLECT_TIMESTAMPS`
A board without HAVE_ACPI_RESUME did not build with
COLLECT_TIMESTAMPS enabled as `cbmem.c` was not built.

Change-Id: I9c8b575d445ac566a2ec533d73080bcccc3dfbca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2549
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-07 00:49:03 +01:00
Paul Menzel a46a712610 GPLv2 notice: Unify all files to just use one space in »MA 02110-1301«
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.

The following command was used to convert all files.

    $ git grep -l 'MA  02' | xargs sed -i 's/MA  02/MA 02/'

[1] http://www.gnu.org/licenses/gpl-2.0.txt

Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-03-01 10:16:08 +01:00
Hung-Te Lin fe18792a08 armv7: Add 'bootblock' build class.
For ARM platform, the bootblock may need more C source files to initialize
UART / SPI for loading romstage. To preventing making complex and implicit
dependency by using #include inside bootblock.c, we should add a new build class
"bootblock".

Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled
for boot block.

For x86, the bootblock is limited to fewer assembly files so it's not using this
class. (Some files shared by x86 and arm in top level or lib are also changed
but nothing should be changed in x86 build process.)

Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2013-02-03 05:45:48 +01:00
Stefan Reinauer d37ab454d4 Implement GCC code coverage analysis
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.

See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.

To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.

For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/

Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-12 19:09:55 +01:00
Stefan Reinauer 4c4dd93be7 Only include libgcc wrappers on x86
ARM does not need them, and they're causing trouble

Change-Id: I6c70a52c68fdcdbf211217d30c96e1c2877c7f90
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2009
Tested-by: build bot (Jenkins)
2012-12-08 03:52:53 +01:00
Stefan Reinauer 1e753294c4 Drop boot directory
It only has two files, move them to src/lib

Change-Id: I17943db4c455aa3a934db1cf56e56e89c009679f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1959
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2012-11-30 21:56:33 +01:00
Stefan Reinauer 179206a1ac src/lib/Makefile.inc: Add license header
Change-Id: If8bce4ebde9101ac9087fcbd43adc0e08c26352d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/1957
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-30 21:34:38 +01:00
Patrick Georgi 23f38cd05c Get rid of drivers class
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.

These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.

With ramstage.a gone, we can drop this special class, too.

Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-11-27 22:00:49 +01:00
Duncan Laurie f5e9ac48c6 SMM: Add support for malloc in SMM if using TSEG
This is used by the SPI driver and ELOG.

It requires SMM TSEG and a _heap/_eheap region defined in the
linker script.  The first time malloc is called in SMM the
start and end pointers to the heap region will be relocated
for the TSEG region.

Enable SPI flash and ELOG in SMM and successfully
allocate memory.  The allocated addresses are verified
to be sure they are within the TSEG heap region:

smm.elf:00014000 B _eheap
smm.elf:00010000 B _heap
TSEG base is 0xad000000

Memory allocated in ELOG:
ELOG: MEM @0xad018030

Change-Id: I5cca38e4888d597cbbfcd9983cd6a7ae3600c2a3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1312
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24 23:44:19 +02:00
Ronald G. Minnich 9764d4c690 Implement stack overflow checking for the BSP
Previous patches implemented stack overflow checking for the APs.
This patch builds on the BSP stack poisoning patch to implement
stack overflow checking for the BSP, and also prints out maximum
stack usage. It reveals that our 32K stack is ridiculously oversized,
especially now that the lzma decoder doesn't use a giant 16K on-stack
array.

Break the stack checking out into a separate function, which
we will later use for the APs.

CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8

To test failure, change the DEADBEEF stack poison value in c_start.S
to something else. Then we should get an error like this:
Stack overrun on BSP.Increase stack from current 32768 bytes
CPU0: stack from 00180000 to 00188000:Lowest stack address 00180000

Separate the act of loading from the act of starting the payload. This
allows us better error management and reporting of stack use. Now we
see:
CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8

Tested for both success and failure on Link. At the same time, feel free
to carefully check my manipulation of _estack.

Change-Id: Ibb09738b15ec6a5510ac81e45dd82756bfa5aac2
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1286
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-07-24 23:29:12 +02:00
Stefan Reinauer fb89dd0a93 Use fast memset in SMM mode, too
... and always include IP checksumming in romstage.
It's generally useful and our upcoming port needs it.

Change-Id: I248402d96a23e58354744e053b9d5cca6b74ad3a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/827
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-04-04 19:45:10 +02:00
Stefan Reinauer 1afe51af83 Add native memset() function on x86
Change-Id: Ia118ebe0a4b59bdcefd78895141a365170f6aed2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/737
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2012-03-30 00:57:24 +02:00
Stefan Reinauer 0054afa11d Add faster, architecture dependent memcpy()
Change-Id: I38d15f3f1ec65f0cb7974d2dd4ae6356433bddd8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/736
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2012-03-30 00:51:31 +02:00
Vadim Bendebury 3e31600e62 CBMEM CONSOLE: Enable coreboot CBMEM console.
The appropriate Makefiles are modified to include the required
source code in compilation.

Change-Id: I91842b1ba0f89d611d3249b63c020a2713a9124f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/722
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-29 20:15:06 +02:00
Vadim Bendebury 6f72d6965c Add timestamp collecting to coreboot.
This patch adds code to initialize the time stamp collection
facility in coreboot. It adds a table in the CBMEM section, which
provides the base timer reading value (all other readings are
offsets of this one) and an array of timestamp id/timestamp value
pairs.

Just two values are being added now, this will have to be used
more extensively and also integrated into payloads to provide more
comprehensive boot process time measurements.

Also, since the CBMEM area could already contain a section (from the
previous run, before reset), when processing a section addition
request we should check if a section already exists and return its
address, if so.

Change-Id: I7ed9f5c400bc5432f228348b41fd19a67c36d533
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/713
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2012-03-28 20:43:59 +02:00
Stefan Reinauer 526087172d Fix dependency problem for uart8250.c as well
If you build in parallel, option_table.h will occasionally not be there yet
and the build will fail.

Change-Id: I828956ab2e05c48d20c2f7c55616cc8fa19e1227
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/698
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2012-03-09 20:34:43 +01:00
Stefan Reinauer ba9dae27e1 Fix compilation with CONFIG_USE_OPTION_TABLE enabled
Change-Id: I6c5d973442bc1770702180a8964f1bf6ed6062ed
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/696
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-03-09 20:34:21 +01:00
Gabe Black 1025f3afc8 Add an implementation for the memchr library function
Change-Id: Icded479d246f7cce8a3d2154c69f75178fa513e1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/708
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Mathias Krause <minipli@googlemail.com>
2012-03-09 20:00:53 +01:00
Sven Schnelle 20fc631ad2 Fix usb debug dongle support
- move enable_usbdebug() declaration to usbdebug.h
- reinitialize debug driver in ramstage, as copying the data
  structure from romstage doesn't work right now. This way of copying
  data from romstage to ramstage is really board/cpu specific, and is
  likely to break often. So don't do it.

Change-Id: I394678ded6679c1803e29eb691b926182bdcab68
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/355
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-10-31 04:06:10 +01:00
Rudolf Marek 7f0e93060e Add support for the tracing infastructure in coreboot.
The compiler is forced to emmit special functions on every
entry/exit of the function. Add a compile time option
to support it. Function entries will be printed in
the console. The CONFIG_TRACE has more documentation.

Patch for userspace tools will follow.

Change-Id: I2cbeb3f104892b034c8756f86ed05bf71187c3f3
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/178
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-09-07 01:26:47 +02:00
Sven Schnelle 4297a9a101 X60: trigger save cmos on volume/brightness change
Change-Id: I020e06bc311c4e4327c9d3cf2c379dc8fe070a7a
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/25
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2011-06-15 08:51:18 +02:00
Stefan Reinauer 4885daadb3 Add support for memory mapped UARTs to coreboot and add the OXPCIe952 as an
example.

This newer version reflects the recent changes to further simplify the console
code and partly gets rid of some hacks in the previous version.

Signed-off-by: Stefan Reinauer <reinauer@google.com>
Acked-by: Peter Stuge <peter@stuge.se>                                                                                                                                          



git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6544 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-26 23:47:04 +00:00
Stefan Reinauer 24ef134b37 drop half an uart8250 implementation from smiutil and use the common code
for that instead. This also allows using non-uart8250 consoles for smi
debugging.

Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>



git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6501 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-14 22:28:00 +00:00
Stefan Reinauer 16ce01b0d8 This patch gets usbdebug console working in romstage.
- actually hook up usbdebug in printk/print_ for romstage
- make usbdebug.c more similar to the Linux kernel version it was
  originally derived from.
- increase retries and timing for usbdebug init (at least one chipset
  seems to need this)
- src/pc80/usbdebug_serial.c is not needed
- some small console cleanups

Signed-off-by: Stefan Reinauer <reinauer@google.com>
Acked-by: Patrick Georgi <patrick.georgi@secunet.com>




git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6315 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-01-28 08:05:54 +00:00
Rudolf Marek 475916ddbf Compile cbmem.c instead of including it in romstage,
and do that only if resume is done.

Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>



git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6174 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-13 20:02:23 +00:00
Patrick Georgi d083595350 Remove lib/ramtest.c-include from all CAR boards.
Remove many more .c-includes from i945 based boards.

Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>


git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5910 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-10-05 09:07:10 +00:00
Myles Watson d3f620299c Fix make warnings:
Makefile:261: warning: overriding commands for target `coreboot-builds/a-trend_atc-6220/lib/lzma.ramstage.o'
Makefile:261: warning: ignoring old commands for target `coreboot-builds/a-trend_atc-6220/lib/lzma.ramstage.o'

lzma.c is already included unconditionally in the same file.

Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Myles Watson <mylesgw@gmail.com>


git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5900 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-10-01 15:23:41 +00:00