The value from raw_read_cntfrq_el0() could be large enough to cause
overflow when multiplied by USECS_PER_SEC. To prevent this, both
USECS_PER_SEC and hz can be reduced by dividing them by their GCD.
This patch also modifies the return type of `timer_hz()` from
`uint64_t` to `uint32_t`, assuming that in practice the timestamp
counter should never be that fast.
BUG=b:307790895
TEST=boot to kernel and check the timestamps from `cbmem`
Change-Id: Ia55532490651fcf47128b83a8554751f050bcc89
Signed-off-by: Yidi Lin <yidilin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78888
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Patch adds:
- vboot_fail_and_reboot() for vboot failures handling.
- reboot() weak implementation for payloads to implement, used
by vboot_fail_and_reboot().
- vboot_recovery_mode_enabled() to check if recovery mode flag is set in
vboot context. Implemented for future libcbfs implementation
of VBOOT_CBFS_INTEGRATION in libpayload.
BUG=b:197114807
TEST=none
Change-Id: I53d1955573d54bc56d05f7780c18dcc8ac1fd399
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
To fully and easily implement fallback/recovery in libcbfs with vboot
support the codebase requires access to vboot context. Moving context
management to libpayload allows to avoid unnecessary overhead and code
complication and still allows payloads to access it in a way it was
designed. Access to this codebase will also allow implementation of e.g.
vboot_fail_and_reboot() and other helpful utilities used by coreboot and
depthcharge.
BUG=b:197114807
TEST=make unit-tests
TEST=Build and boot on google/ovis4es with CL:4839296 and
VBOOT_CBFS_INTEGRATION enabled
Change-Id: Id719be7c4f07251201424b7dc6c1125c6b5756d8
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Clang does not recognize comments to indicate falltrough is intended
behavior.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Idcf7a24fc763b80863902702172b4ea950e132b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77431
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add commonlib/bsd/elog dependency in libpayload. This will allow other
payloads (e.g. depthcharge) to implement their own eventlog read and
write utilities.
Also include commonlib/bsd/elog.c source to libc-srcs. This ensure
payloads could utilize commonlib elog helper functions.
Change-Id: I64d0fdd2a8eff1d89a1ac451d37b61787b5564e7
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add 'lb_fill_pcie' function to pass PCIe information from coreboot to
libpayload, and add CB_ERR_NOT_IMPLEMENTED to the cb_err enum for the
__weak function.
ARM platform usually does not have common address for PCIe to access the
configuration space of devices. Therefore, new API is added to pass the
base address of PCIe controller for payloads to access PCIe devices.
TEST=Build pass and boot up to kernel successfully via SSD on Dojo
board, here is the SSD information in boot log:
== NVME IDENTIFY CONTROLLER DATA ==
PCI VID : 0x15b7
PCI SSVID : 0x15b7
SN : 21517J440114
MN : WDC PC SN530 SDBPTPZ-256G-1006
RAB : 0x4
AERL : 0x7
SQES : 0x66
CQES : 0x44
NN : 0x1
Identified NVMe model WDC PC SN530 SDBPTPZ-256G-1006
BUG=b:178565024
BRANCH=cherry
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: I6cdce21efc66aa441ec077e6fc1d5d1c6a9aafb0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Shelley Chen <shchen@google.com>
Replace 'struct lb_uint64' with 'typedef __aligned(4) uint64_t
lb_uint64_t', and remove unpack_lb64/pack_lb64 functions since it's no
longer needed.
Also replace 'struct cbuint64' with 'cb_uint64_t' and remove
'cb_unpack64' in libpayload for compatible with lb_uint64_t.
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: If6b037e4403a8000625f4a5fb8d20311fe76200a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63494
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
cb_err_t was meant to be used in place of `enum cb_err` in all
situations, but the choice to use a typedef here seems to be
controversial. We should not be arbitrarily using two different
identifiers for the same thing across the codebase, so since there are
no use cases for serializing enum cb_err at the moment (which would be
the primary reason to typedef a fixed-width integer instead), remove
cb_err_t again for now.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaec36210d129db26d51f0a105d3de070c03b686b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62600
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
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>
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>
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>
Yidi Lin