Mainboard is PAL60/LA-6562P (UMA). The version with an Nvidia dGPU was
not tested. I do not physically have this system; someone with physical
access to one sent me the output of autoport which I then modified to
produce this port. I was also sent the VBT binary, which was obtained
from `/sys/kernel/debug/dri/0/i915_vbt` while running version A08 of the
vendor firmware.
This was originally tested and found to be working as a standalone board
port in Libreboot, but this variant based port in upstream coreboot has
not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: Ibdd40cc15642b8d404159d5962670ccc4167a9ec
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The value used is not acceptable to BFD linker.
Change-Id: I0f134a96c596d69e10dd441b96184b119e9f1908
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84013
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows nvramcui to be build with clang.
Change-Id: I5e56ead81fc92b7ba4fb63a2c098b0e10b01ca53
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84010
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on autoport. data.vbt extracted from a running system
using "intelvbttool --inlegacy"
Like with 8200 SFF, OEM firmware write-protects itself, but not
the IFD, GBE or ME regions when FDO jumper is applied. Therefore,
ME can be shrunken with me_cleaner and BIOS region moved there.
Tested:
- Internal flashing from the latest endor BIOS (v2.33)
- Sandy Bridge Pentium G630 CPU
- RAM: 8+0, 8+4, 8+8 1866MHz DDR3
- SeaBIOS 1.16.2, metest86+ v6, coreinfo, nvramcui & tint payloads
- libgfxinit txtmode & corebootfb
- VGA, DisplayPort (DVI monitor through an adapter)
- Gigabit Ethernet
- All front and back USB ports
- Booting Void Linux
- Rebooting
- Mini-PCIe WLAN (PCIe)
- Both SATA ports: 2.5" & DVD
- PS/2 keyboard and mouse
- Fan control
- TPM settings in SeaBIOS
Untested:
- Second Mini-PCIe slot (or is it mSATA): connector not present on my unit
- MXM graphics
Not working:
S3: it sleeps for a few seconds and wakes up on its own
Change-Id: I1cba7a5e664758eba7ea2ab8a55658b307d1d173
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79583
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard is Krug 15". I do not physically have this system; someone
with physical access to one sent me the output of autoport which I then
modified to produce this port. I was also sent the VBT binary, which was
obtained from `/sys/kernel/debug/dri/0/i915_vbt` while running version
A14 of the vendor firmware.
This was originally tested and found to be working as a standalone
board port in Libreboot, but this variant based port in upstream
coreboot has not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: Ic9bfc028d4b8ae01ccc019157bb53e7764671134
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Mainboard is PAL50/LA-6591P (UMA). The version with an Nvidia dGPU was
not tested. I do not physically have this system; someone with physical
access to one sent me the output of autoport which I then modified to
produce this port. I was also sent the VBT binary, which was obtained
from `/sys/kernel/debug/dri/0/i915_vbt` while running version A25 of the
vendor firmware.
This was originally tested and found to be working as a standalone board
port in Libreboot, but this variant based port in upstream coreboot has
not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: Ic48d9ea58172a5b13958c8afebcb19c8929c4394
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82126
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mainboard is QXW10/LA-7902P (UMA). I do not physically have this board;
someone with physical access to one sent me the output of autoport which
I then modified to produce this port. I was also sent the VBT binary,
which was obtained from `/sys/kernel/debug/dri/0/i915_vbt` while running
version A21 of the vendor firmware.
This was originally tested and found to be working as a standalone board
port in Libreboot, but this variant based port in upstream coreboot has
not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
Change-Id: Idaf6618df70aa19d8e60b2263088737712dec5f0
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82125
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Mainboard is QALA0/LA-7761P (UMA). The version with a Nvidia dGPU was
not tested. I do not physically have this system; someone with physical
access to one sent me the output of autoport which I then modified to
produce this port.
I was also sent the vbios obtained using intel_bios_dumper while running
version A22 of the vendor firmware, which I then processed using
`intelvbttool --inoprom vbios.bin --outvbt data.vbt` to obtain data.vbt.
This was originally tested and found to be working as a standalone board
port in Libreboot, though this variant based port in upstream coreboot
has not been tested.
This can be internally flashed by sending a command to the EC, which
causes the EC to pull the FDO pin low and the firmware to skip setting
up any chipset based write protections [1]. The EC is the SMSC MEC5055,
which seems to be compatible with the existing MEC5035 code.
[1] https://gitlab.com/nic3-14159/dell-flash-unlock
Change-Id: I9fcd73416018574f8934962f92c8222d0101cb71
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79012
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Instead of using defines for command IDs and argument values, use enums
to provide more type safety. This also has the effect of moving the
command IDs to a more central location instead of defines spread out
throughout the header.
Change-Id: I788531e8b70e79541213853f177326d217235ef2
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Undefined behavior in unit-tests is no fun. assert_string_equal()
expects properly zero-terminated strings. None of the encoded test
strings contain a termination, hence add it manually.
Without this change, the test was often failing with a wrong error
message:
[==========] tests_lib_b64_decode-test(tests): Running 1 test(s).
[ RUN ] test_b64_decode
[ ERROR ] --- "AB" != "AB"
[ LINE ] --- tests/lib/b64_decode-test.c:38: error: Failure!
[ FAILED ] test_b64_decode
[==========] tests_lib_b64_decode-test(tests): 1 test(s) run.
Probably due to unprintable characters in the string. No idea why
my system is more susceptible to this issue.
Change-Id: Id1bd2c3ff06bc1d4e5aa21ddd0f1d5802540999d
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84088
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Reviewed-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a sandybridge-style devicetree setting for SPD addresses,
and use it instead of runtime code in mb_get_spd_map() for all
haswell boards without CONFIG(HAVE_SPD_IN_CBFS) - effectively all
boards except google/slippy.
Patch also covers recently added Z97 boards using Broadwell MRC.
Also update util/autoport to match.
abuild passes for all affected boards.
autoport builds, but otherwise untested.
Change-Id: I574aec9cb6a47c8aaf275ae06c7e1fb695534b34
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79025
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit aa6865291a.
Reason for revert: We applied this patch for touchpad stuttering issue
for XOl, but the same touchpad problem was reported. So we would revert
this change and apply kernel patch (crrev/c/5808335) to avoid the
touchpad issue.
Change-Id: I78139932e76dbd4128fb325dd70b7dcff3bcc81c
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
By default, any URL with a scheme of "http", "https", "ftp", or "mailto"
is treated as an external link. Since the "ircs" scheme is not included,
the IRC link in community/forums.md does not get resolved as an external
link, and instead tries to link to a header in the docs themselves. Fix
this by explicitly defining which schemes should resolve to external
links using the myst_url_schemes configuration option [1], which is now
set to the default schemes along with "ircs".
This fixes the "cross-reference target not found" warning for
'ircs://irc.libera.chat/#coreboot'
[1] https://myst-parser.readthedocs.io/en/latest/syntax/cross-referencing.html#customising-external-url-resolution
Change-Id: I9e1c76b2bacbacaa06340f940c76b50de38e43e8
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84069
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Turn off L2C SRAM and reconfigure as L2 cache:
Mediatek SoC uses part of the L2 cache as SRAM before DRAM is ready.
After DRAM is ready, we should invoke disable_l2c_sram to reconfigure
the L2C SRAM as L2 cache.
- Configure DMA buffer in DRAM:
Set DRAM DMA to be non-cacheable to load blob correctly.
TEST=build pass, register(disable_l2c) read ok
BUG=b:317009620
Change-Id: I6a3cb63d3418f085f5d8d08b282dd59ea431c294
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83925
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
To reduce duplicate pad_func of MediaTek SoCs, move the pad_fun to a
common directory.
TEST=Build pass
BUG=b:317009620
Change-Id: I145233ef887a38251e8fc129b8357f236c5f7a2b
Signed-off-by: Jarried Lin <jarried.lin@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83989
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
When the config of MCU firmware blob such as CONFIG_SPM_FIRMWARE is
non-empty, we should always expect the file to exist. Similarly, since
the device is unlikely to boot without the DRAM blob (assuming MRC_CACHE
doesn't contain valid memory training data), dram.elf should always
exist as well.
Therefore, remove the check for the existence of the blobs. Build would
fail if any of the blobs is missing.
Change-Id: I755e7c5a70b34b0c3d3915ab339c65263688aad7
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84053
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This will not succeed in compiling on all target and compiler
combinations but at least gets the ball rolling. The change is not
invasive.
Some notes:
- GCC has issues with LTO on ARM
- Clang uses LLD automatically on some arch
- Clang with LTO fails on x86 as it forwards the linking to GCC for some
reason
- SMM building succeeds but the binary is empty
Change-Id: Ieb9204777fd349542744a8946e2207731c37969c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84003
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add get_wifi_sar_cbfs_filename(). This function uses the FW_CONFIG
for WIFI_CATEGORY to choose the right wifi_sar hex file.
Below is the file mapping:
wifi_sar_0.hex = wifi6
wifi_sar_1.hex = wifi7
BUG=b:345596420
TEST=emerge-nissa coreboot chromeos-bootimage
Cq-Depend: chrome-internal:7607427
Change-Id: If8339a2a1d32d3e885ef87ea2ec2847f107f1fbd
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84051
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Sync checklist with release template; add new heading for paragraph
on pushing the signed tag to make it stand out.
Change-Id: Id49b3f38d3501382b7fb7ac791190c0cacd58a11
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84034
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These are the final release notes before the release is tagged. They
will be updated after the tag is in place with any differences,
including changing the "upcoming release" notice with the notice that
it has been released.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I449e8490d72976c8f723dc3b5ab3b77d7b16e3a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84046
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In preparation for the upcoming release, add the template for the
24.11 release and update index.md.
Change-Id: I1e524f1db0090bf8815b08315f9cbc9894965af7
Signed-off-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84036
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Iccmax of VccIn_Aux is 25A with MBVR design.
BUG=b:348258637
TEST=Local build successfully and boot to OS normally.
Change-Id: I59c420c03a8f01d185f616a2212798266b4251e0
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Reviewed-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
EE change GPP_C1 from pull-up to OD&no pull-up in PCH GPIO Table.
BUG=b:358472598
TEST=Build and verified test result by EE team
Change-Id: I84d1b42a39bebbcd610cebc46f979018fc79238f
Signed-off-by: Roger Wang <roger2.wang@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83904
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some targets cannot be supported by clang as clang generates slightly
larger binaries which the hardware won't accept. This is usually the
case with CONFIG_CHROMEOS.
Change-Id: I88cf8ce16fb6c61c19d615e396f5871179b06fc8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69747
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PCIE WLAN Bluetooth is on port8, need to correct USB port for PCIE WLAN
bluetooth companion device.
BUG=b:345596420
TEST=Build and test on nivviks, check BRDS is shown in SSDT.
Change-Id: I0908ff500434401bf89a5313427cf304f32cf929
Signed-off-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
