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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Thomas Heijligen
