It is already using winbond_enable_serial(). Once
w83697hf_set_clksel_48() is unified into winbond/common/early_init.c,
this file is no longer needed and can be dropped.
Change-Id: I7424233b5d70e143721038493f194760f07346a1
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/21332
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This function is identical throughout all Winbond superios in
the tree, so move it into superio/winbond/common/early_init.c,
renamed from early_serial.c because it now does more than just
early serial.
Change all affected mainboards to use the unified function.
Change-Id: If05e0db93375641917e538d83aacd1b50fbd033b
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/21331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
IRQ 9 is used for different purpose on this mainboard so move SCI away
to IRQ 10.
Change-Id: I7f055447f5d92bc4696b38e8103a7aebde95d9d3
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/21586
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The System Control Interrupt is routed per default to IRQ 9. Some
mainboards use IRQ 9 for different purpose. Therefore it is necessary to
make the SCI configurable on Apollo Lake.
Change-Id: Ib4a7ce7d68a6f1f16f27d0902d83dc8774e785b1
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/21584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable LTR for Root port 0, where wifi card is connected.
BUG=b:65570878
TEST=After enbaling LTR on port 0 on the MB devicetree, No errors reported
by AER driver for root port 0.
Change-Id: I222a87fe2094c8424760ccf578e32b9ac042f014
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/21548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There are a lot errors reported by AER driver for root port 0.
The erors are being caused by an unsupported request from the
device to the upstream port. Enabling LTR on the root port stops
these errors, it is because LTR is enabled on the device side but
not on the root port and hence root port was logging the LTR messages
from the device as unsupported.
The PCIe base spec (v3.1a) section 6.18 also states that:
LTR support is discovered and enabled through reporting and control
registers described in Chapter 7. Software must not enable LTR in an
Endpoint unless the Root Complex and all intermediate Switches indicate
support for LTR. Note that it is not required that all Endpoints support
LTR to permit enabling LTR in those Endpoints that do support it. When
enabling the LTR mechanism in a hierarchy, devices closest to the
Root Port must be enabled first.
If an LTR Message is received at a Downstream Port that does not
support LTR or if LTR is not enabled, the Message must be treated
as an Unsupported Request. FSP has a UPD for enabling/disabling
LTR on root port, use the same for configuring LTR on PCIe root ports.
BUG=b:65570878
TEST=After enbaling LTR on port 0 on the MB devicetree, No errors reported
by AER driver for root port 0.
Change-Id: Ica97faa78fcd991dad63ae54d2ada82194b4202a
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/21547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In coreboot commit bcd0bdabed (soc/intel/cannonlake: add rtc failure
checking), the function soc_get_rtc_failed was supposed to be moved,
but the old function was not removed, causing a build error.
BUG=b:63054105
Change-Id: I31c1966af413df3f5a5492a5dd891a6eb26a1fc4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/21616
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's an occasional issue on machines which use CMOS for their
vbnv storage. The machine that just powers up from complete G3
would have had their RTC rail not held up. The contents of vbnv
in CMOS could pass the crc8 though the values could be bad. In
order to fix this introduce two functions:
1. vbnv_init_cmos()
2. vbnv_cmos_failed()
At the start of vboot the CMOS is queried for failure. If there
is a failure indicated then the vbnv data is restored from flash
backup or reset to known values when there is no flash backup.
BUG=b:63054105
Change-Id: I8bd6f28f64a116b84a08ce4779cd4dc73c0f2f3d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
It's helpful to use the common vbnv_reset() function to
initialize the vbnv contents when backing store failures occur.
Therefore, allow that to happen.
BUG=b:63054105
Change-Id: I990639e8c163469733fdab0d3c72e064acc9f8d8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to early_pch_common.c and
add a helper function to determine if failure occurred.
BUG=b:63054105
Change-Id: I710d99551cfb6455244f66b47fcbecc790ae770f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I368c31b9935c0fa9e8a1be416435dd76f44ec1ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: Ic4bf99dc3a26fbc3bd508e484963b9298ef1b24b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I1d90cc557225ddbba1787bf95eae0de623af487e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I88bf9bdba8c1f3a11bc8301869e3da9f033ec381
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21554
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred. In addition actually
provide soc_get_rtc_failed() which properly indicates to the common
code that RTC failure did occur in the cmos_init() path.
BUG=b:63054105
Change-Id: I9dcb9377c758b226ee7bcc572caf11b7b2095425
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: Ia0a38f00d2a5c7270e24bdd35ecab7fbba1016d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21552
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to prepare for checking RTC failure in the early boot
paths move the rtc failure calculation to pmutil.c and add a helper
function to determine if failure occurred.
BUG=b:63054105
Change-Id: I1b02028a1830ff9b28b23da7a4a1fd343f329f0d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add vbnv_init() which is responsible for doing any vbnv initialization
and reading the vbnv contents. Having this function allows for
putting vbnv backing store specific support in the main vboot logic
path.
BUG=b:63054105
Change-Id: Id8f0344e5de5338417ae2e353ae473d6909c860a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21550
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having each potential caller deal with the differences
of cmos_init() and init_vbnv_cmos() when VBOOT is enabled put the
correct logic within the callee, cmos_init(), for handling the
vbnv in CMOS. The internal __cmos_init() routine returns when the
CMOS area was cleared.
BUG=b:63054105
Change-Id: Ia124bcd61d3ac03e899a4ecf3645fc4b7a558f03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21549
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Linux Pstore area must not be cleared on a reboot. Set the option
to not clear the memory in AGESA.
BUG=b:64193190
BRANCH=none
TEST=Memory clear isn't called in AGESA.
Change-Id: I9b8286ade718fa80bf3badd478ab9a7df643ab98
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21596
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Kahlee has a single memory channel, not two. This corrects DMI type 17
reporting and the memory clear functions.
BUG=b:65403853, b:64193190
BRANCH=none
TEST=AGESA DMI reports the correct number of DIMMs.
Change-Id: Ic263d2677a480448beaf3850391b1a3d4ed38657
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
vboot images come with multiple regions carrying CBFS file systems. To
expedite hashing (from slow flash memory), the FW_MAIN_* regions are
truncated since they typically have pretty large unused space at the
end that is of no interest.
For test purposes it can be useful to re-engage that space, so add a
command that creates a new empty file entry covering that area (except
for the last 4 bytes for the master header pointer, as usual).
BUG=b:65853903
BRANCH=none
TEST=`cbfstool test.bin expand -r FW_MAIN_A` creates a new empty file of
the expected size on a Chrome OS firmware image.
Change-Id: I160c8529ce4bfcc28685166b6d9035ade4f6f1d1
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/21598
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Fix typo in comment
- Aphabetize package list and put each package on a single line
- Add environment variables into coreboot user's .bashrc file
- Add openssl, qemu, and shellcheck to installed packages
Change-Id: I37771be5d3ecaa61d76d99e689b422144a6d7dc6
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/21582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chris Ching <chingcodes@chromium.org>
- Update checkpatch.pl to version 0547fa58
(checkpatch: add 6 missing types to --list-types)
- Update spelling.txt to version d9f91f8
(scripts/spelling.txt: add a bunch more spelling mistakes)
- Fix an additional unescaped left brace in a regex - causes warnings
in new versions of perl.
Change-Id: Ic443099e90a46280f18d58799afc72d00dc83793
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/21581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Chris Ching <chingcodes@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch outputs decoding errors with BIOS_WARNING instead of
depending on CONFIG_DEBUG_RAM_SETUP.
Returns SPD_STATUS_INVALID on invalid settings for tRR, bcd and tCK
and doesn't try to create a valid setting if an invalid setting is
detected.
Change-Id: Iee434d1fa1a9d911cc3683b88b260881ed6434ea
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/21480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This simplifies computing dram timings a lot.
This removes computation of rank size based on columns, rows,
banks,... and uses the information in SPD byte 31. The result of this
is that dimms with multiple asymmetric ranks are not supported
anymore. These however are very rare and most likely never tested on
this platform.
This also uses i2c block read instead of byte read to speed up the
raminit. The result is less time is being spend reading SPDs.
It still keeps smbus read byte as a backup if i2c block read were to
fail.
Change-Id: I97c93939d11807752797785dd88c70b43a236ee3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/18305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
If results are uploaded the temporary directory in which they are
stored gets deleted, yet we currently point to the deleted directory in
the output.
This patch fixes it so that we point to the actual location in the local
repository where uploaded results are found.
Change-Id: I1f42c3296ec1d19fcfa4911307e07e67de289895
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/21415
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add PMC pci driver on top of PMC common code, also include pmc init code
reference from skylake.
Change-Id: I95895a3e26cdebd98a4e54720bd4730542707d7e
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/21251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ACPI spec requires devices with children to have an HID,
and Windows enforces this strictly. Without the SIO device
having an HID, Windows will not detect the attached PS2 keyboard
and trackpad. Therefore, add the proper HID.
TEST: boot Windows on google/stout, observe PS2 keyboard and
trackpad detected and functional.
Change-Id: I61d7341c15483f8e1fe0e485a25591ceb92eaae1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
ToString() requires the input buffer data to be null-terminated,
but the data returned by the EC is not, leading Windows to fail
to report any battery data at all. Correct this by concatenating
a null terminator (0x00) to the end of the buffer data before
inputting to ToString() where needed
TEST: boot Windows on google/stout, observe battery data
reported correctly.
Change-Id: I974afcd6ff1c617301d0897d6bd1fe14200aa3b9
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
EC ACPI code is calculating the drain rate, but does not store it
in the battery status package before returning it. Correct this
omission, and set the drain rate to a preset minimum if calculated
value is less. Taken from vendor firmware ACPI dump.
Change-Id: I52837d5879112ab3103976bda28906fac8f880ec
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
me_cleaner now allows setting a bit in the PCH straps - AltMeDisable
tells the ME to stop execution after BUP - disabling the 30 minute
watchdog - but also "breaking" the ME. The ME reports opmode = 2.
This means the ME will not respond when we wait for an acknowledgement
about the DRAM being ready. The current code waits 5 seconds for a
response, that in this case, never comes.
If the ME is reporting opmode 2, don't delay or wait for a response
from the ME.
Tested on my X220, this patch fixed the five seconds before the payload
executed. Verified using the timestamp patch.
Change-Id: Ifdda6b2dbb8ae3a650be6d5df6c60475a3fa74aa
Signed-off-by: Nathaniel Roach <nroach44@gmail.com>
Reviewed-on: https://review.coreboot.org/21466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add find_fcba(), find_frba(), find_fmba(), find_fpsba()
and find_fmsba() to replace those copy-pasted addressings.
This commit is one separated from the original I6d05418c.
Change-Id: I98965711e4cb9792e5cc86cc4c1035559e0274f5
Signed-off-by: Bill XIE <persmule@gmail.com>
Reviewed-on: https://review.coreboot.org/21511
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Redesign some array-like structures as true arrays,
and rewrite functions to dump them as loops.
This commit is one separated from the original I6d05418c.
Change-Id: I161c9a2ae83d26e658d67d0804e943fff95fe076
Signed-off-by: Bill XIE <persmule@gmail.com>
Reviewed-on: https://review.coreboot.org/21510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There is no reason to keep a separate region_filenames array,
so I merge it into region_name(s).
This commit is one separated from the original I6d05418c.
Change-Id: I38489c6d3b3c161e9b0281188e6cdd0b62e38335
Signed-off-by: Bill XIE <persmule@gmail.com>
Reviewed-on: https://review.coreboot.org/21509
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Const-correct some functions which do not write back,
and use pointers to access existing region_t variables.
The last changeset is dismantled this time.
This commit is only focused on const-correctness.
Change-Id: I6d05418c8b32fa31dcd038a3e56f9aefe13fa9c4
Signed-off-by: Bill XIE <persmule@gmail.com>
Reviewed-on: https://review.coreboot.org/21288
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows the user to specify a custom path for cbmem on the DUT.
Change-Id: I2c28737d6efaae238fd6831cd3d00b2142b39a4c
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/21565
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
According to clang, main has no prototype for bcom/winnetp680
so add it into corresponding raminit.h
Change-Id: I8a55267901986757a4fa88ee13460ffbed3eeadc
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/21356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Add lens_focus property with reference to VCM device for OV13858
camera module to register the corresponding v4l2 sub-device
asynchronously.
BUG=b:64133998
BRANCH=none
TEST=Build and boot soraka. Dump DSDT and verified that it has the
required entries and verified the camera functionality.
Change-Id: Ib22403f668dd07d6b9226fe2c22b533223b69473
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/21512
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Set keyboard backlight to 75% on boot, except when resuming
from S3. This enables the backlight at a reasonable level
prior to the OS driver taking over, providing early proof-of-life
and enhanced usability in grub etc.
Uses same method as other google boards with a keyboard backlight
(chell, link, samus). 75% value determined based on user feedback.
TEST: boot google/lulu,gandof boards, observe keyboard backlight
enabled in pre-OS environment.
Change-Id: I7ed59289419af21764b1b5bd0a534d3b630c6c6b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Since the git:// protocol is unencrypted and unauthenticated, there's a
security risk associated with using it: A man-in-the-middle attacker
could replace e.g. the master branch with malicious code.
Mitigate this risk somewhat by cloning GRUB2 via HTTPS.
Change-Id: Ice8f8d108e7dfa1a1ecd58d9735944fa9570ace8
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/21344
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Add support for google/reks (Lenovo Chromebook N22/N42) as
a variant of the cyan Braswell basebaseboard.
- Add board-specific code as the new reks variant
- Add new I2C touchscreen device and SPD files to the baseboard
for potential reuse by other variants
Sourced from Chromium branch firmware-reks-7287.133.B,
commit 7d812d4: Revert "Revert "soc/intel/braswell: Populate NVS SCC BAR1""
Change-Id: Iac9e2b5661aa33e12927f4cb84ebaee36522a385
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/21128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Keith Hui