While we assume a keyboard is attached, we send an echo command every
500ms. If there is no data coming from the keyboard within 200ms, we
assume it was detached.
Correspondingly, if we assume no keyboard is attached, we run an echo
command once per second.
Change-Id: I2c75182761729bf30711305f3d8b9d43eafad675
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47593
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This is already the case on x86 but not on the ARM platforms, and
{read,write}[bwl] are using volatile pointers, too, so follow suit.
Change-Id: I6819df62016990e12410eaa9c3c97b8b90944b51
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The new `Makefile.payload` can be included by the Makefiles of pay-
loads for in-tree builds. The basic idea is to use libpayload's
build results without the `make install` step, and to ensure that
incremental builds work. For instance, if libpayload's code changes,
a `make` for the payload would automatically update the libpayload
build and rebuild the payload. But if there are no code changes in
libpayload, only updated files of the payload will be re-built.
The configuration of libpayload is supposed to be automatically
generated from a `defconfig` file. If this `defconfig` changes,
libpayload and the payload will be re-built.
Change-Id: If5319f1bf0bcd09964416237c5cf7f8e59f487a2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47633
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add read64 and write64 for consistency with x86.
BUG=b:178785769
Change-Id: I342e3a23201d0b804ea5ecfe47ee3e4bb516de4c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
It either doesn't exist (in-tree builds) or is the same as $_LIBDIR.
Change-Id: I9551cbfc3295d86c22a3785be7cdc0f65eeb08c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47632
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We only need `$_OBJ` in the include path for in-tree builds. Also,
curses only need special handling for those and PDCurses turned out
to need many more include paths.
Change-Id: Idd29ef33065033e26ba61b09d412d8ca3566d643
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of checking for an already fully build `libpayload.a`, we check
for the `libpayload.config` which is the actual prerequisite to start
using `lpgcc`. This will allow compilation of payload sources before or
in parallel with the build of `libpayload.a`.
Change-Id: Ic0143fefe33560af8b013ae48bbbe231b3ad46f3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Introduce a `$_OBJ` variable, that points to the build directory for
in-tree usage of `lpgcc`. If unset, the default `../build` relative
to the location of `lpgcc` is used.
Change-Id: I35112d7533d69aa51252dd2bceec010a62522403
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47629
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This should make it easier to find the correct config for in-tree
builds.
Change-Id: I08d396ae3cedc65f63c4b8865701ea123c7d56cb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47628
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Keep libpayload's xcompile in its build dir. While we are at it,
align things with the top-level version.
Having `.xcompile` in a central place led to race conditions when
multiple payloads try to build their own libpayloads in parallel.
Change-Id: I504e1862db79b368289867f7568c9169f27a1549
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The keyboard self-test is required for some devices. At least one
device (integrated keyboard in a ThinkPad X201) actually starts the
test automatically leading to spurious output and no response for
the first seconds.
We wait up to 5s for the self-test result. On failure or timeout,
the command will be repeated until the 30s init timer runs out. This
happens all in the background of the UI polling loop.
To not unnecessarily delay the boot process, we first try an oppor-
tunistic initialization which skips the self-test.
Change-Id: Ie07b31e74d06e116ac81e76309621eed39a19b49
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Will be used to time out in states that don't always advance.
Change-Id: I28235e7638d8157cedf81fd915a41d28a1fc070b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47087
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We'll process the init sequence as part of the polling loop. This
should have several advantages:
* It eases error handling, i.e. we can return to an earlier state.
* We don't have to stall initialization when a keyboard takes a
little longer.
* Generally, these keyboards can be hot-plugged (albeit not by
design).
Change-Id: I9cf5cf31eb420b3994bec20e56a72d37f3d2996e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Draining the keyboard's buffer is only possible when the keyboard
port is enabled. We should also disable input scanning before, as
the buffer could be filled again with new keystrokes otherwise.
Change-Id: Ibac9c0d04880ff4a3efda5ac53da2f9731f6602c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Move the input-buffer draining into a function. It uses the low-level
i8042 API directly to avoid conflicts with changes in the high-level
keyboard API.
Change-Id: I9427c5b8be4d59c2ee3da12d6168d34590043682
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47084
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even if we are careful, it's still possible that we read spurious
data from the keyboard, e.g. keystrokes. Namely, when we send the
reset/disable command, there is a race before the command is pro-
cessed.
So we should always process data from the keyboard in a loop. We
break it, when an ACK (0xfa) or a NAK (0xfe) is received, and warn
on unexpected data unless it might be due to the mentioned race.
This also gives us the opportunity to use command-specific timeouts
which we take from Linux: 1s for the keyboard self-test (as there
are keyboards that perform the test before acking the command) and
200ms for all other commands.
Change-Id: I60a2643a8ff4b9231c63bf970c8749c97c7d8926
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some background first: The original XT keyboards used what we call
scancode set #1 today. The PC/AT keyboards introduced scancode set #2,
but for compatibility, its controller translated scancodes back to
set #1 by default. Newer keyboards (maybe all we have to deal with)
also support switching the scancode set.
This means the translation option in the controller and the scancode
set selection in the keyboard have to match. In libpayload, we only
support set #1 scancodes. So we either need the controller's trans-
lation on and set #2 selected in the keyboard, or the controller's
translation off and set #1 selected in the keyboard.
Valid configurations:
* SET #1 + XLATE off
* SET #2 + XLATE on
Both with and without the PC_KEYBOARD_AT_TRANSLATED option, we were
only configuring one of the two settings, leaving room for invalid
configurations. With this change, we try to select scancode set #2
first, which seems to be the most supported one, and configure the
controller's translation accordingly. We try to fall back to set #1
on failure.
We also keep translation disabled during configuration steps to
ensure that the controller doesn't accidentally translate confi-
guration data.
On the coreboot side, we leave the controller's translation at its
default setting, unless DRIVERS_PS2_KEYBOARD is enabled. The latter
enables the translation unconditionally. For QEMU this means that
the option effectively toggles the translation, as QEMU's controller
has it disabled by default. This probably made a lot of earlier
testing inconsistent.
Fixes: commit a95a6bf646 (libpayload/drivers/i8402/kbd: Fix qemu)
The reset introduced there effectively reverted the scancode
selection made before (because 2 is the default). It's unclear
if later changes to the code were only necessary to work
around it.
Change-Id: Iad85af516a7b9f9c0269ff9652ed15ee81700057
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
Provide get_mmu_ranges() for ARM64 to let payloads could get
MMU ranges for all used memory regions.
BUG=b:171858277
TEST=Build in x86, arm, arm64.
emerge-zork libpayload depthcharge
emerge-nyan libpayload depthcharge
emerge-asurada libpayload depthcharge
Signed-off-by: Meng-Huan Yu <menghuan@google.com>
Change-Id: I39b24aefc9dbe530169b272e839d0e1e7c697742
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
This turns on the compiler's printf style format string checker.
BUG=b:167517417
TEST=enabled all USB controllers on volteer and fixed resulting
compiler errors when USB_DEBUG is enabled.
Change-Id: Ic94ebcbafdde8a5f79278b5635111b99af40f892
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45025
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes format string mismatch errors in the USB subsystem found by
the compiler's format string checker.
BUG=b:167517417
TEST=enabled all USB controllers on volteer and fixed resulting
compiler errors when USB_DEBUG is enabled.
Change-Id: I4dc70baefb3cd82fcc915cc2e7f68719cf6870cc
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The current timeout of 500ms is too low. For instance self-test
of the KBC integrated into IT8516E took almost 1s in tests. We
already check for presence of the KBC before the self-test. So
the timeout should only trigger on a hardware defect and we can
leave some margin.
Change-Id: I95f01a4e605a9c7deb894a71e102c3a881759bb1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47588
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Work on this mainboard was abandoned and never finished. It's not really
usable in its current state, so let's get rid of it.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4cd2e2cd0ee69d9846472653a942fa074e2b924d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The OHCI header file declares various enums as follows:
enum { ... } enum_name;
Since the name is at the end, this is actually declaring a variable
called enum_name and *not* a type, which is causing a multiple
definition error in GCC 10. Move the enum_name before the opening brace
to prevent this.
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I452c0a1b118990942aa53f1e7e77f5e8378e8975
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Headers in libpayload define various structs like so:
struct struct_name { ... } __packed;
However, these header files do not include the compiler.h macro that
defines what __packed is, so they are actually defining a variable named
__packed and *not* declaring a packed struct. This leads to defining the
same variable multiple times, which was caught by GCC 10. Add compiler.h
to the compiler parameters so it is included in all files automatically.
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: Ia67182520dc94149e06fe9e03a14b3fc2ee29973
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47153
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Link time optimization is a technique for whole-program optimization.
Instead of doing code generation during compilation, the compiler saves
its intermediate representation to the object files. During the final
linking step, it will then merge all the object files together and
perform optimizations on the entire program. This can often reduce the
final binary size, but also may increase the total compilation time.
This patch introduces a Kconfig option for enabling link time
optimization in libpayload. Since libpayload does no linking of its own,
its LTO archive files will contain only IR and no generated code.
Downstream projects will need to use LTO-aware tools when manipulating
the archives (eg. gcc-ar and gcc-nm), but otherwise do not need to use
LTO themselves -- the compiler will recognize which files are LTO and
which are not, so enabling this option should mostly be "drop in".
For example, when building coreinfo.elf using tinycurses libpayload:
binary size compilation time
default 114 KiB 11.49s
LTO 95 KiB 10.36s
In this case the total compilation time was actually shorter -- despite
the final linking step taking longer, this was offset by the shorter
compilation times for each individual file (since there is no code gen
until the very end).
Change-Id: I048f2ff6298ed0d891098942e1e8b29d35487b91
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38291
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We can skip the PIT-based TSC calibration if we can derive the invariant
TSC rate from CPUID/MSR data. This is necessary if the PIT is disabled,
which is the default, for instance, on Coffee Lake CPUs.
This implementation should cover all Intel Core i processors at least.
For older processors, we fall back to the PIT calibration.
Change-Id: Ic6607ee2a8b41c2be9dc1bb4f1e23e652bb33889
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34170
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The list is incomplete and only contains what we need in the follow-up
commit. It can be extended at will.
Change-Id: Ibf8ddaf510eb513ee74af3e78da46b04802a91b9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
There's no need for the global list of files to ignore, so use git's
ability to work with more local configuration.
Change-Id: I50882e6756cbc0fdfd899353cc23962544690fb3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46879
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use `bool` whenever `0` was used to indicate an error. The mixing of
different types for return values was mildly confusing and potentially
dangerous with the i8042 API close by that uses `0` for success.
Change-Id: I876bb5076c4921f36e3438f359be8ac4c09248cc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46723
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
SMMSTORE version 2 is a complete redesign of the current driver. It is
not backwards-compatible with version 1, and only one version can be
used at a time.
Key features:
* Uses a fixed communication buffer instead of writing to arbitrary
memory addresses provided by untrusted ring0 code.
* Gives the caller full control over the used data format.
* Splits the store into smaller chunks to allow fault tolerant updates.
* Doesn't provide feedback about the actual read/written bytes, just
returns error or success in registers.
* Returns an error if the requested operation would overflow the
communication buffer.
Separate the SMMSTORE into 64 KiB blocks that can individually be
read/written/erased. To be used by payloads that implement a
FaultTolerant Variable store like TianoCore.
The implementation has been tested against EDK2 master.
An example EDK2 implementation can be found here:
eb1127744a
Change-Id: I25e49d184135710f3e6dd1ad3bed95de950fe057
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The PCI bus gets already scanned while gathering system information.
Therefore, use the pacc pointer from sysinfo_t to read the device class
of PCI devices instead of rescanning the bus.
Change-Id: I4c79e71777e718f5065107ebf780ca9fdb4f1b0c
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46416
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Currently, the PCI bus gets scanned multiple times for various reasons
(e.g. to read the device class). Therefore, and in preparation to
CB:46416, introduce the pacc pointer in the sysinfo_t struct and scan
the PCI bus while gathering system information.
Change-Id: I496c5a3d78c7fb5d7c9f119a0c9a0314d54e729f
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
32-bit LBA limits drives, that have or emulate 512B sectors, to 2TiB
capacity. Therefore, enable the 64-bit support.
Change-Id: I663029a2137c5af3c77d576fe27db0b8fa7488a9
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46534
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Since the list of tested controllers is not actively maintained, enable
all AHCI controllers by default. Also, improve the readability of its
help text by adding a comma to it.
Change-Id: If30f58f8380ab599f8985e85c64510dc88e96268
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The device class is read at different places and it is read from the
hardware directly. Therefore, and in preparation to CB:46416, introduce
the device class attribute in the pci_dev struct. With this, there is
only one interaction with the hardware and it's also more user friendly.
Change-Id: I5d56be96f3f0da471246f031ea619e3df8e54cfb
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46347
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 initialization of the 'equals' counter is incorrect, so that
when 'equals >= SSZ * SSZ', the pixels in the sample array might not be
all the same, leading to a wrong pixel value being set in the
framebuffer.
The 'equals' counter stores the number of latest pixels that were
exactly equal. Within the for loop of 'ox', the sample array is updated
in a column-based order, and the 'equals' counter is updated
accordingly. However, the 'equals' counter is initialized in a row-based
order, which causes it to be set too large than it should be. Consider
the example where sample[sx][sy] are initially:
[X X X A A A] // sy = 0
[X X X B B B]
[X X X B B B]
[X X X B B B]
[X X X B B B]
[X X X B B B] // sy = SSZ
Then, the correct implementation will initialize 'equals' to be 15, with
last_equal being B. Suppose all of the remaining pixels are B. Then, at
the end of the 'while (fpfloor(ixfp) > ix)' loop when ix = 4, or
equivalently after 4 more columns of sample are updated, 'equals' will
be 15 + 6 * 4 = 39, which is greater than SSZ * SSZ = 36, but we can see
there are still 2 A's in the sample:
[B B B B A A]
[B B B B B B]
[B B B B B B]
[B B B B B B]
[B B B B B B]
[B B B B B B]
Therefore, we must also initialize the 'equals' counter in a
column-based order.
BUG=b:167739127
TEST=emerge-puff libpayload
TEST=Character 'k' is rendered correctly on puff
BRANCH=zork
Change-Id: Ibc91ad1af85adcf093eff40797cd54f32f57111d
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.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>
According to the xHCI spec, the Slot State field in the Slot Context
Data Structure is 5 bits wide. So, fix the code to match.
ref. xHCI spec 1.2
section 6.2.2, Figure 6-2: Slot Context Data Structure
BUG=none
TEST=xHCI compiles
Change-Id: I0ae735af3d0840aeee846fa939c37af9aea3dff1
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45023
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We do not need to set the CS (Command Stop) bit in the Command Ring
Control Register. CS is implied by CA (Command Abort). I'm not sure if
there is a defined execution order for these command bits, so it's
safer to only use the CA bit as it includes the CS function.
Ref: xHCI spec 1.2 (May 2019), Section 5.4.5, Table 5-24.
BUG=b:160354585,b:157123390
TEST=able to boot into recovery using USB stick on servo v2 on volteer
as well as HooToo 8-1 hub
Change-Id: Iaeba98b6da8da49f529358ca6d68270440ea0f42
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44876
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This fixes issues with how we handle events generated by the xHCI
"command abort" command. first, depending on the state of the xHCI
controller, the COMMAND_ABORTED may not be generated. If the
controller was between commands, only the COMMAND_RING_STOPPED event
will be generated. Second, do not adjust the command ring "cur"
pointer as that just confuses the controller.
BUG=b:160354585,b:157123390
TEST=able to boot into recovery using USB stick on servo v2 on volteer
as well as HooToo 8-1 hub
Change-Id: I055df680d1797f35d9730e2bfdb4119925657168
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44875
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
For payloads with UI based on CBGFX, they usually start by calling
clear_canvas or clear_screen and then draw the UI elements. However,
that makes the screen flicker.
A typical solution is to identify and minimize the area to redraw.
However for payloads with complicated UI and do not care about latency,
an alternative is to enable buffered I/O.
The new enable_graphics_buffer() will redirect all graphics I/O
into an invisible working buffer. To flush (redraw) the buffer to the
real screen, call flush_graphics_buffer(). To stop buffering, call
disable_graphics_buffer().
BUG=None
TEST=Add the enable, flush and disable calls to payload 'depthcharge',
built a firmware and boots into Chrome OS recover UI. No more
flickering. The average rendering time on x86 platform is 1.2ms.
Change-Id: Id60a2824fd9e164feae16b92b68b003beabea8d3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44654
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
libpayload's drivers keep growing. With certain hardware/payload
combinations (last time witnessed with Kontron/bSL6 and FILO), the
default configuration runs out of memory.
As there is a lot enabled by default, also set a big default heap size.
Tested with FILO on QEMU/Q35.
Change-Id: I51a1514097aeb8b3c835a2387db66869b81d0bcc
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44176
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Similar to set_blend(), add set_color_map() for mapping background and
foreground colors of a bitmap. Also add clear_color_map() for clearing
the saved color mappings.
Note that when drawing a bitmap, the color mapping will be applied
before blending.
Also remove unnecessary initialization for static variable 'blend'.
BRANCH=puff
BUG=b:146399181, b:162357639
TEST=emerge-puff libpayload
Change-Id: I640ff3e8455cd4aaa5a41d03a0183dff282648a5
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44375
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This ensures that it's available under BSD license terms.
Change-Id: Ica13014b847473fee02516be0b27684c6cfb07bc
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43964
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a function draw_line() to draw either a horizontal or vertical line
segment.
Theoretically a horizontal line can also be drawn by calling
draw_rounded_box() with dim_rel.x being the line length and dim_rel.y
being the line width. However, due to the truncation in integer division
when converting relative coordinates to absolute ones, this will
potentially produce inconsistent line widths, depending on the value of
pos_rel.y.
It is guaranteed that draw_line() will produce consistent line widths,
regardless of the position of the line. Also, when the thickness
argument is zero, this function is able to draw a line with 1-pixel
width, which is not achievable by draw_rounded_box().
BRANCH=puff
BUG=b:146399181, b:161424726
TEST=emerge-puff libpayload
Change-Id: I2d50414c4bfed343516197da9bb50791c89ba4c2
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
With commit 287cf6c7d1 (lp/drivers/usb: Work around QEMU XHCI
register issue) we restructured our capability register accesses
because the compiler used the wrong access size. While we do use
only 32-bit types now, a compiler may still try to be clever and
optimize things in unexpected ways. So we add an explicit read32()
now.
For instance for the 8-bit MaxPorts field, in the most significant
bits of `capreg + 4`, our read + mask + shift
((cap)->hciparams1 & 0xff000000) >> 24
was turned into a single 8-bit read instruction by GCC on x86:
31: 0f b6 52 07 movzbl 0x7(%edx),%edx
Change-Id: I76accd0ef718e70ca46807eb06a9177c3afd99f1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43575
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Extend the local APIC timer delay so that it can be started,
and waited for, independently.
Add an EOI so that more than one APIC timer interrupt is possible.
Previous to this, because there was no EOI, the first timer
interrupt the CPU took was also the last it would take --
apic_delay would only work one time.
Change-Id: Ib11aeee5b7da81287166ac68fc327e7ae62d1b84
Signed-off-by: Ronald G Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Up until now we have no way of adding transparency into our firmware
screens. Add set_blend() and clear_blend() functions to store alpha
value and rgb values to calculate alpha blending in
calculate_colors().
BUG=b:144969091,b:160839199
BRANCH=puff
TEST=dut-control power_state:rec
press ctrl-d
Ensure background is dimmed when dialog pops up
Change-Id: I95468f27836d34ab80392727d726a69c09dc168e
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch improves the image resampling (scaling) code in CBGFX to use
the Lanczos algorithm that is widely considered the "best" resampling
algorithm (e.g. also the first choice in Python's PIL library). It is of
course much more elaborate and therefore slower than bilinear
resampling, but a lot of the difference can be made up with
optimizations, and the resulting code was found to still produce
acceptable speeds for existing Chrome OS UI use cases (on an Arm
Cortex-A55 device, time to scale an image to 1101x593 went from ~88ms to
~275ms, a little over 3x slowdown). Nevertheless, if this should be too
slow for anyone there's also an option to tune it down a little, but
still much better than bilinear (same operation was ~170ms with this).
Example images (scaled up by a factor of 7):
Old (bilinear): https://i.imgur.com/ytr2n4Z.png
New (Lanczos a=3): https://i.imgur.com/f0vKluM.png
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Idde6f61865bfac2801ee4fff40ac64e4ebddff1a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42792
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>
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>
No other architecture in libpayload outputs anything in the main entry
routine. Let alone an exception test which looks like a real exception
to the normal user and is most likely really misleading. Silence the
startup code.
Change-Id: I6e49f24ad46ce578a4bb111c2d623ca4470a1866
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43126
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There is no bfd "arm64". The correct bfdname is "aarch64". Fix it. With
this change libpayload will build with the AArch64 GCC.
Change-Id: If7a6b14691107c5d4fc67c3cd3990ecc849d4af1
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
log2(1) is 0 and log2(0) is -1. If we have the int64_t 0xffffffff then
log2(0xffffffff >> 31) = log2(0x1) = 0, so the current reduction code
would not shift. That's a bad idea, though, since 0xffffffff when
interpreted as an int32_t would become a negative number.
We need to always shift one more than the current code does to get a
safe reduction. This also means we can get rid of another compare/branch
since -1 is the smallest result log2() can return, so the shift can no
longer go negative now.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib1eb6364c35c26924804261c02171139cdbd1034
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Fix potential overflow when multiplying integers in transform_vector().
This issue is causing the absolute coordinate of the bottom right corner
of the box to be incorrectly calculated for draw_rounded_box(), which is
used in menu UI to clear the previous screen.
In addition, check the lower bound in within_box().
BRANCH=none
BUG=b:146399181, b:159772149
TEST=emerge-puff libpayload
TEST=Previous screen is cleared properly for menu UI
Change-Id: I57845f54e18e5bdbd0d774209ee9632cb860b0c2
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42770
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Shelley Chen <shchen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the stub video_console_init() removed from depthcharge in
CL:2241493, depthcharge will fail to compile:
payloads/libpayload/gdb/stub.c:76: undefined reference to
`video_console_init'
Since video_console_init() is meant to be implemented in
libpayload, libpayload should be consistent with itself by not calling
this function when it's not implemented (i.e., when !LP_VIDEO_CONSOLE).
Therefore, initialize video console only if LP_VIDEO_CONSOLE is set.
BRANCH=none
BUG=none
TEST=USE="menu_ui" emerge-gale depthcharge
Change-Id: Ic45f9073330258cb77301003484ec525b2404180
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42505
Reviewed-by: Joel Kitching <kitching@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes a logic bug in how timeouts are reported back. In the
timeout case, the original code would return -1 instead of 0. All call
sites expect a return value of 0 as the timeout indicator.
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Change-Id: I81a888aa0a1544e55e6a680be8f3b7f6e0d87812
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This adds a hook so that a payload can optionally perform USB service
functions in conjunction with regular USB port status polling. In
particular, this allows depthcharge to control the state of an
external USB mux. Some SoCs like Tiger Lake have a USB mux for Type-C
ports that must be kept in sync with the state of the port as reported
by the TCPC. This can be achieved by hooking into the poll routine to
refresh the state of the USB mux.
BUG=b:149883933
TEST=booted into recovery from Type-C flash drive on volteer
Change-Id: Ic6c23756f64b891b3c5683cd650c605b8630b0fb
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@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>
When drawing two adjacent boxes with draw_box(), there will be a gap
between them. This is due to the truncation in integer division when
calculating the bottom right coordinate of the box.
In this patch, the relative bottom right coordinate is calculated before
transforming to an absolute one. The same issue is also fixed for
draw_rounded_box().
Also check validity of 'pos_rel' and 'dim_rel' arguments for
draw_rounded_box().
BRANCH=none
BUG=chromium:1082593
TEST=emerge-nami libpayload
Change-Id: I073cf8ec6eb3952a0dcb417b4c3c3c7047567837
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41392
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>
The latest Intel FSP advertises xHCI v1.2 chipset support, so update
libpayload to include that version. No critical changes were identified
in review of the xHCI v1.2 spec, and booting from USB works with the
included change as expected.
BUG=b:155315876
TEST=booting from multiple USB sticks/hubs with the latest Intel FSP
that advertises xHCI v1.2
Change-Id: I236fed9beef86ff5e1bf7962d882fdae5817a1ff
Signed-off-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41039
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I rushed CB:40895 in to fix a bug only to introduce another. xhci_init()
no longer crashes, but it doesn't correctly initialize the XHCI
controller either, and unfortunately the error messages are all hidden
behind USB_DEBUG. This patch fixes the incorrect address calculation to
what it was before CB:39838.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I14293e2135108db30ba6fd2efea0573fe266fa37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The QEMU XHCI driver does not implement the Port Change Detect bit
in the USBSTS register. As a result no devices are attached without
looking at each port individually.
Detect this as a quirk based on the QEMU XHCI controller PCI ID,
and apply it to the root hub quirk list so it can get used by the
generic hub driver to skip this check.
With this change an attached USB mass storage device is detected and
able to boot when supplied to qemu:
-drive if=none,id=usbmsc,format=raw,file=/tmp/disk.img
-device qemu-xhci,id-xhci
-device usb-storage,bus=xhci.0,drive=usbmsc
Change-Id: I6689cb1dbb24c93d45f5c5ef040b713925d07588
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39839
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
memcpy() is meant to be used on normal memory and often implemented with
architecture-specific optimizations to make that as performant as
possible. MMIO registers often have special access restrictions that may
be incompatible with whatever memcpy() does. For example, on arm64 it
uses the LDP (load pair) to load 16 bytes at a time, which makes 4-byte
MMIO registers unhappy.
This patch removes the caching of the XHCI capreg registers and changes
it back to a pointer. The CAP_GET() macro is still accessing a full
(non-bitfield) uint32_t at the end so this should still generate a
4-byte access (which was the goal of the original change in CB:39838).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id058c8813087a8e8cb85f570399e07fb8a597108
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40895
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
`lib_sysinfo->serial` is a virtual pointer into coreboot tables.
It's not valid across relocation. Accessing the wrong value during
relocation of FILO resulted in a hang with DEBUG_SEGMENT and UART
console enabled. Work around that by caching the whole table entry
locally.
An alternative would be to revise `sysinfo`, to contain no virtual
pointers to anything outside the payload.
Change-Id: I03adaf57b83a177316d7778f7e06df8eb6f9158e
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Reto Buerki <reet@codelabs.ch>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: I4d9bc98863c4f33c19e295b642f48c51921ed984
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37069
Reviewed-by: Bob Moragues <moragues@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The QEMU XHCI controller does not support byte/word reads from the
capability register and it expects dword reads only.
In order to make this work move the access of the capability
register fields to use macros instead of a packed struct bitfield.
This issue was filed upstream:
https://bugs.launchpad.net/qemu/+bug/1693050
The original fix attempt in 2012 was not effective:
6ee021d410
With this change the controller is detected properly by the libpayload
USB drivers.
Change-Id: I048ed14921a4c9c0620c10b315b42476b6e5c512
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
If one branch has braces all should have them.
Change-Id: I94e70c6c6188768d9b37a2d154f4d5b8af31f78c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39396
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a function to set the RTC to provided struct tm.
Change-Id: I17b4c1ee0dcc649738ac6a7400b087d07213eaf0
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/23585
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These macros serve no purpose anymore, let's do the substitution
manually once and for all. Also update the comment on the macros
and fix whitespace on the touched lines.
TEST=Checked that there are no changes in compiled code.
Change-Id: Ib60f9ab157e2e7d44b551dd4f695a6c25ebeb405
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I5be3904298cd88c60dbc6d8d662beeede2abe442
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35960
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On Lenovo T500 the RTC readings where wrong, as RTC has
different encodings, depending on the statusB register.
Support BCD vs binary RTC format and AM/PM vs 24h RTC format.
Fixes wrong date and time on Lenovo 500.
Change-Id: Id773c33e228973e190a7e14c3d11979678b1a619
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/18498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This makes payloads which are hardcoded to a 80x25 console look much
better, e.g. FILO with its "GRUB" user interface.
Change-Id: I9f4752328d85d148cd40a0c2337c7191e1d6a586
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Keeping a local copy of the framebuffer info allows us to make changes,
e.g. add offsets. It also avoids trouble with relocation.
Change-Id: I852c4eb229dd0724114acb302ab2ed7164712b64
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Fix two out-of-bounds reads in lz4 decompression:
1) LZ4_decompress_generic could read one byte past the input buffer when
decoding variable length literals due to a missing bounds check. This
issue was resolved in libpayload, commonlib and cbfstool
2) ulz4fn could read up to 4 bytes past the input buffer when reading a
lz4_block_header due to a missing bounds check. This issue was resolved
in libpayload and commonlib.
Change-Id: I5afdf7e1d43ecdb06c7b288be46813c1017569fc
Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com>
Found-by: Mayhem
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
cbfs_get_handle() and cbfs_get_attr() are both looping over elements to
find a particular one. Each element header contains the element's
length, which is used to compute the next element's offset. Invalid or
corrupted CBFS files could lead to infinite loops where the offset would
remain constant across iterations, due to 0-length elements or integer
overflows in the computation of the next offset.
This patch makes both functions more robust by adding a check that
ensure offsets are strictly monotonic. Instead of infinite looping, the
functions are now printing an ERROR and returning a NULL value.
Change-Id: I440e82fa969b8c2aacc5800e7e26450c3b97c74a
Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com>
Found-by: Mayhem
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fix an out-of-bounds read in the LZMA decoder which happens when the src
buffer is too small to contain the 13-byte LZMA header.
Change-Id: Ie442f82cd1abcf7fa18295e782cccf26a7d30079
Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com>
Found-by: Mayhem
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39033
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 `chars` pointer references the heap which is part of the payload
and relocated along with it. So calling phys_to_virt() on it was
always wrong; and the virt_to_phys() at its initialization was a
no-op anyway, when the console was brought up before relocation.
While we are at it, add a null-pointer check.
Change-Id: Ic03150f0bcd14a6ec6bf514dffe2b9153d5a6d2a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch makes libpayload enable the instruction cache as the very
first thing, which is similar to how we treat it in coreboot. It also
prevents the icache from being disabled again during mmu_disable() as
part of the two-stage page table setup in post_sysinfo_scan_mmu_setup().
It replaces the existing mmu_disable() implementation with the assembly
version from coreboot which handles certain edge cases better (see
CB:27238 for details).
The SCTLR flag definitions in libpayload seem to have still been
copy&pasted from arm32, so replace with the actual arm64 defintions from
coreboot.
Change-Id: Ifdbec34f0875ecc69fedcbea5c20e943379a3d2d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
We set MPS to speed_to_default_mps(speed) initially
but later compare maxpacketsize with 8 to change mps.
So compare with speed_to_default_mps(speed) to determine
if we need to change settings here.
BUG=b:147783572
BRANCH=none
TEST=works with 12Mbps/8MPS USB device
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: I32455483fceec56f14af6118b77615c14b3f9f39
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38556
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A function draw_rounded_box() is added to draw a box with rounded
corners. In addition, this function is different from draw_box() in 2
ways:
- The position and size arguments are relative to the canvas.
- This function supports drawing only the border of a box (linear time
complexity when the thickness is fixed).
BRANCH=none
BUG=b:146105976
TEST=emerge-nami libpayload
Change-Id: Ie480410d2fd8316462d5ff874999ae2317de04f9
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Print error message before error return for better debugging.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I52039dcab72c6295dfb6b887a7000a6d2bd050ee
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Mathew King <mathewk@chromium.org>
To support showing CBMEM logs on recovery screen, add a function
cbmem_console_snapshot() to copy the CBMEM console to an allocated
buffer. Non-printable characters are automatically replaced with '?' to
ensure the returned string is printable.
BRANCH=none
BUG=b:146105976
TEST=emerge-nami libpayload
Change-Id: Ie324055f5fd8276f1d833fc9d04f60a792dbb9f6
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
CB:37594 change the flag makes PC_KEYBOARD_IGNORE_INIT_FAILURE
obsolete. Remove it.
BUG=b:145130110
TEST=N/A
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Idcf816155b32dd691b48a7479297b556d32dd6f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mathew King <mathewk@chromium.org>
Wilco device uses the AT translated keyboard and doesn't need to set
scancode set. Remove the ignore flag and put into translation mode
instead.
BUG=b:145130110
TEST=Draillion keyboard is usable on every boot.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ie1053e24e44c5bad28b56cc92d091e24f3d9b6fd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mathew King <mathewk@chromium.org>
According to the POSIX standard, %p is supposed to print a pointer "as
if by %#x", meaning the "0x" prefix should automatically be prepended.
All other implementations out there (glibc, Linux, even libpayload) do
this, so we should make coreboot match. This patch changes vtxprintf()
accordingly and removes any explicit instances of "0x%p" from existing
format strings.
How to handle zero padding is less clear: the official POSIX definition
above technically says there should be no automatic zero padding, but in
practice most other implementations seem to do it and I assume most
programmers would prefer it. The way chosen here is to always zero-pad
to 32 bits, even on a 64-bit system. The rationale for this is that even
on 64-bit systems, coreboot always avoids using any memory above 4GB for
itself, so in practice all pointers should fit in that range and padding
everything to 64 bits would just hurt readability. Padding it this way
also helps pointers that do exceed 4GB (e.g. prints from MMU config on
some arm64 systems) stand out better from the others.
Change-Id: I0171b52f7288abb40e3fc3c8b874aee14b9bdcd6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: David Guckian
gcc seems to have some stupid problem with deciding when to inline byte
swapping functions (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92716).
Using the compiler builtin instead seems to solve the problem.
(This doesn't yet solve the issue for the read_be32()-family of
functions, which we should maybe just get rid of at some point?)
Change-Id: Ia2a6d8ea98987266ccc32ffaa0a7f78965fca1cd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To avoid trampling over interesting exception artifacts on the real
stack, our arm64 systems switch to a separate exception stack when
entering an exception handler. We don't want that to use up too much
SRAM so we just set it to 512 bytes. I mean it just prints a bunch of
registers, how much stack could it need, right?
Quite a bit it turns out. The whole vtxprintf() call stack goes pretty
deep, and aarch64 generally seems to be very generous with stack space.
Just the varargs handling seems to require 128 bytes for some reason,
and the other stuff adds up too. In the end the current implementation
takes 1008 bytes, so bump the exception stack size to 2K to make sure it
fits.
Change-Id: I910be4c5f6b29fae35eb53929c733a1bd4585377
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37464
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch changes all existing instances of clrsetbits_leXX() to the
new endian-independent clrsetbitsXX(), after double-checking that
they're all in SoC-specific code operating on CPU registers and not
actually trying to make an endian conversion.
This patch was created by running
sed -i -e 's/\([cs][le][rt]bits\)_le\([136][624]\)/\1\2/g'
across the codebase and cleaning up formatting a bit.
Change-Id: I7fc3e736e5fe927da8960fdcd2aae607b62b5ff4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch removes the recently added update8/16/32/64() API and
replaces it with clrsetbits8/16/32/64(). This is more in line with the
existing endian-specific clrsetbits_le16/32/64() functions that have
been used for this task on some platforms already. Rename clrsetbits_8()
to clrsetbits8() to be in line with the new naming.
Keep this stuff in <device/mmio.h> and get rid of <mmio.h> again because
having both is confusing and we seem to have been standardizing on
<device/mmio.h> as the standard arch-independent header that all
platforms should include already.
Also sync libpayload back up with what we have in coreboot. (I'm the
original author of the clrsetbits_le32-definitions so I'm relicensing
them to BSD here.)
Change-Id: Ie4f7b9fdbdf9e8c0174427b4288f79006d56978b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37432
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
After removing urara no board still uses this SoC, and there are no
plans to add any in the future (I'm not sure if the chip really exists
tbh...).
Change-Id: Ic4628fdfacc9fb19b6210394d96431fdb5f8e8f1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36491
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
buffer_to_fifo32() is a simple wrapper to buffer_to_fifo32_prefix(), but
unfortunately its arguments are swapped. This patch fixes the issue.
Change-Id: I6414bf51dd9de681b3b87bbaf4ea4efc815f7ae1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36942
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some special keys emit a prefix scan code 0xE0. We will ignore all
these except for the power button, F12 and cursor keys on drallion.
Media key mapping is set in depthcharge and will be sent to libpayload
keyboard driver. Whichever board requires this change will update its own
media key mapping.
BUG🅱️139511038
TEST=boot in recovery mode, press F12 to go to diagnostic mode and power
button to confirm. Also in recovery mode left arrow, right arrow, up arrow,
down arrow changes the language on the firmware screen.
Change-Id: I1c11939d18391bebe53ca21cf33a096ba369cd56
Signed-off-by: Thejaswani Putta <thejaswani.putta@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36654
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Mathew King <mathewk@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the first CSW transfer failed, get_csw function will retry
CSW transfer again, but the return value is not updated.
Change-Id: I289916baa08d0a189d659164a0002347f6f435db
Signed-off-by: Changqi Hu <changqi.hu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36678
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
* Mark files in CBFS as IBB (Initial BootBlock)
* Will be used to identify the IBB by any TEE
Change-Id: Idb4857c894b9ee1edc464c0a1216cdda29937bbd
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29744
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>
Nico Huber
