| Age | Commit message (Collapse) | Author |
|---|
|
CBFS MCache size was assigned a value of the coreboot tables entry size
instead of the MCache size.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I8a8c3a10c6032121b4c5246d53d2643742968c09
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
This patch introduces new FlashMap API, the fmap_locate_area().
It works on cached FlashMap provided in lib_sysinfo.fmap_cache.
Change-Id: Idbf9016ce73aa58e17f3ee19920ab83dc6c25abb
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
coreboot stores much information in the CBMEM IMD. Until now it was
ignored. This patch makes use of these coreboot tables entries.
It also removes get_cbmem_addr() function as it is no longer needed.
Moreover, the coreboot tables entry CB_TAG_MRC_CACHE does not exist
anymore, as it is not created by the code. It was replaced by
CBMEM_ID_MRCDATA entry, so MRCDATA should now be accessible through
sysinfo structure field.
Change-Id: I5bd02a98ba2631f34014bc0f8e7ebd5a5ddd2321
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
This change adds type-c port information for USB Type-C ports to the
coreboot table. This allows depthcharge to know the usb2 and usb3
port number assignments for each available port, as well as the SBU
and data line orientation for the board.
BUG=b:149830546
TEST='emerge-volteer coreboot chromeos-bootimage' and verify it builds
successfully. Cherry-pick CL to enable this feature for volteer,
flash and boot volteer2 to kernel, log in and check cbmem for type-c
info exported to the payload:
localhost ~ # cbmem -c | grep type-c
added type-c port0 info to cbmem: usb2:9 usb3:1 sbu:0 data:0
added type-c port1 info to cbmem: usb2:4 usb3:2 sbu:1 data:0
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Change-Id: Ice732be2fa634dbf31ec620552b383c4a5b41451
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
The input buffer to the buffer_to_fifo family of functions is only read,
so it can be a const pointer. (Also, remove the MIPS check in libpayload
for these functions... the MIPS architecture has been removed a while
ago.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I021069680cf691590fdacc3d51f747f12ae3df31
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
CB:51638 separated Chrome OS NVS from global NVS by allocating it
separately in CBMEM. CNVS is used in depthcharge to fill firmware
information at boot time. Thus, location of CNVS needs to be shared in
coreboot tables for depthcharge to use.
This change adds a new coreboot table tag
`CB_TAG_ACPI_CNVS`/`CB_TAG_ACPI_CNVS`(0x41) which provides the
location of CNVS in CBMEM to payload (depthcharge).
Additionally, CB:51639 refactored device nvs(DNVS) and moved it to the
end of GNVS instead of the fixed offset 0x1000. DNVS is used on older
Intel platforms like baytrail, braswell and broadwell and depthcharge
fills this at boot time as well. Since DNVS is no longer used on any
new platforms, this information is not passed in coreboot
tables. Instead depthcharge is being updated to use statically defined
offsets for DNVS.
BUG=b:191324611, b:191324611
TEST=Verified that `crossystem fwid` which reads fwid information from
CNVS is reported correctly on brya.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3815d5ecb5f0b534ead61836c2d275083e397ff0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55665
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy_jian@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds details about the memory map windows to translate
addresses between SPI flash space and host address space to coreboot
tables. This is useful for payloads to setup the translation using the
decode windows already known to coreboot. Until now, there was a
single decode window at the top of 4G used by all x86
platforms. However, going forward, platforms might support more decode
windows and hence in order to avoid duplication in payloads this
information is filled in coreboot tables.
`lb_spi_flash()` is updated to fill in the details about these windows
by making a call to `spi_flash_get_mmap_windows()` which is
implemented by the driver providing the boot media mapping device.
BUG=b:171534504
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I00ae33d9b53fecd0a8eadd22531fdff8bde9ee94
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48185
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There are currently 3 different strapping ID entries in the coreboot
table, which adds overhead. The new fw_config field is also desired in
the coreboot table, which is another kind of strapping id. Therefore,
this patch deprecates the 3 current strapping ID entries (board ID, RAM
code, and SKU ID), and adds a new entry ("board_config") which provides
board ID, RAM code, SKU ID, as well as FW_CONFIG together.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I1ecec847ee77b72233587c1ad7f124e2027470bf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The appropriate way to print a u64 variable regardless of the current
architecture is to use the PRI*64 macros. libpayload is mostly used
in 32 bits but when ported to other projects and compiled in 64 bits
it breaks the compilation.
Change-Id: I479fd701f992701584d77d43c5cd5910f5ab7633
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I6faeb7c783052edc4217d2d301dbb905e1fc6a19
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Separate the validity check of calling free(NULL) for clarity.
BUG=b:168441735
TEST=emerge-puff libpayload
Change-Id: I0dc355553410bbe59e658945fb40c05f5f709380
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45465
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
The current realloc() works by freeing the origin buffer, allocating a
new one, and copying the data over. It's true that free() won't touch
the actual memory. However, the alloc() following it will potentially
modify the memory that belongs to the old buffer in order to create a
new free block (right after the newly allocated block). This causes 8
bytes (HDRSIZE) to be overwritten before being copied to the new buffer.
To fix the problem, we must create the header of the new free block
after the data is copied. In this patch, the content of alloc() is split
into two functions:
1. find_free_block(): Find a free block with large enough size, without
touching the memory
2. use_block(): Update the header of the newly allocated block, and
create the header of the new free block right after it
Then, inside realloc(), call memmove() call right after
find_free_block() while before use_block().
BUG=b:165439970
TEST=emerge-puff libpayload
TEST=Puff boots
TEST=Verified realloc() correctly copied data when buffers overlapped
Change-Id: I9418320a26820909144890300ddfb09ec2570f43
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
default_memmove() calls memcpy() when (src > dst). This is safe for the
default_memcpy() implementation, but just calling memcpy() may invoke an
architecture-specific implementation. Architectures are free to
implement memcpy() however they want and may assume that buffers don't
overlap in either direction. So while this happens to work for all
current architecture implementations of memcpy(), it's safer not to rely
on that and only rely on the known implementation of default_memcpy()
for the forwards-overlapping case.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7ece4ce9e6622a36612bfade3deb62f351877789
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44691
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`. This updates the remaining
pointers that are not consumed by libpayload code, all of them
strings.
Also update the comment that `libsysinfo` only containts physical
addresses.
Change-Id: I9d095c826b00d621201c34b329fb9b5beb1ec794
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`. This updates all the references
to CBMEM entries that are not consumed inside libpayload code.
Change-Id: I3be64c8be8b46d00b457eafd7f80a8ed8e604030
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`. This updates all the references
to coreboot-table entries that are not consumed inside libpayload
code.
Change-Id: I95cb0af151e0707a1656deacddb8a5253ea38fc3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Our AArch64 code supports dynamic framebuffer allocation which
makes it necessary to change the framebuffer information during
runtime. Having a pointer inside `libsysinfo` made a mess of it
as the pointer would either refer to the original struct inside
the coreboot table or to a new struct inside payload space. The
latter would be unaffected by a relocation of the payload.
Instead of the pointer, we'll always keep a copy of the whole
struct, which can be altered on demand without affecting the
coreboot table. To align the `video/graphics` driver with the
console driver, we also replace `fbaddr` with a macro `FB` that
calls phys_to_virt().
Change-Id: I3edc09cdb502a71516c1ee71457c1f8dcd01c119
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`.
Change-Id: Icd30e95c6b8115d16dd793914fb01a1a9da1854f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`.
Change-Id: I64a37bef263022edb504086c02a3fd22ce068ba4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Same as with other consoles and drivers that cache an address
outside the payload (e.g. video/corebootfb), we should store the
physical address, so we can derive the virtual address on demand.
This makes it save to use the address across relocations.
As a first step in migrating `libsysinfo` to `uintptr_t`, we
also switch to the physical address there.
Fixes the default build of FILO, tested with Qemu/i440FX and Qemu/Q35.
Change-Id: I4b8434af69e0526f78523ae61981a15abb1295b0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
struct fraction is slooooooooooow. This patch adds a simple 64-bit
(32-bits integral, 32-bits fractional) fixed-point math API that is
*much* faster (observed roughly 5x speed-up) when doing intensive
graphics operations. It is optimized for speed over accuracy so some
operations may lose a bit more precision than expected, but overall it's
still plenty of bits for most use cases.
Also includes support for basic trigonometric functions with a small
lookup table.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id0f9c23980e36ce0ac0b7c5cd0bc66153bca1fd0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
Avoid dereferencing a NULL pointer in case of function parameter 'ptr'.
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Change-Id: I5dba27d9757fb55476f3d5848f0ed26ae9494bee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41698
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Make the code follow the coding style.
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Change-Id: I4ca168c4aedddef51103b270f105feab93739ecc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Our realloc() works (somewhat suboptimally) by free()ing the existing
allocation and then reallocating it wherever it fits. If there was free
space before the old location, this means the new allocation may be
before the old one, and if the free space block is smaller than the old
allocation it may overlap. Thus, we should be moving memmove() instead
of memcpy() to move the block over.
This is not a problem in practice since all our existing memcpy()s are
simple iterate and copy front to back implementations which are safe for
overlaps when the destination is in front of the source. but it's still
the more correct thing to do (in case we ever change our memcpy()s to do
something more advanced or whatever).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I35f77a94b7a72c01364ee7eecb5c3ff5ecde57f6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ib7f1ba1766e5c972542ce7571a8aa3583c513823
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38911
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Since struct vb2_shared_data already contains workbuf_size and
vboot_workbuf_size is never used in depthcharge, remove it from struct
sysinfo_t. In addition, remove lb_vboot_workbuf() and add
CBMEM_ID_VBOOT_WORKBUF pointer to coreboot table with
add_cbmem_pointers(). Parsing of coreboot table in libpayload is
modified accordingly.
BRANCH=none
BUG=chromium:1021452
TEST=emerge-nami coreboot libpayload depthcharge; Akali booted correctly
Change-Id: I890df3ff93fa44ed6d3f9ad05f9c6e49780a8ecb
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The MIPS architecture port has been added 5+ years ago in order to
support a Chrome OS project that ended up going nowhere. No other board
has used it since and nobody is still willing or has the expertise and
hardware to maintain it. We have decided that it has become too much of
a mainenance burden and the chance of anyone ever reviving it seems too
slim at this point. This patch eliminates all MIPS code and
MIPS-specific hacks.
Change-Id: I5e49451cd055bbab0a15dcae5f53e0172e6e2ebe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34919
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There's a recurring pattern of reading cbtable entries that point into
cbmem entries. Move that pattern into its own function.
Coccinelle patch used for this:
@@
identifier T, T2;
expression TARGET;
@@
-struct cb_cbmem_tab *const T2 = (struct cb_cbmem_tab *)T;
-TARGET = phys_to_virt(T2->cbmem_tab);
+TARGET = get_cbmem_ptr(T);
Change-Id: I7bd4a7ad8baeeaebf0fa7d4b4de6dbc719bc781f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35756
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Now that FMAP is cached in CBMEM and its pointer is added to coreboot
table for quick lookup, this change adds a new member "fmap_cache" to
sysinfo_t that can be used by payloads to get to FMAP cache.
BUG=b:141723751
Change-Id: If894c20c2de89a9d8564561bc7780c86f3f4135a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Many peripheral drivers across different SoCs regularly face the same
task of piping a transfer buffer into (or reading it out of) a 32-bit
FIFO register. Sometimes it's just one register, sometimes a whole array
of registers. Sometimes you actually transfer 4 bytes per register
read/write, sometimes only 2 (or even 1). Sometimes writes need to be
prefixed with one or two command bytes which makes the actual payload
buffer "misaligned" in relation to the FIFO and requires a bunch of
tricky bit packing logic to get right. Most of the times transfer
lengths are not guaranteed to be divisible by 4, which also requires a
bunch of logic to treat the potential unaligned end of the transfer
correctly.
We have a dozen different implementations of this same pattern across
coreboot. This patch introduces a new family of helper functions that
aims to solve all these use cases once and for all (*fingers crossed*).
Change-Id: Ia71f66c1cee530afa4c77c46a838b4de646ffcfb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
vboot_handoff is no longer used in coreboot, and is not
needed in CBMEM or cbtable.
BUG=b:124141368, b:124192753
TEST=make clean && make runtests
BRANCH=none
Change-Id: I782d53f969dc9ae2775e3060371d06e7bf8e1af6
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33536
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
size_t is the natural integer type for strlen() and array indices, and
this fixes several integer conversion and sign comparison warnings.
Change-Id: I5658b19f990de4596a602b36d9533b1ca96ad947
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33794
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
- Constify the string argument
- Change int to size_t, which is what xmalloc expects
Change-Id: I8b5a13319ded4025f883760f2b6d4d7a9ad9fb8b
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The documented return value for strlcat is horribly wrong, as is the
return value itself. It should not return the number of appended bytes,
but rather the length of the concatenated string. From the man page:
The strlcpy() and strlcat() functions return the total length of the
string they tried to create. For strlcpy() that means the length of
src. For strlcat() that means the initial length of dst plus the
length of src. While this may seem somewhat confusing, it was done
to make truncation detection simple.
This change is more likely to fix existing code than break it, since
anyone who uses the return value of strlcat will almost certainly rely
on the standard behaviour rather than investigate coreboot's source code
to see that we have a quirky version.
Change-Id: I4421305af85bce88d12d6fdc2eea6807ccdcf449
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Add comments to intentional fall throughs and enable the warning.
Change-Id: I93e071c4fb139fa6e9cd8a1bfb5800f5f4eac50b
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
Pass the return value from early_mmc_wake_hw() to the payload so that
payload can skip sending CMD0 and resetting the card in case of success
or in case of a failure in firmware, payload can recover by sending
CMD0 and resetting the card.
BUG=b:78106689
TEST=Boot to OS
Change-Id: Ia4c57d05433c3966118c3642913d7017958cce55
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/25464
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Our strtol() and strtoull() function contain almost exactly the same
code. This is a) bad in general and b) may cause the code to get out of
sync, such as it recently happened with CB:32029.
This patch changes strtol() to be based on strtoull() so that the main
parsing code exists only once, and also adds a strtoll() to round off
the library. Also fix the bounds imposed by strtoul() to be based on the
actual length of a 'long', not hardcoded to 32-bits (which is not
equivalent on all architectures).
Change-Id: I919c65a773cecdb11739c3f22dd0d182ed50c07f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
New compilers are a little more stringent about defining the same
prototype more than once, so some of our CONFIG_LP_DEBUG_MALLOC wrappers
don't quite work the way they are written anymore. Also, several of the
printf()s weren't written 64-bit safe. And let's add some
double-evaluation safety while I'm here anyway... and I have no idea why
this ever depended on CONFIG_LP_USB, that just seems like a typo.
Change-Id: Ib54ebc3cfba99f372690365b78c7ceb372c0bd45
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/14921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
|
|
strtoull() can optionally take a second pointer as an out-parameter that
will be adjusted to point to the end of the parsed string. This works
almost right, but misses two important edge cases: firstly,when the
parsed string is "0", the function will interpret the leading '0' as an
octal prefix, so that the first actually parsed digit is already the
terminating '\0' byte. This will cause the function to early abort,
which still (correctly) returns 0 but doesn't adjust *endptr.
The early abort is pointless anyway -- the only other thing the function
does is run a for-loop whose condition is the exact inverse (so it's
guaranteed to run zero iterations in this case) and then adjust *endptr
(which we want). So just take it out. This also technically corrects the
behavior of *endptr for a completely invalid string, since the strtoull
man page says
> If there were no digits at all, strtoul() stores the original value of
> nptr in *endptr (and returns 0).
The second issue occurs when the parsed string is "0x" without another
valid digit behind it. In this case, we will still jump over the 0x
prefix so that *endptr is set to the first byte after that. The correct
interpretation in this case is that there is no 0x prefix, and instead a
valid 0 digit with the 'x' being invalid garbage at the end. By not
skipping the prefix unless there's at least one valid digit after it, we
get the correct behavior of *endptr pointing to the 'x'.
Change-Id: Idddd74e18e410a9d0b6dce9512ca0412b9e2333c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Create a new cbtable entry called VBOOT_WORKBUF for
storing a pointer to the vboot workbuf within the
vboot_working_data structure.
BUG=b:124141368, b:124192753
TEST=Build and deploy to eve
TEST=util/lint/checkpatch.pl -g origin/master..HEAD
TEST=util/abuild/abuild -B -e -y -c 50 -p none -x
BRANCH=none
Change-Id: Id68f43c282939d9e1b419e927a14fe8baa290d91
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31887
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch is a raw application of
find payloads/ -type f | \
xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g'
Change-Id: I883b03b189f59b5d998a09a2596b0391a2d5cf33
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
libfdt requires memchr. Add missing function to libc.
Change-Id: I872026559d16a352f350147c9d7c4be97456a99f
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/c/31354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Replace _delay with an arch_ndelay(). This way each arch can setup their
own delay mechanism.
BUG=b:109749762
TEST=Verified delay's still work on grunt.
Change-Id: I552eb30984f9c21e92dffc9d7b36873e9e2e4ac5
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/28243
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Since we can derive chromeos_acpi's location from that of
ACPI GNVS, remove chromeos_acpi entry from cbtable and
instead use acpi_gnvs + GVNS_CHROMEOS_ACPI_OFFSET.
BUG=b:112288216
TEST=None
CQ-DEPEND=CL:1179725
Change-Id: I74d8a9965a0ed7874ff03884e7a921fd725eace9
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/28190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
There is a confusingly named section in cbmem called vdat.
This section holds a data structure called chromeos_acpi_t,
which exposes some system information to the Chrome OS
userland utility crossystem.
Within the chromeos_acpi_t structure, there is a member
called vdat. This (currently) holds a VbSharedDataHeader.
Rename the outer vdat to chromeos_acpi to make its purpose
clear, and prevent the bizarreness of being able to access
vdat->vdat.
Additionally, disallow external references to the
chromeos_acpi data structure in gnvs.c.
BUG=b:112288216
TEST=emerge-eve coreboot, run on eve
CQ-DEPEND=CL:1164722
Change-Id: Ia74e58cde21678f24b0bb6c1ca15048677116b2e
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/27888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch adds support to read the SKU ID entry from the coreboot table
that was recently added in coreboot.
Change-Id: I1c3b375da6119a4f8e8e7e25a11644becb90f927
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22743
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch mirrors recent cleanups in coreboot regarding the strapping
ID entries in the coreboot table.
Change-Id: Ia5c3728daf2cb317f8e2bc72c6f1714d6cb4d080
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/22742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I97e393537ccc71ea454bb0d6cdbbb7ed32485f1e
Signed-off-by: Nicola Corna <nicola@corna.info>
Reviewed-on: https://review.coreboot.org/21011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Use a `for` instead of a `while` loop and use meaningful identifiers.
Also, don't use more than one variable for one and the same purpose,
don't use more (non-const) variables than necessary, don't alter more
than one variable per statement, don't compare pointers of different
types and don't do pointer arithmetic on `void *`.
This was meant as a fix up to a regression but that has already been
fixed.
Change-Id: I0c8fd118d127a26cfcf68bfb0bf681495821e80a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Fix an issue when setting an unaligned buffer where n is less
than the difference of the rounded up pointer and the pointer.
This was identified where n=1 was passed. n was decremented
once, as expected, then decremented again after the while()
evaluated to false. This resulted in a new n of 4GB.
Change-Id: I862671bbe7efa8d370d0148e22ea55407e260053
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/20655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
The memcpy(), memmove() and memcmp() functions use word by word
operations regardless of the pointer alignment. Depending on the
platform, this could lead to a crash.
This patch makes the memcpy(), memmove() or memcmp() operate byte per
byte if they are supplied with unaligned pointers.
Change-Id: I0b668739b7b58d47266f10f2dff2dc9cbf38577e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/20535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The optimization of the memset() function introduced by commit
dbadb1dd634c8c9419215ade0666a7fb69a4447b (libpayload: Reorder default
memcpy, speed up memset and memcmp) is provoking an issue on x86
platform when compiling without the CONFIG_GPL option.
GCC is making use of the movdqa instruction to copy words. This
instruction can raise a "General Protection Fault Exception" when it
is called on a non-aligned address argument.
Change-Id: I73382a76a4399d8e78244867f2ebb1dca176a6bf
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/20524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The word 'coreboot' should always be written in lowercase, even at the
start of a sentence.
Change-Id: I2ec18ca55e0ea672343a951ab81a24a5630f45fd
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
When console input driver registers itself, perform flush of input
buffer to avoid interpreting any stale key presses before libpayload
is run.
keyboard.c: Remove the redundant buffer flush.
8250.c: Ensure that serial_hardware_is_present is set before call to
add input driver.
BUG=b:37273808
TEST=Verified that any key presses in serial console before payload is
up do not have any effect after the payload starts running.
Change-Id: I46f1b6715ccf6418f5b2c741bf90db2ece26a60d
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19345
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
BUG=chrome-os-partner:56947
TEST=Verifed country code can be parsed from VPD in depthcharge.
BRANCH=None
Change-Id: I2fbbd4a784c50538331747e1ef78c33c6b8a679b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: acea6e2a200e8bd78fd458255ac7fad307406989
Original-Change-Id: I4616fefc6a377d7830397cdadb493927358e25cc
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/425819
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/18124
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This patch makes strtok_r:
- handle the end of the string
- handle string that contains only delimiters
- do not set ptr outside of str
Change-Id: I49925040d951dffb9c11425334674d8d498821f1
Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>
Reviewed-on: https://review.coreboot.org/16524
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I5a1d1ce8ba268b08d1275f392f0b9e602860c6ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1260729
Reviewed-on: https://review.coreboot.org/15957
Tested-by: build bot (Jenkins)
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Omar Pakker
|
|
Since r is a pointer, memset(r, 0, sizeof(r)) would only zero the first
4 (or 8) bytes of the newly allocated struct align_region_t.
An alternative to this patch would be to use calloc, or introduce a new
zalloc (zeroed allocation; a single-element calloc) and use that.
Change-Id: Ic3e3487ce749eeebf6c4836e62b8a305ad766e7e
Found-by: Coverity (ID 1291160)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14244
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This is adding complexity to the code more than it saves
space, plus some of the tables could potentially be interesting
outside of the ChromeOS context.
Change-Id: I4bf24608f3e26d3b7871a5031ae8f03bc2c8c21f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14070
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
When CONFIG_LP_TIMER_RDTSC is enabled honor the TSC information
exported in the coreboot tables as the cpu_khz frequency. That
allows get_cpu_speed() not to be called which currently relies
on the 8254 PIT. As certain x86 platforms allow that device
to be optional or turned off for power saving reasons, allow
a path where get_cpu_speed() is no longer called. Additionally,
this approach also allows the libpayload to not duplicate logic
that already exists in coreboot.
BUG=chrome-os-partner:50214
BRANCH=glados
TEST=Confirmed in payload TSC frequency is honored instead of
using get_cpu_speed().
Change-Id: Ib8993afdfb49065d43de705d6dbbdb9174b6f2c4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13671
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
If I wanted to fill the whole memory address space with one byte, I
wouldn't try it that subtle.
With size_t beeing unsigned the loop condition >= 0 was always true.
Change-Id: Idee6a4901f6697093c88bda354b5e43066c0d948
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11286
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
rdtsc() is only used for nvram access.
Change-Id: I896116d6a5782e5e50aa3acfbe1831b080f55d34
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11137
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Write boot media information in sysinfo, if it exists. This allows picking the
right CBFS for further files in case there are several.
Change-Id: I75a8ee6b93f349b9f2fab1e82826aba675949c0a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10869
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
They will become more common soon, so better support them now.
Change-Id: I2b16e1bb7707fe8410365877524ff359aeefc161
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This will make the code work with the different styles
of Kconfig (emit unset bools vs don't emit unset bools)
Roughly, the patch does this, and a little bit of fixing up:
perl -pi -e 's,ifdef (CONFIG_LP_.+?)\b,if IS_ENABLED\($1\),g' `find . -name *.[ch]`
perl -pi -e 's,ifndef (CONFIG_LP_.+?)\b,if !IS_ENABLED\($1\),g' `find . -name *.[ch]`
Change-Id: Ib8a839b056a1f806a8597052e1b571ea3d18a79f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10711
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Parse coreboot table and fill in mtc_start and mtc_size values in
sysinfo structure.
BUG=chrome-os-partner:41125
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt
Change-Id: If210ea0a105f6879686e6e930cb29e66bc5e6cd0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b70d0d35c85fa1a2317b0239276d5d9e7a550472
Original-Change-Id: I60b6f8ed4c704bd5ad6cce7fce2b9095babe181e
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/276778
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10563
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Who knows it still?
Change-Id: If6e36569cd9a1ba3da8b3fe84264cd2a6dfd634b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10443
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch adds a few bit counting functions that are commonly needed
for certain register calculations. We previously had a log2()
implementation already, but it was awkwardly split between some C code
that's only available in ramstage and an optimized x86-specific
implementation in pre-RAM that prevented other archs from pulling it
into earlier stages.
Using __builtin_clz() as the baseline allows GCC to inline optimized
assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and
to perform constant-folding if possible. What was previously named log2f
on pre-RAM x86 is now ffs, since that's the standard name for that
operation and I honestly don't have the slightest idea how it could've
ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm
with Float result, whereas the Find First Set operation has no direct
correlation to logarithms that I know of). Make ffs result 0-based
instead of the POSIX standard's 1-based since that is consistent with
clz, log2 and the former log2f, and generally closer to what you want
for most applications (a value that can directly be used as a shift to
reach the found bit). Call it __ffs() instead of ffs() to avoid problems
when importing code, since that's what Linux uses for the 0-based
operation.
CQ-DEPEND=CL:273023
BRANCH=None
BUG=None
TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new
log2() and __ffs() results on Falco for a bunch of test values.
Change-Id: I599209b342059e17b3130621edb6b6bbeae26876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f
Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273008
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add serial number to lib_sysinfo from coreboot table.
BRANCH=none
BUG=chrome-os-partner:37813
TEST=ryu boots and /proc/device-tree/firmware/android is populated
with "compatible", "hardware", and "serialno" properties
Change-Id: I565b332a16b177c51907ffab7976ebd7a665aaaf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5535119f5d499b04bdc178c3040241d2872c4e13
Original-Change-Id: Ie2e222780d1577689a1cbf76ae8514c74fc469f4
Original-Signed-off-by: Stephen Barber <smbarber@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/259140
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
A payload may want to run erase operations on SPI NOR flash without
re-probing the device to get its properties. This patch passes up
three properties of flash to achieve that:
- The size of the flash device
- The sector size, i.e., the granularity of erase
- The command used for erase
The patch sends the parameters through coreboot and then libpayload.
The patch also includes a minor refactoring of the flash erase code.
Parameters are sent up for just one flash device. If multiple SPI
flash devices are probed, the second one will "win" and its
parameters will be sent up to the payload.
TEST=Observed parameters to be passed up to depthcharge through
libpayload and be used to correctly initialize flash and do an erase.
TEST=Winbond and Gigadevices spi flash drivers compile with the changes;
others don't, for seemingly unrelated reasons.
BRANCH=none
BUG=chromium:446377
Change-Id: I92b7ff0ce66af8d096ec09a4c900829ef6c867e0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 988c8c68bbfcdfa69d497ea5f806567bc80f8126
Original-Change-Id: Ie2b3a7f5b6e016d212f4f9bac3fabd80daf2ce72
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239570
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9727
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds CB_TAG_RAM_CODE and an entry to sysinfo_t.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=Built and booted on pinky w/ depthcharge patch and saw that
/proc/device-tree/firmware/coreboot/ram-code contains correct
value
Change-Id: I35ee1bcdc77bc6d4d24c1e804aefdbbfaa3875a4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ca6d044f2e719ded1d78a5ab3d923e06c3b88d6b
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I69ee1fc7bc09c9d1c387efe2d171c57e62cfaf3f
Original-Reviewed-on: https://chromium-review.googlesource.com/231132
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8755
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
CQ-DEPEND=CL:228856
BUG=chrome-os-partner:33676
BRANCH=None
TEST=Compiles and boots to kernel prompt. ramoops console log verified after
causing kernel to fault.
Change-Id: I5af9b995113ee30ac60347acba8fa945fb5cd17a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 80c843fc78b137eb5540f8fefc4a69545b896fb6
Original-Change-Id: I8886015977e1fd999ef74fe73d08cff935cbce5c
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/228742
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8754
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The WiFi calibration blob saved in the CBMEM by coreboot needs to be
visible by depthcharge to supply it to the kernel.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none yet
Change-Id: I43a857f073a47ca315d400df4c53d5eb38e91601
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 46a649608e6740e07c562c722fadd8c64e264b5f
Original-Change-Id: Iecd8739c9269b58064b3c3275f5376cebcd6804b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225506
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8753
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
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>
|
|
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>
|
|
BUG=none
BRANCH=none
TEST=none
Change-Id: I56f357db6d37120772a03a1f7f84ce2a5b5620e9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/241855
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/8396
Tested-by: build bot (Jenkins)
|
|
In cases where timer clock frequency is not an integer number of
megahertz, the calculations in timer_us() lack accuracy.
This patch modifies calculations to reduce the error. The maximum
interval this calculation would support decreases, but it still is in
excess of 1844674 seconds for a timer clocked by 10 MHz, which is more
than enough.
BUG=none
TEST=manual
. verified timer accuracy using a depthcharge CLI command
Original-Change-Id: Iffb323db10e74b0ce3b4d59a56983bfee12e6805
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207358
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit e1abf87d438de1a04714482d5b610671e8cc0663)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia892726187ab040dd235f493c92856c15951cc06
Reviewed-on: http://review.coreboot.org/8128
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
|
|
The current default memcpy first copies single bytes to align the
amount, then copies the rest as full words. In practice, the start of a
buffer is much more likely to be word-aligned then the end, and aligned
word access are usually more efficient. This patch reorders those
accesses to first copy as many full words as possible and then finish
the rest with byte accesses to optimize this common case.
This fixes a data abort when using USB on ARM without CONFIG_GPL. Due to
some limitations of how DMA memory is set up in coreboot on ARM, it
currently does not support unaligned accesses. (This could be fixed with
a more complicated patch, but it's usually not an issue... unless, of
course, your memcpy happens to be braindead).
Also add word-aligned accesses to memset and memcmp while I'm at it, and
make memcmp's return value standard's compliant.
BUG=chrome-os-partner:24957
TEST=Manual
Original-Change-Id: I2a7bcb35626a05a9a43fcfd99eb958b485d7622a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/203547
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 05a64d2e107e1675cc3442e6dabe14a341e55673)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0030ca8a203c97587b0da31a0a5e9e11b0be050f
Reviewed-on: http://review.coreboot.org/8126
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds a console_kill_output_driver() function, which can
remove a previously registered output driver. This is mostly useful when
you overlay some output channel over another, such as when the GDB stub
takes direct control of the UART (and thus has to get rid of the
existing serial output driver).
BUG=chrome-os-partner:18390
TEST=None
Original-Change-Id: I6fce95c22fd15cd321ca6b2d6fbc4e3902b1eac3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202561
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 87680a246429d24e99b7b477b743c357f73b752c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I50001cee4582c962ceedc215d59238867a6ae95a
Reviewed-on: http://review.coreboot.org/8116
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Fix pointer related casts since this can create a problem for 64-bit systems.
BUG=None
BRANCH=None
TEST=Compiled successfully for link, nyan using emerge-* libpayload
Original-Change-Id: I4cbd2d9f1efaaac87c3eba69204337fd6893ed66
Original-Reviewed-on: https://chromium-review.googlesource.com/199564
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 914b118a64b0691aeca463dff24252db9c24109e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I11f070ed5d3eddd8b9be30c428cb24c8439e617b
Reviewed-on: http://review.coreboot.org/7905
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
|
|
1 << 63 is undefined for 32bit numbers.
Change-Id: I22f0e2486b133ea18cfbb8dd79fd4aed91ac0a4c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/7972
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The console output driver framework in libpayload is currently built on
the putchar primitive, meaning that every driver's function gets called
one character at a time. This becomes an issue when we add drivers that
could output multiple characters at a time, but have a high constant
overhead per invocation (such as the planned GDB stub, which needs to
wrap a special frame around output strings and wait for an
acknowledgement from the server).
This patch adds a new 'write' function pointer to the
console_output_driver structure as an alternative to 'putchar'. Output
drivers need to provide at least one of the two ('write' is preferred if
available). The CBMEM console driver is ported as a proof of concept
(since it's our most performace-critical driver and should in theory
benefit the most from less function pointer invocations, although it's
probably still negligible compared to the big sprawling mess that is
printf()).
Even with this fix, the problem remains that printf() was written with
the putchar primitive in mind. Even though normal text already contains
an optimization to allow multiple characters at a time, almost all
formatting directives cause their output (including things like
padding whitespace) to be putchar()ed one character at a time.
Therefore, this patch reworks parts of the output code (especially
number printing) to all but remove that inefficiency (directives still
invoke an extra write() call, but at least not one per character). Since
I'm touching printf() core code anyway, I also tried to salvage what I
could from that weird, broken "return negative on error" code path (not
that any of our current output drivers can trigger it anyway).
A final consequence of this patch is that the responsibility to prepend
line feeds with carriage returns is moved into the output driver
implementations. Doing this only makes sense for drivers with explicit
cursor position control (i.e. serial or video), and things like the
CBMEM console that appears like a normal file to the system really have
no business containing carriage returns (we don't want people to
accidentally associate us with Windows, now, do we?).
BUG=chrome-os-partner:18390
TEST=Made sure video and CBMEM console still look good, tried printf()
with as many weird edge-case strings as I could find and compared serial
output as well as sprintf() return value.
Original-Change-Id: Ie05ae489332a0103461620f5348774b6d4afd91a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196384
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit ab1ef0c07736fe1aa3e0baaf02d258731e6856c0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I78f5aedf6d0c3665924995cdab691ee0162de404
Reviewed-on: http://review.coreboot.org/7880
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ie5c279ef90bd9ed5e2624bf852dcff1f06531a13
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4767
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
`*memory` is not changed in `hexdump()` and just read so make it
`const`.
Change-Id: I9504d25ab5c785f05c39c9a4f48c21f68659a829
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5403
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This function returns the number of microseconds scaled from the number of raw
timer ticks. It accepts a base parameter which is subtracted from the current
time, which makes it easy to keep track of relative times.
Change-Id: I55f2f9e90c0e12cda430bbe88b044f12b0b563c8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179600
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4dd549e18d170dbf918c5b4b11bbe1f4e99b6695)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6897
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
If a programming error is detected, die can be used to print a message and
stop execution similar to failing an assert. There's also a "die_if" function
which is conditional.
die functions, like asserts, should be used to trap programming errors and not
when the hardware does something wrong. If all code was written perfectly, no
die function would ever be called. In other words, it would be appropriate to
use die if a function was called with a value that was out of bounds or if
malloc failed. It wouldn't be appropriate if an external device doesn't
respond.
In the future, the die family of functions might print a stack trace or show
other debugging info.
Old-Change-Id: I653fc8cb0b4e459522f1b86f7fac280836d57916
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178000
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 59df109d56a0f5346562de9b3124666a4443adf0)
libpayload: Fix the license in some files which were accidentally made GPL.
Some files were accidentally made GPL when they were added to libpayload. This
change changes them over to a BSD license to be in line with the intended
license of libpayload.
Old-Change-Id: Ia95ac4951b173dcb93cb489705680e7313df3c92
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182202
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5f47600e50e82de226f2fa6ea81d4a3d1c56277b)
Squashed the initial patch for "die" functions and a later update to
the license header.
Change-Id: I3a62cd820e676f4458e61808733d81edd3d76e87
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6889
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Since the DMA memory is allocated by Coreboot (outside of the payload's
linker script), it won't get zeroed upon loading like the heap.
Therefore, a warm reboot that doesn't reset memory may leave stale
malloc cookies lying around and misinterpret them as memory that is
still in use on the next boot. After several boots this may fill up the
whole DMA memory and lead to OOM conditions.
Therefore, this patch explicitly wipes the first cookie in
init_dma_memory() to prevent that from happening. It also expands the
existing memory allocator debugging code to cover the DMA parts, which
was very helpful in identifying this particular problem.
Change-Id: I6e2083c286ff8ec865b22dd922c39c456944b451
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169455
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 8e5e1784638563b865553125cd5dab1d36a5d2cb)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6645
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch makes the EHCI driver work on ARM platforms which usually do
not support automatic cache snooping. It uses the new DMA memory
mechanism (which needs to be correctly set up in the Coreboot mainboard
code) to allocate all EHCI-internal communication structures in
cache-coherent memory, and cleans/invalidates the externally supplied
transfer buffers in Bulk and Control functions with explicit calls as
necessary.
Old-Change-Id: Ie8a62545d905b7a4fdd2a56b9405774be69779e5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167339
(cherry picked from commit 322338934add36a5372ffe7d2a45e61a4fdd4a54)
libpayload: ehci: Cache management is hard, let's go copying...
It turns out that my previous commit to make the EHCI stack cache aware
on ARM devices wasn't quite correct, and the problem is actually much
trickier than I thought. After having some fun with more weird transfer
problems that appear/disappear based on stack alignment, this is my
current worst-case threat model that any cache managing implementation
would need to handle correctly:
Some upper layer calls ehci_bulk() with a transfer buffer on its stack.
Due to stack alignment, it happens to start just at the top of a cache
line, so up to 64 - 4 bytes of ehci_bulk's stack will share that line.
ehci_bulk() calls dcache_clean() and initializes the USB transfer.
Between that point and the call to dcache_invalidate() at the end of
ehci_bulk(), any access to the stack variables in that cache line (even
a speculative prefetch) will refetch the line into the cache. Afterwards
any other access to a random memory location that just happens to get
aliased to the same cache line may evict it again, causing the processor
to write out stale data to the transfer buffer and possibly overwrite
data that has already been received over USB.
In short, any dcache_clean/dcache_invalidate-based implementation that
preserves correctness while allowing any arbitrary (non cache-aligned)
memory location as a transfer buffer is presumed to be impossible.
Instead, this patch causes all transfer data to be copied to/from a
cache-coherent bounce buffer. It will still transfer directly if the
supplied buffer is already cache-coherent, which can be used by callers
to optimize their transfers (and is true by default on x86).
Old-Change-Id: I112908410bdbc8ca028d44f2f5d388c529f8057f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169231
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 702dc50f1d56fe206442079fa443437f4336daed)
Squashed the initial commit and a follow up fix.
Change-Id: Idf7e5aa855b4f0221f82fa380a76049f273e4c88
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6633
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds a mechanism to set aside a region of cache-coherent
(i.e. usually uncached) virtual memory, which can be used to communicate
with DMA devices without automatic cache snooping (common on ARM)
without the need of explicit flush/invalidation instructions in the
driver code.
This works by setting aside said region in the (board-specific) page
table setup, as exemplary done in this patch for the Snow and Pit
boards. It uses a new mechanism for adding board-specific Coreboot table
entries to describe this region in an entry with the LB_DMA tag.
Libpayload's memory allocator is enhanced to be able to operate on
distinct types/regions of memory. It provides dma_malloc() and
dma_memalign() functions for use in drivers, which by default just
operate on the same heap as their traditional counterparts. However, if
the Coreboot table parsing code finds a CB_DMA section, further requests
through the dma_xxx() functions will return memory from the region
described therein instead.
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
(cherry picked from commit d142ccdcd902a9d6ab4d495fbe6cbe85c61a5f01)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6622
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Representing a (non-negative) length with a signed integer is not
optimal, so change its type to `size_t`.
Change-Id: Ic0c2b7e081ba32d917409568ee53007d9ab7f8f3
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4768
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
You might want to use the serial hardware for something other than a console,
or you might want to intercede in the serial stream to wrap it in another
protocol. This is what you'd do to send output to GDB while using it to debug
the payload.
Change-Id: I2218c0dbb988dacb64e5bdaf5d92138828eff8b6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179559
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit da9ab46d974745125fe7d8b29ce43336c3586cd5)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6547
Tested-by: build bot (Jenkins)
|
|
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This change makes it possible for vboot to avoid an
exploit that could cause involuntary switch to dev mode.
It gives depthcharge/vboot some information on the
type of input device that generated a key.
BUG=chrome-os-partner:21729
TEST=manually tested for panther
BRANCH=none
CQ-DEPEND=CL:182420,CL:182241,CL:182946
Change-Id: I87bdac34bfc50f3adb0b35a2c57a8f95f4fbc35b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/182357
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: http://review.coreboot.org/6003
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
