Change-Id: I15cfbbab15b940641c3952f2cfb4b11c37574816
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/c/29299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When building coreboot from scratch with 'make -j4', I sometimes see
this error:
CREATE build/mainboard/emulation/qemu-riscv/cbfs-file.wblRgZ.out (from /.../coreboot/.config)
HOSTCC cbfstool/cbfstool (link)
make[1]: execvp: build/util/kconfig/conf: Permission denied
make[1]: *** [/.../coreboot/util/kconfig/Makefile:92: savedefconfig] Error 127
It happens, I think, because the rule generated by
cbfs-files-processor-defconfig runs 'make savedefconfig', which builds
build/util/kconfig/conf, and something also builds it, at the same time.
Fix this case, by making this rule depend on $(objutil)/kconfig/conf.
The same fix is also precautiously applied to the rule for
$(KCONFIG_AUTOHEADER) in Makefile.
Change-Id: Ie93eda567f88ca08c97df7e70cdff5b07442747d
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/c/29984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Disable SATA port 0 and port 1 as that's not used as SATA on platform.
BUG=N/A
TEST=Build and boot up fine on google arcada board.
Change-Id: I1b8801f7a0f9b7847b85d7c315fa0a2093b32f70
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/30091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Roy Mingi Park <roy.mingi.park@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
There are 2 vendor BIOS's for the Lenovo X200 with the difference being the
settings in the VBT blob to accommodate different backlight frequencies.
Linux however sticks with the setting set by the firmware.
Tested on Lenovo X200 with CCFL backlight.
Change-Id: I4c4a7011ce03cdd511fa2e2160c2f006ba2707ba
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/29904
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not just for the mailing lists, tools and IRC channel.
Change-Id: I23883cfd8200496f4281d73b6e75fac0d3448a3c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It's not very helpful to tell somebody who feels wronged "that their
mail was probably lost" (in just as many words).
State why we don't go for a mailing list or ticket system for grievances
and encourage contact multiple people from the outset.
Change-Id: Idac4bcdf8b596a7325e463036c580b17a8b2f27b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I reordered the contacts by current activity and added a link to the
CC-BY-SA license, otherwise it's the original text.
Change-Id: I6f41611db8d9a2f60b24d95abdf30f4fd47cd6f2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30085
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's originally written by Martin who graciously allowed to me rework it
a bit and push it into coreboot's documentation.
Change-Id: I14938d678e4620abec7ed5f0d35dddaf00edda6d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/30082
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PEN_EJECT GPIOs are active high and also require an internal pull-up.
Update the GPIO configuration appropriately.
BRANCH=octopus
BUG=b:117953118
TEST=Ensure that the system boots to ChromeOS. Ensure that the stylus
tools open on pen eject. Ensure that the system can enter S0ix and S3
states successfully when the pen is inserted. Ensure that the system
wakes on Pen Eject. Ensure that the system does not enter S0ix and S3
states when the pen is placed in its holder. Ensure that the
suspend_stress_test runs successfully for 25 iterations with the pen
placed in its holder.
Change-Id: Ibf9cb214a8ce7561efbb77a7e99d1e386cf064c3
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/30107
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add mechanism to configure GPE wake event which in turn can be used as ACPI
Power Resources for Wake
BRANCH=octopus
BUG=b:117953118
TEST=Ensure that the wake GPE event is added to ACPI Power Resource for
Wake.
Change-Id: Iacc12b8636aaac98a8689a211cbe1dcfe306f342
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/30106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Update the GPIOs for the next board build. Mostly minor changes but
the polarity change on GPP_E8/RECOVERY on sarien will result in it
booting to recovery every time unless using new hardware.
For this reason the recovery mode GPIO that is passed to vboot is
commented out for sarien. It is only used for testing and currently
it is useful to have an image that works on both board versions.
Change-Id: I32d84f3010cb4d3968370a03f7e191b1710a50e8
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30062
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently CoffeeLake FSP is incorrectly modifying GPIO pad configuration
if specific UPD variables are not set as it expects.
This affects the display-related SOC pads with the following UPD variables:
UINT8 DdiPortBHpd; // GPP_E13
UINT8 DdiPortCHpd; // GPP_E14
UINT8 DdiPortDHpd; // GPP_E15
UINT8 DdiPortFHpd; // GPP_E16
UINT8 DdiPortBDdc; // GPP_E18/GPP_E19
UINT8 DdiPortCDdc; // GPP_E20/GPP_E21
UINT8 DdiPortDDdc; // GPP_E22/GPP_E23
UINT8 DdiPortFDdc; // GPP_H16/GPP_H17
Until FSP is fixed to not touch the pad configuration this workaround
will reprogram the GPIO settings after FSP-S step so they are correct
when the OS attempts to use them.
This was found in CoffeLake FSP Gold release:
https://github.com/IntelFsp/FSP/tree/master/CoffeeLakeFspBinPkg
As well as the current top-of-tree for the FSP sources.
BUG=b:120686247,chromium:913216
TEST=verify correct GPIO configuration for GPP_E group in the kernel
Change-Id: I19550c4347cf65d409de6a8638619270372c4d0a
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The kernel GPIO driver only expects some GPIO communities to be exported
in the _CRS and it will not work correctly if the other communities are
exported.
CNL-LP: GPIO communities 0, 1, 4
CNL-H: GPIO communities 0, 1, 3, 4
Additionally one of the pin offset values was incorrect in GPIO
community 1 for CNL-LP. This doesn't have any specific failure mode but
it was found when auditing the GPIO code.
Details of the kernel expected map can be found in the linux kernel at
drivers/pinctrl/intel/pinctrl-cannonlake.c
BUG=b:120686247
TEST=check /sys/kernel/debug/pinctrl/INT34BB:00/pins to ensure that
pins >= 198 are not reading all zeros for the pin config registers.
Change-Id: Ie1a2f3b9f9f4b24a9fc57e468dee50e99753912f
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Synaptics Trackpad wake event is incorrectly routed to GPE0_DW2_02. The
concerned GPIO is not connected and hence wont trigger a wakeup. Fix the
GPE wake configuration for synaptics trackpad.
BUG=b:120666158
BRANCH=octopus
TEST=Ensure that the wake on trackpad works with Synaptics touch pad.
Ensure that the system can enter S0ix successfully(run
suspend_stress_test -c 25).
Change-Id: I87b8c266266280f61700839d428e6f8938b0f72f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/30105
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
console->scroll_up() was hanging when console->rows is 0. This
was happening on delan if no screen was attached. If there are no
rows, just return.
BUG=b:119234919
TEST=Boot delan with no flat panel. System boots to OS
Change-Id: Ib022d3c6fc0c9cf360809dca28761a50c787304a
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/c/30092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
FSP defined a special clock source usage 0x70 for PCH LAN device, update
that to google sarien platform.
BUG=b:120003760
TEST=Boot up into OS, ethernet able to be listed in ifconfig.
Change-Id: I9f945be4f0ce15470ab53f44e60143f3fd0fddf8
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/c/30100
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Part Number
Correct Ram_ID=0b0011 SPD Module Part Number to "MT40A1G16KNR-075:E" from
"4ATS1G64HZ-2G6E1".
BUG=b:120000816
BRANCH=master
TEST=mosys memory spd print all
Change-Id: I9d582b3753de9a48865eb6eca7e4fbdb31b799ff
Signed-off-by: Lucas Chen <lucas.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/30049
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Number
Correct Ram_ID=0b0000 SPD Module Part Number to "H5AN8G6NAFR-UH" from
"HMA851S6AFR6N-UH".
BUG=b:120000816
BRANCH=master
TEST=mosys memory spd print all
Change-Id: I1f6e885638589a35334a9a8f905af4877c5d1f91
Signed-off-by: Lucas Chen <lucas.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/30048
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Part Number
Correct Ram_ID=0b0010 SPD Module Part Number to "MT40A512M16JY-083E:B"
from "4ATF51264HZ-2G3B2".
BUG=b:120000816
BRANCH=master
TEST=mosys memory spd print all
Change-Id: I6847a55968260cdbc1588ddeb8d23c515ad87920
Signed-off-by: Lucas Chen <lucas.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/30050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The Intel Sensor Hub was enabled on the wrong variant so this change
moves the enable from sarien to arcada.
Change-Id: If933623f7dbb45c4805fb61430465236eca19ee8
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
A new liara specific VBIOS updating eDP power sequence is available now,
Change Kconfig to use it if board is google liara.
BUG=b:120534087
TEST=Build liara, booted, tested eDP test compliance.
Change-Id: I444cfa0bd755480e006f11c0d692b25b96129c29
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/c/30090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
A liara specific VBIOS was released and merged to blobs. Now coreboot
need to point to the updated blob, so it can use liara specific VBIOS.
Liara Chromebook Stoney VBIOS BRT39865
BRT39865.001 12/05/18,01:13:54 CL#1716128 @ 15.49.0.18 ATOMBuild#436504
Major Changes included:
1. First Stoney VBIOS released to Liara update eDP power up sequence.
BUG=b:120534087
TEST=none
Change-Id: I3b060b1ccfb311584afd0fb66258eb7cc942408d
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/c/30089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Recently there has been a change to print ME version. But the stage at
which the version is printed causes the HECI device to remain in D0 state.
This in turn prevents the SoC from entering S0ix state.
This change moves printing ME version a little earlier so that the HECI
device is put into D0i3 state by FSP and the SoC can enter S0ix state
successfully.
BRANCH=octopus
BUG=b:120571529
TEST=Ensure that the ME version gets printed in BIOS logs. Ensure that
the device boots to ChromeOS. Ensure that the device enters S0ix
successfully(using suspend_stress_test -c 25).
Change-Id: I85bc45003a040c8347f929457792d78a9a077c6c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/30074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Use CONFIG_CPU_MAX which defaults to 1 instead of CONFIG_RISCV_HART_NUM.
The default value of CONFIG_RISCV_HART_NUM was 0 and cause a jump to address 0.
Add a die() call to fail gracefully.
Change-Id: I4e3aa09b787ae0f26a4aae375f4e5fcd745a0a1e
Signed-off-by: Philipp Hug <philipp@hug.cx>
Reviewed-on: https://review.coreboot.org/c/29993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Xiang Wang <wxjstz@126.com>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Correct a build error that occurs when HUDSON_UART is selected.
Replace sizeof() of a nonexistent variable with the intended type.
This was introduced in
bd48b23 "southbridge//hudson: Get rid of void pointer math".
BUG=b:118484178
TEST=Build Bettong with Chipset/"UART controller for Kern"
Change-Id: Icc0ff9d80c3f5cab9ab837cf1cd0cd8eb0753284
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The code annotated by the comment is dealing with root port 7, so update
the comment to reflect that. It looks like the comment was copied from
the root port 3 case, but not updated.
Change-Id: I0e27e4453f4c3b2b1b9dffb0c89b71373c6b303e
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/c/30078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The code is based on autoport and that for T430s
Tested:
- CPU i5-3337U
- Slotted DIMM 2GiB
- Soldered RAM 4GiB from samsung (There may be more models here)
- Camera
- pci-e and usb2 on M.2 slot with A key for wlan
- sata and usb2 (no superspeed components) on M.2 slot with B key for wwan
- On board SDHCI connected to pci-e
- USB3 ports
- libgfxinit-based graphic init
- NVRAM options for North and South bridges
- Sound
- Thinkpad EC
- S3
- TPM1 on LPC
- EHCI debug on SSP2 (USB3 port on the left)
- Linux 4.9.110-3 within Debian GNU/Linux stable, loaded from
Linux payload (Heads), Seabios may also work.
Not tested:
- Fingerprint reader on USB2 (not present on mine)
- Keyboard backlight (not present on mine)
- "sticky_fn" flag in nvram
Not implemented yet:
- Fn locking in nvram (may not be identical to "sticky_fn")
- C-based native graphic init (since T431s has eDP instead of LVDS)
- Detecting the model of Soldered RAM at runtime, and loading the
corresponding SPD datum (3 observed) from CBFS (the mechanism may be
similar to that on x1_carbon_gen1 and s230u, but I do not know how
to find gpio ports for that, and SPD data stored in vendor firmware.)
Change-Id: Ic8062cacf5e8232405bb5757e1b1d063541f354a
Signed-off-by: Bill XIE <persmule@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Provide rise/fall times as measured on existing boards. This will
need adjusted for new boards but provides a starting point that
makes I2C clocks look reasonable.
Tested by measuring I2C bus speed and rise/fall times with a scope.
Change-Id: Ic18010f5efc41dcee8925d696767ba2c44e3df4b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Add an entry to the soc_clock table for a 216MHz clock so that
the I2C controller clock is calculated correctly when the I2C
bus is used in coreboot.
This was tested by measuring the I2C clock speed on H1 I2C bus
on a sarien board in coreboot and ensuring it is ~400KHz.
Change-Id: I6c3cacdad318a5ce41bc41e3ac81385c2d4f396c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The input clock for the I2C controllers was set at 133MHz but should
really be 216MHz according to the kernel:
https://patchwork.kernel.org/patch/10408729/
"Intel Cannon Lake PCH has much higher 216 MHz input clock to LPSS I2C
than Sunrisepoint which uses 120 MHz. Preliminary information was that
both share the same clock rate but actual silicon implements elevated
rate for better support for 3.4 MHz high-speed I2C."
This change was tested on a sarien board where an I2C trackpad that was
measuring ~700MHz on I2C and is now measuring ~380MHz.
Change-Id: I792d1f013da5538a2b8157e2f99b754ca7b6bf70
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/30061
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As part of the memory mapped BIOS region is covered by SRAM, check
that CBFS always fits the effectively mapped region of flash. This
is usually taken care of by reserving the SRAM range in the FMAP
(e.g. as BIOS_UNUSABLE), but can be missed.
Change-Id: If5a5b553ad4853723bf13349c809c4f6154aa5f2
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/30055
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Re-write the UAO handling code as it had stopped working (#171)
(the flag was not getting read from the RTC properly in SMM)
Remove the SMM code as it's not needed (but EC flag won't be set
upon entering S3 now)
Set the EC flags on boot the same way other flags are set
Document bitwise operators for clarity
Propagate changes to other Thinkpads
(updated X201 to have 2 bits for the flag as it only had 1)
Per Nicola Corna's previous commits, 0x0d is set for "AC only"
"AC only" does exhibit different behaviour - the USB port is
turned on a few seconds after entering S3, rather than < 1 sec,
regardless of AC status
Tested on X220
Change-Id: If812cd1ef8fb1a24d7fadbe834f574b40cbcd56a
Signed-off-by: Nathaniel Roach <nroach44@gmail.com>
Reviewed-on: https://review.coreboot.org/c/29565
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested - Lenovo t520 still builds fine with this patch.
Change-Id: I82492c071ca760f0790b992acbdb86021f470cfe
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Fix some compiler warnings due to pointer to integer conversions
with different size.
Required for 64bit ramstage.
Change-Id: Ibfb3cacf25adfb4a242d38e4ea290fdc3929a684
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/29875
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The gerrit docs aren't very explicit about it, but file:"^foo$" is more
robust than file:^foo$.
Change-Id: I16c7d972d365cd04ca5fbb78012ad4eaad667be6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/29781
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I fried my mainboard because I tried to orient my chip by lining a blue dot on
the corner of my chip with a dot depicted on the chip datasheet. They
apparently have nothing to do with each other, and this is normal. Add
warning about this to the docs to hopefully spare others from a similar fate.
Signed-off-by: Michael Bacarella <michael.bacarella@gmail.com>
Change-Id: Ib634589aaa11f75bde2ef2e13d2cacc4cae19a3f
Signed-off-by: Michael Bacarella <michael.bacarella@gmail.com>
Reviewed-on: https://review.coreboot.org/c/30028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
T Michael Turney