Age | Commit message (Collapse) | Author |
|
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>
|
|
Clean up pci_alloc() and return pointer to allocated memory directly.
Change-Id: Ib2ee8dbfaabbf7a824b4fd75ad7c779393af2900
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46345
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Change-Id: Ic88defd30c6d3791a51b78a14135aff55e89394d
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46285
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add 32-bit `popcnt` and 64-bit `popcnt64` helpers.
Change-Id: I2e6a1007e475b662a85c067d96f81326e7f02905
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Add 64-bit versions of clz, __ffs & log2: `__ffs64`, `__clz64`,
and `log2_64`.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Iefc6e6c51f5b20607c88e38660a499a4f77ce0d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The appropriate way to print a u64 variable regardless of the current
architecture is to use the PRI*64 macros. libpayload is mostly used
in 32 bits but when ported to other projects and compiled in 64 bits
it breaks the compilation.
Change-Id: I479fd701f992701584d77d43c5cd5910f5ab7633
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ibdc211d7f4ec0fbbefafb5eae4c1615c64c99280
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
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>
|
|
Change-Id: If8aa28a22625b7b2cf9b58958de87ee752f637f6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Change-Id: I6faeb7c783052edc4217d2d301dbb905e1fc6a19
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44605
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Separate the validity check of calling free(NULL) for clarity.
BUG=b:168441735
TEST=emerge-puff libpayload
Change-Id: I0dc355553410bbe59e658945fb40c05f5f709380
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45465
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
The current 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>
|
|
- Remove copyright notices and add authors to AUTHORS
- Use SPDX license identifiers for all files
- Add coreinfo to the license header lint
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: Ib0c5328a4027849b1eda4f57141a898335230726
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The current realloc() works by freeing the origin buffer, allocating a
new one, and copying the data over. It's true that free() won't touch
the actual memory. However, the alloc() following it will potentially
modify the memory that belongs to the old buffer in order to create a
new free block (right after the newly allocated block). This causes 8
bytes (HDRSIZE) to be overwritten before being copied to the new buffer.
To fix the problem, we must create the header of the new free block
after the data is copied. In this patch, the content of alloc() is split
into two functions:
1. find_free_block(): Find a free block with large enough size, without
touching the memory
2. use_block(): Update the header of the newly allocated block, and
create the header of the new free block right after it
Then, inside realloc(), call memmove() call right after
find_free_block() while before use_block().
BUG=b:165439970
TEST=emerge-puff libpayload
TEST=Puff boots
TEST=Verified realloc() correctly copied data when buffers overlapped
Change-Id: I9418320a26820909144890300ddfb09ec2570f43
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
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>
|
|
see https://seabios.org/Releases
Change-Id: I20e57314b867581f41921178ff1ffcbaa50a0843
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Idwer Vollering <vidwer@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>
|
|
Change-Id: Iba73ae4d89cef94f238e9a74300f6088669f355b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43716
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Ia77c5be4b22740f88fb9c11bff95036adbd8145f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I2960f95937db23aa3a38ca64085728e6d10968f8
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Ie08e92778e029b962cf0ed5f95ab740458e82fc5
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
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>
|
|
Resolve missing dependency to fix concurrent building.
Resolves: https://ticket.coreboot.org/issues/271
Change-Id: Idbd9155e01fcc4571a61f1bba5b2b4a446036da0
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43407
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Signed-off-by: Selma BENSAID <selma.bensaid@intel.com>
Change-Id: I17ae7450a9641268fe392bed0f24846abc8e6f56
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43203
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
|