Age | Commit message (Collapse) | Author |
|
Use static_fw_config.h during depthcharge build to be in line with latest
depthcharge changes on the main branch.
https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/+/2523517
BUG=none
TEST=Boot to OS
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: I72a681d9321750c392000e11a21d81020dde3fd7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52403
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Meera Ravindranath <meera.ravindranath@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Varshit B Pandya <varshit.b.pandya@intel.com>
|
|
If we select scancode set #1 and keep that, it can confuse Linux
with keyboards that don't return to set #2 when asked to load the
defaults. This happens for instance with various integrated Think-
Pad keyboards but was also seen with an external PS/2 one.
The chosen configuration, scancode set #2 without translation, seems
to be the default for many systems. So we can expect other payloads
and kernels to work with it.
Change-Id: I28d74590e9f04d32bb2bbd461b67f15014f927ec
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47594
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of ignoring keyboards indefinitely when they failed to
initialize, we wait 5s and then start over with the hotplug
detection. As we always assume a present keyboard at first,
we'd otherwise never have a chance to hot plug a device after
the initial 30s timer ran out.
Change-Id: I8dec4921b2e932442d52b5118cdcf27090633498
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
While we assume a keyboard is attached, we send an echo command every
500ms. If there is no data coming from the keyboard within 200ms, we
assume it was detached.
Correspondingly, if we assume no keyboard is attached, we run an echo
command once per second.
Change-Id: I2c75182761729bf30711305f3d8b9d43eafad675
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47593
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Three stages of the new tint build system:
1) generate_core.sh extracts the core part from buildgcc script,
most importantly the checksum calculation/verification functions.
2) tintify_core.sh adds the tint-specific footer/header to the core,
such as the properties of current version including its checksum.
3) tint.sh - generated and "tintified" core script - builds a tint.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: Ib71f5b861ecf91949a5af12812258e60873f0498
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BUG=b:182963902
TEST= validated on qualcomm sc7280 developement board
Change-Id: Ic28f02cdf5c0e4c2458aee0ad7c74383c88d8874
Signed-off-by: Ravi Kumar Bokka <rbokka@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
|
|
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Signed-off-by: Balaji Manigandan B <balaji.manigandan@intel.com>
Change-Id: Ice0b908b23921cd9afbef52d2471f5ded277a136
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51280
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Selma Bensaid <selma.bensaid@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Upstream edk2 dropped separate 32-bit support for UefiPayloadPkg, and
removed the architecture suffix from the package dsc filename.
Test: build/run qemu with CONFIG_TIANOCORE_UEFIPAYLOAD selected.
Change-Id: I40077f1d370f0cb5627645b305b57e6c71e44095
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Reproducible builds have to be independent from user, host,
domain, time.
Taken from OpenWrt (GPL2).
Change-Id: I420588acc66647051c08e4da6fbedc205cd62877
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35393
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Tested with qemu virtual NVMe and Intel hardware. Works with FILO.
Change-Id: Ie75b1dc743dac3426c230c57ee23b771ba3a6e0c
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33582
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Without the boot template, u-root doesn't include any boot commands.
Booting other OS is impossible.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I7d0742d115715eb40e293e2a8711d1ff20d8970a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51331
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This is already the case on x86 but not on the ARM platforms, and
{read,write}[bwl] are using volatile pointers, too, so follow suit.
Change-Id: I6819df62016990e12410eaa9c3c97b8b90944b51
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Remove trailing whitespace in files that aren't typically checked.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I8dfffbdeaadfa694fef0404719643803df601065
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50704
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Rebase the libpayload_tint.patch to update its internal version
numbers from 0.04+nmu1 to 0.05.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I91f780f80026147c3c35330625a4106c65a1ddf0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50468
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Old archive is not available anymore. The tint sources inside the new
archive are the same (something changed in a debian subdirectory but
we aren't using it), so a libpayload_tint.patch is still valid.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: If556fac7d1d8379a022f59ed6aee1450b7bc5aa7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48616
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The sub-process calls break make's dependency tracking, hence we have
to always perform the calls if we want to allow automatic, incremental
builds.
We let each rule depend on a new, phony target `force-payload`. It has
roughly the same effect as tagging all the targets as phony, but doing
so would feel wrong as some of them are actual files.
Change-Id: I1bc2406db371e8dddbfdf71f68a6665a5b558f5e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Ie15aec4059fbeb99f714c3d674df5fabdb7c081c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47637
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I34bf659c1a069ccc27ca613bbf86780d4da49259
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47636
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I388d60e6f3aeb2184966152f0934845d42834de0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47634
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The new `Makefile.payload` can be included by the Makefiles of pay-
loads for in-tree builds. The basic idea is to use libpayload's
build results without the `make install` step, and to ensure that
incremental builds work. For instance, if libpayload's code changes,
a `make` for the payload would automatically update the libpayload
build and rebuild the payload. But if there are no code changes in
libpayload, only updated files of the payload will be re-built.
The configuration of libpayload is supposed to be automatically
generated from a `defconfig` file. If this `defconfig` changes,
libpayload and the payload will be re-built.
Change-Id: If5319f1bf0bcd09964416237c5cf7f8e59f487a2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47633
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
coreboot's Makefile exports a lot of variables that influence make sub-
processes (e.g. for Kconfig). We don't want these variables leak into
sub-processes for (lib)payload builds, hence unexport them.
Change-Id: I8da2d8db6238d456723b9c22bee80c62e97027b0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48940
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
coreboot's Makefile exports a lot of variables that influence make sub-
processes (e.g. for Kconfig). We don't want these variables leak into
sub-processes for (lib)payload builds, hence unexport them.
Change-Id: I7d65c0aa6d4550bd6600c437e838339af69496da
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48939
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
FILO's Makefile will check for libpayload and might not even `clean`
if it's not found.
Change-Id: If5f8f4ecce317e54cd4b5688553cc38220f6e6df
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36461
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ieb10a881ef1d983f11318f0f6934491fd19fd0bf
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Change-Id: I3dafffa61f4fe6089fd11ef6579626aff8088df5
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add read64 and write64 for consistency with x86.
BUG=b:178785769
Change-Id: I342e3a23201d0b804ea5ecfe47ee3e4bb516de4c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50115
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
They all operate on that file, so just add it globally.
Change-Id: I953975a4078d0f4a5ec0b6248f0dcedada69afb2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Target added to INTERMEDIATE all operate on coreboot.pre, each modifying
the file in some way. When running them in parallel, coreboot.pre can be
read from and written to in parallel which can corrupt the result.
Add a function to create those rules that also adds existing
INTERMEDIATE targets to enforce an order (as established by evaluation
order of Makefile.inc files).
While at it, also add the addition to the PHONY target so we don't
forget it.
BUG=chromium:1154313, b:174585424
TEST=Built a configuration with SeaBIOS + SeaBIOS config files (ps2
timeout and sercon) and saw that they were executed.
Change-Id: Ia5803806e6c33083dfe5dec8904a65c46436e756
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49358
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Allows us to build with `-Wmissing-prototypes`.
Change-Id: I722b41e515ee472697028a912b9136ce59611051
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47635
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
It either doesn't exist (in-tree builds) or is the same as $_LIBDIR.
Change-Id: I9551cbfc3295d86c22a3785be7cdc0f65eeb08c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47632
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We only need `$_OBJ` in the include path for in-tree builds. Also,
curses only need special handling for those and PDCurses turned out
to need many more include paths.
Change-Id: Idd29ef33065033e26ba61b09d412d8ca3566d643
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add $_DOTCONFIG and $_XCOMPILE pointing to the respective files and
use them.
Change-Id: I719b42d1c8abf055948daf5b000daa30cd249edd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Icfbfff3ba680a85eb2f683867064b19f40b9d40f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48898
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I125e40204f3a9602ee5810d341ef40f9f50d045b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48897
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Instead of checking for an already fully build `libpayload.a`, we check
for the `libpayload.config` which is the actual prerequisite to start
using `lpgcc`. This will allow compilation of payload sources before or
in parallel with the build of `libpayload.a`.
Change-Id: Ic0143fefe33560af8b013ae48bbbe231b3ad46f3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Introduce a `$_OBJ` variable, that points to the build directory for
in-tree usage of `lpgcc`. If unset, the default `../build` relative
to the location of `lpgcc` is used.
Change-Id: I35112d7533d69aa51252dd2bceec010a62522403
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47629
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This should make it easier to find the correct config for in-tree
builds.
Change-Id: I08d396ae3cedc65f63c4b8865701ea123c7d56cb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47628
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Keep libpayload's xcompile in its build dir. While we are at it,
align things with the top-level version.
Having `.xcompile` in a central place led to race conditions when
multiple payloads try to build their own libpayloads in parallel.
Change-Id: I504e1862db79b368289867f7568c9169f27a1549
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Extract the architecture (-a) and package (-p) options into a
new variable (ARCH) to simplify the construction of BUILD_STR.
Test: build/boot various boards w/Tianocore payload
Change-Id: I490d48428ac56d613d0b704700dfcf4ebfb2d245
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48942
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a Kconfig option to set the tianocore boot timeout,
which is passed to the payload via a command line parameter.
Allows boards without an internal display (eg) to set a longer
boot timeout, in order to ensure the boot splash/menu prompt
are visible upon boot.
The associated changes on the tianocore side have already been
merged into MrChromebox's CorebootPayloadPkg and UefiPayloadPkg
branches (coreboot_fb and uefipayloadpkg respectively).
Change-Id: Ifeaadff05f6667d642c05b81f53c1d2dbc450af6
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I60699e044b5bacd3f5292fed7edbf529ae133284
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47592
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I643a821d4c41fc068f2bab0bd571b0a4a359f59a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47591
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I855d975a4729da34a6fa73a63dbbd12c856bdc00
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The keyboard self-test is required for some devices. At least one
device (integrated keyboard in a ThinkPad X201) actually starts the
test automatically leading to spurious output and no response for
the first seconds.
We wait up to 5s for the self-test result. On failure or timeout,
the command will be repeated until the 30s init timer runs out. This
happens all in the background of the UI polling loop.
To not unnecessarily delay the boot process, we first try an oppor-
tunistic initialization which skips the self-test.
Change-Id: Ie07b31e74d06e116ac81e76309621eed39a19b49
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Will be used to time out in states that don't always advance.
Change-Id: I28235e7638d8157cedf81fd915a41d28a1fc070b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47087
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We'll process the init sequence as part of the polling loop. This
should have several advantages:
* It eases error handling, i.e. we can return to an earlier state.
* We don't have to stall initialization when a keyboard takes a
little longer.
* Generally, these keyboards can be hot-plugged (albeit not by
design).
Change-Id: I9cf5cf31eb420b3994bec20e56a72d37f3d2996e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Draining the keyboard's buffer is only possible when the keyboard
port is enabled. We should also disable input scanning before, as
the buffer could be filled again with new keystrokes otherwise.
Change-Id: Ibac9c0d04880ff4a3efda5ac53da2f9731f6602c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Move the input-buffer draining into a function. It uses the low-level
i8042 API directly to avoid conflicts with changes in the high-level
keyboard API.
Change-Id: I9427c5b8be4d59c2ee3da12d6168d34590043682
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47084
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Even if we are careful, it's still possible that we read spurious
data from the keyboard, e.g. keystrokes. Namely, when we send the
reset/disable command, there is a race before the command is pro-
cessed.
So we should always process data from the keyboard in a loop. We
break it, when an ACK (0xfa) or a NAK (0xfe) is received, and warn
on unexpected data unless it might be due to the mentioned race.
This also gives us the opportunity to use command-specific timeouts
which we take from Linux: 1s for the keyboard self-test (as there
are keyboards that perform the test before acking the command) and
200ms for all other commands.
Change-Id: I60a2643a8ff4b9231c63bf970c8749c97c7d8926
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Some background first: The original XT keyboards used what we call
scancode set #1 today. The PC/AT keyboards introduced scancode set #2,
but for compatibility, its controller translated scancodes back to
set #1 by default. Newer keyboards (maybe all we have to deal with)
also support switching the scancode set.
This means the translation option in the controller and the scancode
set selection in the keyboard have to match. In libpayload, we only
support set #1 scancodes. So we either need the controller's trans-
lation on and set #2 selected in the keyboard, or the controller's
translation off and set #1 selected in the keyboard.
Valid configurations:
* SET #1 + XLATE off
* SET #2 + XLATE on
Both with and without the PC_KEYBOARD_AT_TRANSLATED option, we were
only configuring one of the two settings, leaving room for invalid
configurations. With this change, we try to select scancode set #2
first, which seems to be the most supported one, and configure the
controller's translation accordingly. We try to fall back to set #1
on failure.
We also keep translation disabled during configuration steps to
ensure that the controller doesn't accidentally translate confi-
guration data.
On the coreboot side, we leave the controller's translation at its
default setting, unless DRIVERS_PS2_KEYBOARD is enabled. The latter
enables the translation unconditionally. For QEMU this means that
the option effectively toggles the translation, as QEMU's controller
has it disabled by default. This probably made a lot of earlier
testing inconsistent.
Fixes: commit a95a6bf646 (libpayload/drivers/i8402/kbd: Fix qemu)
The reset introduced there effectively reverted the scancode
selection made before (because 2 is the default). It's unclear
if later changes to the code were only necessary to work
around it.
Change-Id: Iad85af516a7b9f9c0269ff9652ed15ee81700057
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|