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>
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>
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>
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>
We set MPS to speed_to_default_mps(speed) initially
but later compare maxpacketsize with 8 to change mps.
So compare with speed_to_default_mps(speed) to determine
if we need to change settings here.
BUG=b:147783572
BRANCH=none
TEST=works with 12Mbps/8MPS USB device
Signed-off-by: Kangheui Won <khwon@chromium.org>
Change-Id: I32455483fceec56f14af6118b77615c14b3f9f39
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38556
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A function draw_rounded_box() is added to draw a box with rounded
corners. In addition, this function is different from draw_box() in 2
ways:
- The position and size arguments are relative to the canvas.
- This function supports drawing only the border of a box (linear time
complexity when the thickness is fixed).
BRANCH=none
BUG=b:146105976
TEST=emerge-nami libpayload
Change-Id: Ie480410d2fd8316462d5ff874999ae2317de04f9
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
To support showing CBMEM logs on recovery screen, add a function
cbmem_console_snapshot() to copy the CBMEM console to an allocated
buffer. Non-printable characters are automatically replaced with '?' to
ensure the returned string is printable.
BRANCH=none
BUG=b:146105976
TEST=emerge-nami libpayload
Change-Id: Ie324055f5fd8276f1d833fc9d04f60a792dbb9f6
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This patch changes all existing instances of clrsetbits_leXX() to the
new endian-independent clrsetbitsXX(), after double-checking that
they're all in SoC-specific code operating on CPU registers and not
actually trying to make an endian conversion.
This patch was created by running
sed -i -e 's/\([cs][le][rt]bits\)_le\([136][624]\)/\1\2/g'
across the codebase and cleaning up formatting a bit.
Change-Id: I7fc3e736e5fe927da8960fdcd2aae607b62b5ff4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
The MIPS architecture port has been added 5+ years ago in order to
support a Chrome OS project that ended up going nowhere. No other board
has used it since and nobody is still willing or has the expertise and
hardware to maintain it. We have decided that it has become too much of
a mainenance burden and the chance of anyone ever reviving it seems too
slim at this point. This patch eliminates all MIPS code and
MIPS-specific hacks.
Change-Id: I5e49451cd055bbab0a15dcae5f53e0172e6e2ebe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34919
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some special keys emit a prefix scan code 0xE0. We will ignore all
these except for the power button, F12 and cursor keys on drallion.
Media key mapping is set in depthcharge and will be sent to libpayload
keyboard driver. Whichever board requires this change will update its own
media key mapping.
BUG🅱️139511038
TEST=boot in recovery mode, press F12 to go to diagnostic mode and power
button to confirm. Also in recovery mode left arrow, right arrow, up arrow,
down arrow changes the language on the firmware screen.
Change-Id: I1c11939d18391bebe53ca21cf33a096ba369cd56
Signed-off-by: Thejaswani Putta <thejaswani.putta@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36654
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Mathew King <mathewk@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In interactive payloads, the USB stack's poll procedure is implicitly
called from the UI loop. Since all USB control transfers are handled
synchronously, polling hubs with these slows the UI significantly down.
So switch to interrupt transfers that are done asynchronously and only
perform control transfers when the hub reported a status change.
We use the interrupt endpoint's max packet size instead of the theo-
retical transfer length of `(bNrPorts + 1) / 8` as Linux' code mentions
hubs that return too much data.
Change-Id: I5af02d63e4b8e1451b160b77f3611b93658a7a48
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/18499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We're planning to have a use case with a custom USB device that
implements the USB mass storage protocol on its bulk endpoints, but does
not have the normal MSC class/protocol interface descriptors and does
not support class-specific control requests (Get Max LUN and Bulk-Only
Reset). We'd like to identify/enumerate the device via
usb_generic_create() in our payload but then reuse all the normal MSC
driver code. In order to make that possible, this patch factors a new
usb_msc_force_init() function out of usb_msc_init() which will
initialize an MSC device without checking its descriptors. It also adds
some "quirks" flags that allow devices registered this way to customize
behavior of the MSC stack.
Change-Id: I50392128409cb2a879954f234149a5e3b060a229
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some broken USB mass storage devices send another zero-length packet at
the end of the data part of a transfer if the amount of data was evenly
divisible by the packet size (which is pretty much always the case for
block reads). This packet will get interpreted as the CSW and screw up
the MSC state machine.
This patch works around this issue by retrying the CSW transfer when it
was received as exactly 0 bytes. This is the same mitigation the Linux
kernel uses and harmless for correctly behaving devices. Also tighten
validation of the CSW a little, making sure we verify the length before
we read any fields and checking the signature in addition to the tag.
Change-Id: I24f183f27b2c4f0142ba6c4b35b490c5798d0d21
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34485
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sometimes the display native orientation does not match the device
default orientation, so allow rotation of the framebuffer before
it is displayed on screen.
set_pixel now take coordinates in the rotated coordinate system,
and converts the coordinates before writing to the framebuffer.
Also, screen.size now matches the rotated system (_not_ the
framebuffer size).
BUG=b:132049716
TEST=Boot krane, see that FW screen is orientation properly.
Change-Id: If9316c0ce33c17057372ef5995a2c68de4f11f02
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34732
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Increase the timeout for USB requests to 5 seconds for all USB host
controllers.
Prior to this fix, the xCHI driver was detecting false timeouts during
SET ADDRESS requests when nested downstream hubs were connected to the
xHCI root hub.
BUG=b:124730179
BRANCH=sarien
TEST=Build libpayload and depthcharge on sarien/arcada.
TEST=Without change replicate USB set address timeouts in depthcharge
when dock and 4K monitor connected (which includes a total of 4 USB
hubs). With timeout fix, depthcharge boots OS with no USB errors and
the same USB topology. Note that this tests xHCI operation only.
Change-Id: I53e3e67d893420e7c9e8b52c47dd0edb979e5468
Signed-off-by: Keith Short <keithshort@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Documentation is scarce on the matter, however the related coreboot
code suggests that after the ACK, the keyboard also sends the result
of the self test (passed/failed). It looks like this result is never
consumed here, probably resulting in further confusion for later com-
mands.
Let's revert this for now (if it's not too late for the 4.10 release)
and break things later again. IMHO, due to the fact that there are
dozens of different keyboard controller and keyboard implementations
and no accurate specification followed, such changes should be tested
on a lot of hardware before merge.
This reverts commit a99ed13e33.
This reverts commit 7ae606f57f.
Change-Id: I4d4304d5d8a01e013feac61016c59bcaeea81140
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33244
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Martin Kepplinger <martink@posteo.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
CB:32951 ("libpayload: Reset PS/2 keyboard") added a call to reset
keyboard and check the return value of keyboard_cmd() to compare
against I8042_KBCMD_ACK. However, keyboard_cmd() already checks for
ACK and returns 1 or 0 based on whether ACK is received.
This change fixes the check introduced by CB:32951 to compare against
0 just like the other checks for keyboard_cmd(). Additionally, it adds
error messages for all failed commands in keyboard_init() to make the
prints consistent in case of failure.
BUG=b:134366527
TEST=Verified that logs do not contain "ERROR: Keyboard reset failed"
anymore.
Change-Id: Idcadaae12e0a44e404a1d98c6deb633d97058203
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Loading a libpayload based payload like coreinfo or FILO from SeaBIOS or
GRUB pressing keys does not give the expected results.
For example, pressing F1 gives the character 24 translated to scan code
6a. ESC for example 43 (111) in coreinfo loaded from SeaBIOS on QEMU
Q35.
The problem is not reproducible using the payload directly, that means
without SeaBIOS or GRUB. The problem seems to be, that those have already
initialized the PS/2 controller and AT keyboard.
Comparing it with coreboot’s PS/2 keyboard code, the keyboard needs to
be reset. That seems to fix the issue, when the keyboard was initialized
before.
TEST=Build coreboot for QEMU Q35 with SeaBIOS, and coreinfo as secondary
payload. Run
qemu-system-i386 -M q35 -L /dev/shm -bios build/coreboot.rom -serial stdio
press 3 to select the coreinfo payload, and verify that the keys F1 and
F2 are working.
Same with coreinfo loaded from GRUB on the ASRock E350M1.
Change-Id: I2732292ac316d4bc0029ecb5c95fa7d1e7d68947
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Free several resources when AHCI initialization fails. Note that it is
only safe to free resources when the command engine has stopped, since
otherwise they may still be used for DMA.
Found-by: Coverity CID 1260719, 1260727, 1261090, 1261098
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I6826d79338b26ff9696ab6ac9eb4c59f734687d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Depthcharge uses the keyboard type to help determine whether
it can trust the keyboard for security-sensitive confirmations.
Currently it trusts anything except usb, but now there's a need
to distrust ec-based ps/2 keyboards that are associated with untrusted
ECs. To help facilitate this, coreboot needs to report more
details about non-usb keyboards, so this change replaces the current
instances of unknown with enum values that distinguish uart and gpio
from ec-based keyboards.
BUG=b:129471321
BRANCH=None
TEST=Local compile and flash to systems with trusted and non-trusted
ECs. Confirmed that security confirmation can't be performed via
keyboard on a system with an untrusted EC but can still be performed
on a system with a trusted EC.
Change-Id: Iee6295dafadf7cb3da98b62f43b0e184b2b69b1e
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
GPT4 is a 32-bit timer and the counter of GPT4 will overflow in about
330 seconds (0xffffffff / 13MHz). Timer and delay functions will not
work properly if the counter overflows. To fix that we should use the
64-bit timer (GPT6).
BUG=b:80501386
BRANCH=none
Test=emerge-elm coreboot; emerge-kukui coreboot
Change-Id: I9f080e47253a1b1bab4636a45cb86c8666a25302
Signed-off-by: Tristan Shieh <tristan.shieh@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: You-Cheng Syu <youcheng@google.com>
