Disable unused USB devices in the device tree so that the concerned ACPI
objects do not get exported to the OS.
BUG=b:133513961
BRANCH=octopus
TEST=Boot to ChromeOS. Ensure that the USB devices are disabled based
on port status and the concerned ACPI objects are not exported.
Change-Id: I0faccdfb8a9df9ec52130437433b15973e3d6f1a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add devicetree configuration for USB devices so that USB Port
Capabilities (_UPC) and Physical Location of Device (_PLD) ACPI objects
can be exported to the OS.
BUG=b:133513961
BRANCH=octopus
TEST=Boot to ChromeOS. Ensure that the _UPC & _PLD ACPI objects are
exported for the configured USB devices in the SSDT table.
Change-Id: I832ffe305d256296b7447035c5e5dcafb7c296d9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add API to disable USB devices that are not present but are configured
in the device tree either after probing the concerned port status or as
explicitly configured by the variants.
BUG=None
BRANCH=octopus
TEST=Boot to ChromeOS.
Change-Id: Ied12faabee1b8c096f2b27de89ab42ee8be5d94d
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33377
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It feels appropriate to define SoC specific XHCI USB info in SoC
specific XHCI source file and an API to get that information instead of
defining it in elog source file. This will help in other situations
where the information is required.
BUG=None
BRANCH=None
TEST=Boot to ChromeOS.
Change-Id: Ie63a29a7096bfcaab87baaae947b786ab2345ed1
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34290
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch lists all supported vesa mode by oprom
using Function 0x4F00 (return vbe controller information).
This information might be useful for user to select correct vesa
mode for oprom.
TEST=Enabling external pcie based graphics card on ICLRVP
Case 1: with unsupported vesa mode 0x118
Now coreboot will show below msg to user to know there is a potential
issue with choosen vesa mode and better users know the failure rather
going to depthcharge and debug further.
Calling Option ROM...
... Option ROM returned.
VBE: Getting information about VESA mode 4118
VBE: Function call invalid with unsupported video mode 0x118!
User to select mode from below list -
Supported Video Mode list for OpRom are:
0x110
0x111
0x113
0x114
0x116
0x117
0x119
0x11a
0x165
0x166
0x121
0x122
0x123
0x124
0x145
0x146
0x175
0x176
0x1d2
0x1d4
Error: In vbe_get_mode_info function
Case 2: with supported vesa mode 0x116
Calling Option ROM...
... Option ROM returned.
VBE: Getting information about VESA mode 4116
VBE: resolution: 1024x768@16
VBE: framebuffer: a0000000
VBE: Setting VESA mode 4116
VGA Option ROM was run
Change-Id: I02cba44374bc50ec3ec2819c97b6f5027c58387f
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34284
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When generating entries in SSDT for DesignWare I2C controllers, only
use the speed selected in the devicetree, instead of trying all of them.
This quiets a message which looks like a bug ("dw_i2c: bad counts"),
later on in this driver when checking rise/fall times.
BUG=b:137298661
BRANCH=none
TEST=Boot and verify that I2C controllers still function, and
the nastygram message is gone.
Change-Id: I07207ec95652e8af1a42bfe31214f61a183a134e
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34385
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We would like to wake nocturne up in suspend from an MKBP event. On
Nocturne, MKBP events are notified to the host via a GPIO from the EC,
EC_INT_L. However, the AP cannot wake from suspend from this GPIO.
Therefore, we'll use the host event interface to wake the system
instead.
This commit simply enables MKBP events to wake the system in suspend.
BUG=chromium:786721
BRANCH=firmware-nocturne-10984.B
TEST=Build and flash nocturne, generate MKBP events on the EC and verify
that the system wakes up in suspend.
Change-Id: I6aff4d38051c939257533229fd0085e42c01d02f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Since they're in charge of enforcing it, they should also get to see
when somebody attempts to change it.
Change-Id: I8c12dd0c27f7c3661e9755a5181db08563c8561f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Marc found more interesting things to do (yay, Marc!) and Martin
offered to volunteer on the arbitration board in his place.
Change-Id: Ic5bf00735afdf8942e543043238890011a82c890
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The paragraph starts talking about community organizers. By making
their definition a separate paragraph it's hopefully easier to find
what this means.
Change-Id: Icb9abbbd05b59bd4ee741d10f4c9c1a8c321b430
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Make it a separate section, emphasize that people should get support
early, note that personal interaction and email are the two best
ways to seek help.
Change-Id: I8cb613fefe1a7b4db1ee948fb9927a38f0421011
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
The processor P_BLK doesn't support throttling. This behaviour could be
emulated with SMM, but instead just update the FADT to indicate no support
for legacy I/O based throttling using P_CNT.
We have _PTC defined in SSDT, which should be used in favour of P_CNT by
ACPI aware OS, so this change has no effect on modern OS.
Drop all occurences of p_cnt_throttling_supported and update autoport
to not generate it any more.
Change-Id: Iaf82518d5114d6de7cef01dca2d3087eea8ff927
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
"Always assume" is rather final and (in some readings) invalidates the
need for the rest of the text.
Change-Id: Ibf6f776494367d012ce69a64fa928c1dd4206c0e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
run_rom->data is a uint16_t, so use the appropriate read function.
Change-Id: Icc14421412885495df90c90ed7da6e7d2eba4182
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1402145
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34372
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This bit shift attempts to set bits 8 and 9 of the byte variable (counting
from 0). However, as the name suggests, this variable is only 8 bits
wide, so the shift does nothing. Reading section 7.5 of the
AMD SB800-Series Southbridges Register Programming Requirements manual,
bits 8 and 9 are already set by default, so we can remove the bit shift.
(Alternatively, we could try setting the corresponding bits one byte
higher in 0xF1 if needed.)
Change-Id: I645236441e02925ee01339378d213cb343027363
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1229582
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
- Use log2() when rounding down size_mb to the closest power of 2.
Do a sanity check beforehand that size_mb is nonzero, else log2()
will return -1 and there will be an undefined integer shift.
- The framebuffer size needs to be between 8 and 512 MiB, so check
after all the calculations are done to make sure this is the case.
Change-Id: I3962e5cdc094c8da22d8dbadf16637e02fa98689
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1391086
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Implicit fall throughs are a perpetual source of bugs and Coverity Scan
issues, so let's squash them once and for all. GCC can flag implicit fall
throughs using the -Wimplicit-fallthrough warning, and this should
ensure no more enter the code base. However, many fall throughs are
intentional, and we can use the following comment style to have GCC
suppress the warning.
switch (x) {
case 1:
y += 1;
/* fall through */
case 2:
y += 2;
/* fall through - but this time with an explanation */
default:
y += 3;
}
This patch adds comments for all remaining intentional fall throughs,
and tweaks some existing fall through comments to fit the syntax that
GCC expects.
Change-Id: I1d75637a434a955a58d166ad203e49620d7395ed
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
This switch was likely copy-pasted from the one right above it. However,
the MEM_CLOCK_800MHz case isn't needed, since that is explicitly checked
and avoided before the while loop. With that gone, only the
667MHz/default case is left, which we don't need to switch over anymore.
Change-Id: Idfb9cc27dd8718f627d15ba92a9c74c51c2c1c2d
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1347372
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33407
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add function tlcl_getcapability() to return TPM2 capability.
To support TPM2 capability TPM_CAP_PCRS handling is added to
unmarshal_get_capability().
BUG=N/A
TEST=Build binary and verified logging on Facebook FBG-1701
Change-Id: I85e1bd2822aa6e7fd95ff2b9faa25cf183e6de37
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch configures GPIO pin GPP_G7 as NF1 with internal pull down.
As per schematics SD host controller SD_WP pin is not connected to
uSD card connector. Configured gpio pin as NF1 with internal pull down
in order to overcome gpio default state in hatch which makes SoC
SD_WP pin is enable.
BUG=b:137729527
BRANCH=None
TEST=Able to write/read data to/from sd card after mounting card device.
Change-Id: I0187267670e1dea3e1d5e83d0b29967714d6065e
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34396
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Following changes are done to enable ALC1011 codec on Helios
1. ACL1011 4 devices to I2C4
2. GPIO H13 is set to GPO as per schematics
Verified SSDT table and i2cdetect from kernel.
Signed-off-by: Naveen Manohar <naveen.m@intel.com>
Change-Id: I0d71e3bd2d4493d059a33023c1afe1b630181d4f
Signed-off-by: Sathya Prakash M R <sathya.prakash.m.r@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33932
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The BBST() method writes an updated status flag mask that is intended
to be stored back in the battery object. This value needs to be
passed as a reference to an object to prevent it from being evaluated
at the time the method is loaded or it will not actually update the
BSTP value in the battery device.
This was tested by instrumenting the _BST method in the primary
battery and ensuring the value can be updated by the BBST method.
Change-Id: Ia8e207a2990059a60d96d8e0f3ed3c16a55c50f4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Add changes needed to build a project using Merlin Falcon SOC using 00670F00
vendor code, which is backward compatible with Merlin Falcon. Only the AGESA
binary image is different then the one used by 00670F00.
BUG=none.
TEST=Tested later with padmelon board.
Change-Id: Id3341f6a1ef2561a6391d3db8c54f6bdd09b0c0e
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Existing coreboot oprom implementation relies on user selected
vesa mode through CONFIG_FRAMEBUFFER_VESA_MODE Kconfig option
and expects that all oprom might support user selected vesa mode.
Take an example:
Enabling AMD external radeon PCIE graphics card on ICLRVP with
default vesa mode 0x118. Unable to get valid X and Y resolution
after executing vbe_get_mode_info() with 0x4118, return data
buffer shows 0x0 resolution. It causes further hang while trying
to draw bmpblk image at depthcharge.
This patch checks for output register AH in all vbe function
(0x3 and 0x4f00/1/2) and die() if returns error.
Change-Id: Iacd2ce468e038a14424f029df3a0adec3e5fa15c
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This change provides an implementation of variant_memory_sku() for
helios that overrides memory ID 3 and 4 to 0 and 1 to workaround the
incorrect memory straps in hardware for board id 0 and unknown.
BUG=b:133455595
Change-Id: I38fab1f91decac5d0a146e5a6c74e88f677af305
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
This change adds support for variant_memory_sku() that allows variant
to return memory SKU ID. Current implementation of memory_sku() is
renamed to weak implementation of variant_memory_sku(). Functionally
this change should be the same as before for all hatch variants. This
function will be overriden by helios in a follow-up CL.
BUG=b:133455595
Change-Id: I509c263ec08e0060c12ef1ea9fed673f1e3f3a41
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Read the northbridge BARs from device PCI0:0.0.
Untested.
Change-Id: I27bfb5721d9ae3dc5629942ebac29b12a7308441
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Autoport generates these structures as static so let's make it consistent.
See also commit 128205fd with Change-Id
I83382d38a4a3b7ed11b8e7077cc5fbe154e261a7 ("autoport/bd82x6x.go: Improve
gpio.c generation").
Change-Id: I4e07bd755ca4a65b76c69625d235a879fe7b43cb
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33524
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Here, vga_disable stored but we read it only if MAINBOARD_DO_NATIVE_VGA_INIT.
Found-by: scan-build 7.0.1-8
Change-Id: I5c359df71568b56f48eca9615c6265da33d4a073
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34331
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Correct all GPIOs with reference to the Apollo Lake SoC EDS Vol 4
revision 2.4 chapter 10.1.2.3 List of Pins that are GPIOs but cannot be
used in Function 0 (GPIO) mode.
In additional, set an internal pull to any GPI that does not have an
external resistor so that the input is not in an undefined state.
Change-Id: Ia8fe457eddbed0f4ee6bff9ef9dd7a92545be40b
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Uwe Poeche <uwe.poeche@siemens.com>
The limitation for SD-Card was originally only made for mc_apl2
mainboard. Since other mc_apl mainboards also use the SD-Card interface,
the speed mode setting is made in the parent mainboard_final.
In additional, all UHS-I bus speed modes are disabled because of a
limitation for industry use cases. This means that only HS mode is
permitted.
Change-Id: I2f1b51f13a53c2507c52d6a169d6384b8570b3bc
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34377
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This patch makes VGPIO_3 GPIO PIN output and low independent of
cnvi is connected or not.
BUG=b:123062346
BRANCH=None
TEST=boot up Hatch device and make sure VGPIO_3 gpio pin is driven low.
Change-Id: I629b99676f56747de1b244724709e14069250097
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34376
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Taken from
"Intel 6 Series Chipset and Intel C200 Series Chipset"
Document Number: 324645-006 and
"Intel 5 Series Chipset and Intel 3400 Series Chipset"
Document Number: 322169-004 and
"Intel 6 Series Chipset"
Document Number: 324645-001.
UPDCR was found in GNU/Linux's drivers/pci/quirks.c.
DMC2 was guessed as it's close to DMC and defined for 5 series chipset.
Test:
Run BUILD_TIMELESS=1 and compared the coreboot.roms, no differences.
Change-Id: I4fed7c38078cabd4308424c7547416e87c9e6fa7
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This CL allows that everyone can use main() in lib/bootblock.c
even if you select CONFIG_BOOTBLOCK_CUSTOM. I also rename main
functions used in some soc/ to avoid the collision with the
main function defined at lib/bootblock.c.
Change-Id: I0575c9d1ce9dea9facfcc86760dff4deee9c1e29
Signed-off-by: Asami Doi <d0iasm.pub@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34250
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GCFC (Graphics Clock Frequency Control) read is not used at
the line below.
As the default value is zero, let's remove unused read.
Found-by: scan-build 7.0.1-8
Change-Id: I82c567e3a5b0c0c4a8596ea0cb7693667c71b720
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34329
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The code currently checks that 4 <= dev_index <= 10, which after
subtraction by 4 can index into an array of length at most 7. This is
fine for the largest cpl array (which does have length 7), but is
too large for some of the others, which are smaller. This adds bounds
checks for each array access to ensure they are all within bounds.
Change-Id: I1610d35ca6cbb6cfb42c251e75b0e8b22b64252b
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1229676
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Only needed in ramstage, and only for MP tables.
Change-Id: Ia7c1e153b948aeefa4c3bea4920b02a91a417096
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33922
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Makefile.inc allows extending site-specific configurations.
This change is to allow make utility to list supported options,
irrespective of a .config file availability.
Change-Id: I7c968c773c368ea74689b9741c4c978c35110187
Signed-off-by: Balaji Manigandan B <balaji.manigandan@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The speed argument should be one of the six values from the mem_clock
enum, so something is very wrong if this is not the case. Better to
die now than return 0, which will cause a division-by-zero error
later on where this function is called. The first two speeds are also
unsupported and have the same problem with returning 0, so die on those
as well.
Change-Id: Ib628c0eed3d6571bdde1df27ae213ca0691ec256
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1391088
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33409
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the decoded SPD DRAM frequency is slower than the controller minimum,
then there will be an unsigned integer underflow in the following loop,
which will lead to a very large out of bounds array access. Ensure this
does not happen.
Change-Id: Ic8ed1293adfe0866781bd638323977abd110777e
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1229675
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Karthikeyan Ramasubramanian