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>
BOOTBOOT is a multi-platform, architecture agnostic boot protocol.
The protocol describes how to boot an ELF64 or PE32+ executable inside
an initial ram disk image into clean 64 bit mode. This version uses
libpayload to do that. Depending on the lib's configuration, initrd
can be in ROM as a cbfs file or a Flashmap partition; on disk a GPT
partition or a file on a FAT formatted ESP partition.
For more information see https://gitlab.com/bztsrc/bootboot
Change-Id: I8692cde0730338026a7760a293c1e37f66004bc0
Signed-off-by: Zoltan Baldaszti <bztemail@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Implements fit_payload_arch for the arm (aarch32) architecture, so that
FIT images can be used. The implementation is very similar to the
existing implementations for arm64 and riscv, and has mostly been
lifted from these other ports.
TEST: Booted Beaglebone Black (in progress port, to be submitted soon!)
with a FIT image containing a 5.4 kernel, dtb and initramfs.
Change-Id: I6b50c6f06b83c00a5b3622b5bbafe67130b6d233
Signed-off-by: Sam Lewis <sam.vr.lewis@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
After `make clean` a new build should not be based on stale artifacts.
Hence we have to remove them.
Change-Id: I540a83a6c87b843b1c4c9c55990bf3e91fe90d79
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
After `make clean` a new build should not be based on stale artifacts.
Hence we have to remove them.
Change-Id: I18292c674986078d991668124193b6aa31234d47
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44179
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
Upstream does not require it. From the repository readme:
"Note: When cloning submodule repos, '--recursive' option is not recommended.
EDK II itself will not use any code/feature from submodules in above submodules.
So using '--recursive' adds a dependency on being able to reach servers we do not
actually want any code from, as well as needlessly downloading code we will not use."
Change-Id: I0c5d6dd6e5070720870fc22b2476c6fe8dc7fd40
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43063
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
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 hardware IRQ option was not passed to SeaBIOS Makefile and resulted
in HARDWARE_IRQ being permanently disabled regardless of Kconfig
selection in coreboot. On platforms that need the hardware IRQ it caused
hangs at boot menu or iPXE prompts.
TEST=enter SeaBIOS boot menu on Libretrend LT1000
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Iafcfd743177bbcd1ee23e227c74dd8268c4c23c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41147
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
The git checkout hint introduced in cb:36343 does not get printed but
executed instead. Escape the single-quotes to fix this.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I1277c3788a141b25cd9f22ec0476ee56b64aea4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The check for changed files, introduced in cb:36343 does not work
(anymore?) due to the quotes. Thus, drop them.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: Ie126e3d604990b2346f1f004f912080104e2789d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Certain boards require SeaBIOS' HARDWARE_IRQ option to be
deselected in order for the platform to boot. Add a Kconfig
to allow selection of HARDWARE_IRQ enablement, and write to
SeaBIOS' .config file in cases where it needs to be disabled.
Deselect the option for google/rambi variants so they boot
with boards defaults.
Test: build/boot google/clapper, verify board boots vs hanging
at boot menu prompt.
Change-Id: I23e9b30d2d1042c86bd10f134d6fe361edaf8cb2
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
-n needs to check against a string, but if CONFIG_TIANOCORE_BOOTSPLASH_FILE
is unset, then $(CONFIG_TIANOCORE_BOOTSPLASH_FILE) evaluates to nothing
and the check fails, leading the Makefile to try and copy a non-
existant file/path.
Change-Id: Iff717dd48748cff16f485bafaa91c7a225fb5bdb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Allow a custom boot splash to be used with UefiPayloadPkg:
- remove Kconfig guards restricting to CorebootPayloadPkg
- set destination path for logo file based on bootloader selected
Test: build/boot qemu with UefiPayloadPkg with custom boot logo
Change-Id: Ia0a10d1528f516f6b9d3645b83be0fb4e85bc348
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40591
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Recent changes to upstream edk2 necessitate ensuring
that Tianocore's submodules exist and are up to date,
otherwise building UefiPayloadPkg will fail.
Change method used to detect a dirty tree so that initialized
submodules do not taint the result.
Test: build qemu with Tianocore UefiPayloadPkg option successfully.
Change-Id: Ie2541f048966ec0666d8196508ccdb6c5f089de6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
`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>
nvramcui requires use of CMOS for NVRAM configuration,
so depend on HAVE_OPTION_TABLE and select USE_OPTION_TABLE
to ensure that nvramcui is actually functional when included
in a build.
Change-Id: I0595514f636b8ce67bbc789ecc96a93c99068c50
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40222
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
This adds the path to chrome EC headers to the depthcharge
build. Depthcharge currently includes a manually maintained copy of
the EC headers which are perpetually out of sync with the real
interface definitions. By adding the include path, we can build
depthcharge with the actual EC interface definitions and eliminate the
manual maintenance of copies of EC headers. Once the include path is
in place, we can remove the copies of the EC headers from depthcharge.
BUG=b:152373049
Change-Id: I1ce0ad9dc99ea52f177d4fb034fd23efd95a7864
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@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>
For a very long time, SeaBIOS sometimes failed to build when using
multiple threads. This known problem has been haunting everyone for a
very long time. Until now.
Unlike most other payloads, building SeaBIOS results in two files: the
SeaBIOS payload itself and SeaVGABIOS. Each file has its own target, and
there's a third target called "seabios", which has the same recipe as
the SeaBIOS file, which calls `payloads/external/SeaBIOS/Makefile` with
a bunch of arguments. In addition, SeaVGABIOS depends on "seabios".
When executing serially, if the file of either SeaBIOS or SeaVGABIOS is
needed, the SeaBIOS Makefile will be run. This will generate both files,
so it is not necessary to run the Makefile more than once.
However, when using multiple threads, it can happen that one thread
wants to make the SeaBIOS file, while another one wants to make the
SeaVGABIOS file, which depends on "seabios". This implies that both
threads will execute the SeaBIOS Makefile at about the same time, only
to collide when performing git operations. Since git uses a lock file
when updating the index, one of the threads will fail to acquire the
lock with an error, which will ultimately cause the build to fail.
Whenever this happened, manually aborting with Ctrl-C made the build
process fail again because of the same error. The only way to get past
this problem, other than using one thread, was to let the unfinished
jobs complete. The thread that acquired the lock on the SeaBIOS git
repository would finish building SeaBIOS, so that target would not need
to be remade. When restarting the build, only the target that failed is
rebuilt, so it does not collide with any other thread.
To address this issue, make the SeaVGABIOS file target depend directly
on the SeaBIOS file instead, and remove the duplicate "seabios" target.
Change-Id: I251190d3bb27052ff474f3cd1a45022dab6fac31
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Upstream UEFIPayload[1] now includes support for PS2 keyboards, but
defaults it to disabled. Enable it, as CorebootPayload does.
Note that this increases payload size in coreboot by a little over 5 KiB.
1. 33a3293651
Change-Id: If6d468809142a0049ce1648217d62b070229ad6b
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38960
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The build process of this payload is unnecessarily prolix. Therefore,
make use of the `-q` flag to abridge the output.
TEST=When building for X64, UEFIPAYLOAD.fd does not differ.
Change-Id: I6eba069ff5be2813d180dae40ab10155f0542f33
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39123
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Change-Id: I8261bc28e5bc9aa32db1dccef7035486995c9873
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39051
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Felix Singer
