BRANCH=None
BUG=None
TEST=Manual
Change-Id: I8b31a0b194d353ea3e7863513f2e36f3e032fad8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7ccba49a7c2372cdfff6e2947e417d4d4f5436c2
Original-Change-Id: I9beebdf29e4fc4aa645581146fdc61c659de72df
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229973
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/8808
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built secmon which had this type of relocation.
Change-Id: Ie367c348fbf59465e238e5fa60f217f5373501b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a754bc1fe39c19ab8b2f7be9648cccb06156b0ef
Original-Change-Id: If170d9e270daf3153e92d16c06516915c727e930
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218843
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8807
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When adding gargabe collection to x86 the --gc-sections
flags was inadvertently missed when linking romstage_null.debug.
Fix this omission.
Change-Id: I7d2700755afa78459c6f8707303a0e64936a1a9f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8850
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Chapter 3.1 "Periodic Frame List" of EHCI 1.0 specification says
"Frame List Link pointers always reference memory objects that are
32-byte aligned."
jwerner@chromium.org suggests setting it to be 64-byte aligned for
consistency with other EHCI queue structures.
BUG=chrome-os-partner:31993
TEST=Tested on nyan platform. Before adding patch, USB keyboard behind
an external hub is not working to switch between "Default Locale" and
"English" (after pressing ESC+REFRESH+POWER on embedded keyboard and
later Left/Right-Arrow key on USB keyboard).
Change-Id: Ie6259f2df20ae2618c2074e831fad087f227091d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 23fc02e6ba3b17be4eaf18810ec6fc0d9c0e0b9a
Original-Change-Id: If52ddc43ebd5d509c19f104928dced5bd09b1706
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/218403
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8738
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Data toggle should be running like 0, 1, 0, 1, ...
In the failed case (where a low-speed USB keyboard or km232 device
is installed), data toggle will be running as 0, 1, 0, 1, ..., 1, 1.
Therefore causing Halted or Transaction Error bit to be set in qTD
Status field.
BUG=None
BRANCH=None
TEST=Tested on nyan_kitty platform, firmware-kitty-5771.61.B branch.
Attached USB keyboard or km232 device to root-hub port (same side as
SD card slot).
Made sure no transaction error after doing interrupt transfer.
Change-Id: I576f3c583dae4c279a6e0e8ffdfce5abe463277d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64b0428aaab869e20f6720669e953acf82ecb846
Original-Change-Id: Ic2c0f95cff2ae6e314967b0b82231a962255f1a7
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233857
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These functions are usually provided by gcc lib, which is not supposed
to be included on embedded platforms. This patch adds a no thrills C
implementation.
Other than MIPS platforms are happy using the gcc library provided
implementation, but in case of Chrome OS MIPS toolchain the libraries
are compiled with the small GOT, such that the entire data segment
does not fit.
With this implementation mips, arm and x86 targets build fine.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=checked the logic by incorporating this code into a C file and
running a loop continuously comparing random inputs' division and
left and right shift results.
The test ran for extended periods of time without failure.
Change-Id: I468acd2fdbcdd493a76758a394e79cad35f9535a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2cc5f8668dd2609408af8da5a74c5a3d063fc0d3
Original-Change-Id: Ib46616d7eb0b2b497199270057514f730bb1cb0b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232232
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_romstage() to perform
the necessary work to load and run romstage.
Change-Id: Id59f47febf5122cb3ee60f9741cfb58cb60ccab5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_ramstage() to perform
the necessary work to load and run ramstage.
Change-Id: I37b1e94be36ef7a43efe65b2db110742fa105169
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8710
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide a common run_romstage() function to be used by
bootblocks to load and run romstage. This is similar to
run_ramstage() in that it provides a single entry point
for doing the necessary work of loading and running romstage.
Change-Id: Ia9643cc091f97a836cf5caefdff8df4a3443df4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8709
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Miraculously a console is being compiled in for romstage.
However, as no calls were potentially printing to the preram
console this was being ignored. Instead provide the symbol
required so as not to fail the build.
Change-Id: Id8f0b6e6d15b41fa7fe1b63bf2d91f15baa0edda
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8712
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of two headers for payload and ramstage loading
combine the 2 files into one. This also allows for easier
refactoring by keeping header files consistent.
Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8708
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
GD25LQ64C and GD25LB64C have the same ID and settings.
BUG=chrome-os-partner:25907
BRANCH=baytrail
TEST=Boot with GD25LQ64 and check MRC data save/restore works.
Change-Id: I8a4aa7cabd9a7657c2f0bae255a87341db3f1061
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20b5896adbbbdedcb1b7de435466dcc6bfa703cb
Original-Change-Id: I86d1e69552b6000faa9e0523356e27d7e2a6a6db
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193238
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8770
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This allows us to use the driver before ramstage.
BRANCH=none
BUG=none
TEST=built and booted on Pinky
Change-Id: I0700388b0e4e0562e3c0a52863c8357097bfd8d6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cd57587dab74de509d5c50cfc1ad337d765af6c8
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I0ce901331e401274254b8889484ffb41359119fa
Original-Reviewed-on: https://chromium-review.googlesource.com/235864
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8774
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When the driver is included in bootblock, malloc() is not available.
Come to think of it, it is perfectly fine to use a statically
allocated structure for the SPI device descriptor - coreboot is
unlikely to require concurrent support of multiple SPI devices of the
same kind.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=bootblock on the FPGA board recognizes the installed Winbond
device:
coreboot-4.0 bootblock Tue Nov 11 07:27:24 PST 2014 starting...
SF: Detected W25Q16 with page size 1000, total 200000
Change-Id: Iea1936a219d38848580a10f75eb8bbcab17e6507
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0b4082442aa526d387a80cb5872d78670e6b468b
Original-Change-Id: Iaa69d610ef18e69b1ae5ade2d958f9fe1595a723
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228959
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8771
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
S25FL116K family uses the first 3 bytes in response to a legacy identification
command (9f) while previously supported models use the last 4 bytes. This change
defines identify functions to allow both types to be handled correctly.
BUG=none
BRANCH=tot
TEST=verified romstage is loaded on cosmos development board.
Change-Id: I1970a9af17e81299fada5029724d405de4022156
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 65ff436db2355cb68a766a3dedbcd7e2f765e6db
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Icdd2645e356652672c4482e7b805da1bc0f21e71
Original-Reviewed-on: https://chromium-review.googlesource.com/234431
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8773
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It turns out that CB_TAG_ACPI_GNVS is handled in both x86 specific and
common coreboot table parsing code. The MRC cache case used only by
x86 is handled in the common code.
This patch restores sanity and moves processing to where it belongs.
BRANCH=none
BUG=none
TEST=verified that arm and x86 targets build.
Change-Id: Iaddaa3380725be6d08a51a96c68b70522531bafe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0afae893d5027026cb666cd46e054aeae4e71f83
Original-Change-Id: I2c114a8469455002c51593cb8be80585925969a7
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225457
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8752
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Pass MAC addresses found in coreboot table into lib_sysinfo.
BUG=chrome-os-partner:32152
TEST=with all changes in place MAC addresses are properly inserted
into the kernel device tree.
Change-Id: I6b13c1c2c246362256abce3efa4a97b355647ef8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e2fe74f86b4ed43eb8a3c9d99055afc5d6fb7b78
Original-Change-Id: I1d0bd437fb27fabd14b9ba1fb5415586cd8847bb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219444
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8751
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are three instances of coreboot.c in libpayload. for x86, arm
and arm64 architectures. The arm and arm64 instances are exactly the
same. The differences with the x86 instance are as follows:
- a very slightly different set of coreboot table tags is parsed (one
tag added and two removed)
- instead of checking a fixed address if it contains the coreboot
table, the x86 version iterates over two address ranges.
This patch refactors the module, leaving architecture specific
processing in arch subdirectories and moving the common code into
libc.
BUG=none
TEST=none yet
Change-Id: I1c7ad6f74e3498e93df78086ba0ff708c08e0a5c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3df209d58ebd5c5b1cf0168f6466e065d1ef3598
Original-Change-Id: I6dfed73f6ba5939f692d0f98d2774c0e0312a25f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210770
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8750
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Make board ID value supplied in the coreboot table available to the
bootloader on all three architectures.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: I6c2d39e94212b55650929d7d99896581d23f789d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 723e4a600a5d3a03e960169b04f8322f6dd2486b
Original-Change-Id: I7847bd9fe2d000a29c7ae95144f4868d926fb198
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210430
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8730
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As opposed to other architectures, on MIPS gcc toolchain provided
gcclib is not always adequate, for instance when the library does not
account for the case when data segment is too large to fit into the
64K GOT.
Let's make sure the library is not included when building for MIPS
targets.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the rest of patches applied the FPGA board boots all the way
to verifying and loading the kernel from the USB stick.
Change-Id: I710d3c49bdc57877152cf28d5bd8cb4fa4d0b9ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f8d7d84c81af7e3eee1c8f3304c15069e8701cde
Original-Change-Id: I1a26b9e575a20101329359b80dffc236ef7f9e9f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232231
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8740
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a macro to check if a value is aligned.
BUG=chrome-os-partner:36258
BRANCH=none
TEST=Build and boot on Pistachio.
Change-Id: I0680954eb1b1964a631527f96aa0570a32944fa1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4f1717648e0a4b54217d71f8d0a15d496737d156
Original-Change-Id: Ie0bc1374918a7ffaaec5fea62c1193a42edd416c
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246692
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8757
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add support to check if the driver for console_out or console_in is already
present in the list. If console_init is called twice, then the driver might get
added twice leading to a loop.
BUG=None
BRANCH=None
TEST=With console_init in libpayload and depthcharge both, there are no console
loops seen anymore
Change-Id: I9103230dfe88added28c51bff33ea4fa1ab034c1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6931236ba2cfa71849973fe41cc340b7d70656ad
Original-Change-Id: If9a927318b850ec59619d92b1da4dddd0aa09cd1
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214072
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8739
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds a simple function to convert a string in UTF-16LE
to ASCII.
TEST=Ran against a string found in a GPT with the intended outcome
BRANCH=none
BUG=none
Change-Id: I94ec0a32f5712259d3d0caec2233c992330228e3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1104db8328a197c7ccf6959a238277f416a2113a
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Change-Id: I50ca5bfdfbef9e084321b2beb1b8d4194ca5af9c
Original-Reviewed-on: https://chromium-review.googlesource.com/231456
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8733
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For memalign() requests the current allocator keeps metadata
about each chunk of aligned memory that copmrises the size
requested. For large allocations relative to the alignment
this can cause significant metadata overhead. Instead, consider
all memalign() requests whose size meets or exceeds 1KiB or
alignment that meets or exceeds 1KiB large requests.
These requests are handled specially to only allocate
the amount of memory required for the size and alignment
constraints by not allocating any metadata as the whole region
would be consumed by the request.
BUG=None
BRANCH=None
TEST=Built and tested various scenarios. Noted the ability to
free() and properly coalesce the heap as expected.
Change-Id: Ia9cf5529ca859e490617af296cffd2705c2c6fd8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4e32fc57626dac6194c9fd0141df680b4a5417e8
Original-Change-Id: Icdf022831b733e3bb84a2d2f3b499f4e25d89128
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242456
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some USB sticks seem to send a NAK at a place where they mustn't
by spec, leading to a controller side error condition.
To avoid it, wait a millisecond which is enough to get past the
NAK condition. That delay only happens on device discovery so it
won't affect boot time by more than 1ms per device.
BUG=chromium:414959
BRANCH=none
TEST=depthcharge recognizes a Lexar 16GB USB stick after applying
this change.
Change-Id: I0e385702a5259b16fda0a253fc121d8f66e6705c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10bbfda8395af009e7f910cc503f50c2ad969ae8
Original-Change-Id: I6dd5ca34e9f3767003ccb0ca9daaf16116f4a2df
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228791
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-on: http://review.coreboot.org/8735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
EHCI driver accesses mmio space using regular struct pointers. In order to avoid
any CPU re-ordering, memory barrier is required in async_set_schedule,
especially for arm64. Without the memory barrier, there seems to be re-ordering
taking place which leads to USB errors with some flash drives as well as
transfer errors in netboot.
BUG=chrome-os-partner:31533
BRANCH=None
TEST=With the memory barrier introduced, netboot for ryu completes transfer
without any error and finishes within 6-7 seconds.
Change-Id: Ib6d29dc79fd5722c27284478e8da316929e86bff
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 561bdd746c4d4446ce0a6d21337d354625d85ddc
Original-Change-Id: Ic05d47422312a1cddbebe3180f4f159853604440
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/213917
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for memory barriers in arch {arm,arm64,x86}. This is required to
force strict CPU ordering. Definitions are based on FREEBSD atomic.h
definitions.
BUG=chrome-os-partner:31533
BRANCH=None
TEST=Memory barriers tested with ehci driver on arm64
Change-Id: I50060b0f33a6bd6cb95e829df079df379b2ff2a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 937d66cdab92a8521ede8307f5af8f5c20d3e552
Original-Change-Id: Ie51e3452f7a254b24111000da5dbe8714ac22223
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/213916
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8731
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Similarly to xzalloc() and xmalloc() provide an xmemalign() function
to do the approriate assertions on allocation failure.
BUG=None
BRANCH=None
TEST=Built and booted using xmemalign().
Change-Id: I59579d9ee973af3bb34037b7df5b1024b60e348d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3001822656024dbfc34d6b849a0245274b8c0f46
Original-Change-Id: Ie307d4c9c1882bba25745afe38455f2682303e37
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242455
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/8728
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add OpenBSD's header-only implementation of some
basic data structures, imported from
src/sys/sys/queue.h, revision 1.38
(all whitespace errors kept verbatim)
Unlike home-grown solutions they likely handle
all corner cases correctly from the start and
unlike Linux's solution it's properly documented
(see OpenBSD's LIST_INIT(3)) and also BSD-l.
BRANCH=none
BUG=none
TEST=none
Change-Id: I89ae4df0c73662c355537283e7559af03a8b99a0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6f89e0316e6d68158c689bed4b1bdfe168c1449a
Original-Change-Id: Ie08a567851a2f07cbd2ac80ba31d8bca9844937d
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/240190
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/8727
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
uio_usbdebug enables you to debug coreboot's usbdebug driver inside a
running operating system (only Linux at this time). This comes very
handy if you're hacking the usbdebug driver and don't have any other
debug output from coreboot itself.
Currently, only Intel chipsets are supported.
Change-Id: Iaf0bcd4b4c01ae0b099d1206d553344054a62f31
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/4695
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mainboards/amd/fam10: Initialize cbmem area after raminit
When GFXUMA is enabled, CBMEM is placed at TOM - UMASIZE
When GFXUMA is disabled, CBMEM is placed at TOM
This matches the behaviour present before conversion to early
CBMEM.
The CBMEM location code implicitly assumes TOM does not change
between romstage and ramstage. TOM is set by romstage raminit,
and is never changed by romstage or ramstage afterward. As
the CBMEM location is positioned at a specific offset from TOM
that is known to both romstage and ramstage early CBMEM is safe
on Fam10h systems.
TEST: Booted ASUS KFSN4-DRE and verified both cbmem timestamp
tables from romstage and cbmem log tables from ramstage.
Change-Id: Idf9e0245fe91185696ff664b06182c26b376c196
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8489
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Our target is to get rid of backup_top_of_ram() and get_top_of_ram()
entirely so only declare these with LATE_CBMEM_INIT=y.
Change-Id: I54f549fe774996f4d803f9ec527e0fac46f6576f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8749
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
The CBMEM memory segment is always placed at TOM - UMASIZE when GFXUMA
is enabled, however when GFXUMA is disabled an attempt was made to locate
the CBMEM memory segment above the I/O hole in certain rare cases.
Removing this special case does not impact functionality, and paves
the way for early CBMEM support.
Change-Id: I98d29ab9d601a4e20f58e2cd0a66abb13b494e74
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: Aaron Durbin <adurbin@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
The AMD RS780 early initialization code originally used the
CF8/CFC I/O method for PCI configuration space access. After
the default configuration access method was changed to MMIO
(http://review.coreboot.org/#q,aad07472), booting would hang
at "PCI: pci_scan_bus for bus 01". Fix the problem by changing
function rs780_nb_gfx_dev_table() so that it no longer borrows
the BAR3 address needed for PCIe MMIO config usage.
Change-Id: I8816b94c848e1b50f8c880e5867a96ca2a33a8a7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8394
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
We use paths relative to that in the buildgcc script.
Change-Id: I2b79c3d2c75088af7e8e362d18a38274352eb965
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8713
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The GCC 4.9.2 update showed that the boot_state_init_entry
structures were being padded and assumed to be aligned in to an
increased size. The bootstate scheduler for static entries,
boot_state_schedule_static_entries(), was then calculating the
wrong values within the array. To fix this just use a pointer to
the boot_state_init_entry structure that needs to be scheduled.
In addition to the previous issue noted above, the .bs_init
section was sitting in the read only portion of the image while
the fields within it need to be writable. Also, the
boot_state_schedule_static_entries() was using symbol comparison
to terminate a loop which in C can lead the compiler to always
evaluate the loop at least once since the language spec indicates
no 2 symbols can be the same value.
Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
SERIRQ_CONTINUOUS_MODE is specific feature of LPC busses.
This fixes a KCONFIG unmet dependency warning on ARM mainboards with
chromeec.
Change-Id: Iae61986219585dcb1124cf3b24fa32a8596d56c8
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8665
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add license header with copyright of the original authors.
Change-Id: I8c55bb38a2a2a387ad2461e11d402c7392fa2497
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8691
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The decode of UART addresses down to the LPC bus needs
to occur early to allow romstage console messages to
be seen. This enables the decode of most of the I/O
ports typically seen in a system.
Change-Id: I6636946af4ad5320a5a46c2920b4f06345b5f806
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8661
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The current spi_xfer() function sets the count in hardware and then
loops while waiting for the requested number of bytes to be sent or
received. However, the number of bytes to be transferred may exceed
the maximum count that can be programmed into the controller.
This patch re-factors spi_xfer() to split the low-level FIFO handling
portions for transmit/receive into their own functions to be called
by loops in spi_xfer() which will break large transfers into smaller
ones.
BUG=chrome-os-partner:30904
BRANCH=storm
TEST=built and booted with a >64KB payload on Storm
Original-Change-Id: I70743487996cf08cfc602449f2181a7fcd99bfa4
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209838
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Tested-by: Trevor Bourget <tbourget@codeaurora.org>
(cherry picked from commit 5ec28de11f12c2438356f45ce978a17fbb603bf7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0033e0dd96006cfd30a7a4f5e5a052f677e05108
Reviewed-on: http://review.coreboot.org/8676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Julius Werner